Today's shelter-in-place project was to tidy up my electronics & cabling & hook up my wireless feed hold. I'm using this remote control relay. It's wired into the 'door' port on the BlackBox & I'm using the custom compiled version of Grbl with the door interlock feature enabled. Pressing the remote button 'opens the door' & this is what I see in the OB Control console: [external from hardware] ] OpenBuilds CONTROL received a FEEDHOLD notification from Grbl: This could be due to someone pressing the HOLD button (if connected), or DriverMinder on the xPROv4 detected a driver fault At the machine, motion halts & the router stops. Pressing the button again 'closes the door' & the Resume button continues cutting. On my Shapeoko & using Carbide Motion, when the door open function is activated, the router would lift to a safe Z height & then stop. On resume the router would start, lower to cutting position and continue. My question is, is what's happening (in red above) normal for Grbl? I think Carbide Control might be doing something extra & I'd just like to confirm that things are working as they're supposed to on the WorkBee. Thanks!
I just recently asked this question as well because I too had a Shapeoko XXL and the WHOLE REASON I bought this Black Box controller because I didn't like the Buildbotics controller that came with my Onefinity cnc router is because I assumed the DOOR OPEN feature would do exactly what the Shapeoko did. They've been sending me links to read up on Grbl and what actions happen during a DOOR OPEN situation. I kept trying to get my point across that I understand the DOOR OPEN when flashed over to the firmware on the Black Box will turn the spindle off and pause the job, but it DOES NOT raise the Z axis to a safe height. So if Carbide 3d made it possible on their Grbl firmware v1.1 board why can't the Black Box which is running the same thing as the Shapeoko and Nomad as far as Grbl do the same thing and raise the Z axis.
Yes, you CAN RAISE Z if you just recompile Grbl with your choice of parking motion gnea/grbl Theres no magic in what Carbide does, they just use Parking Motion Instructions here: gnea/grbl
There are options in config.h (part of GRBL's source code) for the parking motion, then you have to compile and flash your custom GRBL to your controller.
So is this not ever going to be something Open Builds plans to change an make standard in the firmware for the Blackbox? Please forgive me, but I'm just an average guy who lives in Florida and is a commercial HVAC service technician. I can do controls, electrical, install air conditioning systems, but the cnc thing is just a hobby of mine I've gotten into after first having a Shapeoko XXL router and now have a Onefinity cnc router. I have downloaded the latest version of Grbl v1.1f or h, I can't remember which one. I see the config.h file. I don't quite understand what I'm supposed to do to enable Parking. I gotta be honest, I also don't understand why I have to make this change for myself when I assumed it would already be an enabled feature for the Blackbox that EVERYONE could benefit from.
- Our machines are open-frame, not in enclosures - raising z is quite optional. The default behavior is to stop motion and turn of router. Keeping current position, easier to restart, less likely to cause errors. - every imaginable configuration can be achieved but if its not a "standard" machine, some configuration is required - if we enable the feature for every door install, what happens to the 99% of customers who do not need the feature - you are selling yourself short, editing the config file and clicking upload is really not that hard. Try it! Its a skill you will be using all the time in this hobby, particularly because you have a custom machine - install arduino - install grbl library (as per Wiki) - go to documents, arduino, libraries, grbl, src then edit config.h and setup the parking motion you want the machine to do, and enable it - go to arduino and upload (as per the wiki) Happy to help with the process (rather than argue whether it should be standard or not, lets bury the hatchet and help you where you get stuck so you can learn the skill) If you really get stuck, i'll compile it for you (exception, cannot possibly do so for every customer, every time they need a minor config change)
Okay. I'll give it a shot. So is the firmware used exactly the same as what one would download from the gnea/grbl page for "latest firmware"? Nothing special? And should I use the arduino IDE to bring in the grbl library, make the change, and compile it?
This. I used HOMING_FORCE_SET_ORIGIN on my laser to use positive coordinate space (and apparently homing at pulloff, not switch activation, which I love). It's genuinely trivial to use config.h for custom solutions- just make sure you're editing the config.h in your Arduino library and not the one in your Downloads! All you're doing to uncomment something is deleting the two little forward slashes before the hash mark that comment it out to make the compiler ignore it. You'll see it change color in the IDE. I should probably also use SPINDLE_PWM_MIN_VALUE, now I'm looking at it, for better engraving tonal resolution. Looks like parking is also available as an M-code option too, which is interesting- I wonder if that's purely a modal on/off, or if you can also trigger a park via G-code? Not super clear if the different M56s do something different, or if it's all just a variant of a single binary option.
By default gnea/grbl is "active" (not commented out) In here you should tell Grbl what you want the Z to do. How fast to go up, how fast to go down, how far away from the Z-limit to stop, etc Although those parameters are not commented, they don't take effect until Line 564 gnea/grbl is uncommented (made active) And then optionally, gnea/grbl enables the M56 override command - can probably leave it commented out for now - I can't imagine a need to override your chosen behaviour per-job.
And one more question for now because I'm working and can't really try anything out until I get home, but should I use the latest grbl firmware that can be downloaded from github or do ya'll have a downloadable one I should use to make the change to? Is there anything that OPEN BUILDS has personally changed in the firmware to make work with your platform. As of the moment I can actually use a couple of your preloaded machine profiles like the Lead 1010 because they do operate my Onefinity exactly as it should except for the steps per mm since it's ball screw driven & not lead screw driven. I already played around a bit and made a custom machine profile and calibrated all my steps per mm. I guess what I'm saying is that your proaded firmware works perfectly with my machine, I just wanna enable the Parking feature.
We use stock standard Grbl. The only change we make is just to make our life a little easier for support purposes, and that is default $4=1 (Required for the BlackBox drivers) and $1=255 (just a friendly feature to keep the motors always-enabled - prevents Z dropping down under gravity during idle) - your Grbl settings profile (keep a backup before flashing) should have those anyway so restoring it will set those)
Awesome. Thank you Peter. I apologize if I was rude in any way previously. It was just frustrating because coming from previously having a machine that had this Parking feature already enabled and working along with having the ability to enable and disable a bit setter (TLO) and defined coordinates for the (TLO) probing to take place it just seemed like it was a standard feature I thought would be in the OB control software. I do hope that one day the (TLO) will be implemented into the control software because that would be freakin awesome when doing 3d carves where you've essentially milled away your previous Z zero.
I also apologise that I got a little frustrated, felt like you were not seeing that Grbl can do parking motions - my mistake was not seeing that you needed help with config.h to do so. But I am glad we are working together and sorting this out. Mondays right (; I really did want you to dig in and learn to do it - because that kind of knowledge and power just makes you all the more capable going forward. We don't want to hold people's hand, we want to give them the tools to change the world! The other company you mention, likes forcing customers into "one way of doing" and then it limits what you can do with your machine. That config file as Rob says too, is trivial to edit, but has such cool features that don't always apply to everyone - and the Grbl devs did such a steller job with comments in the config file, and documentation in the wiki, that honestly, all I know more about Grbl than anyone else, is what I read there. TLO: Longer, more recent, discussion here: Product/feature request- tool length sensor/ function - not quite as trivial, and the hard part is the "user" in the game - to prevent them causing a crash of the machine while a TLO is active (See Post #8 in that thread).
Wish I knew how to write macros. Maybe I'll try and start using machine bed as Z zero for everything.
It's either that or I've taken a liking to using stop collars on my bits. Plan to possibly make up a jig that I can use to set each bit at the same length of stick out.
I've recently started using this one: https://pwncnc.com/purchase/ols/products/collar-set I've only used it on a few jobs and it works well. I have yet to see what kind of runout the collars introduce so havent committed to them 100%
Yeah I remember him making that, but wasn't to fond of the design. I'll probably mill one out of aluminum on my benchtop mill.
Well, a gentleman or woman from github suggested I try doing these changes in the config.h file with an Arduino which I happen to have actually. And I did do a #include <grbl.h> upload to the arduino and was able to actually connect to the arduino using your control software. I'm not having any luck uncommenting line 564. So frustrated and ready to give up honestly. I've uncommented, saved the changes in the Arduino libraries grbl folder, not the folder I actually downloaded from github. And all i get is an error shown below. Arduino: 1.8.13 (Windows 10), Board: "Arduino Uno" Sketch uses 30754 bytes (95%) of program storage space. Maximum is 32256 bytes. Global variables use 1646 bytes (80%) of dynamic memory, leaving 402 bytes for local variables. Maximum is 2048 bytes. Low memory available, stability problems may occur. avrdude: verification error, first mismatch at byte 0x7800 0xff != 0x91 avrdude: verification error; content mismatch avrdude: verification error; content mismatch And this is the ONLY change I made. // Enables and configures parking motion methods upon a safety door state. Primarily for OEMs // that desire this feature for their integrated machines. At the moment, Grbl assumes that // the parking motion only involves one axis, although the parking implementation was written // to be easily refactored for any number of motions on different axes by altering the parking // source code. At this time, Grbl only supports parking one axis (typically the Z-axis) that // moves in the positive direction upon retracting and negative direction upon restoring position. // The motion executes with a slow pull-out retraction motion, power-down, and a fast park. // Restoring to the resume position follows these set motions in reverse: fast restore to // pull-out position, power-up with a time-out, and plunge back to the original position at the // slower pull-out rate. // NOTE: Still a work-in-progress. Machine coordinates must be in all negative space and // does not work with HOMING_FORCE_SET_ORIGIN enabled. Parking motion also moves only in // positive direction. #define PARKING_ENABLE // Default disabled. Uncomment to enable
I think my issue which I have no idea how to fix is that line 30 gnea/grbl has squiggly lines under it indicating an error. This is in the Microsoft Visual Studio I think it's called. Wants me to install some vcpkg which I yet again have no idea how to use. As much as I wanna understand and learn this stuff I just can't grasp any of it. I just wanna enable PARKING
Chinese fake arduino? Or genuine Arduino? Verification mismatch is a good indication of either wrong bootloader on the chip, or a bad chip. Or a bad serial chip like the very cheap CH340s (instead of a good USB serial chip like at8u2, ftdi, cp210x etc) You'll probably get the same error if you try uploading the Blink arduino example. Its not a Grbl error, it's the hardware (the arduino) Use Notepad++ to edit config.h Visual Studio is way overkill to edit a text file
It's not a genuine Arduino. I got it from Spark Fun a few years ago. I their version of an Uno called the Red Board. Well, off to work I go. Thanks Peter. I do think there's something wrong with the bootloader because even though it will download the (#include grbl.h) from the arduino grbl documents the very first time before altering anything as soon as I do make a change it don't like it and I get the errors.
Windows defaults to using Visual Studio for the config.h file to open it. I tried using that only because it's easier to read being a nice black background with green, pink, & light blue letters. I did try just basic Notepad and WordPad with no success either.
