RoboPaint drawing just stops

Paul Williamson

Initial build and test of the WaterColorBot went smoothly, up until I tried to print one of the example images built into RoboPaint. For example, the one called "still life". When I click Start it washes the brush and begins to paint with yellow. It successfully paints the highlight on the apple and most (all?) of the yellow dots on the orange. And then ... it just stops. The "Status" area in the "Auto-paint" box in RoboPaint says "Drawing path svg_24 fill..." when it stops, and it just keeps on saying that forever. There is never any error message. The USB LED on the EBB is blinking alternate short and long pulses. If I push the "Pause" button at this point, it appears to start the drawing over from the beginning, and again stops in the same place. This seems quite repeatable.

For another example, if I try the "mono lisa" example, it paints a couple of lines of orange, then moves the brush to a different location (where there isn't any orange I can see in the image) and then ... just stops. This time the Status is "Drawing path svg_61 fill...", but clicking the Pause button doesn't do anything. In fact, all of the in-window controls seem to be unresponsive.

I don't see anybody else reporting similar lock-ups on the forum or elsewhere on the net. What should I look for to debug this?

Bot S/N 0094. EBB board v2.3. RoboPaint says 0.7.0 on the main screen and Version 27.0.1430.0 (1430.0) on the About dialog. Running on a MacBook Air under Mac OS X 10.9.2, with the EBB plugged directly into the Air's USB port (no hub).

Thanks!

Windell Oskay

Hi Paul,

I'm sorry to hear about the trouble.  I'll ask the author of Robopaint to check in on this.  But, I'm also wondering if there could be a hardware problem at the root. Have you tried using RoboPaint RT or the Inkscape extensions for WaterColorBot?  If there's a hardware problem (an intermittent disconnect), I would expect it to show up there as well.

Secondly, we will likely have a new beta release of RoboPaint out in a few days, which might be able to help shed some light on the issue. (Or perhaps, even fix it.)

Paul Williamson

Thanks, Windell.

I have messed around briefly with RoboPaint RT, and it seems to work. However, the small number of operations I've done in RoboPaint RT doesn't mean much. The auto-paint function in RoboPaint does a lot more operations.

The fact that it's always failing at the same place in the auto-paint playback suggests it's not a simple intermittent.

I haven't tried the Inkscape extensions yet. I'll do that soon.

Paul Williamson

EBB firmware version:

EBBv13_and_above EB Firmware Version 2.0.1

That's not the latest, I don't think. What EBB firmware version is currently best for WaterColorBot?

Windell Oskay

Is that the firmware that came with your WaterColorBot?  (If so, what color is the EBB?)

Paul Williamson

Yes, that's the version that came with it. The EBB board is white with black printing.

Windell Oskay

Thanks-- there are some newer versions, but we would would recommend sticking with the version that it came with for the time being.  At some point in the future there will be a real "recommended" update, but for the time being, the original will give the best compatibility with the software.

Paul Williamson

I just printed a very complicated drawing using Inkscape extensions, with no problem.

Windell Oskay

That certainly suggests that it's a bug in Robopaint, not a hardware or firmware issue.  (Is that good news?) We should have that new version of Robopaint for you to try in the next day or two. 

Windell Oskay

The new version of RoboPaint, version 0.7.5 has now been posted. Would you please give it a try?

https://github.com/evil-mad/robopaint/releases/tag/v0.7.5-2014.03.08

Paul Williamson

RoboPaint 0.7.5 still misbehaves in similar ways on my WaterColorBot.

The Still Life example is no longer provided, so I can't re-test it.

On the Mona Lisa sample, it still does exactly the same amount of successful painting as before, and still locks up with "Drawing path svg_61 fill..." in the status area. However, the Pause button is no longer unresponsive -- instead, it restarts the painting, like it used to do on the Still Life example. The new Cancel Print not-quite-a-button does work, which is good, except that somehow it fails to get exactly back to the home position. All the above observations held for several repeats, and then it went back to the old behavior, with all the on-screen interactions unresponsive.

Speaking of the Cancel Print not-quite-a-button ... the dialog for this has buttons "Cancel" and "OK", and one is expected to hit "OK" if he wants to cancel and "Cancel" if he doesn't want to cancel. That is just bad.

Oddly, the version number shown in the About dialog and in the Finder is still exactly the same as it was before. Only the (completely different) on-screen version number has been updated.

Windell Oskay

Hi Paul,

Thank you so much for giving that a try, and I am sorry that it was not much better of an experience.  It sounds like 0.7.5 is a mixed blessing in terms of interface, and additionally does not fix the main issue.  Version 0.7.5 is still "pre-release" and I think that we still have some work to do before we can give it an "official release."

Question: When you cancel a painting, and you say that it "fails to get exactly back to the home position," does it go home when you press the "Park Home" button, or is it genuinely losing position?  (Perhaps obvious, but these kinds of tests can be run without a brush in the machine, so that you're not wasting paint or paper.)

Version 0.7.5 has a new feature that may help us get to the bottom of the responsiveness issue. When you open up RoboPaint, please press Ctrl-Shift-D to open up the dev tools window. There, click on the "console" tab which will log what's going on behind the scenes.  Is there anything different that happens when the interface becomes unrepsonsive?

We are aware of -- and I am also not happy about -- the version number issue. ( https://github.com/evil-mad/robopaint/issues/113 )  Perhaps we could title the app something like "RoboPaint 0.7.5.app" to skirt the issue.