Fix an acceleration anomaly by making block->steps unsigned #3614
Conversation
| @@ -52,7 +52,7 @@ | |||
| // the source g-code and may never actually be reached if acceleration management is active. | |||
| typedef struct { | |||
| // Fields used by the bresenham algorithm for tracing the line | |||
| long steps[NUM_AXIS]; // Step count along each axis | |||
| unsigned long steps[NUM_AXIS]; // Step count along each axis | |||
| unsigned long step_event_count; // The number of step events required to complete this block | |||
There was a problem hiding this comment.
I see that steps and step_event_count are treated as though they cannot go over 0x7FFFFFFF in the Bresenham algorithm. The negative of the value is assigned to a counter. Then the algorithm looks for the counter to go over zero. If steps or step_event_count are ever 0x80000000 or higher, the code will fail. But surely there could never be more than 2.14 billion steps in a single move, right?
|
Let's pick some really bad numbers. M5 spindel, 400 steps/revolutionn, 1/128 microstepping -> 64000 steps / mm. 0x7fffffff = 2,147,483,647. 2,147,483,647 / 64000 = 33554 mm = 33.5m |
|
Thanks for doing the maths. I am rushing around like a pigeon with its head cut off today. |
|
Some time I would like to log acceleration behavior and see how the anomaly comes about. Buffer some diagnostic info in the stepper routine and serial-out the data in the main loop. |
An acceleration issue appears to be caused by conflicting signedness of
block->stepsand locals used in the acceleration handler. Canblock-steps[]simply be madeunsigned long? Why is it signed?#3613 proposed an alternate solution.