@Oystein_Krog Damn, you’re right again… Thanks for correcting me!
@Pavel_Karoukin No, I run windows, just used to use linux before.
Anything you might be able to try in winetricks? You could also try Mono, have had better luck with that then wine. (I only ever got about two programs to work in wine.)
GRBL uses interrupts for receiving serial data, there’s no wait in the main loop, it comes in realtime. https://github.com/grbl/grbl/blob/master/grbl/serial.c#L159
The planner is future looking, it does not react line by line - https://github.com/grbl/grbl/blob/master/grbl/planner.c#L71
@Andrew_Hodel Not sure I understand what you mean? By definition, interrupts cause the main loop to wait – the serial command listening blocks everything else going on. That’s the problem with high serial transfer rates, interrupting step pulse generation and motion planning.
GRBL uses look-ahead so it can accelerate and coast across multiple segments, but the TRIGGER for acceleration slowdowns – what it used to decide how fast to go – is the change in velocity at the corner of each segment transition. Which means GRBL barrels through finely-faceted arcs without recognizing them as requiring slowdown.
There is no waiting when it’s just putting data in a buffer.
Why would line segments in an arc require a slowdown between them?
It’s using clock cycles, so it’s waiting. AVRs have zero clock cycles to spare much of the time. It’s well-known that USB comms can cause pause-zits and poor print quality at high speeds. That’s a major reason why slicers slow down for outer perimeters these days – no controller-induced zits on the outside.
If you set the speed to 120mm/s or something else high and do a tight arc with lots of facets, the gantry will flex due to high centripetal acceleration. That throws circles out of round. Try slicing a very high-res tight arc in a non-decimating slicer like S3D and watch GRBL blow through it at high speed with massive ringing on the exit path.
Zmzzc vvcc