Sudden program stop in Grbl Controller

[muddlinthrough]

While using Grbl Controller with a g-code file of about 1.5M lines, the program crashed about line 651510. The spindle continued to run and the machine went hard to the +X stop. Needless to say, the piece is ruined. I did have the Feed Override set at 200 since the steps were very small and very little material was being removed (soft wood).

Here is output in the Console interface. I did check and couldn't find anything in the following code that might have been buffered and would have triggered the Error 25.

Any insight into what I did wrong would be appreciated. I have only been using the program for a few days, so please forgive me if I've left out important information or included too much.

Thanks.

X3.5193 Y0.7414 X3.5207 Y0.743 X3.5216 Y0.7451 X3.522 Y0.7472 Y0.7493 Z-0.3688 Y0.7512 Z-0.368 <Run|WPos:89.464,19.386,-9.375|Bf:0,39|FS:926,1 Y0.7528 Z-0.3668 Y0.7541 Z-0.3651 Y0.7548 Z-0.3632 Y0.7551 Z-0.3612 G0 Z0.2 F20 X3.2218 Y0.7906 G1 Z-0.3533 Z-0.3612 X3.222 Y0.7908 Z-0.3632 X3.2224 Y0.7915 Z-0.3651 X3.2231 Y0.7925 Z-0.3668 X3.224 Y0.7939 Z-0.368 X3.2251 Y0.7955 Z-0.3688 X3.2262 Y0.7972 Z-0.3691 X3.2303 Y0.8038 X3.234 Y0.8107 X3.2373 Y0.8178 X3.2401 Y0.8251 X3.2424 Y0.8325 X3.2443 Y0.8401 X3.2456 Y0.8478 X3.2465 Y0.8556 X3.2468 Y0.8612 X3.2471 Y0.864 X3.2472 Y0.8654 Y0.8661 X3.2471 Y0.8668 X3.2467 Y0.8681 X3.2461 Y0.8694 X3.2457 Y0.8702 X3.2451 Y0.871 X3.2433 Y0.8725 Error:25 Repeated g-code word found in block. Error:2 Missing the expected G-code word value or numeric value format not valid. Error:25 Repeated g-code word found in block. Error:25 Repeated g-code word found in block. Alarm:1 Hard limit has been triggered .... etc.

[zeevy]

Looks like gcode generated is not fully compatiable with grbl 1.1 firmware. The reason for hard limit trigger can be due to spindle back emf. If you are using usb OTG connection then there are very good chances for interruption because of the back emf.

Try to run the machine without spindle on and with out wood to troubleshoot.

[muddlinthrough]

I probably wasn't clear. The "<Run...." line is not in my code. It looks like a machine status that was output to the console by the Controller software. What might cause the app to output that line? If the app did output that message while my g-code was running, would that cause the Error 25? I see that there is "FS" in that line, which could be interpreted as g-code words and I don't think they are compatible on the same line.

Also, is there a way to send the console output to a file so that I can retain the failure information? I am using Grbl Controller v. 2.56 on a Samsung Tablet.

I can certainly try re-running the program, but since the error occurred about 4.5 hours into the run, I would like to do some investigating first. Is there a way to run my g-code in a debug mode? Perhaps set a breakpoint or single step through sections of the code?

Thanks.

[zeevy]

"<Run|WPos:89.464,19.386,-9.375|Bf:0,39|FS:926,1" are coming from firmware to app console. not sent by app to firmware (you can turn them off)

There is no option to send the console logs to file in app.

"Error:25" is coming from firmware, please check the compatibility of the generated.

This application does not do any pre processing of gcode, so if the gcode is not compatible with grbl firmware then it will not work (other senders like UGS, Candle may work as they do the pre processing of gcoce and remove/converts any incompatible gcode).

In app there is an option to skip error 25 (Ignore unsupported gcode commands", you can try that.

"Alarm:1 Hard limit has been triggered " you need to find way to address this

[muddlinthrough]

I think my gcode is not the problem. It is generated by Fusion 360 and I removed the M6 command. I have used this gcode to carve a piece previously and it worked. I looked again at the code and cannot find anything that would cause Error 25. That section of the code is simple XY movements.

Is it possible that the firmware status message got into the command buffer? After printing the status message, it looks like 32 more commands are processed before the Error 25 is triggered.

Also, after examining the work piece, it looks like approximately 25 more commands were executed that were not output to the console. At a certain point, the machine stops following the carve path and instead makes a straight cut in the +X direction until it hits the hard stop. In order to reach the point where the hard X cut starts, about 25 more commands would need to be executed that are not reported.

It looks like the Controller lost its place in the code and stopped sending commands but did not stop the machine. So the machine continued to follow the last commanded path and speed, cutting in the +X direction until the hard stop was reached. Would it be possible to have the Controller stop the machine when it loses the buffer?

I understand EM interference can cause some problems. I am using the USB OTG connection, but have a shielded cable. As I said, I have made this cut before and have not changed any of the wiring. I will look at this again, though.

If you could help me with disabling the firmware status message, I will try the job again and see how it goes.

Thanks.

[zeevy]

You can turn off firmware status messages by toggling the button "Verbose output"

[muddlinthrough]

Verbose output was not enabled during this run. How did the firmware message get through?

[zeevy]

https://github.com/zeevy/grblcontroller/blob/master/app/src/main/java/in/co/gorest/grblcontroller/listeners/SerialCommunicationHandler.java#L73

Machine status messages are shown in app console only when the "verbose button" is enabled (errors and alarms all other messages from firmware not stopped)

its a one way output firmware to app console, not app console to firmware.

Spindle EMF may cause many problems. to narrow down the issue please run the machine with spindle off and without wood.

Also there is a check gcode method available ( in both app and firmware )

[muddlinthrough]

I ran the machine without spindle or wood. Since the previous run stopped after about 4.5 hours, I ran it with the Feed override pushed up to 200%. The program ran for about 30 minutes and stopped. The last line on the console was “<Run|WPos:98.231,47.903,-5.451|Bf:0,128|FS:246,0|Ov:200,100,100>ok”. Just before that was a typical XY command.

I reset the machine and ran again, this time without the Feed override. The program stopped after 2 minutes. The last line was “<Run|WPos:10.083,59.522,-6.333|Bf:0,128|FS:508,0|Ov:100,100,100>ok”. Again, preceeded by an XY command.

I thought about what you said about back emf from the spindle. I don’t know much about electricity, but I figured this might be caused by extra load on the spindle? Since the spindle was off, I wondered if the load on the stepper motors could cause similar problems.

I checked the lead screws and they did look a little dirty. I cleaned them up a little and re-oiled them. I ran the program again and it ran to completion. Maybe it was my fault all along. Does this make sense to you?

I am still curious as to why the machine status message got sent to the console even though the verbose output was switched off.

Thanks.

[zeevy]

The last line in the app console may not be the actual command which caused the problem, Its possible that app has sent many commands before it acknowledged the error (this is due to rx buffer in firmware).

There is an option in app which will disable this buffered streaming "Settings" => "Application Settings" => "Enable single step mode". This can be used to trace the bad gcode commands.

If the machine is working faulty in feedrate more than 100%, then there is a possibility that stepper motors are not getting enough current and loosing steps. (increase in micro stepping of the driver will also decrease the torque )

USB connection may not work properly due to emf from various sources. (bluetooth is more reliable though it is not as fast as USB)

[muddlinthrough]

Enable single step mode was on for the runs I did today, so I think the command history is accurate.

If the dirty lead screws caused slow movement, could that have delayed the ok response violating the status update interval and allowing the machine status message to get through?

Fails occurred both with and without feed rate > 100%.

[zeevy]

https://github.com/gnea/grbl/issues/1158

[zeevy]

Enable single step mode was on for the runs I did today, so I think the command history is accurate.

If the dirty lead screws caused slow movement, could that have delayed the ok response violating the status update interval and allowing the machine status message to get through?

Fails occurred both with and without feed rate > 100%.

I have no clue on this

[muddlinthrough]

Thanks for the tip. I have ordered some ferrites and will let you know how they work out.

[muddlinthrough]

Sorry this took so long. Still having some issues, but am reasonably certain it is not a software issue. This issue should be closed.

Thanks.