search

fra589 / grbl-Mega-5X

5/6 Axis version of Grbl, the open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on an Arduino Mega2560
https://github.com/fra589/grbl-Mega-5X/wiki
Other
341 stars 159 forks source link

Streaming GCode Program -> Error 25 + 2 #312

Closed fra589 closed 1 year ago

fra589 commented 1 year ago

Discussed in https://github.com/fra589/grbl-Mega-5X/discussions/307

Originally posted by **GrblGru** November 17, 2022 Hi Gauthier, I have a question about the USB interface. A user of my program uses Grbl and also sometimes Mega-5X for lasering. The traverse paths are often very short. Thereby a lot of commands are generated like e.g. s0 F2000 x0 Y9.800 z0 S250 F600 x0.1 Y9.800 S0 F2000 x0 Y9.700 z0 S250 F600 x0.1 Y9.700 etc. During the execution of the program sometimes after some time one of the two errors appears : 25 A G-code word was repeated in the block... 2 Numeric value format is not valid or missing an expected value Because this happens at different places in the program I suspect an error in the interface protocol. I have created the interface according to the Streaming Protocol: "Character-Counting" and never had problems with it so far. Testing is very time consuming, because the error occurs only intermittently. But it looks like the problems only occur in interaction with the Laser commands. When I change the S250 command to S0, the error has never occurred until now. Could it be that the S250 command sometimes takes so much time that the protocol is disturbed ? Is it possible to increase the size of the planner buffer (currently 120) ? I save the commands that I have sent. Can I see somewhere which command caused error 25 or 2 ? What can I do to make the interface more secure ? I would be very grateful for tips on how to debug such an error. Thanks for your time
fra589 commented 1 year ago

The problem seems to come from the difference between Linux end of line which is only one character (LF) and the Windows end of line which is two (CRLF). When Windows send a GCode line, Grbl reply with 2 OK sentence. This generate an error in the count of the GCode bytes sent by the sender in Streaming Protocol "Character-Counting" mode. Also, Grbl does not send an error or alarm on serial input buffer overflow. Characters are therefore lost at the streaming level without the sender knowing about it. This results in incomplete GCode commands (which can be recombined) and which generates error 25.

@++; Gauthier.