Tuning LW4 CAM to produce gcode which doesn’t starve Smoothie’s planner over USB. The two traces are X step and Y step.
This is Pro to another level!!!
Well done Todd.
How are you testing this?
How will this impact the very small moves required for raster engraving?
This is for the path cam only; the raster cam will use a different code path (@Sebastien_Mischler 's). I capture the waveforms from a run and look for spots where both axis go quiet.
But how do you expect you’d be able to tune this for general use ( ie for folks who don’t have a scope to tune it ) ?
Yes but how do you know the right way to do it for any given machine ? It’s going to be different based on the machine’s config
That is true
I tuned the CAM’s defaults for feeds up to 500 mm/s; any machine running this speed or slower running smoothie (GRBL users can probably get more aggressive) should work out of the box, as long as the firmware’s max feed and acceleration aren’t too aggressive for the machine. The main parameter is segment length (.5 mm default, I still need to expose it to the UI). Users needing finer detail will have to sacrifice feed; they’ll have to slow it down until it doesn’t sound rough. Users must either tune the firmware’s max feed and acceleration correctly, use community-recommend conservative defaults, or only buy machines that are already tuned. I don’t know a good way for CAM to compensate for firmware settings which are too aggressive for the machine.
We could probably create & publish gcode testfiles to find the right settings for the firmware on each machine (by listening to sound of jerk and stalling steppers).