Error 22 and 25 with move commands after a program abort with "!".

[GrblGru]

Hello all,

when I abort a running program with "!", I get strange error messages afterwards when I send normal commands to the controller.

For example, with a simple "G90" I get the error message 22. "Feed rate has not yet been set or is undefined".
Or with a "X0 Y0" I get error 25 "A G-code word was repeated in the block".

With GRBL and also with Mega-5X it works.

What am I doing wrong ? Does anyone have an idea ?

[terjeio]

when I abort a running program with "!"

! is the feed hold command which suspends reading commands from the input buffer - what do you send after that to get out of feed hold mode before continuing sending?

[GrblGru]

Thanks for the quick answer.

The commands are part of the handling after which the operator cancels a program because something is not correct.
"!" is sent and a dialog appears where he can choose if he really wants to abort or let the program continue.
If he presses "Continue" "~" is sent. If he presses "Exit" "0x18" (Soft Reset) is sent.
Afterwards, however, one usually presses the "Back to start point key". There the Z-axis is moved up and then moved to 0,0.
So normal commands: "g90 g0 Z5", "g90 g0 x0 y0").

So in this case a function is needed that deletes all commands from the input buffer and puts everything in a kind of home position, so that I can send normal commands again afterwards.
I thought so far that this is the command "0x18" (soft reset). Is this wrong ? Which commands should I better use in this case ?

[terjeio]

Soft reset should flush the input buffer. So perhaps a bug in the driver, which one are you using?

[GrblGru]

I am using a Due. This is the version message:

[ver:1.1f.20220906:]
[opt:vnslw,35,1024,5,0]
[newopt:enums,rt+,noprobe,tc,sed]
[firmware:grblhal]
[nvs storage:*flash]
[driver:sam3x8e]
[driver version:2200907]
[board:ramps 1.6]
[aux io:3,3,1,0]

[terjeio]

I am not able to reproduce this. However, there might be a reason for this: if using native USB connection and sending soft reset immediately followed by further commands data might be garbled. This is due to the flush routine emptying both the USB and the grblHAL input buffers on a reset. Do you wait for the welcome message after a soft reset before resuming sending?

If using native USB can you try with commenting out this line?

[GrblGru]

I have tried sending the commands with an external terminal program. With it everything works.
Only with my program it does not work. This indicates that my program is the cause.
But with GRBL and Mega-5X it works fine and I can't find any error. I can change whatever I want. It's always the same.
As soon as I send "\x18" from the SIO-thread I get different error messages at the next command.
Even when sending "?" there are errors.
It makes no difference if I send the command immediately after "\x18" or 5 minutes later.

I don't understand what you mean by native USB. The DUE has 2 USB ports, from which I use the one named "Programming ATMEGA16U2". I also used this to load GrblHAL into the controller with the Arduino IDE.
The other interface "Native USB SAM3X" I have not used.

Is it possible to load GrbHAL directly into the DUE with e.g. bossac.exe ? Maybe you can provide me with a corresponding file. This would allow us to eliminate errors that I may have made when creating. Or does that not make sense ?

[terjeio]

This is odd. Other senders work? I have tested with ioSender and that works as it should.

I don't understand what you mean by native USB.

Native USB is when the USB communication is handled by the processor, the programming port has the ATMEGA16U2 chip in between which translates USB to UART (serial) comms and is limited to the baud rate set in the processor. Native USB is typically not limited - I have seen transfer rates in excess of 400kbytes/sec with the Teensy 4 - a 40x speed gain over 115200 baud!

Is it possible to load GrbHAL directly into the DUE with e.g. bossac.exe ?

Yes I believe so, however I have never tested that.

Maybe you can provide me with a corresponding file.

Perhaps you can try the web interface that I am currently working on? I have not verified binaries generated for the Due yet - nice if you can do so.

[GrblGru]

I have now tried a lot again, but cannot find any error in my sequence.

I can also send the command sequence to the controller via my command line. Then it works exactly the same as with an external terminal (CoolTerm). Inside my program it does not work. I think that the difference is that in terminal mode the input buffer does not run full.
But in normal program mode many more lines are sent. I count the sent characters and make sure that max 120 characters are in the send buffer. (Streaming a G-Code Program to Grbl https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface)
You will surely take care on your side that there are no incomplete sentences in the buffer.
But I suspect that there is something wrong with a soft reset in this area.

Is it possible that you log the received commands in a file ? Then you could see if I am not still sending something wrong.

[terjeio]

I count the sent characters and make sure that max 120 characters are in the send buffer.

The input buffer for most grblHAL drivers are 1024 bytes, the smallest 512 bytes (F103). The size is reported in the $I response.

Is it possible that you log the received commands in a file ?

Sadly the Arduino IDE does not support debugging. A pity that my STM32 boards worked with GrblGru, these are debuggable...

I have tried with your latest beta, as mentioned above STM32F446 and STM32F756 works - the Due does not. No issues with ioSender.
I wonder if this is somehow similar to the Pi Pico issue recently reported where ioSender worked but two others did not. USB driver related?

[GrblGru]

I think there is a misunderstanding. BOTH boards (DUE and also STM32) deliver the error at soft reset.
So with your STM32 board it should be debuggable.

I have found something how you might be able to reproduce the error with a terminal program.
I used CoolTerm.

1. First transfer the following lines. Thereby X is moving very slowly.

G1 g90 F20 X1000
G91 F1000
G3 j-3.000 y-6.000 z-1.500
G3 j3.000 y6.000 z-1.500

2. Interrupt the move by typing "!"

3. Now enter "Ctrl X" for soft reset.

4. Now enter "g1 g90 f100 x200" or something else.
   An error appears.

Is there an error in the lines ? Actually only the first line is executed and then the program is terminated.

[terjeio]

So with your STM32 board it should be debuggable.

My STM32F103 sadly let out the magic smoke a while ago so I cannot debug with that.
However when I test with your sequence above I am able to duplicate on the F756 and yes, there is a bug - in fact a regression dating back more than 3 years! Strange that it has not been reported before, could be due to you always issuing a feed hold (!) before reset when a program is running? I belive most, if not all other, senders has a separate reset button that immediately stops any motion.

BTW I was led astray by another error from the Due emanating from my test program, it had a M7 command (mist on), which is not supported by the board I tested with.

I have already updated the source for the Due that is used by the web builder, will commit to github a little later.

[GrblGru]

Great that you were able to fix the problem so quickly.
I just loaded the DUE bin from the web builder. Now it works :)

Thanks again for your great program. I'm looking forward to trying out all the features. :)