EBB firmware - for v2.2.4 and above, revert to v2.0.1 <duration> units

[GoogleCodeExporter]

Version 2.0.1 used 40uS units for <duration> parameters, and this is what 
everyone is used to. For v2.2.4 and above, revert to this, with an option 
(SC,x) to use the 1mS units if a user chooses. This will make v2.2.4 act the 
same as v2.0.1 with regards to servo move speeds and such.

Original issue reported on code.google.com by brian.schmalz on 26 Apr 2014 at 10:31

[GoogleCodeExporter]

It turns out this was not accurate. The only two commands that changed between 
these two versions with respect to the units on the <duration> parameters was 
SP and TP. The current Inkscape extension does not use the <duration> parameter 
for either of these commands, so there is no reason to support the 40uS units 
for <duration>. I'm going to leave them both at 1mS units, as that's what the 
documentation states and close this issue. 

Original comment by brian.schmalz on 28 Apr 2014 at 12:46

• Changed state: Invalid

[GoogleCodeExporter]

It is worth noting that the SP command is used in RoboPaint, both for the 
EggBot and the WaterColorBot. 

Original comment by windell@oskay.net on 28 Apr 2014 at 12:57

[GoogleCodeExporter]

Ahh! That's really good to know. Does it use the duration parameter? Or
does it add it's own manual SM delay afterwards like Inkscape does (to get
around the bug in the SP command's duration parameter pre 2.2.1)

Original comment by brian.schmalz on 28 Apr 2014 at 1:17

[GoogleCodeExporter]

My first impression looking at the code is that it's only used with zero-time 
parameter.   You could verify with your WCB, to make sure that it still works 
even if you add an arbitrary delay there in the firmware.

Original comment by windell@oskay.net on 28 Apr 2014 at 4:40

[GoogleCodeExporter]

OK, that's a great start. I'll watch the serial traffic to see if it ever
sends a non-zero parameter.

I guess the other option is simply to revert to the previous behavior for
these too commands : a default value of 0 for <duration> if no value is
given. That way we don't have to worry about if this change will mess
anybody up. Things will work just as they did before, except that now, if
you do use a non-zero <duration> parameter, it will correctly delay before
the next command.

Maybe that's what we should do. Why make this harder than it needs to be,
right?

*Brian

Original comment by brian.schmalz on 28 Apr 2014 at 8:01

[GoogleCodeExporter]

OK, I've gone and made the default value of the <duration> parameter 0mS for 
the SP and TP commands. I've tested the timing with a logic analyzer of 2.0.1 
and the new 2.2.4 and the both match perfectly now.

Original comment by brian.schmalz on 28 Apr 2014 at 9:37