I’ve walked through that guide step by step. That’s why I’m not sure what’s going wrong. My system sees the controller in my device manager, but CONTROL only shows Bluetooth devices in the drop down menu. We tried it on a Windows 10 laptop and the drivers repeatedly failed to install, both automatically and manually. I’m very comfortable in Terminal and their instructions are pretty clear and simple. As I mentioned, I’ve installed all the drivers and even the D2xx Helper they recommend for Mac. There must be something simple I need to tweak via Terminal somewhere. Maybe some permissions or something. Especially since I can’t find anyone suffering my same fate...
To ease your mind that its not CONTROL, install CNCJS or any other Grbl host. You'll see they also don't show it. I dont have a Mac so cant help you directly, but its either Drivers or Permissions. Did you get the the new port dialog etc as per the PDF? Is MacOS up to date (else search 'macos version x.y.z ftdi ft231x')
On your Windows laptop, try installing as Administrator, if your virus scan squacks, select install regardless. I had my TrendMicro not happy about this installation and had to go through a forced installation as TM saw this as a threat.
I contacted FTDI and they helped me get it connected. FYI: DO NOT install the D2xxHelper unless you're on MacOS 10.11 (aka: read the instructions, idiot (read: idiot=me)). Now onto an actual CONTROL issues: CONTROL keeps adding itself to my Login Items list in System preferences, even after being removed several times. CONTROL also keeps requesting "Do you want the application “OpenBuildsCONTROL.app” to accept incoming network connections?" on each launch even though I've set it to "Allow" repeatedly in my System Preferences CONTROL doesn't quit when I choose it from the menu or hit Cmd-Q. I have to Force Quit it every time. The main window will close, but the application does not quit.
Thanks for the tips, now we know for the next guy (; Network: It should only ask once, and haven't had any other reports of this yet. I'll log it as a new bug (see ONTROL also keeps requesting "Do you want the application “OpenBuildsCONTROL.app” to accept incoming network connections?" on each launch even though I've set it to "Allow" repeatedly in my System Preferences · Issue #40 · OpenBuilds/SW-Machine-Drivers), and see what I can find out (Mac users are significantly less than the Windows users sorry) Login: There is an known upstream bug in the Electron code (not ours) that we are waiting for them to fix, where on newer Mac's its doesnt allow us to remove it (keeps autostarting) - this is unfortunate and will be fixed as soon as we complete the Electron 4 upgrade, or earlier if the bug is fixed in the current Electron version sometime - sadly out of our control. That said, in a way though, it is intended. On windows, it also auto starts and then sits nicely in the system tray next to the clock out of the way. Mac autostart is a little more forceful - leading to your experience... The idea here is that it sits in the background similar to a "printer driver" (Think HP, Epson etc) - but due to cross platform nature its not entirely as transparent. On windows it hides nicely out of the way in -the systray. On Mac the "dock" is as close to the systray as we have. On linux it hides in the tray too (even on raspberry pi's pixel desktop) - if you have a windows machine, try it for a while and see the intended feeling (clicking that Transfer Gcode button in cam.openbuilds.com is so satisfying when the app is running out of the way in the systray) Being always-on is needed for the integration with cam.openbuilds.com and upcoming projects (Justified: The browser cannot launch applications, so we cannot run the driver for you. If its already running we can interact with it which is what we need) This is pretty standard industry behaviour (see Cricut's agent, EaselDriver, etc) - Doing it this way helps those users who are not IT professionals - they dont need to worry, it just works. They dont need to remember to run something first, or start it or whatever, its just always there. Its a shame Mac doesnt keep it hidden in the dock. Its two seperate components - a "server" that should sit in the dock at all times, and a Window (that gets launched from the integration API, launchers and context menus) Correct way to quit: The native Quit code is something I am lacking behind on, need to work on it (Electron: Close w X vs right click dock and quit), but not having a mac makes testing it kinda hard. So to Quit: Use the context menu on the Dock icon:
I see your point about it acting more like a printer driver (being a graphic designer, that's a language I understand!), but since this is my 'daily driver' that I'll be using occasionally for my fun new CNC side projects, I like to keep my always-on apps to a minimum. Once I get more comfortable with everything I intend on setting up a dedicated machine to live in the basement with the LEAD machine. There are numerous applications I run (1Password, Magnets, Dropbox, Adobe CC) that give the option to "Hide from Dock" while maintaining background operation or a Menu icon. If you were able to go that route I would be fine letting it live in the background. I'm just not a fan of seeing apps I'm not using in my app switcher that I use frequently throughout the day.
I hear you on that! I also keep mine slim. I'll see if theres any new workaround yet (Wasnt last time i looked) or otherwise i might have to do the unthinkable and exclude Mac users from autostart entirely (so you guys will miss out on the automated integration) I'll try get some time allocated to work on it, and the Networking nag bubble and might press on your button to test afterwards if I need to!
Lol! Nah, theres like 4 of you guys and one's on our side already. You would be cool, so that leaves two on two (; No workarounds, so for now, I am indeed going to disable to autostart. At least the part where it adds itself to the login items. Then in a couple days, i'll add a little settings tab that allows you to Opt-in to add it to login settings. That might just work. Regarding the networking thing, i think it might be down to Code Signing - Support - Apple Developer - we're not signing any of the software yet, but seems its becoming inevitable as OS makers keep tightening down forcing developers into their certification/store programs for revenue purposes... that said, since I am wont be forcing it to start on login, you'll only have to click the annoying 'allow' once in a while when you start CONTROL
Okay, so if you grab v 1.0.130 from OpenBuilds Software - Quit on the Dock context menu should now actually quit it. Closing the window with the [x] button still minimizes to tray as always - Can you test for me that force-quit is a thing of the past? Shutting down should automatically quit etc. - If you remove it from your login settings manually, it should not add itself back ever again (on Mac) - Removed some of the GPU switches when run on Mac - Mac should have its WebGL working optimally in default config, the extra switches now only get used on Win/Linux (For intel onboard gfx mostly) - wasnt something on your list, but an oldie - still since you have a real mac, let me know if you lost the 3D viewer or something extreme like that
And we are 4 VERY important folks! Quit on the Dock context menu should now actually quit it. Closing the window with the [x] button still minimizes to tray as always Confirmed. I will add it's a little strange to me to have 2 buttons ( _ & x ) that do essentially the same thing. Since I'm the newly appointed arbiter of all that is Mac here, there's typically a view command in the Menubar for Main Window such as Cmd 1 or Cmd 0. It's not very intuitive that the x minimizes the window and the only way to reopen that window is to click on the Dock icon. Can you test for me that force-quit is a thing of the past? Shutting down should automatically quit etc. Confirmed. If you remove it from your login settings manually, it should not add itself back ever again (on Mac) Confirmed. Removed some of the GPU switches when run on Mac - Mac should have its WebGL working optimally in default config, the extra switches now only get used on Win/Linux (For intel onboard gfx mostly) - wasn't something on your list, but an oldie - still since you have a real mac, let me know if you lost the 3D viewer or something extreme like that Confirmed. I did get a JS error upon launch and I did copy it, but I then copied and pasted this bullet to respond to and lost it... I'll follow up if it happens again. A new issue I'm running into is if I physically disconnect my xPRO, I have to reboot in order for it to show up in the CONTROL menu again. Is that a driver issue I should contact FTDI about, or is that something you've encountered before?
Potential fix for the Network permission on MacOS: Users can self-sign the application after install. Not as perfect as a official Apple certified one, but will help stop it from asking it all the time: $ sudo codesign --force --deep --sign - /Applications/OpenBuildsCONTROL.app $ sudo codesign -dvvvv /Applications/OpenBuildsCONTROL.app $ sudo codesign --verify -vv /Applications/OpenBuildsCONTROL.app Now it will ask for permission one last time on next start, and then not again until the next update (After update just sign again - could be scripted, will investigate)
Before escalating to FTDI, see if you can catch that JS error again, always a good idea to confirm something like that isnt related first... Then I'll dig in and see if we cleanup port on unplug properly (We had a issue like that in the very early days, but thats been patched for months on Windows - there isnt any specific OS code in that part though so it should be fixed for all) Some of the odd behaviour is because the code is 100% cross platform: the same code runs on Mac, Windows and Linux. On Windows the [ _ ] button minimises it to the Taskbar. And the [ x ] button minimises it to Tray (Same behaviour as Skype for example). Sadly Mac does things a little different. Of course the upside is - despite the quirks, at least it DOES run on Mac, so it helps with that [edit] PS: Not sure what the parts of the dock is called, but minimise takes it down to a different spot than close does - check the GIF I shared earlier... They dont minimise to the same place
Hi I don't now if that post must be here . It's my first post ,i have 150x150 belt driven ,i have download the software and the machine is working perfect . When i am drawing it needs to calculate the toolpaths about more than 3 min to calculate , the internet connection it's ok , is that normal or the problem is somewhere else ?
Hi @GeoPan - you are right, this is the wrong thread, OpenBuilds CONTROL is the application that connects to the machine. What you are referring to is OpenBuilds CAM (Support thread here: for future reference: OpenBuilds CAM Software. No biggie, just remember next time (; Depending on the complexity of the toolpath and CPU of the PC its not uncommon. Nothing to do with your internet speed, etc. The processing is done locally in your browser, to calculate offsets, and previews from the vector data. Quite a bit of maths, so its not totally crazy that it takes a while on a complicated toolpath There is a tweak you can apply if your PC is a little slow: Click Settings -> Settings Scroll down to 5. Advanced Check the Disable Tool-Width Preview checkbox, and save As shown here: This takes away a lot of the computational load your machine has to do, but at the expense of not showing the toolpath in the nicer, prettier way. It will only show the centerline of the toolpath.
Hey all, I was wondering if there's a changelog somewhere for the OpenBuilds Control software - I couldn't find one and don't know what exactly has changed but everything has been running so great for me with this latest version! I didn't have any serious issues with the earlier versions, but I was experiencing some small nagging quirks like the path previews being slow to load sometimes or requiring a 'Reset View' each time I loaded new gcode. And I didn't measure the connection times before, but even that seems to happen more quickly as of the last couple updates. Everything is working absolutely perfectly for me now, even on the early-gen i3 hooptie I'm running my Lead CNC off of. I also don't remember seeing the 'Fine Tune' feature for the steps/mm in the Grbl settings before, but I just used that and I really appreciate the step-by-step walkthrough for tuning those numbers - very cool! A whole lot easier and quicker than measuring the distances on the wasteboard. Big thanks to everyone working on this great software for continuing to improve things, it's now fitting seamlessly into my workflow and is one less thing that I have to worry about.
Thanks for the compliments! The changelog history is best viewed on Github at OpenBuilds/SW-Machine-Drivers but its quite technical. I've added a nicer human-moderated Changelog to CAM already (check the button in the Settings tab, and also bottom of OpenBuilds Software), and i am adding the same to CONTROL too, just not there yet - OpenBuilds/SW-Machine-Drivers is where i will be keeping track, and then in a couple days there'll be a log just like CAM that pulls from this So for now, the git commit log is the way to go. Regarding minor niggles: they can't get fixed if they arent reported, so always feel free to post any of them you find, either here or on OpenBuilds/SW-Machine-Drivers and i'll do my best to get them fixed for you asap.
Thanks Peter, appreciate the extra info! And I'll definitely pop in here with any issues in the future. I had so many variables going on with my new setup that I wanted to do a little more testing on my end first, but you beat me to it . Now that everything is running buttery smooth I'll be able to provide more informed and helpful feedback hopefully! Thanks again and keep up the great work!
I was able to figure out that the git code was a browser application and not the windows exe which I modified and now looks like this
Nice, which firmware are you using? Ps: not sure if you got through the whole process, but its not entirely a browser application, its actually Electron, so the frontend on its own needs the Node/Electron backend as well before it will work. From your screenshot the two play buttons is a dead giveaway that the Websocket server is down, so not sure if you are just mocking up the UI in the browser as a step 1, or if you'd like a run down of how to get your custom version tested (npm install, ./node_modules/electron .) and compiled (npm install, ./node_modules/.bin/build) Youd also need to extend the parsers in index.js, and UI in app/js
I took the latest 1.1g as of last night and then retro added the C axis modifications. My C works but I needed test software so I decided to modify this as it works perfectly. Its a mock up as the controller is on another PC so I'm just getting the web ui figured out and then I will test functionality once I figure out how all this ties together. Thanks
I have a question I apologize in advance for the lengthy story about the control software and the X Pro v2 A couple years ago I built a modified c beam machine with a x pro v2 board which I used successfully for 2 years. I ended up giving that machine to my son in law who decided to replace that board with an x controller. I received that board back and am trying to use it on an ACRO 510. I can not seem to get it to work properly. While I had the c beam I used UGS with out any problems. I’ve updated the GRBL to 1.1 but yet when I jog the machine with any software UGS or Openbuilds it doesn’t work properly when I turn on the machine and try to jog the machine it will I’ll move only 1 time the only way I can get it to move again is to turn the machine and the software off and back on then it will move 1 time and then I repeat the off/ on sequence again. I noticed in one of the posted Mark day to make sure to use the jumpers but doesn’t say exactly how to set them up. Any help would be appreciated.
sound like your original machine had homing switches but this one does not.... also you should do a reset of the EEPROM. give it a $RST command before any movement. after that you will need to reset all the motion parameters, $100 for X steps per mm etc. gnea/grbl <-- read all about the reset command here
Prerequistes: Install NodeJS 8.x (Not 10, we have a few older dependencies that need 8) In the folder you cloned from git, open a terminal (I prefer git-scm with MinGW's terminal on windows, but even CMD will do). In the folder, run "npm install" - this uses Node Package Manager to download all the nodejs dependencies, it creates node_modules during this step. It will be right in the root of the folder (same folder as where package.json lives) To test (without compiling) run SW-Machine-Drivers\node_modules\.bin\electron . (The [space]dot after electron tells the electron executable to serve the content of the current directory so NB) This launches your code directly. Make sure the official OpenBuildsCONTROL if you have it installed, is shutdown (properly quit from the systray menu) before running the dev version The terminal fom where you ran it (cmd, mingw, etc) acts as a rolling log too - useful Once you are happy and want to build an installer, run SW-Machine-Drivers\node_modules\.bin\build - this creates a EXE installer in SW-Machine-Drivers\dist\
@Michiglenn - I've added Changelog to 1) Each of the sections on OpenBuilds Software 2) The button on the settings tab of OpenBuilds CAM Gcode Creator - Public Beta and 3) A section on the Troubleshooting tab of OpenBuildsCONTROL
Another JS error popped up again. I'm not certain this is the same error as before, or how to replicate it, but I'm attaching it below: Uncaught Exception: TypeError: Cannot read property 'displayBalloon' of null at SerialPort.<anonymous> (/Applications/OpenBuildsCONTROL.app/Contents/Resources/app.asar/index.js:731:21) at emitOne (events.js:116:13) at SerialPort.emit (events.js:211:7) at SerialPort._error (/Applications/OpenBuildsCONTROL.app/Contents/Resources/app.asar/node_modules/serialport/lib/serialport.js:150:10) at SerialPort.<anonymous> (/Applications/OpenBuildsCONTROL.app/Contents/Resources/app.asar/node_modules/serialport/lib/serialport.js:229:19) I'm still having the issue of having to reboot whenever the Controller has been disconnected, but I'm thinking it's because there are two drivers installed. I'm going to remove the non-Apple driver this evening after work and see if that alleviates the problem. Here are the results from a ‘sudo kextstat | grep FTDI’ before a reboot, after the Controller had been uplugged and reconnected to the computer: 174 0 0xffffff7f83c16000 0x7000 0x7000 com.FTDI.driver.FTDIUSBSerialDriver (2.4.2) E16D9540-AF63-36AD-94C4-B1164FBD6078 <91 57 6 5 3 1> And this is after a reboot with the board plugged in: 157 0 0xffffff7f83b95000 0x7000 0x7000 com.FTDI.driver.FTDIUSBSerialDriver (2.4.2) E16D9540-AF63-36AD-94C4-B1164FBD6078 <91 53 6 5 3 1> 159 0 0xffffff7f83ba3000 0x3000 0x3000 com.apple.driver.AppleUSBFTDI (6.0.0) 94C7EDB6-0A50-30B2-BAD0-F83A234A9E1F <158 91 23 6 5 3 1>
Compiling v1.0.133 now (available for download in about 20mins) - which should fix that JS error. The error happens just before we cleanup the serialport (because MacOS doesnt have a "AppIcon" so the balloon message doesn't pop up that would've said "Port error, "OpenBuilds CONTROL received the following error: " + err.message where err.message would have been that the port just got unplugged ) So its not unlikely that the port cleanup doesn't happen then. From 1.0.133 all the AppIcon calls are checked before being called (if on mac, don't call) so its worth checking if that's solved the unplug first
If you are already following this thread, you might want to follow Things you didn't Know about OpenBuilds Software as well - it will be updated regularly too
