I almost finished building my Arco System and started working on electronics. I have CNC xPro V3 board with GRBL V1.1. I use GrblControl software. I didn't connect anything to the board. I got Error Codes 6 and 9. I found out that Error Code 6 means no homing switches are installed. I don't know that Error Code 9 means. I didn't buy any switches. I connected the board to an 24VDC PSU made for CNC routers and 3D printers. How can I fix the Error Code problems?
the full list of error codes is here Grbl v1.1 Interface · gnea/grbl Wiki · GitHub seems to me your GRBL is set up for home/limit switches but they are not installed. read this Grbl v1.1 Configuration · gnea/grbl Wiki · GitHub and turn off homing and limits.
I can't enter anything in the textbox because GRBLControl keeps on flashing the error codes every second.
but wait, if you are using 'grblcontrol' and GRBL1.1 then it will never work since GRBLcontrol has not been updated to work with GRBL 1.1. rather use Candle 1.1.7 Releases · Denvi/Candle · GitHub
you read Grbl v1.1 Configuration · gnea/grbl Wiki · GitHub (config) and set the appropriate variables according to Set up the Homing Cycle · gnea/grbl Wiki · GitHub (homing) where it explains how to turn it on, you just turn it off.
I found out that GRBL Panel software works. I can jog the machine. I should be getting the switches from Probotix.
I'm having a similar issue - Running a CNC xPRO V3 on an oxcnc build with macOS. It was running fine, but my old mac died, so I replaced it and now I get an endless loop of error:9 whenever I connect to the board. Did alot of reading and tried every possible solution I could find but to no avail. Would appreciate anyone's suggestions on how to resolve this problem. Cheers.
error:9 is "G-code locked out during alarm or jog state". so why is it in an alarm state? do you have homing switches? anything changed? check the GRBL setup carefully. What GUI are you using? it may have had settings on the old machine that you need to duplicate on the new.
I can't pinpoint why it is an alarm state. Yes, I have homing switches and physically nothing changed other than running it on a new computer. I even tried physically disconnecting the switches to see if I would get a different response but it's the same. I did reflash the board to GRBL 1.1f to see if that made any difference but same error and I have gone through the GBRL setup to check that the settings are the same as when it was operating properly. I was using UGS. I've also tried UGS platform and OpenBuilds CONTROL but all report that the board is in an alarm state that I can't get out of.
Dump out your Grbl settings for us to check. Otherwise we can only offer guesswork Send $$, copy, paste in a reply Also, copy paste the output of "$N"
First Change the GRBL settings to turn off homing entirely and check that it then comes up without an alarm. Home will then be wherever you turned it on. Then: Use the OpenBuildsCONTROL troubleshooting page to check that the switches are working correctly. Once the switches are confirmed to be working correctly you can reenable homing (but leave soft limits off) Make sure you set the 'homing pull off' to enough to release the switches reliably. The default is 1mm which is pretty much always too small. Note that the serial console will usually display details about the cause of the alarm.
Ok, so here are my GRBL settings along with most of the message string. I turned off homing but that didn't seem to resolve the issue, it was still in an alarm state. I was able to check the limit switched using OpenBuildsCONTROL and they are working correctly. It's very hard to actually change any of the settings because of the frequency of the alarm/error pop up window. I've posted the result of "$N" at the end. Thanks.
error 1 and 2 mean: 1 G-code words consist of a letter and a value. Letter was not found. 2 Numeric value format is not valid or missing an expected value. so I'd say that your PC or controller is not communicating correctly over usb. Tried a different (short) USB cable?
1) Run '$RST=*' from the Serial Console tab 2) go to Wizards and Tools - grbl Flash. Reflash your controller. 3) unplug everything to avoid any external faults from putting us on a goose chase, connect just the board, via USB to computer 4) reboot Pc 5) test again
Oh and of course all this is OpenBuilds CONTROL (known to work... Get it working here first it miggt be your other software)
Managed to reflash the controller, unplugged everything, rebooted & still got error messages. See below
While it starts up fine, then starts erroring... what are you sending/doing/clicking when the errors start... At the end, the port closed. Did you hit disconnect, or did the port die on its own... Still looks like USB comms issues if you didnt send/do anything 1) Try a different cable 2) Try a different PC 3) Make sure you have the official FDTI Drivers Virtual COM Port Drivers Last suggestion - sure you are on latest version of CONTROL (v1.0.172 at the time of this post) OpenBuilds Software - FREE Software for CNC Control: OpenBuilds CONTROL and OpenBuilds CAM Might be a clue here too... That new Mac might be the issue... Either drivers, or the ports are broken? Try a different PC (bet its gonna work fine on another PC)
Peter & David, thanks for your time and input - looks like it was the FDTI drivers. You both pointed to a USB communications issue. I had neglected to install the correct drivers on my new computer - I installed them tonight and the board is responding as it should. Haven't had a chance to cut anything yet but through OpenBuilds CONTROL, I've been able to jog and home the machine which I could not do before. Looking forward to doing some cutting tomorrow. Thanks again!
Hey Jeff, I am getting the same error 6 and then 9..... What did you do to remedy the error codes.... Thanks!
Read gnea/grbl - all errors and alarms But you need to know what ALARM (note difference between errors and alarm) put it in locked mode first Please don't split off from your existing thread about the same issue Error 9 carving Paradise Box - just makes it harder to keep track of the troubleshooting steps. In that thread the same applies. Each error 9 has a very clear history leading up to it. Please go back to that thread and provide the requested information so we can tell you what the root cause is
