Minimum Move Distance variable

[LeonMF]

I've been working with the Smoothie developers on the print lockup bug. They are working on their end but the reason it only happens with S3D is because there are moves that are smaller than the resolution of the machine. This results in floating point math errors in the firmware. They are fixing their end but this is the part that S3D could do to fix this problem.

What they need is for S3D to not generate these small moves that needlessly fill the buffer, don't improve print quality and are pointless. The simplest way to handle this without potentially breaking other compatibility would be with some form of minimum move length setting.

[Cosineadditive]

YES, this would be hugely helpful for the 32 bit smoothie guys. The buffer length is only 32 moves, which isn't much in a tight radius corner. The problem is that if the buffer is overrun, which happens often, the acceleration moves aren't computed correctly. We're having to lower the resolution of the STL export to trick S3D into creating longer line segments. This doesn't work very well.

[tomMulholland]

In case someone else happens across this thread, I made a simple Python program to deal with short segments. It's available here:
https://github.com/tomMulholland/pyEng/ ... _python.py

There are also Matlab and Octave (free Matlab) versions.

This script works for printers that operate with *Absolute Positions* for the E axis. If you have a printer that takes *Relative* E positions, you would need to modify it slightly. You would find the E value from the ignored line and add it to the E value of the next line.