Move distance shouldn't include E when XYZ are moving.

[jv4779]

Distance calculation for moves don't include E axis unless it is the only axis moving.

Clip the max feedrate based on the firmwares max step frequency. Previously this was clipped in calc_timer which limited the speed indirectly. This lead to issues with estimate_acceleration_distance and intersection_distance overflowing the long type and making accelerate_until and decelerate_after bogus when large feedrates were used. The net effect is the firmware steps at the same rate as before, but does it in a sane manner. The under/overflow of accelerate_until was a major cause for the jerking observed. When this was negative the acceperation code tried to accelerate for the entire move causing acceleration_timer to hit zero, causing calc_timer to return a 32ms step spacing introducing a full to almost zero step rate change instantly.

[jv4779]

Would you prefer I pushed to experimental?

[bkubicek]

is this still an issue with the current beta 1 of v1.0.0 (see tags)?

[jv4779]

Yes. I checked the v1 code and it is still doing the distance wrong, which
will cause the speed to be lower than requested.
On Nov 22, 2011 1:40 PM, "Bernhard Kubicek" <
[email protected]>
wrote:

is this still an issue with the current beta 1 of v1.0.0 (see tags)?

---

Reply to this email directly or view it on GitHub:
ErikZalm#1 (comment)

[ErikZalm]

I added the distance calculation correction. The steprate is limited in the stepper routine.

Thanks for this fix. Sorry it took so long to put it in the code.