Oh well, so much for the easy answers... Although the one thing I can tell you is that the only problem I've had with it on Win 7 is that my only machine running 7 is a couple rooms away from the machine. Both *.207 and *.215 have worked & updated fine (if a little too enthusiastically in the latter case). What exactly is (or isn't) happening? Is it giving any sort of errors when you try to launch it, or any visible activity at all? And does it show up in the task manager? I get 2-4 different OpenBuildsCONTROL.exe processes in mine. One other thing to keep an eye out for is that initially it doesn't (or doesn't always - I had some mixed results with *.207) open a window on launch - it only sticks an icon in the systray (which then promptly hides itself if you miss the initial tooltip) & waits for you to click it to open the UI. Speaking of which (hey @Peter Van Der Walt !), is there a particular reason for not opening a window right at the start (maybe coupled with a command-line switch for the people who really want to run entirely headless)? It seems a little more intuitive for desktop/laptop users (who I assume are the primary target), and it might also be a convenient way to side-step troubleshooting the .deb's issue with needing to launch twice when the icon doesn't appear (err... unless that issue turns out to be tied to the one with the menu icon, in which case... ugh...). -Bats (and I was so looking forward to an easy answer)
I think you'd have to struggle to convince Windows that anything with a .exe isn't executable. It's pretty superficial about that sort of stuff. -Bats (*waggles fingers at CPU* "This is not the executable you are looking for" CPU: "This is not the... hey! It's got a .exe! I'ma gonna run it anyhow!")
I also cannot get this latest version to open. it starts to but just freezes as a transparent box. Running on windows
is there anywhere to download earlier versions of openbox? I rolled back to 148 because 215 isnt working for me. but miss alot of the functions in the more recent versions
Yes, it's definitely .exe. Bats, I am getting the same issue as Campbellcastle. Sometimes is goes directly to giving me a transparent box, and sometimes it shows the icon then I click the icon and up pops a transparent box. Yes, it shows up in task manager. I re-downloaded .207 and it worked great. Just ran a job.
This is where Batcrave sent me to before to download .207. I just downloaded the 1.0.207 exe. It booted up immediately when I started it. OpenBuilds/OpenBuilds-CONTROL
Here is the information we have. I have already uninstalled and reinstalled nodes several times according to the instructions below, but the same error always appears. curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash - sudo apt-get install -y nodejs sudo apt-get install -y npm sudo npm install -g npm@latest DEBUGCONTROL=true node index.js Console Debugging Enabled Starting OpenBuilds CONTROL v1.0.216-internal-test Error: The module '/home/pi/Desktop/OpenBuilds-CONTROL/node_modules/@serialport/bindings/build/Release/bindings.node' was compiled against a different Node.js version using NODE_MODULE_VERSION 76. This version of Node.js requires NODE_MODULE_VERSION 64. Please try re-compiling or re-installing the module (for instance, using `npm rebuild` or `npm install`). at Object.Module._extensions..node (internal/modules/cjs/loader.js:718:18) at Module.load (internal/modules/cjs/loader.js:599:32) at tryModuleLoad (internal/modules/cjs/loader.js:538:12) at Function.Module._load (internal/modules/cjs/loader.js:530:3) at Module.require (internal/modules/cjs/loader.js:637:17) at require (internal/modules/cjs/helpers.js:22:18) at bindings (/home/pi/Desktop/OpenBuilds-CONTROL/node_modules/bindings/bindings.js:112:48) at Object.<anonymous> (/home/pi/Desktop/OpenBuilds-CONTROL/node_modules/@serialport/bindings/lib/linux.js:2:36) at Module._compile (internal/modules/cjs/loader.js:689:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10) { Error: listen EADDRINUSE: address already in use :::3001 at Server.setupListenHandle [as _listen2] (net.js:1277:14) at listenInCluster (net.js:1325:12) at Server.listen (net.js:1412:7) at Object.<anonymous> (/home/pi/Desktop/OpenBuilds-CONTROL/index.js:55:59) at Module._compile (internal/modules/cjs/loader.js:689:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10) at Module.load (internal/modules/cjs/loader.js:599:32) at tryModuleLoad (internal/modules/cjs/loader.js:538:12) at Function.Module._load (internal/modules/cjs/loader.js:530:3) at Function.Module.runMain (internal/modules/cjs/loader.js:742:12) code: 'EADDRINUSE', errno: 'EADDRINUSE', syscall: 'listen', address: '::', port: 3001 } { Error: listen EADDRINUSE: address already in use 0.0.0.0:3000 at Server.setupListenHandle [as _listen2] (net.js:1277:14) at listenInCluster (net.js:1325:12) at doListen (net.js:1458:7) at process._tickCallback (internal/process/next_tick.js:63:19) code: 'EADDRINUSE', errno: 'EADDRINUSE', syscall: 'listen', address: '0.0.0.0', port: 3000 }
Did you first have a newer version of node, then did the npm install, then downgraded nodejs? Delete node_modules and rerun npm install You are trying to run two instances of node index.js, so the ports 3000/3001 is already in use by the other process. "sudo killall -9 node" to kill them all Debug log from a run without other instances might be more interesting - so redo that test on a fresh run
Alrighty then let's log this is as a real bug on git please. I am on leave today but will tackle that one tomorrow
I suggest running it twice, you say the problem is that he's already running it twice... Maybe we should compromise and have him only run it one and a half times? -Bats (bash: killhalf: command not found)
The Pi Build runs of NodeJS, makes a webserver, local install of Chromium used as UI. No electron, no systray, etc: refer OpenBuilds/OpenBuilds-CONTROL and OpenBuilds/OpenBuilds-CONTROL
I suppose that means no one-and-a-half processes either then. Probably for the best. I'd actually be really curious to try playing with it on a Raspi - it'd make for a cute little control box, and it would certainly simplify some cooling issues I've been nervous about on my CNC PC - but I think I've made my life... "interesting" enough with the desktop linux version, that I really don't need to add any more complications. Also, my Pi is a first gen (first batch, even) Model B, which I'm sure would expose me to a whole world of issues that were since resolved & features that weren't yet implemented (and did they ever figure out how allow the composite video & analog audio outputs to work simultaneously without horrendous noise?), which makes things even more.... "interesting. -Bats (and when I say "interesting", I mean a gigantic ****ing pain in the bat. "may you live in interesting times" indeed.)
Too slow (; Well havent had a Pi4 across my desk yet, but the Pi3 suffers with decent sized jobs, you can disable the 3D viewer in Troubleshooting tab and it helps, but where the fun then (; The main reason we don't intend providing any more info/support than OpenBuilds/OpenBuilds-CONTROL is that we simply can't be offering Linux tech support too (; - instructions are there, but you are on your own (;
Just updated to the newest build after upgrading from 1.0.918 and my machine now drops connection repeatedly whereas before it was stable like a rock. Going back to the old build now.. Winxp rig, no real updates in like..forever..because this is an exclusive offline cnc box. It never hooks up to the internet, no web browsing etc. Not sure if that makes a difference, but I hope to slowly creep up in updates where the touchoff plate comes in. That'll make my setups much handier.
How did you get it to install on XP in the first place? I was in the same situation as you, but when I'd tried to put CONTROL on it, the installer told me to piss off & that it was too good for XP (not having a spare Win 7 key lying around, that's what flipped my CNC box over to linux). Or is the Win 7+ restriction unique to later versions & it was possible to dance around it when updating from an old install? (not that that sounds like a terribly great idea) And not that I really want to go back to XP, I suppose - and it's entirely possible that the problems you're seeing are part of the reason they dropped XP support. If you're stuck (for whatever reason) with a version without touchplate support, or need to probe in ways the wizard doesn't support, allow me to introduce you to the G38.x series of probe commands. A quick, bare bones Z probe could look something like this: [Bring your tool down to somewhere less than (in this example) 10mm from your touch plate, and MAKE SURE your plate is connected & working - your tool and plate will both thank you for wasting a little extra time to double-check. Don't ask me how I know. Or how many times] Now, in the console: Code: G21 (or G20 for inches - make sure the machine's operating in the units you think it is. This can even be stuck in front of the "G38..." bit as one long command) G38.2 Z-10 F150 (not a Ford pickup; probes downward at 150mm/min for no more than 10mm & stops on contact) G92 Z [plate thickness] (zeros your Z axis by setting the current position to the thickness of the touchplate) (eg, "G92 Z20" for the nominal thickness of the standard OpenBuilds plate - although it's good to measure yours first) [edit: clearly I don't understand WCS as well as I thought (which wasn't very well to begin with). While I used to be able to get away G92 on my Mach/Gecko system, it's been causing trouble for me with CONTROL/BlackBox. Instead, try the rather more unwieldy "G10 L20 P1 Z[plate thickness]" as the third line] If you want to make the position more accurate, use a lower feed rate in place of the F150. Or, if you're impatient but still want accuracy, you can get a little fancier - probe down quickly(ish - high speed probing gets ugly fast (no pun intended), and can overshoot the mark - which can mark up your plate (pun not entirely intended?), or damage a delicate tool) with the G38.2 line, and then follow it up with something like "G38.4 Z1 F10" (basically the reverse of the earlier line - this one moves the probe away from the plate for 1mm at 10mm/min, and stops as soon as the probe contact breaks), followed by zeroing with G92 as before. If you want to get really fancy, with the right plate you can also use G38.x in X & Y for things like locating corners, or the center of circles... but as that gets trickier, I'm going to use the traditional academic copout and say it's "beyond the scope of this document". Also, the first couple times you do this, keep your hand by the "OH !" button & do a visual check to make sure your new zero actually looks pretty--close to zero before actually running anything. Even if you didn't misunderstand or botch something typing it in, it's entirely possible that I botched something explaining it. Ok, entirely likely that I botched something. [edit: yup!] Once you've got it working the way you want and overcome whatever traps I inadvertently laid for you, you can toss it in a macro (err... if you've got a version with macros - I don't really know when those were introduced... worst case, a notepad doc that you can copy & paste from). You'll only have to change it when you get a new touch plate... or accidentally drive tools into your current one so many ing times you need to re-flatten the top & plug in the new measurements*. -Bats * unless by some chance you're actually competent, in which case your experience may differ. I wouldn't know, never having been competent myself
While this should be unlikely, what specifically does the error log show when it drops? What controller is in use here?
Ok, so I was mistaken - I was on several boxes during the day and zigged when I should have zagged lol The box that runs my Workbee is a Windows 7 platform, not the XP I mistook it to be The controller being used is one of the early black box controllers, 385oz-in motors on a (don't hate me) Chinese Workbee 750x750.. It fit the room I had and was the only thing I could afford.. The problems that I was having was that I would connect the black box, set my piece up, start my spindle and then my machine would drop connection to com port 4. (I didn't write down the error) I tried different ways of hooking things up and it would always drop connection as soon as I turned on my spindle. The thing confusing me was that it used to work just fine before the Control update. And now that I have a previous version running, it works just fine again. My spindle control cable isn't anywhere near my USB cables or stepper control cables. If I can figure out what the problem is I'll happily do what it takes because I'm eager to hook up a z probe and being able to use the XYZ probing function would make things run like silk. I'll try to replicate the error tomorrow (Saturday) by updating again and trying to run it, then I'll post what I get.
VFD spindle? Those things generate a tonne of EMI so that it worked before was maybe just luck, magic, a wire routed a little further away, or similar. EMI from spindles are a pain, thats why we recommend a simple Dewalt router instead (simpler, works fine, and doesnt mess with other systems) so plan to mitigate by - space VFD and spindle cables far from other electronics (suspect spindle power cable from ceiling, for example) - Add ferrite cores to any signal/usb wires - route USB far from any power/motor cables
It came with the machine package so I just went with what I got. You're right though, the spindle is a pain in the kiester..lethal voltage piped though something you have to solder from the get-go to make sure it's grounded plus making sure all the various setting are correct or you get the 'magic smoke'.. This one dies and I'm going to a router for sure. We just bought a house with an actual shop so I'll be able to set this up like it's meant to be rather than sitting outside on my back porch lol Thanks for the info, much appreciated!
Not just the BlackBox's USB cable, either. My prior motherboard was more sensitive to EMI than my current one (possibly because it was made in the era of the capacitor plague and they were on the edge of blowing their guts) and it turned out the cable from a gamepad was acting as an antenna (despite being several feet from any other wiring) - whenever the VFD hit a certain frequency, the PC would die. Unplug the gamepad? No trouble. Unfortunately that gamepad was my pendent, which made things difficult. Another recommendation that's usually made when battling VFD noise is that when you can't route the cables entirely away from each other (since sometimes there's no choice but to cross the streams wires), to make sure they cross at a 90° angle. -purp (sad thing is, I think now I almost miss the gamepad more than I'd miss the VFD)
True story! Using a Cut40 HF start plasma, I had to add ferrites to every cable going into the laptop (mouse, keyboard, power, etc) too else it would freeze up when the plasma triggers on
Huh..who'da thunk.. Well, I guess my education in small electronics grows along with my education in engineering I suppose. Good to know though, once we move to the new house I'll have a better idea on how to set things up in the garage for a more permanent home
On the newest revision (v1.0.215) I'm having issues with the Z probe wizard. It defaults to 20mm for the Openbuilds probe but I can't figure out how to make my own probe preset or permanently change the default from 20mm to 3.9mm (the thickness of my probe). I am manually changing it each time I start Control. FWIW, I tried clicking all of the little pictures on the icon first this time before I asked another "how do you edit a macro" question...
Yeah, right now it always defaults (and reverts) to 20mm when you run the probe wizard. I figured I'd already exceeded my quota of whining about that particular wizard & should just deal with it for now, but, yeah, I found it frustrating too. It seems to me like the easiest compromise between their preferred "No Settings" stance (and the obvious preference for primarily supporting the plate they offer) and making life easier for the rest of us would be to just save the previously entered value - maybe with a "reset to default" button if there's a worry that a new user will accidentally set it to something else & need to be rescued. -Bats (a new user who apparently doesn't own any measuring tools... and can't check the specs on the part store... or measure it with the Z axis... but they're probably out there)
... just wait... The current implementation was just a step on the road to an even better experience, thats why theres no "save last used value" nonsense etc, we were too busy working on the REAL deal instead... Patience my friends... its a virtue. And something about "good things come to those who wait" (; ETA a week or so, waiting on some other internal process before this can be releases (; (v1.0.220 or later)
Peter, I figured you were all over it if it wasn't another PEBKAC error on my part. I really like Control as it does everything I need and if you know how it and grbl works, you can pretty much configure it how you need it.
First of thank you for the awesome Control software - It really works nicely especially since Estlcam does not support the XproV4 (sorry, wrong info - does not support the bluelink bluetooth). The only problem that I sometimes have is that when I pause a job I do need to move the spindle around or after a tool-change I need to manually zero the Z again - Because I cannot move it the Spindle or re-zero the Z, I have to Pause, stop the job. Change the tool, re-zero X - edit the gcode to skip the parts that are already done and continue the job. Would be nice if there would be an overwrite to allow tool movement in a pause state and re-zeroing X.
The V3 and V4 are functionally identical - you can use the V3 setup from Estlcam Pausing and moving: Not in line with the intended audience of CONTROL (absolute beginners) as it may endanger the user or the machine if moves/commands can be executed without knowledge of what they do, or how to correct before resuming a job Proper toolchanges is in the works (see Toolchanges · Issue #26 · OpenBuilds/OpenBuilds-CONTROL - lots more work to do) but the correct way to handle toolchanges at the moment is to split each tool into its own GCODE file - that ensures positions can be set, header info is sent again, everything is setup right for the next tool. And even better, can run that finishing pass that won't finish in time today, next weekend, as its nicely split off into another file (;