Lag during work

[ambarusa]

Hello, I just tried out this wifi based method, and after some minimal corrections in the code, I managed to make the system work. After using the engraver quite a lot, I found out that there are appearing some lags during engraving, which means that the laser is freezing in its current state (burning, or in off state), making some visible glitches in the final result. Do you have any ideas what should cause the problem? Maybe could be possible to implement some protection (ie. if there is no instruction the shut down the laser, or load the g code in a sort of buffer before start, and watch only a stop/pause command). I think my local network always seemed to be stable (it still can cause the problem). Thank you.

[arkypita]

Hi
I usually have the same issue with WebSocket protocol. I never understand why.
I prefer to use Telnet protocol over WiFi, this gives less lag (not remove the issue, but less frequent)

Use GRBL v1.1 with laser mode on and M4 command for power on will remove your burns problem because when laser stop moving its always turned off.

[ambarusa]

Thanks! I will make some tests. I didn't have time to fully understand the code, but is there a way to load the g code in a buffer before starting the work, and then watch only a stop/pause command from the UI?

[arkypita]

Grbl firmware use all the memory available in the limited hardware of an arduino/atmega328 so the receiving buffer is only limited to 128 chars.

Maybe a buffer could be added in esp module (now used as a pure tunnel) but this will make more complex the protocol because LaserGRBL should be keep track of buffer size in esp for not overflow/overfill it, and the code on esp should be keep track of grbl buffer.

Definitively not a good solution.