Open JJZ71 opened 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
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.
ok got reply, having a look now
Just for reference This is a link to a useful simulator to test code https://camotics.org/download.html
Thanks MeJasonT, I installed and ran the gcode, all I could see was one warning about not having a tool selected.
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
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?
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.
is this your control board
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.
I have an UNO R3, is sounds like it might be rf/electrical noise
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)
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
Thanks, MeJasonT, I'll play with it tomorrow and report back.
This is an EEPROM issue. See the FAQ. Try not to stream three consecutive g10 commands. You can combine the into one.
Chamnit, so your saying I need to run a $RST=*
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.
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.
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.
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.
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
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
I just have submitted PR #641 for eeprom prblem. This should fix the issue.
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?
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.
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.
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?