gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.07k stars 1.61k forks source link

Unexpected error was detected error:22 #638

Open JJZ71 opened 5 years ago

JJZ71 commented 5 years ago

Untitled

ScreenShot059

Hi, all I have a brand new UNO R3 and CNC Shield.

I am running the same GCODE multiple times and it fails 3/4 of the time with this error but at different points in the code.

It fails even if I run it $C

I have tried CNCjs and UGS , 2 different USB cables and 2 different notebooks.

Can anyone suggest a fix?

MeJasonT commented 5 years ago

You appear not to have set a feedrate

send F100 for example

take a look at https://github.com/gnea/grbl/issues/167 https://github.com/gnea/grbl/issues/255

what control interface/program are you using It looks like you are simply jogging the machine and not running a file - is the correct

I use GRBL-Panel and Candle CNC have a look at them if you haven't already https://github.com/gerritv/Grbl-Panel/releases https://github.com/Denvi/Candle

GRBL commands are here https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands

Try sending somthing like: (G21; Set units to milimeters G90; Set absolute coordinates G1 X100 Y100 F100; move)

G21 G90 G1 X100 Y100 F100

JJZ71 commented 5 years ago

dremel gbrl postprocessor.txt

First line of the Gcode is:

G1 X1 Y1 F180

I have attached the file as a .txt

If the feedrate was missing would it run successfully 1/3 of the time? I have tried running the code on CNCjs and UGS with the same result.

MeJasonT commented 5 years ago

ok got reply, having a look now

MeJasonT commented 5 years ago

Just for reference This is a link to a useful simulator to test code https://camotics.org/download.html

JJZ71 commented 5 years ago

Thanks MeJasonT, I installed and ran the gcode, all I could see was one warning about not having a tool selected.

MeJasonT commented 5 years ago

code ran fine using grbl-panel I have a uno attached to pc without machine connected running version 1.1f Grbl as a test bed. It looks like your problem may be to do with rf/electrical noise which is affecting your communications. Try running the same test i have without your machine connected to the Uno R3 and see if that's ok - then reconnect your machine and try.

Camotics is good for checking out paths but isn't machine specific to the grbl fur-balls may not necessarily show up

JJZ71 commented 5 years ago

MeJasonT,

I tried running it in check code mode $C and it still failed.

Can you tell me how to run the test on the UNO without the machine connected?

MeJasonT commented 5 years ago

If you have a spare Arduino Uno then simply upload grbl to it and traet it as if the machine was connected to it, otherwise - is the Uno R3 inserted into your control board or is it micro processor built into your board. you want this on its own - stops you from destroying a perfectly good machine whilst starting out. T2De7aXMxXXXXXXXXX-462592119

is this your control board sku165456-2

MeJasonT commented 5 years ago

you should be able to then run code live or in check mode. As grbl does not have axis feedback and relies on its own estimation of machine position, it runs quite happily without a machine connected. If you have limit switches connected and homing set up then it will need frigged to get it to work. basically disable them in settings.

JJZ71 commented 5 years ago

I have an UNO R3, is sounds like it might be rf/electrical noise

MeJasonT commented 5 years ago

Ok check list time Screened cables for motors and end stops, preferably wired separately and earthed at one end (controller end making it the closest point to earth potential)

MeJasonT commented 5 years ago

If you disable hardware end stops and homing. set your machine up to a safe 0,0 home position using software limits you may discover that the noisy coms issue is with the end stops. It is possible to use the machine without hardware limits and without homing - you just have to be careful how your machine behaves

JJZ71 commented 5 years ago

Thanks, MeJasonT, I'll play with it tomorrow and report back.

chamnit commented 5 years ago

This is an EEPROM issue. See the FAQ. Try not to stream three consecutive g10 commands. You can combine the into one.

JJZ71 commented 5 years ago

Chamnit, so your saying I need to run a $RST=*

109JB commented 5 years ago

Both of the pictures in the first post show a reset occurred somehow. This first one shows that after the G10 commands a portion of a parser state response message was received ( [GC:G1 ), and then the reset message ( Grbl 1.1g ['$' for help] )

Once the reset occurs, any programmed feedrate is cleared.

image

Likewise, in the second one you can see a partial status report message and a reset message. Again, the reset is going to clear any feedrate info.

image

I can't say why there is a reset occurring, but it looks like whatever is causing the reset is what is causing your problem.

cheton commented 5 years ago

The character-couting protocol is used in CNCjs to stream a G-code program to Grbl, putting "G10 L20" in the middle of a G-code program will possibly cause a reset because it will persist work coordinate settings to EEPROM, and the sender have to wait for the queue to finish.

https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl#streaming-protocol-character-counting-recommended-with-reservations

When Grbl stores data to EEPROM, the AVR requires all interrupts to be disabled during this write process, including the serial RX ISR. This means that if a g-code or Grbl $ command writes to EEPROM, the data sent during the write may be lost. This is usually rare and typically occurs when streaming a G10 command inappropriately inside a program. For robustness, GUIs should track and detect these EEPROM write commands and handle them appropriately by waiting for the queue to finish executing before sending more data. Note that the simple send-response protocol doesn't not suffer from this issue.

@JJZ71 You can try appending a %wait to each "G10 L20" to wait for the planner queue to empty. %wait is a special command in CNCjs that will wait until all "ok" responses to be returned.

G10 L20 P1 X0 Y0 Z0
%wait
109JB commented 5 years ago

The character-couting protocol is used in CNCjs to stream a G-code program to Grbl, putting "G10 L20" in the middle of a G-code program will possibly cause a reset because it will persist work coordinate settings to EEPROM, and the sender have to wait for the queue to finish.

Except in his second example screen there is no G10

cri-s commented 5 years ago

I just have submitted PR #641 for eeprom prblem. This should fix the issue.

109JB commented 5 years ago

I just have submitted PR #641 for eeprom prblem. This should fix the issue.

It may fix an issue, but I don't think it is going to fix the OP's issue. If you look at the second screen, there were normal G1 commands preceding a reset. There weren't any commands that would be accessing/writing to EEPROM. Am I missing something?

image

JJZ71 commented 5 years ago

I changed from CNCjs to UGS and enabled Single Step Mode and status polling the error 22 have almost completely stopped. Hopefully, it will help narrow down the issue a little further.

ScreenShot002

MeJasonT commented 5 years ago

This is an EEPROM issue. See the FAQ. Try not to stream three consecutive g10 commands. You can combine the into one.

I'm following the thread with interest i'm trying to figure out what indicated it was an EEPROM error, from the code example i could see how the feedrate was missing but knowing once its been sent will remain in grbl until its reset or the command is overwritten. That's what gave me the impression it only happened every so often and we don't know from the example if the board was reset between attempts. Would it be possible for someone to direct me to the FAQ that Sonny has mentioned.