Machine sometimes drives into the wall upon quitting RoboPaint

[oskay]

Not sure why this is-- quitting the application sometimes appears to issue a command that drives the robot into the wall, for quite a distance.

[techninja]

...WEIRD! I doubt the issue is in CNCServer.. I suspect this has to do with closing from a mode after sending commands/moving? The mode may be trying to send something. See if you can pin down the exact way to reproduce this and I'll try to fix, should be easy if I can reproduce.

[oskay]

It has happened to me several times, when I was least expecting it. I don't have recipe for reproducing it yet.

[oskay]

OK, this bug has now actually caused me to lose blood, so I'm following up!

Testing on a mac.

Open RP, go to edit mode, open SVG, go to print mode, quit. OK!

Open RP, go to edit mode, open SVG, go to print mode, paint SVG.
Then, quit RP. BZZZZZZZZZZZZZZZZZZZ - running violently into wall.

Actually seems to work every time. Does not seem to be sensitive to what's in the SVG file. Seems to work across different modes (paint/pencil).

Can be prevented by depowering motors before quitting.

[techninja]

Not having much luck reproducing this. Mac OSX Mavericks, latest build. I can almost understand that this is an extra park command or something.. but not sure how or why. 😕

[oskay]

It appears that this only happens with newer firmware on the machine--
I get this behavior consistently with EBB firmware 2.3.0, but not on 2.0.1. (I've been using multiple machines for testing, with these two firmware versions on them.)

Quoting myself from a different thread,

The most significant difference between 2.0.1 and 2.3.0 is that 2.3.0 returns an "OK" for each valid command (rather than nothing) that is not a query, and an "Unknown command" message (rather than nothing) for each invalid command.

So... it seems that the machine is in a metastable state, when at idle, after completing a job. Perhaps it is prepared to execute another park command (as you have suggested) but has not executed it yet...?

[oskay]

Confirmed still present in 2.0.0-Beta 1, dated January 12, 2016.

[EmbeddedMan]

Is there anything I can do to help debug something like this? Add a UART
output for every byte that comes and goes through the USB connection on the
EBB maybe?

On Wed, Jan 13, 2016 at 1:16 PM, Windell Oskay notifications@github.com
wrote:

Confirmed still present in 2.0.0-Beta 1, dated January 12, 2016.

—
Reply to this email directly or view it on GitHub
#250 (comment).

[techninja]

That's not a surprise, I've done nothing to fix it as I haven't reproduced it yet 😛.

Not sure what firmware I'm running. I never did get around to reading the firmware version in CNCServer, or doing things different depending on said version.

I never found the OK ack to be reliable, at least as far as when it would come in relation to when a command was sent, so what I do in CNCServer is simply wait for the "serial buffer" to drain, and assume it's all good and go right back to sending the next command/waiting.

From what I've seen there are at least... 3 "buffers" that hold on to serial data when it hasn't been grabbed by the EBB yet. Possibly one in hardware/OS specific, one in node-serialport, and then mine (which I try my best to control, ensuring the latest two commands are in the hands of the EBB at any moment in time). Getting that timing right of course allows for only a small margin of error, so I often err on the side of too many commands at once, which is handled by the two closest buffers to the EBB... I assume. I don't actually have a very complete knowledge of this as I'm still mostly just a hacked web developer 😄.

It's possible the drain isn't happening at the right time? Or... Perhaps I should send something other than a movement command as the last? I'd be curious to see what the actual movement beyond 0,0 is to confirm that it's simply doing the same movement it did last... You could do this by starting the carriage in the center, run everything as a small black painting in the top left (to avoid hitting the bottom/right), then see where it goes beyond that when closing.

[oskay]

Perhaps I should send something other than a movement command as the last?

That is what I would try first... Maybe a "read pen state" or something benign like that. Where could I add that in the code to test?

[techninja]

In the paper.utils, autoPaint is controlled by "run" commands, very easy to add a new one here at the end. Could like just add more like this:

      // Wrap up
      run([
        'wash',
        'park',
        'up',
        'down',
        'up',
        ['status', i18n.t('libs.autocomplete')],
        ['callbackname', 'autoPaintComplete']
      ]);

You should be able to clearly see/hear it do these to know it's working, and if it's duplicated, there's no harm.

[oskay]

Yup!

Sufficient to do:

      // Wrap up
      run([
        'wash',
        'park',
        'up',
        ['status', i18n.t('libs.autocomplete')],
        ['callbackname', 'autoPaintComplete']
      ]);

[oskay]

Is there any reason to imagine that simply adding an 'up' like that could cause a foreseeable issue?

[techninja]

No... though it's not actually FIXING the problem being presented.. it's certainly a low-energy workaround 😄. ANother bonus, any mode that uses autopaint will get this fix as well.

[techninja]

Right.. should I just go ahead and get this workaround in and re-roll the release?

[oskay]

Yes please. :)

[techninja]

All update files and date updated, check it!

[oskay]

Great-- this fix workaround appears to work just fine.

[techninja]

Okey dokey! So.. I guess we're Ok to launch the beta? Hope you can sign it.

[oskay]

Trying. It might be easier to add this into the build process than recursively signing it "backwards".