The past couple of days Ive been having issues with openbuilds software. It will completely stop mid carve. Ive been doing the same carve and it stops in a different spot each time. I tried to pause it and resume, nothing. I tried to stop it and restart, nothing. I tried to reload the file, nothing. The machine wont even jog after stopping the carve. Its definitely a software issue because when I try to jog it, the software doesn't register a move. I cant go back to home or move the machine in any way. Does anyone know what could be causing this? There were no alarms or errors.
Its an odd bug that hit about 10-11 of our users so far (of about 60,000 downloads) so sadly you are one of the unlucky ones It seems to only happen on specific PCs: If you have a couple minutes to help us debug it we can get it fixed much sooner 1) Find a file/pattern/etc of reliably making it crash (so when we disable something and it runs there is no doubt that it shouldve crashed but now didnt) 2) Disable the various components one at a time, only one at a time, and see if you can isolate it down to just one thing, that when its enabled, crashed the software, but when it is disabled all runs hunky dory Then we know where to look at fixing
ok ill get on that later. I charge 80 dollars/hr for debugging. But since the software is free I'll do it pro bono.. Just curious, did the other unlucky people with the issue only have trouble with some files? And did disabling the features you pointed out always fix the issue?
lol! The issue so far appears to be file agnostic, seems to be something in the 3D viewer (at least disabling the whole 3D viewer with first menu item seems to resolve the hangup, so next step is to see which subsection of the 3D viewer is playing a part) "did disabling the features you pointed out always fix the issue" - well, since its so rare, and the number of users willing/able to help even rarer, at this point its hard to say, I'm very glad you are willing to help us look too, as thats one more dataset to help find clues. For Jeff, its between Skybox and Realtime Position indicator: See OpenBuilds CONTROL Software and OpenBuilds CONTROL Software and downwards from there It could also be behaviour related so pay attention to any patterns that emerge like for example "its only happening on the first file of the day" or "only after two big jobs" etc any that sort of pattern clues can help too
PS this part is a little different from the other people... So dont spend too much time on just checking if this bug is related - it might be something else
ok i tried it again with the same file. Before i started, I disabled all 3d viewing options. It stopped at almost the same exact spot as last time. This time I got a GRBL error 9. G-code locked otu druing alarm or jog state x153.15417 y-3.16876 z-2.54
Lucky you, unlucky me, you are not one of those affected by the bug then As Grbl went into an alarm state, that does explain this part too: (those would be ignored when Grbl is in Alarm state) When Grbl enters alarm state the bell should flash too So the question then just remains what put Grbl into alarm mode: Theres a few reasons: gnea/grbl lists them all, most likely is limits falsely triggered (EMI) or incorrect GCODE (not compatible with Grbl, the fact that you stop on the same line makes me suspect that one more likely)
Unlucky for both of us. Lol I've used this file around 25 times the last month or so and haven't had an issue until yesterday so It can't be the file. I don't even have hard limits enabled so i dont know what it could be. I guess the next step is to try the same file with ugs and see what happens. If the problem persists then I know it's not software related and you can sleep easy tonight.
Y-3.16876 might be a clue. Have you got soft limits enabled? Did you home your machine (set machine co-ordinates) before setting wcs zero? Apologies if these are stupid questions. Alex.
Sorry was just assuming based on "its usually on of those" in the absense of the facts Still, if GRBL is in alarm mode, just got find out why it went into alarm to help find the root cause
Hey Alex, thanks for the input. Yes I did home before setting up work home. Any suggestions on how to do that? I'm not experienced in troubleshooting this stuff at all.
Running into issues lately also. CONTROL worked fine last week now its not working for me. Was going white frozen screen after i would upload file. So i disabled 3d rendering system and now it’ll get all the way to me hitting run, it’ll start the carve for a split sec and freeze. The coordinantes act like its running the carve but nothing it moving...so strange.
OpenBuilds CONTROL should popup with the alarm if it happens while its connected, Grbl does not store the code, only sends the alarm message when it enters the alarm state the first time: See gnea/grbl
Sounds a lot more like a controller side issue: Power to the controller dropping out? If the DROs update then comms to Grbl is still flowing and sending moves, getting feedback etc, so not software
Hey Peter. After trying a fresh install and a few other things with no change, I decided to try another file. It worked perfectly. So I guess something happened to the file? Anyway I post processed the same from fusion again and It works fine now.
I’ll check all my connections but i don’t believe thats it because everything works fine moving any axis manually with the jog. Its only when you hit run. And prior to disabling the 3d rendering system it was giving me a frozen white screen which led me to software.
Ok, when i get home I’ll enable the 3d viewer and try a different file to see if that changes anything. If it doesn’t ill post the code.
Sweet, thank you! Doubt its version related (havent made changes to the core of the 3D viewer in months)
Well, after initial findings just playing around on the computer it looks like its a series of corrupt files that i made. It threw me off because 1) i had never had a corrupted file. 2) i initially tried two separate files of a 12 layer mandala that I’m putting together for the wife and both didn’t work. Turns out i messed up 3 of the 12 files. thank you for the guidance Peter. That should do the trick. I’m planning on cutting the files tomorrow so I’ll post how it goes.
I was having a similar issue, I was random stoppages. I am using a 500watts Chinese spindle. In the most part around 10k-12k RPM no problem but as soon as i increased the speed in introduced to much noise. The way a solved the issue as by installing an RC filter on each of the limit switches and installing ferrite bead on the spindle motor wire, USB cable and all of the limit switches and stepper motor wires. Also when setting up a job to use more than one cutting tool it won't work because that option is not supported and the software will panic. I hope this helps you
Technically the software doesnt panic, Grbl does. Grbl doesnt support M6 commands. (; We are going to add support for it soonish (couple months at most) (see Toolchanges · Issue #26 · OpenBuilds/OpenBuilds-CONTROL ) to let CONTROL get in between the gcode and grbl, and react to M6 on Grbl's behalf
Thanks Peter for information, i am still new at this is been only about 4 months since i started my first cnc machine project.
I found the problem. 1- I had turned off the simulator under Diagnostics. 2- my CNC was software/GRBL was interpreting the 7" diameter work to be about 1/2 an inch and thus it was just milling on the small area as if if it was milling the whole piece. The solution. I had model the piece in Fusion 360 in imperial (inches) and generated the G-code in inches format. All I had to do was change the settings to mm in the fusion 360 design and then go to manufacture/Generate and post process the Gcode. Now Openbuilds control can display the model the correct size. Thanks you
I was having the same problem, locking up at any time, very frustrating. Being a Ham Operator, I am used to using ferrite filters, passing the USB cable twice though the filter works better.
