Streaming GCode Program -> Error 25 + 2

[GrblGru]

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]

Hi @GrblGru,

Strange behavior...?
It seems to me rather that you have interference at the hardware level in the serial communication (laser interference?) and not a logical problem in the program (neither Grbl nor GrblGru)...
However, personally, I don't use the "Character-Counting" streaming method. In my streaming code, I use the "simple method" which wait for the "OK" or "error" message.

Where do you see than the planner buffer is 120?
In the planner code (planner.h), the size of the BLOCK_BUFFER_SIZE is 36, this mean than the max number of linear motions that can be in the plan at any give time is 36,
and in serial.h, the receive serial buffer size is RX_BUFFER_SIZE = 255 (it was 128 in older version).

Maybe we can increase the sizes as long as the memory of the processor is not full... I didn't made the calculation.

It should be possible to add a debug message that returns the GCode line when an error occurs, it shouldn't be too complicated to do...
(a global variable which would store the line being processed in gcode.c and which would be copied to the serial port in the event of an error)?
I can do it for you if you are interested, but it will take me a little time...

@++;
Gauthier.

[GrblGru]

Thanks for your answer.

(laser interference?)

The user has already tried extra short cables with gold contacts, unfortunately without success. I have also seen the error a few times on my test system (without laser).

Where do you see than the planner buffer is 120?

Sorry, I meant the serial receive buffer. It is 128 character. For security I wrote only max. 120 characters.
I have always seen the advantage of the "character counting" streaming method in the fact that the controller always has a few commands in advance in the buffer and never has to wait for new characters.
I will try once to use the 255 characters and also once to wait only for an OK.

Thanks, for your offer to make the error causing command visible.
I don't want to make you any extra work, please let me do some more tests before.

Thanks for your help :)

[fra589]

(laser interference?)

The laser requires a fairly powerful power supply...
I have already observed electromagnetic interference capable of disturbing the serial link during power calls on poorly shielded power supplies or when using low quality serial cables.

@++;
Gauthier.

[GrblGru]

Yes, that could be a possible reason, of course. But I also get the error when I don't have a real laser connected.
So when I connect the PC to the controller at my desk and start the program. It is already mysterious.

[fra589]

Hi @GrblGru,

The ability to debug the GCode line is already present in Grbl:
You can see which line is causing the error by activating the #define REPORT_ECHO_LINE_RECEIVED directive in config.h (line 528).
Like this, the GCode lines will be displayed as they are processed and when the error occurs, you will be able to see which line is at fault...

@++;
Gauthier.

[GrblGru]

Hey @gauthier,
you are the best. Thank you very much. :)
I will try it tonight. Hopefully the error will come then too. Sometimes it runs error free for a long time.

[GrblGru]

@gauthier
just a quick feedback for your information.
I have tested very long with the modified version. Unfortunately, the error no longer occurred with it. Probably the timing is changed so much by the additional output. :(
I continue to test.

[sergeyshap1981]

Hi guys,
I'm using ugs as a gcode sender. I had also error 25, sometimes followed by other errors. After some debugging I found out that the serial buffer can overflow. There was a bug in the protocol.c that produced more "ok" responses than needed, resulting in excessive command flow from ugs to grbl. I'm happy to say I fixed the bug. At least it works now where it got stuck before. Also, some emprovements were made. Thus, "ok" response will be postponed to avoid serial buffer overflow, if the buffer is more than half full. Here is my patch:
error25_patch.zip
Regards,
Sergej

[GrblGru]

Hi Sergej,

this is really great !
Give me a little time. I will try it out and report back to you.

Thanks a lot :)

[fra589]

Hi @sergeyshap1981,

Thanks for your report.
I'm sorry, but reading carefully the serial.c and protocol.c, I can't see the bug you talk about which produce more "OK" responses than needed... Can you explain it with example of data received that produce this bug?

What I understand in your patch proposal is your code don't send the "OK" reply when the serial buffer is half full. In this case (serial_get_rx_buffer_available() > RX_MIN_BUFFER_SIZE), the "OK" response of the current GCode line will never be send! This can hang a sender which is waiting for all lines responses.

What I also see, is you have suppressed the "OK" output when Grbl receive an empty (blank) line... This OK is needed by some GCode sender for synchronization.

I thing the problem can be come from the "character counting" streaming method worsen by the difference between the end line in Linux which is 1 byte (LF) and the Windows end line which is 2 bytes (CR LF). Perhaps this difference can lead to buffer overflows if the sender sends a lot of small lines in the Grbl serial buffer.

In fact, the Grbl's serial interrupt doesn't send error message when the serial buffer is in overflow condition. I think I need to add this error report soon 😄

@++;
Gauthier.

[sergeyshap1981]

Hi Gauthier,

Thanks for your analysis.
Indeed, in my case there is windows end line with 2 bytes (CR LF), that causes grbl to response with two OKs after each line. UGS receives two OKs and answers with two lines more instead of one line. And so on... I believe UGS buffers OK responses ans answers symmetrically with as many new lines. In my case it caused serial buffer overflow. I could see about 6 new lines comming together from UGS.

The OK will never be send if the buffer is half full, you're right. That means the buffer contains more than 127 characters and enough lines to execute. As well as enouph end line characters to answer to at some later time when the buffer will be emptied a little. I don't see any risk here.

I understand your consideration about hanging a sender. You're right that suppression of "OK" is not good for all cases. I removed it completely during troubleshooting to shorten the problem area and forgot to put it back. Maybe it's reasonable to combine it with an emptiness of a serial buffer, as well. If you're interested, I could try to solve it.

Hope I could explain my case :)

Regards,
Sergej

[fra589]

Hi Sergej,

I'm rather thinking of a solution that would remove the double OK when receiving a CRLF end of line from Windows... I think I know how to do it, it should be rather simple. 😃
I will complete this solution by adding the error status when the serial buffer overflows.
I transfer this discussion to an issue to ensure Git version tracking.

@++;
Gauthier.

[fra589]

I just pushed the new version 1.2h.20220109 which remove the second OK when there is CR just before LF.
I also added the serial RX buffer overflow Alarm (new alarm number 11)

@sergeyshap1981, @GrblGru, since I don't have Windows box to test, can you tell me if it work fine ?
For me, it work good on Linux :-)

@++;
Gauthier.

[sergeyshap1981]

Hi Gauthier,

thanks, I will test it in windows with my milling task that produced errors without patch. I'll give you a feedback.

Regards, Sergej

[GrblGru]

Hi Gauthier,

I am not sure, but can it be that the timing has changed ?
I just loaded your new version and I noticed that at some times no actual positions are sent.
For comparison I have tested this again with GRBL on the UNO. There everything is ok.
Have a look at the screenshots. The green line shows the calculated path. The yellow line shows the path of the actual positions.
During the straight lines everything is ok, but in the area of the radii, in which many support points are together, there is no feedback.

[fra589]

Hi @GrblGru,

It's weird! I haven't changed anything other than not sending OK 2 times when Grbl receives a CRLF...
Nothing else have been changed in the timings.
What is your frequency for sending the "?" status report request?
Does the original grbl-Mega (https://github.com/gnea/grbl-Mega) have the same behavior?

@++;
Gauthier.

[GrblGru]

Sorry, my mistake. :(
After version 1.1g worked, I loaded 1.2h again and overwrote the settings with my values. Now it works again with the new version.

[GrblGru]

Just a quick feedback. So far I did not get the error again. However, I have also not been able to test for very long.