It's a CNC compatible model (stamos 125h cnc), it's turned on by the blackbox. The thing is that it has been working up to now, and I cut 5 identical parts without issues and the 6th fails while I changed absolutely nothing. The issue I had before starting was that openbuilds controll seemingly self destructed initially, it crashed and destroyed the shortcut icon.I had to reinstall and seemingly all my grbl settings were saved. Though this was before cutting the 5 parts.
The reason i was asking, is that HF plasmas with their high voltage pre-arcs are known to cause both electronical damage, or corrupt EEPROMs. Have you tried a 7th attempt yet? Clean start, Rezero, load the file, make sure you are all set and no other funny gcodes sent via terminal before hand. Make sure you are using the same exact GCODE file you used for the first 5 (re-CAMing can introduce differences) Not typical of CONTROL - sounds like that computer needs a reformat or if its a very old computer get a new one Grbl settings are stored in EEPROM on the chip inside your controller: Please do read the entire Grbl wiki: Home · gnea/grbl Wiki - not stored on your computer or in software. Check the Grbl settings tab and see if anything changed from when it was working? Restore the backup you took when it was all set up as a test too.
I'll try to figure that out, I did have to unplug the end triggers as the arc would trigger them. The blackbox is mounted on the bottom side of the table though I do my cuts whenever possible on the opposite end. I probably did around 20-30 tries, restarting the pc, with the same code, different code, new simple code (a circle) Do you think the plasma might have damaged the blackbox? Is there a way to tell? When controlling the XYZ manually from control it works perfectly, the distances, the direction and the zero point all work perfectly. It's when doing the cut without the plasma even turning on that it goes nuts and that the XYZ positions on screen are all wrong.[/QUOTE]
Try reloading the Grbl Settings backup first (or redo the settings if you forgot to take a backup) and we will take it from there
I reset to factory settings but to no avail. I did however discover that when the plasma cutter is powered off that the path is executed perfectly, but as soon as I turn it on the path goes all over the place asif it is messing up the XYZ data so the control tries to compensate. I placed the plasma cutter as far as possible from the table, doesn't fix the issue. I disconnected the plug that connects the plasma to the blackbox, while the plasma is powered on and then the path is correct. So the issue only appears when the powered on plasma is connected to the blackbox, and the path only goes crazy from the moment the plasma is supposed to be triggered on. Do note that the plasma never actually arcs since the issue appeared. So the path goes all over the place while there is no arc, it goes crazy as long as the blackbox is sending arc-on signals to a powered on plasma cutter.
I just managed to do the cut whe setting the plasma to manual mode, so I held the trigger while it did the cut. It helps me move on with the job but doesn't fix the issue. I did have to do several tries as it would't easily arc.
Hi there. Total newbie trying to get my Acro system up and running with mac (10.16.4). With regard to using the Openbuilds Control with the Black Box, I'm just getting an error message when I try to connect: PORT ERROR: Error: Resource busy, cannot open /dev/tty.JBLGO-vCOMM. Have tried with both ports but nothing. Any ideas? Thanks Robin
Indicates some other application is already accessing the port. Close any other running (even background) applications Make sure the FTDI device is present and FTDI drivers installed Try a different computer
I've found a mistake on my end that made me smile. This certainly WON'T be a problem for common users, and I assume that users encountering this "bug" will quickly realize what caused it and how to fix it, but.... here it is. I ran Control this morning only to find out this was displayed instead: I don't know what the default port is for OpenBuilds CONTROL, but for what it is worth, Vue/Vite's (which I was playing with last night, and left the server running) default setting is http://localhost:3000/ Have a great day people!
Thanks Peter I assume it's not trivial to just have it use the next unused port because that would mean than OpenBuilds CAM would no longer know where CONTROL is. Am I right?
Lots of other integrations too. Pick any TCP port and I'll find you at least 2 other potential conflicts. Just close conflicting applications.
So, if I open a websocket to control and just do nothing but log the events via an esp32, control eventually crashes. Also, status updates every 50ms seems insane.
We don't use WebSockets, we use Socket.IO which can backwards support websockets as a fallback, but, not the intended method. The 50ms update interval works great on our applications too Could also relate in how you connect - be careful to open a singular connection once and maintain it - bad code could try to initiate a new connection every loop - resulting in building up a tonne of "clients" connected
It is socket.io. I'm just using a websocket library that supports socket.io. It's just a single connection and then reading the events looking for a 2. This crashes it. I can cope with the 50ms update, that's just an aside.
Post your code - although this might be better off in a Github issue, not really a CONTROL support issue - but happy to take a look and help you debug. See Build software better, together
Sounds good. I just found a couple comments on the esp32 wifi that I want to double check. Might give the wifi to the second core.
my understanding is that the wifi is on the 'other' core by default. would have to read the library code to confirm.
Hello, I've noticed a potential issue with OpenBuilds Control. The program will lose the ability to jog and also run a program. The control software is not locked up, as selections may still be made, but clicking any of the buttons to jog, as well as trying to jog with the keyboard, does not cause the machine to move. This happens pretty regularly. The other issue, which happens less frequently, is that the Run button will be grayed out after opening a G-code file. This seems to be related to the jogging issue, as that functionality is lost when that occurs as well. I am using v1.0.312 on Ubuntu.
No other reports. Are you running any custom macros? Try a different PC? Open stays grayed out until the file is loaded - slow PCs can crash on large files regardless of OS (however in Linux particularly make sure your GPU drivers works properly - as the 3D viewer uses WebGL extensively)
Thanks for the reply. No custom macros. Unfortunately, another PC is not an option, as the C-Beam XL lives in the garage. Regarding the second problem, I'll pay closer attention next time it happens upon loading a file. The PC is pretty old, so that seems like it may be a possibility.
New to using the software, but I cannot seem to be able to update grbl to 1.1. I have the new grbl downloaded, but I don't know the guts of the software to update it.
