Communication error could be salvaged in some cases

[ShelMi]

Currently if there is a persistent communication breakdown in plotLineAndTime which ends up returning a null from ebb_motion.QueryPRGButton(self.serialPort), then python aborts the plot with a runtime error message. This loses position reference for the plot, and thus the entire plot is ruined.

The suggested change incorporated in the attached file explicitly looks for a null response. Here if a null response occurs, the program substitutes a simulated push of the pause button. Therefore the user may be able to use the "Resume" to rescue the plot, after fixing the communication problem.

The attached file is built from a base of the proposed fix for issue 45.

eggbot (2).zip

[oskay]

I'm not 100% certain that I've actually seen this issue, but your proposed fix is straightforward and plausible.

[ShelMi]

Now that ebb_serial.py has an errormsg associated with receiving a null response from comPort.readline(), I have found an exceptionally simple and reliable way to cause an error to occur, so hopefully the root cause may be discernible by those with more knowledge of the internals than I. I do not know if this manifestation of error is related to other i/o errors that have been thought to be hardware i.e. cable related.

The present error is not a hardware or communication problem per se, since it can be reliably caused by merely changing certain parameters on the Timing tab of the Eggbot Control extension.

The problem can be provoked by setting certain combinations of "Speed when pen is down" and "Delay after lowering pen".

Specific timings which cause this are documented in the below results of a small data-taking marathon:

Eggbot: IO error caused by pen lowering delay too long.svg  "Retry1"
   Plotting single horizontal line 111 pixels long, starting 47 px from origin
   ( exact position and length shown to be not relevant,
      but large increases in length cause decreases in failure boundary
      [not yet documented numerically] )

   Setup
         Pen up position   66
         Pen down position 60

   Timing
         Speed when pen down     200
         Speed when pen up       800
         Pen raising speed        50
         Delay after pen raise   200
         Pen lowering speed       20
         Delay after lowering   ALWAYS* FAILS WHEN DELAY = 1500
                                NEVER* FAILS WHEN DELAY  = 1400
                               (transition at about 1468)

   Delay failure boundary does NOT change when:
         Change pen up position to        61 OR
         Change speed when pen up to     200 OR
         Change pen raising speed to     200 OR
         Change delay after pen raise to 800 OR
         Change pen lowering speed to      5 OR
         Change plotted line length to   400 OR
         Change plotted line starting position to 300 px from origin

   However, delay failure boundary DOES change when:
         Change "speed when pen down" to 100:  moves boundary to 900-1000
         Change "speed when pen down" to  20:  moves boundary to 800-900

*  "ALWAYS" and "NEVER" == three times out of three tries.

[oskay]

This is great-- I'll take a look shortly.

[oskay]

Able to reproduce.

May need to add a time.sleep command for longer duration pen up/down moves, much as we do for longer stepper moves.

[oskay]

Sure enough.

It turns out that while we execute a time.sleep command to pause while a long stepper movement command executes, we did not have the same procedure in place for long pen-up and pen-down movements. I have added a sleep command for the pen-up and pen-down movements which appears to correct the communication error in this case.

[ShelMi]

Speaking of delays, I'd like to raise a question here rather than on the forum, because if I'm thinking wrongly about it I don't want to confuse the broader community of users. (Also, if your time.sleep command changes the behavior I don't want to publically raise an issue which may be going away shortly):

In the eggbot wiki, at http://wiki.evilmadscientist.com/Eggbot_Control it is stated:
"After the pen has been lowered, it is important to wait a fraction of a second before starting to draw again. This gives the pen arm a chance to settle in and recover from any minor bouncing. If you start to draw too soon after lowering the pen, there can be some skipping of the pen tip. To control the length of this pause, the "Delay after lowering pen" value is used. This value has units of milliseconds (ms) where 1 second is 1000 milliseconds. This delay should probably be no less than a quarter second (250 ms) and values as large as half a second (500 ms) are not unreasonable. However, you don't want to use too large of a value as the total delay caused by lowering the pen will be this value plus the time it takes to lower the pen." [emphasis added]

To me, this says that the "Delay after lowering pen" starts at the completion of the servo's move to the down position. But my observation tells me that in fact the delay starts at the beginning of the servo move.

Iff I'm correctly observing, then the wiki advice to have a delay of no less than 250 ms is cutting it rather closely. E.g. for U-D = 6 % points, and lowering speed of 20 points/second, the delay expires during the 6/20 = 300 msec servo down motion. True, the pen might conceivably have gotten to the egg already, but there is nonetheless minimal-to-zero delay before the line commences drawing.

I'm not trying to pick nits here, but iff my observation is correct, would you consider re-wording the wiki description - or okaying me to do it since I'm sure there are innumerable more pressing demands on your time? Or something else?

[oskay]

Yes... I think that both the behavior is correct, but the description should probably be updated. The delay does indeed start when the pen begins lowering. Please go ahead and edit the description to reflect reality. :)

Longer term, I would like to update the pen lift and lowering to use the newer method implemented for the AxiDraw software, where the transit time is calculated automatically (from the speed and distance) and the delay time is added to that. The software change is relatively straightforward, but it also requires changing the documentation, which is a little more time consuming.

[ShelMi]

Just a note to say I've made the change in the wiki, in case you want to review it for clarity or accuracy.

[oskay]

Thanks! I've made some minor tweaks for tone, but this is genuinely much better. :)

[ShelMi]

Glad you like it! 8^) I see you tweaked only section 7 and not section 9 - perhaps section 9 is feeling left out?

[oskay]

Ah-- missed that. All tidied up now. Thank you again.