Add a g-code checksum

[d01010101]

Hi, g-code includes a checksum feature commonly used in 3D printers. However, a lot of CNC firmware does not support this feature. The original source code of GRBL hasn't been modified in years...

Here's an example of checksum support with retransmission in Marlin:

SENT: N24 G1 X120.405 Y76.035 E2.23535*97 RECV: Error: checksum mismatch, Last Line: 23 RECV: Resend: 24 RECV: ok

If you could provide me with some hints, maybe I would be able to implement it. In my system, somewhere within the two Linux/GRBL hardware/software stacks, there appears to be a very rare lost byte or some other issue (maybe related to this).

[terjeio]

You can redirect the input stream in a plugin and modify it before delivering the data to the original consumer. E.g. a bit like what I have done here.

[d01010101]

Thanks, but is this only stream modification or is the API flexible enough to allow asking the sender to retransmit?

Also, the checksum seems to be the de-facto standard as a lot of gcode firmware supports it already: https://reprap.org/wiki/G-code#.2A:_Checksum so maybe it would be more useful to support it in the core?

[terjeio]

is the API flexible enough to allow asking the sender to retransmit?

Yes, that is up to how it is implemented in the plugin.

Also, the checksum seems to be the de-facto standard as a lot of gcode firmware supports it already:

That is mostly 3D printer software, I do not know of any Grbl senders that supports it. You know of any?

maybe it would be more useful to support it in the core?

It does not matter much, a core implementation will be nearly exactly identical - only differing in how it is initialized. And it should only be implemented for serial (or USB streams), file streams or network streams (telnet/websocket) does not need it.

[d01010101]

Yes, it is mostly for 3d printers. But that domain is quite alive while the last time when the original grbl source has been touched is 8 years... in the meanwhile, quite a lot of posts can be found asking about the reason behind occasional error messages containing a garbled g-code like a missing byte, despite a USB transfer. Maybe raw TX/RX lines on a USB chip, its not 100% compatibility with Linux, I do not know.

Of course, the lack of cnc-specialized senders who would actually use such a feature is a valid concern. As of me, I can ask the UGS platform devs if they'd accept a respective sender patch (I could write one, looks easy).

[terjeio]

Be aware that Grbl/grblHAL supports a character counting mode that allows the sender to send data until the input buffer is (nearly) full. This will complicate a resend function because the sender may be ahead when a resend of a line is requested. This means that lines might be out-of-order when resent. And additionally the sender may have to add line numbers since these days I do not often see gcode whith line numbers added by the CAM post. One way around this could be to implement communcation via telnet using the PPP transport layer. grblHAL supports telnet on top of lwIP for a number of MCUs, using PPP instead of ethernet or wifi might be fairly straight forward to implement.

But that domain is quite alive while the last time when the original grbl source has been touched is 8 years...

The 8-bit Grbl is a dead end because memory is exhaused - there is simply no room to add features. It still lives on in the 32-bit world where memory is not an issue, except for the oldest/least capable 32-bitters.