Closed cprezzi closed 7 years ago
@darklylabs @fabcreator
On Dec 23, 2016 7:31 PM, "Claudio Prezzi" notifications@github.com wrote:
I have implemented a faster way of communication for smoothieware, where multiple gcodes are comined in one line of max. 64 bytes before sending to serial. Additionaly unneeded decimals are deleted in X values (in laserraster.js). This shortens the gcode which also helps for better speed.
You could test this new communications protocol in branch smoothie_buffer.
Please tell me here, if you find any problems.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/issues/207, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr25ZbU336_oBEzppKAaqlfZFpTJzjks5rLAVVgaJpZM4LU9_x .
@cprezzi in fact multiple X Y on one line with one G1 will cause indeterminate actions and is illegal gcode... You can have multiple gcodes on one line BUT they must be separated by G0 or G1 (or G2/3). The parser effectively splits the one line into multiple lines at the G.
So
G1X38.500S0.10G1X38.100S0.11G1X33.900S0.20G1X33.800S0.28
is correct
and
G1S0.9X0.1X38.1X33.9X45
Is incorrect and illegal and will have undefined results.
@cprezzi how do we test?
@FabCreator: just do a "git checkout smoothie_buffer" in lw3 folder.
@wolfmanjm G1 is modal, so consecutive x moves on multiple lines is valid, but not on one line. Can I send multiple lines in one buffer like: G1S0.5X0.1\nS0.2X0.2\nS0.4X0.3
?
As I said one line is split into multiple lines on a Gx. Yes you can send multiple lines in one single write by concatenating the lines (with the \n at the end of each line), then send the buffer in one write(). However for that to work the X or Y must be the first character on the line and I am not sure the Sxx will work I'll have to check that. If Sx is the first character the entire line will be will be ignored.
was this added to LW3?
The smoothie line buffer is in LW3 master since one month already :)
FWIW I discovered the real culprit to slow raster streaming, and surprise it is NOT smoothie :) I explain more in the issue #219
I have implemented a faster way of communication for smoothieware, where multiple gcodes are comined in one line of max. 64 bytes before sending to serial. Additionaly unneeded decimals are deleted in X values (in laserraster.js). This shortens the gcode which also helps for better speed.
You could test this new communications protocol in branch smoothie_buffer.
Please tell me here, if you find any problems.