t-oster
Reduce Number of Comma Position for Engraving in gCode
Hi, to reduce the data that needs to be streamed to something like a GRBL controller ober a serial or virtual serial port, it makes sense to reduce the number of after comma positions.
Currently, a typical raster engraving line looks like this: G1 X46.524333 Y27.897667 S148.500000
However, it should look like this to have less traffic on the serial line (enable faster engraving) and less burden on the micro controller: G1X46.52Y27.89S148
In my gCode streamer https://github.com/McNugget6750/SimpleG I remove all the space already but I don't handle the number of positions behind the comma. I'd guess that almost no one would. But there is absolutely no need to set laser power with a comma position and coordinate also only make sense with a maximum of 2 positions behind the coma.
Best regards, Timo
Hi did you make and measurements in order to check if this really makes a difference? On what Kind of Hardware? It is not hard to implement, but I am not sure if it introduces errors with some devices. Also i think the more Precision the better. There may be devices which actually work with more digits behind the comma...
In my opinion it makes a huge difference when engraving. Every byte counts. After removing all the spaces and a bunch of comma positions I could engrave much faster. I can modify the gCode on the fly but so may comma positions for an absolute (!!!) coordinate system is hard to justify. Having said that, it might make sense for a relative coordinate system.... Maybe configurable?
In the end, introducing any additional code will lead to more work, because on the one hand fixing bugs becomes more complicated and on the other hand the code itself may introduce bugs for certain special cases. More configuration switches make the setup even more difficult than it already is. Therefore it would be good to know whether this is just a feeling or backed up by measurements.
Possible special cases which I could imagine are:
- Position coordinates not mm but inch (is this even supported?)
- Small maximum power value (S1 = full power), high-power laser which needs to be turned down very much (e.g. to 1%) -> S0.01 is a normal value here.
As the user base of VisiCut is extremely diverse, we need to be careful not to break something with this optimization.
My feeling is that it should either be a fixed number of decimal places (as it is now), or it be specifically locked to the resolution set in the machine options (i.e. the same number of decimal places as the smallest step). It shouldn't be independent.
The only issue with the latter is that resolution is specified in dpi, which is definitely not the best choice for a module that's mm everywhere else.
As part of t-oster/LibLaserCut#71 I've filtered out spaces from the transmitted gcode for Grbl, should save a few bytes in the transmitted gcode.
Looking at the Grbl code, it seems like it has 0.01mm accuracy on all moves, as it stores the positional values as a uint8 value and uint16 mantissa. https://github.com/grbl/grbl/blob/658eb6a8b3cff0da59a61cbb5aa04d2c693c36c3/grbl/gcode.c#L128 . That said I'm not sure how it handles values > 255 so I could be reading things wrong.
Potentially this could be made as a grbl specific tweak, reducing the number of decimal places sent as part of the output. Happy to make a PR if this is acceptable.
👍 vote up for this feature
Already has some dirty solution in our branch https://github.com/minsk-hackerspace/LibLaserCut/commit/8dc023b1fe2bd1edbc239a1f795af75762ee5dc2
This will reduce Gcode file size by 40-50%
From this:
G1 X11.277600 Y386.080800 S140.000000
G1 X11.379200 Y386.080800 S130.000000
G1 X11.480800 Y386.080800 S140.000000
G1 X11.582400 Y386.080800 S120.000000
G1 X11.684000 Y386.080800 S110.000000
G1 X11.785600 Y386.080800 S100.000000
G1 X11.887200 Y386.080800 S90.000000
G1 X11.988800 Y386.080800 S30.000000
G1 X12.090400 Y386.080800 S60.000000
G1 X12.192000 Y386.080800 S70.000000
G1 X12.293600 Y386.080800 S60.000000
To this:
G1 X12.5984 Y385.979 S140
G1 X12.4968 Y385.979 S30
G1 X12.3952 Y385.979 S20
G1 X12.2936 Y385.979 S50
G1 X12.1920 Y385.979 S70
G1 X12.0904 Y385.979 S80
G1 X11.9888 Y385.979 S70
G1 X11.8872 Y385.979 S40
G1 X11.7856 Y385.979 S110
G1 X11.6840 Y385.979 S130
Anyway LaserWeb4 doing much better job by stripping same Y
Y0.30 S0.0000
X67.60 S0.2078
X67.40 S0.2118
X67.20 S0.1961
X66.80 S0.1725
X66.60 S0.2118
X66.40 S0.2706
X66.20 S0.2902
X66.00 S0.2314
X65.80 S0.2275
X65.40 S0.2118
X65.20 S0.2235
X65.00 S0.2745
X64.80 S0.3294
X64.60 S0.2627
@t-oster it looks like reasonable for perfomance
Anyway this GCode is not good for any raster jobs Need new protocol for rasters in GRBL
Current status: You can set the desired number of digits in the lasercutter settings for most GCode-based lasercutters. The default is 6 (which we should probably change to 3).