Development of a new raster protocol

[arkypita]

The gcode and grbl are great, but the use made of them for raster image engraving is a strain on its capabilities (as well as being highly inefficient) as because grbl is a kind of vector protocol.

For this reason I would like to try to write the specifications of a protocol for sending raster data, something that involves sending some modal commands at the beginning (to program the X / Y step between one point and another, the intensity desired for black, the dwell time on each point etc) followed by a series of data that define only the gray values ​​and a line change command.

I intend to do it in two possible ways:

• fixed point time, modulated power
• fixed power, modulated point time

All obviously taking into account the length of the buffer, the management of immediate commands (therefore using escape codes) etc.

My intention is to send this specification to the various manufacturers and firmware developer and see if anyone would like to invest in this idea.

Anyone who wants to collaborate can write below this thread!

[arkypita]

Main Idea

The idea is to "initialize" the machine to a raster mode in which the mode is defined (modulates time or modulates power) the pitch (distance between two points) the direction (horizontal or vertical, increasing or decreasing) and then sending an entire line of points only giving the percentage of gray (0-255).

All bytes sent are treated as dots to engrave, with the exception of all characters used as immediate commands (realtime commands) the character "\n" for newline, and the "G" character which can be used to change mode and/or to exit raster mode, which all must be passed preceded by an escape character to avoid confusion.

The machine autonomously manages the movement between one point and the next and the engraving of the dot, until a g-code like G0 or any other G codes which brings out of raster mode is sent.

[arkypita]

Example of implementation

G8 X0.1 P3 I10 J255

G8 = enter raster mode (power modulation)
X0.1 = move 0.1mm between each point
P3 = stay for 3ms on each point
I10 = use S10 as power for white point (byte 0)
J1000 = use S1000 as power for black point (byte 255)

Then follow a stream of bytes that represent the colors of each point of the scan-line. For each of that bytes the machine will have to turn on the laser for 3 milliseconds, at a power that will be computed by this formula:

S = byte_val * (J - I) / 255 + I

In order not to overload the reception buffer, the streamer must not send more than 127 bytes in a single line, which is why the byte stream must be broken up into blocks followed by a "\n" that allow GRBL to send "ok" commands back to confirm data receive.

At the end of the line the streamer will send G0 Y0.1 to move the laser head up to the next Y line, and will enter the raster mode again by sending G8 X-0.1 P3 I10 J255 (note the -0.1) and it will send the byte stream for the next line, this time from right to left.

[andrewmarles]

Industry standard for g code is RS-274. I would really suggest not changing the standard g-codes. M codes are not standardized and exist for this purpose, although if you add a lot of custom M codes your solution will become unwieldly very quickly for others to use.

There are several active ports of GRBL to 32 bit platforms, GRBLHAL in particular is capable streaming g-code at very high rates over Ethernet on the Teensy4.1 platform. FluidNC and GRBL Advanced are also under active development. It is also very easy to implement completely custom command protocols with GRBLHAL, see here for an example HGPL implementation that was done without modifying core code:

https://github.com/grblHAL/Templates/tree/master/my_plugin/hpgl

Really suggest digging into GRBLHAL as I think it could be what you are looking for. It has been ported to many different 32 bit platforms.

[MitchBradley]

Implementation is not the issue; specification is. A solid, well-thought-out specification can be implemented on any controller firmware with sufficient resources.

[andrewmarles]

Just responding to the OP's post on gnea/grbl where he was asking about GRBL alternatives. Still lots of people that don't know FluidNC and GRBLHAL exist. My experience is extending GRBLHAL so that is what I pointed out.

Following your protocol discussion with interest.

[arkypita]

@andrewmarles thanks to pointing me to GRBLHAL it looks like an interesting project

[MitchBradley]

One possibility for optimizing the bandwidth of the raster byte stream is base-64 encoding. It uses 4 bytes of ASCII to represent 3 bytes of binary data, so a 120-character line gives 90 S values from 0..255. There are also some simple and relatively efficient run-length encoding schemes to further reduce the bandwidth in the common case where there are long runs of unchanging values.

That said, the encoding is probably not the most important first task. First we need to decide on the best way of folding this mode into GCode.

[bdring]

The current implementation is not very inefficient and difficult for controllers to implement. Basically every increment is a new move that must run through the planner. Each line could be sent as a single move. You would need to buffer the power information before the move.

The concept of "dwelling" at a point does not work. The machine must run at a constant speed. If your resolution is 0.1mm and you want 3ms of time over that area that should simply be the speed. 0.1mm / 0.003sec = 33.333 mm/sec.

Some lasers use an overtravel method. That puts the acceleration/deceleration outside of the image area. Currently the controller must try to compensate for the acceleration. Not all lasers are perfectly linear in power and the edges can show artifacts due to that. This does impact the usable work area slightly, so it might be optional.

I personally don't think sticking to strict gcode rules is important. Controllers will need to make major changes to support this, so it is better to create a new and efficient protocol. We should not rule out binary transfers.

[MitchBradley]

It doesn't have to be strict gcode, but it needs to adhere to the gcode expectations for character set and GRBL usage of realtime characters, otherwise we will have all manner of serial protocol glitches and hangs. I think we can do something that is efficient within those constraints.

[arkypita]

Hi @MitchBradley

Implementation is not the issue; specification is. A solid, well-thought-out specification can be implemented on any controller firmware with sufficient resources.

I totally agree with you, and I am happy to listen someone with your experience.

I have tried to write an implementation to help the reader understand what I have in mind, and it has been very helpful to me in focusing on the various critical points I will have to address.

The main critical points that jumped my eye are:

1. avoid using already used g-codes
2. produce an output that can be saved as a text file and reloaded without problems
3. takes into account that a specific firmware (like grbl or others) might use control characters or special characters to control the flow or to execute special actions
4. have a resilient and error proof format that is resistant to communication errors (if 1 byte is missing all the next dots are misaligned)
5. easy to enter and exit from raster mode

Point 2 and 3 lead me to think that using pure binary data is not the best option (lot of escape characters, different firmware by firmware).
Base-64 or other binary to text encoding it is certainly interesting.

[MitchBradley]

Re point 4, we probably want to insist on a non-optional checksum or CRC for the raster data.

[MitchBradley]

Bart said "Each line could be sent as a single move. You would need to buffer the power information before the move."

Let's expand on that. In conventional CNC, you send an S word to set the spindle speed/power, and that applies to subsequent moves until changed by another S word. Suppose that we extend that modality so that, instead of a constant power, we have an array of power values that apply to any subsequent move, interpolated across the extent of the moves along one axis.

We can come up with a more efficient encoding and error checking, but for ease of discussion, let's use a simple hex encoding for now.

G0 X0 Y0
G1 F1000
:X 00 00 5f 6d ff ff 6d 00 00
:X 11 22 33 44
X100
Y.1
X0
S0

This example illustrates several points:

1. :X indicates that the power interpolation applies only in the X direction
2. The two :X lines are concatenated to form a longer array "00 00 5f 6d ff ff 6d 00 00 11 22 33 44". That lets you get around the line length limitation.
3. The array is linearly interpolated along the length of each X move, in the left-to-right array direction for positive direction in X and right-to-left for negative direction
4. The established array applies to all subsequent moves until a new array is established with a new group of : commands
5. You can cancel the power interpolation and return to normal operation with an S word
6. The only new command is the : thing. Everything else is just ordinary GCode.

:X is just an example syntax for talking. We will ultimately want something more expressive.

[MitchBradley]

In your example above, you used I and J as the black and white points that correspond to 0 and 255 in the raster space. Most GRBL setups already have some way to map S values to the hardware signal that controls the actual spindle speed or laser power. I think it is best to have this spec deal with S values from 0..255 and leave the mapping of those to hardware values up to the firmware.

FluidNC has a speed map that can apply to any spindle type, converting a range of S word values to the hardware control variable, with dead zones and piecewise linear interpolation. Other controller firmwares have some way of specifying that mapping.

[arkypita]

Hi @bdring and @andrewmarles
Thanks to both of you for joining the discussion

The concept of "dwelling" at a point does not work. The machine must run at a constant speed. If your resolution is 0.1mm and you want 3ms of time over that area that should simply be the speed. 0.1mm / 0.003sec = 33.333 mm/sec.

This is what LaserGRBL currently does in its conversion from image to gcode: it produce segments of specified S value (optimizing multiple dots of homogeneous color with a longest segment) and run them at constant speed.

This produces a decent result, but this generates lines, not points.
I'm not sure lines are the best way to draw raster images, I believe making points is better (but I have not had the opportunity to test by myself) and some user support this idea #283 #885

I know that standard grbl G4 dwelling at point is limited by firmware implementation (read gnea/grbl#960) but i think it's possible to obtain microsecond accurate timing in most common microcontrollers.

However please not focus on this point! The same raster protocol could support different variant: lines at constant speed and power modulation, points with constant dwell and power modulation, points with constant power and dweel modulation etc.

Re point 4, we probably want to insist on a non-optional checksum or CRC for the raster data.

Of course, that's something I was thinking too.
I was also thinking about the possibility of inserting a byte with the length of the packet at the beginning of the raster data packet itself.

However, it must also be taken into account that if multiple raster data block are sent (and these are buffered in the controller as in the character count protocol) when one of that block is recognized as corrupted, he and the following ones should be discarded by the controller (and re-sent by the sender), otherwise all that mechanisms are useless.

The alternative is to use a "synchronous + repeat on error" type stream mechanism (among other things already implemented in LaserGRBL).

[arkypita]

In your example above, you used I and J as the black and white points that correspond to 0 and 255 in the raster space. Most GRBL setups already have some way to map S values to the hardware signal that controls the actual spindle speed or laser power.

Yes, I am totally aware of this. Grbl, as example, use $30 to define the S-value that correspond to 100% of PWM signal.

I think it is best to have this spec deal with S values from 0..255 and leave the mapping of those to hardware values up to the firmware.

The I and J in my example have exactly this purpose! In my protocol I want to send "pure bitmap grayscale bytes" from 0 (white) to 255 (black) but if I want to use half of the laser power I should tell the controller that 255 correspond to S500 (if $30=1000) and this is why I define I and J.

This will produce a double conversion: from 0-255 (bitmap) to S10-S500 (with I=10 J=500) and then from S10-S500 to PMW 3-127 (with $30=1000) but it is the only way to use the gray values directly and at the same time to be able to use a reduced and translated scale of the laser power according to configured $30.

In any case, this too is a minor detail compared to the rest.

[arkypita]

I'm glad I got this enthusiastic answer from you, but at this point I think it's necessary to step back and ask our-self a question: why a raster protocol? What advantages does it have? Is it really necessary or are other ways are possible?

I see as advantage:

1. the possibility of give out the most on very fast machines equipped with powerful lasers. On these hardware, the current verbose gcode protocol could be a bottleneck in feeding the buffer.

2. move to the controller the implementation of different modes (line, point, time modulation, speed modulation, power modulation) making the code to be generated by the CAM simpler and more homogeneous.

The only really valid reason is the first, admitted and proven that the current protocol is limiting the overall performance.
Any other advantage I miss?

[MitchBradley]

So, back of the envelope calculation. Assume a spot size of 0.1mm . Using a line per spot in G91 mode, each line looks like

X.1S250\r\n

or, when going backwards,

X-.1S250\r\n

So, roughly 10 characters per spot, a bit less on average. 10 characters at 115200 baud is about 1 ms, so 1000 x 0.1mm /sec = 100 mm/sec = 6000 mm/min. That is where the bandwidth limitation starts to kick in. The speed could be increased with a higher baud rate.

I expect that there will be other limitations in the planner code.

[arkypita]

LaserGRBL's current algorithm generate G90 absolute coordinate to prevent cumulative offset in case of communication issues, and use only '\n' as termination. One pixel "on the wire" looks like X137.5S713\n so 11 chars when we have only one decimal position, up to 13 when 3 decimals are used. Average value on real images, including optimization of consequential pixels of the same color, give an average of 11 chars per pixels (not far from your estimation).

So, roughly 10 characters per spot, a bit less on average. 10 characters at 115200 baud is about 1 ms, so 1000 x 0.1mm /sec = 100 mm/sec = 6000 mm/min. That is where the bandwidth limitation starts to kick in. The speed could be increased with a higher baud rate.

Agree with your calculations, but I want to remember that this result is valid if we use 10 lines per millimeter (250dpi) if we double the resolution we double the data to be transmitted per lines and therefore halve the bandwidth bottleneck to 3000 mm/min.

6000 mm/min it is very close to the physical motor speed limit of the vast majority of classic diode laser engraver (atomstack, ortur, neje etc) and the laser power of that types of laser diode (<10W) it is not enough to reach higher speeds on the most common materials.

I should do some concrete tests on the controllers I have, but I believe there is also a bottleneck in the interpretation and execution of the gcode by the microcontroller. A stream of binary data is much easier to interpret and handle than the same data expressed as gcode segments.

[MitchBradley]

Regarding error resend - the real solution is to implement TCP. It is extremely well understood and efficient implementations are available. Why shoehorn error handling into an already-bad protocol? If you are going to fix the protocol, really fix it. TCP can work over a serial line via SLIP or PPP. If you have TCP, any number of problems just disappear. For example, realtime characters are just messages with the urgent flag set.

[cri-s]

I use binary data to enable/disable laser on constant speed.
If there are 80 steps/mm (just as example) then with binary data, it starts at optical limit/homing switch
and then goes up to ... , one bit for every step to switch laser on/off.
For protocol, i simple use base36 encoding ( 0-9 and a-z ) and everything enclosed inside curly braces {}
get base64 decoded and added to internal buffer. I don't use additional crc or something as i have implemented optional checksum/crc that secures

[cri-s]

My personal notes: Don't waste M66 WAIT ON INPUT for outputting things, choose annother one. Do you are aware that this is already implemented on several Grbl branches, mostly ARM based ones, when enabling it inside config.h, extract: #define ENABLE_WAIT_ON_INPUT /* --------------------------------------------------------------------------------------- * Enable M66 wait on input mode * Pvalue is the pin index ranging from 0 to 254 * example: M66 P0 L3 Q5.6 * wait up to 5.6 seconds for digital input 0 to turn ON (HIGH) * * This is a subset of the linuxcnc implementation of M66, with the implementation of digital input only * and only with the wait mode of HIGH and LOW. */ further M Codes are not allowed to have Axis Words. This collide with modal motion and modal macros. Maybe add Gcode, or better, move config/setup to the binary section too. As note, some CNC use # for local variables, @ for global variables and $ for system variables, me too. I'm using framing for sending binary lines, that don't need ACK from grbl side, only NAK in case of error in order to speedup the transmission, and for this it get separated before going in the normal gcode parser. Seeing you'r example, i suggest to use intel hex code including : marker for the binary laser data From firmware support, GRBL have no timing support, there is possible to do per step timing, timing in subitems of steps after 15uS of step, but if you need do 40khz, the timing is only from 0.25uS to 10uS usable for higher power lasers. Sure, it's possible to add timing support in multiplies of 16uS only if considering legacy board, including that shipped with china laser engravers. For diode lasers, for fast response time, it's important to not power off the laser, just power it down into the led region and ramp it up. Respond is then in the nS range, as 0.25uS pulses are visible on paper. Annother option for imaging is per microstep imaging and not per time. Further from doc, direction of imaging is to consider, as certain cnc can only reliable image the target from the same side, as the backlash is not constant. Am Sa., 7. Mai 2022 um 23:10 Uhr schrieb Terje Io ***@***.***

…

: I think instead that the M66 command is modal and is part of the M3, M4, M5 group Why would that be? M66 is a "user defined" command and as such part of modal group 10 per LinuxCNC specs. In grblHAL it will be executed in group 9a - later than group 7 which handles M3/M4/M5 - so IMO in the correct order (if on the same line). [image: image] <https://user-images.githubusercontent.com/20260062/167271264-a357281c-c83c-4711-ac1f-a227324b7f14.png> This would be insanely slow, is that the intention? For fast *pixel perfect* engraving switching the laser on for a short time for each pixel while cruising is, again, IMO the best option. Which leads me back to some questions earlier about design limits. E.g. a DC excited CO2 laser has a typical response time of 1 ms, a RF excited laser in the region of 0.2-0.3 ms (IIRC). This limits the engraving speed vs engraving resolution. I have no experience with diode lasers other than the one I built for my PCB exposer so I do not know what to expect from those. Only that the constant current source I bought with the laser diode was useless for the high speed engraving I required for that (1200DPI @ 230mm/s). There are other limiting factors as well, such as beam spot size... When I clear my backlog (I have been busy with another project for a while) I can try to write an engraving plugin for grblHAL - are there any grblHAL users out there with a diode laser that can help with testing? — Reply to this email directly, view it on GitHub <#1818 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIQ5FQOP33QFPORROQ5WSLVI3L2XANCNFSM5UK56CUQ> . You are receiving this because you commented.Message ID: ***@***.***>

[terjeio]

Don't waste M66 WAIT ON INPUT for outputting things, choose annother one.

I missed that one, yes LinuxCNC style M66 is already supported by grblHAL so cannot be used. Better to use a M-code > 100?

M Codes are not allowed to have Axis Words.

And neither single meaning words such as S, F and T.

As note, some CNC use # for local variables, @ for global variables and $
for system variables, me too.

Used by grblHAL as well. $ migth be used if not in the first position of a line? LinuxCNC uses $ for specifying which spindle to address for some commands, I have started work on grblHAL to support those.

just power it down into the led region and ramp it up. Respond is then in the nS range, as 0.25uS pulses are visible on paper.

You use a high spindle PWM frequency to achieve that?
Do you have/need backlash compensation for high speed engraving?

[MitchBradley]

I feel strongly that the raster data line should have:

1. Framing error detection in the form of a byte count. Lost bytes - a very common problem - will gargle and shift the rest of the line, rendering the "replace unconvertible hex values with 0" rule useless.
2. A CRC
3. A format character, allowing future extension to e.g. base-64 encoding

Error lines should be acknowledged differently from non-error ones, so in case we want to do some kind of retransmission scheme later, at least it will be possible to extend the protocol. If there is no good way to detect error lines, future improvements are very difficult.

One way of handling error lines is to repeat the previous line (in reverse order if the scan is boustrophedon). That leaves a visual artifact, but every lost and uncorrected data scenario leaves some kind of artifact. A repeated line is usually less visible than an image shift resulting from missing bytes that cannot be precisely located within the line.

[solawc]

I very much agree with this point of view and function, there are too many bytes lost due to no frame detection or error detection; we can't guarantee that all hardware is the same, and we can't guarantee that the user's environment is consistent and good, different Interference will always lead to the loss of data from the serial port, and no matter what MCU or MPU, there is a situation where the serial port loses data, and even the SD card has read data errors. Therefore, I think it is necessary to add verification.

[arkypita]

Lots of things to discuss, but at least that's a starting point. I try to answer everyone.
Maybe better to split in different messages as per topics.

I think instead that the M66 command is modal and is part of the M3, M4, M5 group

Why would that be? M66 is a "user defined" command and as such part of modal group 10 per LinuxCNC specs. In grblHAL it will be executed in group 9a - later than group 7 which handles M3/M4/M5 - so IMO in the correct order (if on the same line).

I had noticed that this new binary mode seems to take on a similar role to M3 / M4: M3 constant power laser, M4 variable power laser, M66 laser controlled by binary data. Also it seems very unlikely that these modes could be used together, and finally I liked the idea of being able to turn off binary mode with the M5.

But the most important reason is my ignorance. I did not know the existence of group 10 and this is why I placed it in the modal group 7 instead of 10.

Better to use the "user defined" modal group? it's ok to me!

[arkypita]

Don't waste M66 WAIT ON INPUT for outputting things, choose annother one.

I missed that one, yes LinuxCNC style M66 is already supported by grblHAL so cannot be used.

I admit my ignorance again. I tried searching the internet for what M-codes were used and seems that M66 was unused.
I had looked in reprap's gcode documentation and some other website without being able to find it. Now I'm going to read the documentation on the LinuxCNC site which looks more detailed. I think I will learn a lot.

If it's used, better to switch to another one.

Better to use a M-code > 100?

Since this is not a user customization but is an attempt to write public documentation of a new standard, I was thinking of using a free M code among the "non-user" ones. Obviously, however, without going to conflict with already defined functionalities. Any suggestions?

In any case, I see no problem if using a M-code > 100.

[ShenRen]

In fact, we can consider GRBL's $ command。Such as $B=X0.1 P3 I10 J255

[cri-s]

for system variables, me too. Used by grblHAL as well. $ migth be used if not in the first position of a line? LinuxCNC uses $ for specifying which spindle to address for some commands,

Yes, several vendors use that. It's improve reading of code and allows having position data starting at $1 instead of needing to lookup the codebook what variable is that #2001 as example. Extract from one random cnc mill manual: #00 NULL #1~#33 Local Variables For each level @000 NULL @***@***.*** Global Variables（Common） Common variables for all program levels Not preserved @***@***.*** Global Variables（Common） Common variables for all program levels Preserved $001~$199 : Read only -- $196 is the last used $200~$399 : Read only and preserved -- $333 is last, including 16bit from PLC $400~$599 : Read/Write -- unused, for system integrators or for expanding the call levels $600~$799 : Read/Write and preserved -- $631 is the last used including 16 bits to the PLC NULL is NAN, every double value that is NAN cancel automatically the preceding Word used, necessary for macros, really important. just power it down into the led region and ramp it up. Respond is then in

the nS range, as 0.25uS pulses are visible on paper. You use a high spindle PWM frequency to achieve that?

No, it's on/off. I use HW voltage/current converter and settable minimum/maximum current. I'm using 145mA and 310mA, where the granted laser threshold is 150mA , on 10bit adc, minimum laser on is 31 up to 1023 , I'm using 6bit -> 8bit -> 10bit -> 16bit expansion mapping, 10bit on avr, 16bit on arm. 6 ->8 and 8->10 bit divided range / 3 , lower third is used as is, upper third is subtracted from maximum, and middle third is multiplied by 4. 10 to 16 bit is expanded to 12bit by the same algorith as 6->8bit and then multiplied by 4, to get 14 bit, then again the alg 6->8bit to get 16bit. Expansion code is this: uint16_t expand2bit(uint16_t val, uint16_t limit) { uint32_t tmp = val; uint16_t t,l,lim=limit>>2; tmp=limit*21845; t=tmp>>=16; l=t>>2; if(val>(lim-l)) val = limit-(lim-val); else // upper third if(val>=l) val = ((val-l)<<2)+t; // middle third if(limit>250 && limit<1000) /* 8-10bit */ { tmp=val; val=tmp+=32; if(tmp>=0x10000) val=0xffff; } return val; }

Do you have/need backlash compensation for high speed engraving

No, i expose always from the same side only as i don't make artistic images but tecnically that get processed and with backlash it could violate some requirement. Otherwise yes, it's necessary.

PS i could send my code for handling, but there is some hint. The @n@ format is for program control streaming, no OK get replied, only errrors including the last correct received n line. The :n: format is for SD card streaming, it send back OK code, same as any other gcode on grbl. As the format is compressed, LZSS and RLE , the program must stream first the code to the controller in order to verify the buffering. and at the same time writing down the : format for offline usage, as the PC not really know what is the buffer state of the controller. I mean for things, that need data during movement and the buffer to cache data is too small for holding all data. I'm using ENC , ACK NACK ascii for enquiring normal and binary line buffer capacity for smooth control of transmitting data. I feel it's too specific implementation, but if you want just start with that, see how good it's work, do it.

—

…

Reply to this email directly, view it on GitHub <#1818 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIQ5FWEDQYTZDN5MUL6LATVI5CKLANCNFSM5UK56CUQ> . You are receiving this because you commented.Message ID: ***@***.***>

[arkypita]

When engraving per points the laser head moves and stop at each point, then it turn on the laser, engrave a point without moving, turn off the laser, and then it moves to the next point (using G0 rapid movement).

This would be insanely slow, is that the intention?

I am perfectly aware that this would be slow. Currently I am convinced that this leads to a qualitatively better result but I have not yet managed to have a proof of this.

For fast pixel perfect engraving switching the laser on for a short time for each pixel while cruising is, again, IMO the best option.

However, this cannot be called pixel engraving, it would be dashes: more like lines than points.

I've seen some software that generate gcode for pixel-engraving using G4 dwell command, unfortunately I don't have these software and lasergrbl doesn't support this output. I would at least like to try. Then I can say more.

Which leads me back to some questions earlier about design limits. E.g. a DC excited CO2 laser has a typical response time of 1 ms, a RF excited laser in the region of 0.2-0.3 ms (IIRC). I have no experience with diode lasers other than the one I built for my PCB exposer so I do not know what to expect from those.

Laser diode are commonly used in high-frequency communication system and pulsed operation is very common too.
I think a diode can easily have pulses in the order of nSec but probably the electronics of control board could be a limiting factor.

Obviously, the possibility of making accurate uSec timings on the diode pulse also depends on how the firmware is designed.

Anyway, I have included these modalities because it seems to me that they are achievable using the exact same protocol. If they are not feasible due to technological limitations, or if they do not provide better results than the line mode, for me they can be forgotten.

[arkypita]

M Codes are not allowed to have Axis Words. This collide with modal motion and modal macros.
And neither single meaning words such as S, F and T.

I understand that the axis words could cause conflicts, but why S command too? M3 S1000 is a command that I send when I want to turn on the laser at full power, and it is correctly interpreted.

Maybe add Gcode, or better, move config/setup to the binary section too.

I don't like the idea to move setup to binary section.
I will have to study a little the other commands and what is written on LinuxCNC and try if I find a solution.

[MitchBradley]

S is not an argument to M3, but rather a separate command that can be on a line by itself, as well as on the same line as M3, G1, etc. GCode is weird.

[MitchBradley]

By "weird", I really mean "a complete mess from a programming language perspective". There are programming languages like Forth that are extremely weird, but not at all messy, rather the opposite.

[arkypita]

feel strongly that the raster data line should have:

Framing error detection in the form of a byte count. Lost bytes - a very common problem - will gargle and shift the rest of the line, rendering the "replace unconvertible hex values with 0" rule useless.
A CRC

Communication problems, CRC, byte count.

I first thought they were needed, I still think so, but I don't think they need to be implemented and defined in the documentation of a sub-part of the communication while the other parts of the communication doesn't handle it. Even a re-transmission system that deals only with binary data, and which treats errors on binary packages differently from how it treats those on gcode packages, does not convince me.

I read in reprap that some firmware support CRC and checksum. Perhaps this path should be deepen.

A format character, allowing future extension to e.g. base-64 encoding

Agree, base64 is a must have but I choose hex because it was easier to implement even in limited hw like atmega328 (I wish it could be implemented for these devices as well.)

Error lines should be acknowledged differently from non-error ones, so in case we want to do some kind of retransmission scheme later, at least it will be possible to extend the protocol. If there is no good way to detect error lines, future improvements are very difficult.

Agree.

One way of handling error lines is to repeat the previous line (in reverse order if the scan is boustrophedon). That leaves a visual artifact, but every lost and uncorrected data scenario leaves some kind of artifact. A repeated line is usually less visible than an image shift resulting from missing bytes that cannot be precisely located within the line.

Or using the last know value (usually the pixels close to each other have similar colors).

[MitchBradley]

The CRC link that you cited acknowledges that the checksum (as opposed to CRC) is barely useful. I would go farther, by saying that, since it is optional, it is essentially worthless. In this DIY CNC world, amateur programmers get something barely working and throw it out there, then that becomes the de facto standard, and then its problems become everybody's problems. If something is optional and the implementation that first gets traction does not implement it, then much of the rest of the ecosystem will not support it. So optional error checking is, in effect, no error checking at all. The lack of that has caused me a lot of wasted support time - and I would argue that the support people make the difference between a successful project and a dying one. Lost characters will splice together the beginning of one GCode line and the end of another. Sometimes that results in reported errors; sometimes it just results in corrupted coordinates, causing the machine to make weird moves and bit crashes. Either way, given the propensity of senders to ignore reported errors and just continue anyway, it results in angry and confused customers, and very hard to diagnose error reports from random failures in the middle of megabytes of GCode.

The raster data is going to be an extreme version of this for two reasons

1. In a typical raster engraving job, most of the file will be raster data
2. The raster data has much less redundancy than GCode, so if some of it gets lost, diagnosing the error syndrome is almost impossible. With GCode, you can easily see that a line like "G1 X1.53 Y2.3X1.59 Y2.4" or "G1 X10.4512.77" resulted from character loss. With raster data, detecting and diagnosing errors is much much harder.

So, at the very least, I think that a non-optional CRC should be present. But a byte count is still important as discussed below.

Or using the last know value (usually the pixels close to each other have similar colors).

If you mean the last known value in the line, that works well only in the case where you know that a specific byte has been corrupted in a way that makes unconvertable as hex. In the case where an unknown number of bytes are lost, you do not know where in the line to insert the repetitions, and how many to insert. Without that information, the result of lost-byte errors will be to shift the remainder of the image to the left, possibly destroying the registration of later lines.

In order to limit the shift/registration damage, you need framing at both the scan line level and the data line level. That framing can be done either by pre-declaring the expected length of both scan lines and data lines, or by including byte counts in the lines, or, ideally, both. However you do it, there has to be some way of finding the next good data that represents the start of the next scan line.

[arkypita]

Sometimes that results in reported errors; sometimes it just results in corrupted coordinates, causing the machine to make weird moves and bit crashes. Either way, given the propensity of senders to ignore reported errors and just continue anyway, it results in angry and confused customers, and very hard to diagnose error reports from random failures in the middle of megabytes of GCode.

Unfortunately I know it well ! A good deal of problems affecting the communication between LaserGRBL and its usb-serial connected engraver are of this nature.

The raster data is going to be an extreme version of this for two reasons [...]
So, at the very least, I think that a non-optional CRC should be present. But a byte count is still important as discussed below.

Ok you convinced me: package length and CRC8. Is only 2 bytes more but allow error detection.
It is going to be very similar to Intel HEX format that @cri-s mentioned earlier.

In order to limit the shift/registration damage, you need framing at both the scan line level and the data line level. That framing can be done either by pre-declaring the expected length of both scan lines and data lines, or by including byte counts in the lines, or, ideally, both. However you do it, there has to be some way of finding the next good data that represents the start of the next scan line.

I consider declaring the length of the scan line superfluous because I intended to do the positioning to the next line through a G-code command with absolute XY coordinates.

[MitchBradley]

For CRC-8 there are polynomials that can check up to 247 bits, i.e. 30 bytes, at a Hamming distance of 3 - but those polynomials are essentially worthless at HD 4. You can get 119 bits (14 bytes) at HD 3 and also HD4 with other polynomials. See this 8-bit CRC table.

With CRC-12 you can check 2035 bits/254 bytes at HD 4 - 12-bit CRC table

[cri-s]

Your need something as a code in order to be sure that the machine is the one you intend to use and take in mind, there are scenarios where you use steps instead of timing for laser control and sometimes its needed to position the laser using calibrated positions. Another point is, when you stepper speed is less then 3rpm there is no timing penalty for stepper. Just expose, make step, expose ... Make g0 move ... With m code the setup is too complex, Inside binary you can have several parameters and functions. Further doing binary setup you could mix s and timing data even only partially, instead external m code blocks the motion. arkypita ***@***.***> schrieb am So., 8. Mai 2022, 20:09:

…

feel strongly that the raster data line should have: Framing error detection in the form of a byte count. Lost bytes - a very common problem - will gargle and shift the rest of the line, rendering the "replace unconvertible hex values with 0" rule useless. A CRC Communication problems, CRC, byte count. I first thought they were needed, I still think so, but I don't think they need to be implemented and defined in the documentation of a sub-part of the communication while the other parts of the communication doesn't handle it. Even a re-transmission system that deals only with binary data, and which treats errors on binary packages differently from how it treats those on gcode packages, does not convince me. I read in reprap that some firmware support CRC and checksum <https://reprap.org/wiki/G-code#.2A:_Checksum>. Perhaps this path should be deepen. A format character, allowing future extension to e.g. base-64 encoding Agree, base64 is a must have but I choose hex because it was easier to implement even in limited hw like atmega328 (I wish it could be implemented for these devices as well.) Error lines should be acknowledged differently from non-error ones, so in case we want to do some kind of retransmission scheme later, at least it will be possible to extend the protocol. If there is no good way to detect error lines, future improvements are very difficult. Agree. One way of handling error lines is to repeat the previous line (in reverse order if the scan is boustrophedon). That leaves a visual artifact, but every lost and uncorrected data scenario leaves some kind of artifact. A repeated line is usually less visible than an image shift resulting from missing bytes that cannot be precisely located within the line. Or using the last know value (usually the pixels close to each other have similar colors). — Reply to this email directly, view it on GitHub <#1818 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIQ5FVM6FRTU6NS4DGCI6LVI77O7ANCNFSM5UK56CUQ> . You are receiving this because you commented.Message ID: ***@***.***>

[arkypita]

Thanks to all, I need times to re-read all your comments and hints.

@cri-s I read your messages with interest but I am struggling to understand if what you are exposing is a pure binary protocol or something that I could also use in a g-code style format.

[cri-s]

Basically it is something that i needed and i just implemented it.
It uses base64 encoding, beside some other command chars, the rest get discarded.
Basically base64 chars get stored into binary in chunks of 4 chars, forming 3 bytes. If less then 4 chars are used, 1-3 there can be
used for parameterizing the controller. The other command chars are: '+-.,$'

• and - means that a floating point value follow. The grbl code for reading a floating point value get called.
  . The dot command introduce that a decimal integer number follows, and for parsing it the floating number reading code is called.
  as .123 .234 theoretically is valid, it result to only one 123 argument, because the .234 get read as fractional part and discarded,
  in that case .123|.123 or any other non command char should be used, keeping in mind that spaces and comments get rip off first.
  The modified base64 code (_^) starts with numbers and then lower type letters, je f means 15
  , this stores the unput (less then 4 char) base64 value as argument, and two consecutive commas store and call that function.
  It is possible to store 7 arguments in the current implementation.
  $ , this hashes the follow identifier , to be used with ,, (call)
  For separation, it is advisable to use @ , because it is unliky to be used as command char in future.
  I'm inserting it at end of line too in order that if the first line get disturbed, the gcode interpreter see the at symbol and emit error.:
  This works even the code allows @ variables, because for indirection the [ square bracket ] expression is needed.

Example
@1@ LCK .2345443 ,, @@1n
@1@ LCK .2345443 ,, 1s
@1@ .2345443 LCK ,, 2N
is always the same, last two chars are base64 crc code. Here the code 2345443 is send to machine in order to be sure to use the correct machine. If the code is wrong, error is returned. This was only a example, otherwise the framing counter must increase if
thes 3 lines get send and not just one.
Annother possibility is to use hash code.
@1@ a,7,3 .122@.33 $special_mode_arkypita ,, @@1^
In this example, the word special_mode... get hashed and the call have the arguments (10,7,3,122,33)
Naturally binary data and setup code could get mixed, every 4 base64 chars the data get stored into binary data array.
example
@1@ asdf1fooBAR0 G91,,M5,, +100.000+0.G0,, G90,,M3,, foobar33 @@08
This starts with binary data, then change to G91, disable output (M5), rapid go to the XY coordinate, Enable laser (M3) and continue with binary data
To be noted that @n@ uses streaming protocol (no positive acknowledge) and :n: or #n# is the same with ok messages giving back,
just what you configure. I'm using rle and lzss (5,3) compression, but that could be removed.
@1@0ADR,,0m
This set the adress index of binary data to zero, the interface is flexible, if you need something, you could implement it.
VER and HLP gives out some info about the version and commands, if available. The $hash command was inserted only recently.

As said, it was written for my needs, when sharing it i would rewrite the dot handling to allow repeating dot arguments without separation character. Crc is initial Value: 0xFF, maxim ibutton crc code, ending: ~(eeprom_crc ^ 0x5A) + length;
The initial @ char get dropped, because of protocol handling , so the crc is from first framing number up to the last two chars.
Mega and Blue Pill firmware are available, i know you need to customize it probably and maybe this are useless for you.
For any question, ask.

Ps, @arkypita i have send a request for email address on github in order to share some code, that need a little polish before getting made public.. Maybe it's possible to squeze the code inside mini/... too need to check the actual code what is free using older compiler and it depend what feature you want have. As said, for uno, 16uS is the timing interval for laser if it's more then 15uS, other controller don't have this constraints as timer2 is used for rc servo, timer0 running at 16uS interval, timer1 for port handling, from memory.

[arkypita]

@cri-s i don't receive any email address request from github. if you want you can mail me at my public address info@lasergrbl.com
I think I understand how your system works, but I think it is too far from my idea to have something that can fit inside g-code and grbl standards.

[arkypita]

Sorry if i didn't speak for a few days, i'm very busy with work.
I try to fix some critical points of the previous document:

What M-code to use

M66 is already used by LinuxCNC as "Wait on Input"
Better to use a M-code > 100?

Since this is not a user customization but is an attempt to write public documentation of a new standard, I was thinking of using a free M code among the "non-user" ones. Obviously, however, without going to conflict with already defined functionalities.

My proposal is to switch to M54

M54 seems to be unused in most common firmware implementation: linuxcnc, reprap, marlin and also googling M54 does not give significant results.

What parameter letters can be used

M Codes are not allowed to have Axis Words. This collide with modal motion and modal macros.
And neither single meaning words such as S, F and T.

We need four parameters:

1. X-Step
2. Y-Step
3. ModulatedParam-Min
4. ModulatedParam-Max
5. FixedParam

I and J are fine or not? can we use other letters like P, Q, E?
If so, we have solved this problem.

Binary data format

Here I still have some doubts: let me expose them to you.

I feel strongly that the raster data line should have:
A format character, allowing future extension to e.g. base-64 encoding

First of all: Is it really necessary to define the possibility of having multiple encodings? When generating the g-code you should know which encoding the machine supports, this is inconvenient. The same saved gcode file might be fine for one machine but not for another. IMO using only one encoding it simplify!

However I am open to this Idea, but still having doubt: should repeat it at any single raster data line? It's a waste of bytes! I think that the stream is consistent. Why not use use another parameter of M54 (or use different M-code) just to set "binary data format". Or define it implicitly (not explicited in any way) or auto-guess it by the firmware analyzing character set.

Second: I approve of adding a CRC for data corruption verification and re-transmission request, but do we really need explicit packet length too?

If we apply data discarding and re-transmission when the CRC does not match, what advantages having packet length does it really bring?

[ShenRen]

If we apply data discarding and re-transmission when the CRC does not match, what advantages having packet length does it really bring?

The significance of data length is that we can engraze variable-length data line. In several hypothetical cases, if we use a fixed-length binary data frame, but the last pixels of the image happen to be in a separate packet, we will consider completing the last data frame in a line. When there are too many blank data frames to fill in, the data valid ratio decreases.

[ShenRen]

Variable data frames facilitate complex pattern engraving by grouping data in close Spaces together, skipping empty pixel areas.

[MitchBradley]

One immediate justification for multiple encodings is to add a run-length encoded format. Long runs of constant data, common in images, can thus be encoded very compactly, with significant reduction in file sizes.

[ShenRen]

Keep in mind that not every pixel in our image needs to be engrazed, and we will have a lot of invalid pixel areas.

[shooter64738]

Fairly interesting discussion. I've been working on a control for the last several years, and I think would be easily capable of doing this. It's not grbl, grblhal, grblmega tho.

All the gcode is sent over usb, ethernet, or sd card. The entire program is converted into binary motion data. This is does on the fly if auto cycle start is on, or it's all converted and stored until cycle start is pressed. All rs274 data has to be converted in some fashion anyway..

However, there's a binary protocol built into it. If you are familiar with serialization, a class has data properties set. It is converted into a byte stream. The data is then encapsulated into a binary record. The first byte of the record determines the records type. And the last 2 bytes of the record is always the check sum.

I used this protocol to set parameters in my machine from a pc. The controller uses the protocol to talk to other peripheral devices like spindle controller, water flows, etc.

It could actually benefit the mcu because much of its work could be done ahead of time. If a specific control byte is used so the motion controller knows its raster data, all the gcode processing code be skipped over. It could even be removed if desired and free up space if it's a concern.
The more I think about it, the more I kinda like it. What if an image format protocol were used like tiff, jpeg, etc? I'm pretty familiar with the tiff format already, but probably not the most suitable.

Also lasers are a newer thing for me. I've been mostly working with mills, lathes, and some pick and place machines.

[arkypita]

I apologize if I have not pursued this topic anymore but I am really very busy with the work in this period! :-(
I hope to be able to find some time soon

[tatarize]

First, bonafides, I'm the author of MeerK40t and do a lot of reverse engineering of dedicated laser control cards. A couple notes and an overview of the topic from outside the gcode world. The probably ways such a thing could go and my proposal.

---

First prior art.

There was a small weird project 7 years ago that apparently hacked in Raster-data in G7 with Base64 data into Marlin cards ( https://github.com/TurnkeyTyranny/buildlog-lasercutter-marlin ). G7 is typically Lathe Diameter Mode. I don't think that prior art did any work for you.

Some, but not all, dedicated laser cards rather than CNC firmware hacked to allow laser-cutting (gcode) have a raster modes.

M2 Nano

The M2 Nano, for example, lets you establish G values during rapid mode. This sets the number of stepper motor ticks (in the top or bottom direction) at the turn around point of the raster. Rasters come in a variety of flavors but they usually stop at some point and go the other direction. The M2 Nano detects this as the point where right -> left or left -> right. The M2 is a very low level card and does no processing on the card itself, it basically works like Klipper for 3D printers and uses a streaming protocol, so rather than a computer on a card; it's a 20 buck card with 2 stepper motor chips, a 40 year old processor and Schmidt trigger.

The encoding for M2 Nano has the stepper motors already set (they are set by a single ascii code value), and all it does is convey ticks to the stepper motors to move distances. A lot of K40s and other lasers have stepper motors of discrete tick sizes. So you're looking at conveying absolute distances in ticks rather than overt distances (big weird gcode fractional amounts). So the egv code looks like DbUlDbUlDbUlDbUlDbUlDbUvDjU130DbUbDtUbDb The D means laser-on the U means laser-off the lower case letters convey distance in a=1, b=2, c=3, ... with special distances for z=255 and if you give a number like 130 there that's just a raw distance. Also there are directions like B, T, R, L, and the line there is merely distance + laser_state if it sends a direction which is changes the state of the stepper motor, it stops firing, travels 127 steps slowing down over 4 different speed phases, then kicks in any pre-set G step amount. Then turns around and travels 127 steps speeding up through several different tick-speed phases. And with the stepper motor set a different direction it processes the more data like we see above. -- Keep in mind this is done pretty much without ever doing any math, and never actually parsing data. You set a G value (or two) and you get bidirectional and unidirectional rastering. And the least efficient code is 2 bytes Ua and Da which mean laser-on move 1 step. And laser-off move 1 step respectively (usually you can convey moving much further). The buffer only holds about 127 bytes of data and will constantly read new data setting 206 control code when it can and 238 when it can't accept this data. The rastering can go about 200 mm/s typically before stutter (buffer underuns) and often goes 300-400 and maxes out around 600 mm/s.

Ruida

Ruida runs a purely binary control code language. All commands begin with a high-bit and they can be of whatever length. Numbers that are larger than 7 bits are encoded to just use the 7 low bits. So 32 digit numbers are stored in 5 different 7 bit numbers (they don't/can't set a high bit in payload). This is also all swizzled with a really basic algorithm but varies slightly based on type of machine. But, because the high bit you can always identify and divide the command and the payload. This gives you 0x7E different potential commands with payloads of any size. This is done through serial and through UDP which tries also includes a checksum to try to tell whether anything changed (but, packets go missing, and things get bad, and it's UDP so packets go missing). Rastering is done purely with the same commands as vector, however it can do fully-on, fully-off rastering but also PWM rastering where each step can get flagged with different power amount (this sometimes gives rasters a more 3d view in a single pass raster).

Moshi

Moshiboards run a pure binary control code language with 16 different potential commands. Each command has a known amount of payload. There would be 255 different commands but they engage in a weird swizzling protocol which gives 16 different varieties of the same 16 commands and sprinkles the equivalent control codes throughout the little programs it runs. They run their own raster protocol which is basically "raster mode" which is entered into differently than vector-mode. The speed codes given are in cm/s rather than mm/s (which is how it works in vector mode). And the commands short relative commands in this mode. So Move_Relative_X -20 and Cut_Relative_X -20. It has different commands for move_absolute_position(x, y) and relative_cut_x, relative_cut_y, relative_move_x, relative_move_y. These commands are 2 bytes long. It uses a different writing mode to the CH341 chip to convey realtime commands.

LMC EZCad2

LMC controllers which control EZCad2 Galvo lasers have preset command sizes. A command block is 0xC00 bytes long and consists of 256 commands that are 12 (0xC) bytes in size. These are 6 different int16le values, and the first 2 byte word typically has 0x80xx values specify the list commands (these are inside the 0xC00 blocks) and there's smaller realtime commands which are just single 12 byte commands and these usually are 0x00xx codes. However, the EZCad3 DML controller has commands that are like 0x8100 (lMarkPixelLinePara1). So each command of which there are a great many (way more than you actually need), fits nicely or is made to fit in the remaining 12 bytes (most don't use more than 4 bytes). Also, due to being Galvo the positions are in absolute values between 0x0000 and 0xFFFF for x and y. And usually 2 int16le values give a position. Rasters are done simply using these commands there's a Mark-To(X,Y) and Travel-To(X,Y) command that do the bulk of the work. Changes to thing like speed, power, and for galvo lasers, frequency, are done adding another command in the block. This usually goes fast enough to raster at several thousand mm/s (it's only moving a mirror and the inertia isn't crazy high, but there's built in timings to make sure things get to where they are going before they start firing lasers).

---

So, sorry for the long winded overview of many different cards. But, generally sometimes these cards have dedicated raster modes but it's mostly so they know they'll be running at a faster speeds, or to account for the higher speeds with different accelerations. Usually what these cards have over grbl cards, aren't specialty raster modes but rather the ability to have a pre-defined understanding of the command codes are and will do. Thus do not require any expensive parsing, or planning, they also use the understanding of the stepper motors to give values in pure integer amounts (Ruida gives distances and locations in micrometers). This usually ends up being a lot less data than comparable g-code but it doesn't hold that you could jam in some binary into the existing gcode system and avoid the bottlenecks.

We also need to understand that there are different types of rasters and these all tend to need some support. Regular on-off rastering is one type but regular PWM rastering is also important. You declared a desire to implement one or the other type and really both are sort of important. Also, there are times when it's useful for lasers to raster things diagonally (some controllers don't love this and are not built well for this) but it is certainly something a number of software packages permit.

This gives three ways forward:

• 1: hack in a non-gcode mode into regular grbl or other gcode firmware to run a bunch of quick and easy raw commands that will allow considerably fewer resources but basically just implement things in a way that does not require parsing gcode and skips the planning buffer.
• 2: Add additional power to the gcode code and continue using the same gcode that currently exists for all of those modes. For 300 dollars you can apparently get a gcode-card which is powerful enough to match the speed of a $20 stock laser card that does no computations.
• 3: Some projects like Klipper show that it's fairly possible to basically interpret gcode and use less resources while doing it. Something like this for a laser mode ( https://klipper.discourse.group/t/cnc-laser-support/354/4 ) would, in theory, allow you to perform the regular gcode commands but hyper-optimize them for a laser. Klipper is not well designed for this, but the core principles behind it could maybe apply to a similar project built from the ground up.

I think 2 will happen regardless it's just faster chips on boards, eventually you'll have the resources you need. I'm pretty sure there's a lot of fairly okay ways to do 1, but you are just side-loading non-gcode commands. 3 is fairly interesting, but I'm not sure anybody would tackle such a project, though I could see some modifications to Klipper bridging this gap.

GCode Dash Array Proposal

That said, my two cents for a protocol is to add in a D parameter (all codes are taken, as such these do things in photoplotters and these sets diameter for cutter compensation commands (tough)). However, I'd just hijack this to effectively set dash. Basically we do not feed it scan-lines, we feed it a dash array. And we don't hack in any weird movements, we use the already established movement commands. So:

G1 X0 Y20 D20 2 3 7 9 1

The first value is the distance in currently set units (mm/in), the remaining values are how far between on and off we travel. So in this we're traveling 20 units and we set our dash at 20 units, 2 on, 3 off, 7 on, 9 off, 1 on. If we set our distance value to 1 these dashed values would occur over that 1 unit of distance.

The logic behind this is that since we specify a length we're actually conveying a DPI to the controller. You could, in theory, specify traveling any distance and exactly mark the pixels there, you're defining the pixel size rather than relying on on the controller to know step size or how big our pixels are.

The D-mode setting would not automatically unset.

So sending gcode: D0.1 1 1 would actually convey to the controller a PPI (pulses per inch) value. So regardless of the speed we're going since each 0.1 units we travel we turn the laser on for 0.05 units and then off for 0.05 units and we repeat. That actually results in lines which are at 50% power. We can combine this stuff like G3, G4 to draw-dashed arcs if we wanted. If we are rastering a pure gray color, we can actually set dash-array pulses and not have to reset them if the pattern is the same. You could actually avoid data resend if the same dash pattern applies again.

We get the rather useful feature of dash-array lines, if we set these to macro levels where you could see them, we also get the rather useful feature of PPI power modulation, in addition to and in parallel with the PWM power modulation. And we can shorthand the raster information. If we're going to be drawing a scanline, so we can just tell it the pattern of pixels in this scanline (or segment of a scanline, given the buffer). And we draw the line as normal, but rather than a normal cut-line we get a patterned line. In this case a scanline as set forth in the image.

So rather than a completely hacky side loading of pixel data. We convey a useful feature. You want to draw a dot-and-dash morse-code line around a circle... we have you covered. But, also, we could convey an image raster much more efficiently. In the M66 proposal rather than the encoded sequence command @00004242424200000000424242420000 we'd actually encode that as S66 D8 0 2 4 2 (the pattern repeats half way through so we only needed to define D8 though you could do D16 0 2 4 4 4 2).

We also do not require a defined position, so you can raster not only vertically, horizontally, diagonally but you could raster an series of arcs if you wanted to.

This generally meets the requirement set forth in development of a new raster protocol while also being useful enough that it might be worth implementing anyway. There's some additional things like you could turn the laser on and off at non-specific locations so you actually might be able to raster images smaller than the laser's actual physical step size. And the implementation details is not based on location, but just timing. You're traveling at a specific speed and going to specific distance and the laser is turned on and off over the course of movement but, you don't need to care about your position, this is actually just toggles at specific times. You're just hacking a pattern into the laser's on-off timings. So you're just touching that one system you should have traveled some number of units given your speed, go ahead and trip the laser on->off or off->on according to your D parameter. This should have clear advantages when it comes to implementations.

There's a few other advantages like pixel shortening (it turns out pixels look bigger than they were given where the laser turned on and off because the oblated region is round and not square. Turning the laser on for 1 pixel often means drawing something that looks much more like 1.75-2 pixels wide, thereby darkening the image if there's many small cuts. We could accurately account for that since could turn the laser on and off across fractional pixels.

The syntax is notably similar to SVG stroke-dash-array, the utility of just manipulating the timing is really nice. It's easy to understand and useful in several other ways. You could probably define ramps over distance (progressively increase laser power between two points and two distances) or PWM dashes with rather obvious tweaks to the protocol. And rather than position based the first value could be defined by a different parameter to define the set length.

The raster protocol is a side effect of an otherwise killer feature. That seems like it might make getting people to implement it much easier.

[terjeio]

I'll add Laserburn/Smoothieboard cluster mode as prior art as well. We are experimenting with implemeting this as a plugin for grblHAL now.

Add additional power to the gcode code and continue using the same gcode that currently exists for all of those modes. For 300 dollars you can apparently get a gcode-card which is powerful enough to match the speed of a $20 stock laser card that does no computations.

For lesst than $100 you can get boards for grblHAL that can handle high engraving speeds with plain gcode. The top of the pack is the 600MHz iMXRT1062 MCU found on Teensy 4.x boards with STM32H7xx boards not far behind. PPI mode is also supported by the grblHAL drivers for these MCUs.

There are at least two CNC BOBs for Teensy 4.1 available - T41U5XBB and GRBLHAL2000.

[tatarize]

S values for each dot colon delimited up tp 8 values per line.
In this case a Svalue is given for every dot at 0.06mm spacing.
G1 Y-0.48S0.875:0:0:0:0.875:0:0:0.875
G1 Y-0.18S0:0:0.875
G1 Y-0.24S0:0:0:0.875

Okay, that's genuine prior art, and actually somewhat already working with some firmware. It's an interesting method using the S there with colons.

[Paciente8159]

I've also been able to quickly implement this on µCNC. It's even able to run inside an UNO.

[JasonDorie]

Ortur (Ren) has implemented cluster support in Ortur firmware now, and another board maker, Tim Rothman has done this too. The latest updates of LightBurn enable the 'GCode Clustering' option for GRBL boards, and if the $I info block returns [CLUSTER:##] somewhere in the output, with ## being a number from 1 to 16, LightBurn will alter the cluster output size to match, with 8 being the default.

The method was chosen for its simplicity to implement on the firmware side, as it needs very little extra memory, and requires very little extra processing time. Most diode machines are going to be limited by their physical hardware before they need to go to anything more complex.

Because it's simple, it could be added to other firmware quickly, as a stop-gap while you try to do something more complicated. You'll probably find that the more complicated one isn't really needed.

When I added this to Smoothieware, I found that their PWM output was only being updated at 1000 Hz, so as soon as I started going 250mm/sec with 0.1mm dots, the results blurred because the PWM output wasn't changing fast enough to keep up. I increased the update rate to 4000 Hz, costing some of the CPU cycles gained from adding clustering. I haven't looked at the GRBL-HAL code yet, but that might be something that needs to be adjusted there too as the speeds increase.

[shooter64738]

I've went 2 different routes with mine. So far I'm not sure which ones work best. I tried various ways of converting the raster data to gcode using grbl, but they all suffered buffer under runs and stuttering when running beyond 2000mm/m for a distance greater than 500mm, and a step rate of 80/mm. I haven't tried it on a teensy yet tho.

Regular jpeg rendering to generate intensity values for the laser and the image being a fixed size and a known dpi I didn't have to bother piecing motion segments together to find the return point of the motion. Then finding the laser intensity was pretty basic, by finding the gray value and factoring in current velocity when that pixel is being created. I've had pretty good results so far but still experimenting. The switch between regular gcode and raster mode is selected using an Mcode, and the mcode is only valid if the machine type is a laser.

Second method is looking ahead to a point the motion changes 180*, while storing the S value for each pixel during that travel. Requires quite a bit of memory if the image being loaded is over 1000mm wide. The advantage to it is there's no need for a different process type, but I still use an M code to set raster mode before loading the file.

[arkypita]

Hi all, thanks for the new contributions, I'll gladly read.
I am still very busy after the holidays the return to work was traumatic.