I have just been informed by Jim that this feature is in fact already supported by Smoothie firmware, has been for a long time, it’s just not very popular/widely used.
Simply set delta segments per second ( the way you’d do on a delta printer ) even if it’s a cartesian machine, and it’ll do time-based segmentation out of the box.
So no need to implement it in the host. I believe that’s a more correct approach to it.
Tell me the difference between these two gcode sequences, as executed by Smoothieware:
G0 X0 Y0
G1 X100 F6000
and
G0 X0 Y0
G1 X10 F6000
G1 X20
G1 X30
G1 X40
G1 X50
G1 X60
G1 X70
G1 X80
G1 X90
G1 X100
Why would there be artifacts?
You’ve got constant distances there, though, not constant time. If you had constant times, the speed changes could line up with the counter resets in the step generation to cause light artifacts. This is more likely on 3D printers, but I can imagine it happening on a laser.
Oz, Arthur
Thanks for the continued updates.
How the pause function works is understandable.
I just needed to realize it’s different then working with a HAAS, MetaBeam or OMAX CNC machines.
Pause on those machines stopped them immediately.
Facility maintenance has swallowed up my time this past week preventing any playtime for personal projects.
Hope to get back on the laser build in the coming days.
Thanks again
Steve
We have been raking our brains for a long time on how to correctly implement fast-pause. We had a conversation about it just a few hours ago actually. I really hope we find a way at some point. In the meantime, thankfully there are the segmenting workarounds helping a bit.
What grbl did to get a fast pause/stop is so called “realtime commands”. Every line that comes over USB/serial is checked for such commands and if one is found, it is not added to the input buffer but instead interrupts the actual running command from the planer and splits it with a decceleration, pause and accereation sequence. I don’t know if this could be an option in smoothieware too.
Smoothie does have real-time commands ( like «?» ), what we are missing is the logic to do faster pausing.
I think the real trick is the way to interrupt the actual runnig command with a clean decelleration and pause in a way that can resume (accelerate again) without loosing position. But as I said, I don’t know if this would be adaptable to smoothieware.
We’re working on it, still actually considering solutions even today 
It’s much harder to stop an ongoing block, so we’re thinking we start the pause after the current block ( if config is correct, current block shouldn’t take more than a fraction of a second max ), and start deceleration with the blocks in the queue that are not executing yet ( so they are safe to modify ). then get to speed zero. then when we want to re-start it’s just normal planning. we have a path towards implementing this really, but we know there’s going to be a lot of edge cases / weird things to figure out along the way, if we want to do this right.