Hello again... So..the program has no faults on the start up. However the log/serial console lagging as hell! I tried the dark mode and everything is smooth like baby's skin! So I will use the dark theme for now!
Hello peter, I updated Control and the machine is now running on control 0.367. So far no problems. Greeting Bert Klappe
Getting a lot of errors!! What's that? After homing I try to get the head up and down and this happens! Anyone know?
It could be that something else is trying to use the same port, or you haven't disabled USB selective suspend - advanced section of Windows power settings. docs:blackbox-x32:faq-usb-connection-failed [OpenBuilds Documentation] Alex.
I don't have blackbox..my controller is xpro v3. Do you think is a power issue? Somewhere I read about the volt are not enough for motors and controller and that cause controller to disconnect! Have you heard any of these? Thanks in advanced!
you don't have to be very good (-: just visit Issues · OpenBuilds/OpenBuilds-CONTROL and click the 'new issue' button, birght green, right hand side, then fill in the information requested.
Let me start by saying that I've been using the software for a bit and it is my preferred tool for what it does. However I do have a question and a feature request. As far as the question is concerned, is there a way to stop the daemon portion from running at startup, shy of modifications to the system start list? I did have the tool set up to not start at boot automatically, however the last update I did overwrote that and it auto-starts again. As far as the feature is concerned, would adding the troubleshooting screen to the web interface be possible? As a use case, I show that page and test that the probe is working after I attach it to the end mill, before placing the other portion on the work piece. This allows me to hopefully avoid things like breaking end mills due to a broken connection. It would also be useful when testing limit switches, etc. Currently I have to turn my laptop to face me while testing the probe risking popping the USB cable out (this has occurred a couple of times).
I was thinking about a easy visual probe continuity check as well, instead of having to go to the troubleshooting page each time. Something that I do with another control system that I build, is to make the probing button change color when triggered. Normal image not triggered, and bright green or red when triggered. Maybe that's something that could be done with OBC's probe button.
Thanks for the suggestion, but continually checking continuity indicates some problem, you should be able to trust it. Why do you not have continuity often enough to warrant the constant checking? Rather address the problem. Are you clipping to the collet as advised? Is your wiring good? What is the root issue why you have issues in the first place.
Oh, no problem, just a "comfort" check for a completely new to CNC user. Until he's confident with the processes, I want him to double check. That and the new collet on the router has what I'd call a "Parkerized" black coating that I've noticed doesn't always make continuity. In time it will wear off and be fine. He'll also be using some small tooling, and there's not much length to them to get the current clip on, thus the desire to check when clipping to the collet. The green led on the BBX32 works, but depending on the mounting location, a quick screen indicator on the main screen would be nice as well.
@Peter Van Der Walt just out of curiosity, are there any plans to add support for things like Edge finding touch probes and automatic tool height sensors to Control?
hmm, I might have to outsource that to chatGPT as I can’t code to save myself. A built in wizard, like the current probe wizard, would be ideal IMO.
I use one of the touch plates sold by Blue Ox Solutions on EBay. I created macros for the 3 sizes of endmill that I use, since the X and Y offsets change. I built them from examples I found on the Internet.
An even better approach is to probe X and Y using an accurately turned rod (gauge pin) and then change to the bit to probe Z. Only one macro needed and you don't have the problem of having to change the offsets to allow for inaccuracies in the diameter of the bit. Alex.
Just to circle back to this issue - I found something by accident today. I needed the simulation feature to validate my tool path for an operation, so I turned on the 3D viewer after I had already loaded the Gcode file. And what do you know, it fired right up and didn't smash my CPU for 5 mins like it does if I load a new Gcode file with the 3D viewer already on. This strongly suggests to me that there is an "order of operation" issue in the Control software (and is being masked by those with fast CPU's). Yes, my CPU can't pull the skin off custard, but it's clearly not so slow that it can't run the 3D viewer.
Sample file to reproduce? Only one that really does slow down with viewer, and really does not with the above procedure. Reproducable examples are the only good way to find rare observations. Also remember to measure both ops. File load > into gcode editor (takes a bit of time to render the colored markup too). Then renders in 3D view. Taking a break between the two and measuring only the second is not objective in the usual workflow at all happens in one "period" of waiting. So do add up the two periods Yes just 3D view will be faster, as it already loaded into the gcode editor earlier...
Ok, I've replicated it for you, with reboots in-between the 2 major tests to ensure fairness (Gcode attached). On average, it takes 1 minute 30 Seconds for my laptop to start responding again if the 3D viewer is enabled, vs instant Gcode loading with it off. It takes only 10 seconds to turn on the 3D viewer and wait for the app to restart itself and load the 3D view data. In a nutshell, there is 1 minute and 20 seconds of missing time being wasted here by something being amiss in Control with the 3D Viewer enabled? EDIT: just fixing the video, somehow I only uploaded half of it. EDIT 2: and Fixed - sorry for the video quality, one of the fluro's in my garage is out and the poor lighting makes for a grainy video.
The software is free, so I personally don’t mind Open Builds plugging their products during the loading process.
It changes from time to time, either an OpenBuilds Logo, or news, sometimes a coupon you can use in the store, etc. Whatever it shows, takes place while the main app is loading in the background. By the time the app is loaded, the splash screen is faded out. It's called a "Splash Screen" - learn more about what that is, over on Splash screen - Wikipedia
Unable to replicate, all three test files loads in super fast time over here (realtime GIF below out of Screen2Gif) | PS: some of the load time is hidden behind the splash screen on refresh Sidenote? Is that Windows on a Mac?
I timed the entire reload process from the time I clicked off the "disable 3d viewer" option to the time Control showed the 3D view. It was 10 seconds (you can verify that by timing the video). Yes, it's Windows 10 on an old MacBook with a 2 Ghz Intel Core 2 Duo, 6 GB Ram and a 250 GB Samsung SSD. The fact that it's a Mac running Windows is not relevant, nothing else I run on it has any odd behaviour, and I'd never had any issues with Control until around the time the UI got Dark Mode (which I very much like). Btw, what system specs are you testing on? PS, I can't replicate it in a dual core VM (HW = i5 Hex core), but I'll dredge up an old Dell Core 2 Duo I have lying around and try that.
Ok, so I fired up my old Dell OptiPlex 755 with a Core2Quad @ 2.8Ghz, installed a clean copy of Windows 10 Pro onto an SSD, and OB Control instantly loaded Gcode files and showed the 3D view. So I took out the Quad and installed a Core2Duo @ 2.4Ghz (so only 400Mhz faster than my MacBook), and same thing. I'm beginning to wonder if my OB Control install on my laptop got corrupted during an upgrade somehow.
