OpenBuilds CONTROL Software

This software works with controllers running Grbl 1.1 (Preferably 1.1f) or Smoothieware. If your controller is Grbl compatible, maybe just update Grbl first. Or check the Serial Console tab for clues

 

Screenshot of the Serial Console tab please (after clicking Connect) - we do log all that happens to help with troubleshooting. Without the log, we're in the dark. Sidenote: 1.1e is kinda old. 1.1f has been out for a year and 4 months already .

 

Flashed a Uno with Grbl 1.1e and tested for you, works for me.
Something in the hardware must not be 100% arduino compatible... (Disabled autoreset circuit, DTR not wired up, nonstandard Grbl startup strings, etc)

[-> USB Connect -> When port opens, DTR fires, Grbl Resets, Grbl Sends welcome string, we detect welcome string and print it to log. If its too old, we warn you, else we pull down the settings...]

 

If my suspicion is correct (Cant find a schematic for the Phoenix, doesnt seem to be open source) and they didnt hook up autoreset properly, I added some code to handle the noncompliant boards. Try driver 1.0.103 or newer please OpenBuilds/SW-Machine-Drivers

 

@DavidCNC2017
I am not sure what chip is used on the newer and full smd phoenix boards. Assuming @Hayri PhoenixCNC is still using the same usb chip he did on the older revision of the phoenix board I once had ( MCP2221A ) @Peter Van Der Walt is correct. The board is not resetting when DTR fires due to the fact the mcp2221a does not have a DTR pin. This is the main reason I had problems with my older Gecko Controller with Laserweb. Updating my design to use a chip with a DTR line ( I personally use FT232RL now ) resolved all problems. Sadly this info does not really help those with a phoenix board as they can not swap out usb chip's Hayri would need to update his design.

 

Thanks for the clarification - either way, have a test with v 1.0.103, it should work then. Desoldered the DTR cap on the Uno while i added that code.

 

Note that although you are using Firefox, we don't rely on the browser installed (Not on the Machine driver) - that ships with its own instance of Chromium wrapped in an Electron shell.

We run a little JS code to see if the embedded browser reports it either has WebGLRenderingContext, or a Canvas with experimental-webgl context. If it doesnt, WebGL isnt available on that machine unfortunately - Although the tests work, theres something else on that machine thats stopping electron from having WebGL support. Try a Windows VM (; or different PC


var webgl = (function() {
try {
return !!window.WebGLRenderingContext && !!document.createElement('canvas').getContext('experimental-webgl');
} catch (e) {
return false;
}
})();

To get around the browser disabling WebGL for certain Drivers/Chip combinations, we already throw the --ignore-gpu-blacklist switch in on startup.

I'll make a note to test out the others too - see if they cause more issues and let you know when you can test again. That said though, overrides can only get you so far If the chromium team doesnt like your hardware/drivers theres usually a good reason behind it

app.commandLine.appendSwitch('ignore-gpu-blacklist', 'true')
app.commandLine.appendSwitch('enable-gpu-rasterization', 'true')
app.commandLine.appendSwitch('enable-zero-copy', 'true')
app.commandLine.appendSwitch('disable-software-rasterizer', 'true')
app.commandLine.appendSwitch('enable-native-gpu-memory-buffers', 'true')

 

@Hector Beltran Do me a favour and test with 1.0.104 OpenBuilds/SW-Machine-Drivers - and let me know if it helps at all) (If it doesnt, i'll take it back out)

 

Check the docs for details: WebGLRenderingContext
If you really want to dig in (If 1.0.104 doesnt help), you can try:
1) Press F12 to get devtools on the Driver window
2) Click the console tab.
3) Check !!window.WebGLRenderingContext, !!document.createElement('canvas').getContext('experimental-webgl') and !!document.createElement('canvas').getContext('webgl') as shown below (Paste in, press enter) - if you get TRUE for even just one, we'll enable the viewer.


Then, you can also grab all the juicy details, by entering: window.open('chrome://gpu') [enter]
This tells you all you need to know (Feel free to share if you want me to check it out)

 

It does compile on Pi. We just cant automate the compile yet because of a TravisCI issue. So you need to do that manually. But trust me, its not worth it, Pi is a little slow, and also doesnt have WebGL. I know i am a Pi fan too, but unfortunately Reality doesnt always play along.

Heres my advice coming from being the guy that sees everyone's complaints (gives you a better insight than just relying on having being a cnc user for a decade or so). Stick a PC next to your CNC. You are gonna want to run CAD and CAM on it. You are gonna want good performance and reliability. And you are going to be making things more than fussing with the computer. Old PCs are FREE almost everywhere in the world. Most even nowadays have access to a free copy of Win10. Yeah, I know linux is sexy . I have a couple linux qualifications, worked for SuSE for another decade before. But heres the reality: 98% of our userbase, runs Windows. Guess where the most testing and bugfixes end up? on the other hand, guess how much support time has gone into getting it running for you on Linux now. Lol (; Meanwhile the Windows folks run the EXE and away they go. WebGL just always works too

 

Glad to hear! You won't be sorry

 

Is there any docs for the control? I will say its very intuitive and was super simple to setup. But I dont understand the "Unlock Alarm". In the Workbee build videos, its flashing since the motors aren't powered. Mine doesnt.

 

Alarm comes from grbl. Usually on startup if limits and homing is enabled, (thus you have to unlock and home to set the home state) . Or if limits are installed incorrectly (triggered all the time), or just after a limit was hit (works as intended). If homing is not yet enableD it won't alarm on boot. It may also go into Alarm mode when you send invalid gcodes etc. See Grbl docs at github.com/gnea/grbl/wiki for info

 

Just a correction, alarm has no bearing on whether the motors are powered or not. Its a firmware state

 

Ahhh, that makes sense. I dont have the limits wired up yet. Thanks!

 

For future reference, here's the 9 kinds of Alarms Grbl goes into: gnea/grbl

 

That part made my day by the way! (;

 

• Keyboard Shortcuts is already on the pending list at Keyboard Shortcuts · Issue #20 · OpenBuilds/SW-Machine-Drivers
• TouchProbe, i had it in an internal build a week or two back already to start playing with it. Will be released in a couple weeks:

• Predefined Positions ( and hand-in-hand will fall full on Coordinate Systems once we go down that road) : I'm on the fence on this one. The primary goal of this application is to ease entry into CNC - so for the most part we hide the work coordinate systems and only show Grbl's default (G54) along with the setzero functions. That gets the noobs up to speed easier. I am not objecting against catering to the advanced users at all, but, it takes a little work and thinking to integrate advanced features into the UI in a way that new users (often here, new to CNC overall too) can find their way without worry, and at the same time, have the features accesible to the Advanced user (So not hidden away in too many menus). I've opened an issue to track, but expect it to be a while, got to wrap my head around a few ideas how we can handle the UI (Well, and need to extend some parser code etc too) WCS Support · Issue #21 · OpenBuilds/SW-Machine-Drivers
  Alternatively if we ignore WCS, and just go for the predefined positions, a generic Macros buttons implementation may be more suitable (Add your own buttons from settings)

 

I just upgraded to the latest (1.0.111). Why did you take out the go to X, Y or Z 0 buttons? I used them. Yes, I know I can type in G0 X0.....