I have a client who recently upgraded his machine to GRBL1.1G. I was looking at it, and the zeroing of the Axes is completely different than 1.1F and before. Using GRBL Panel, You can no longer use disconnect reconnect or the E-stop input to reset position to 0. This is good, I didn't really like using these methods, but I didn't want to bother with the Work Offsets approach because it always got me into trouble. Never liked the automatic loading of offsets into G54, since I never used it. Never used the zero buttons beside the position display, because it was too easy to get everything all screwed up with the offsets. The new system seems to be much better, less dinking around to zero position, but I would like an explanation of what's changed and how it works. Could not find anything on GRBL Github page, the documentation has not been updated to explain the changes, and in fact there is no mention of these changes at all in the release notes either. Anyone know of any documentation on this change? MG PS on the Github GRBL Releases page, the release is listed as 1.1H, not 1.1G. Is this a typo? There is no 1.1G release listed, it goes from F to H.
Hmmm... Haven't seen anything significantly change on my end in bCNC, but I also never saw any kind of option to "not use G54", even in previous versions. It's just there, by default, and everything you do applies to it as long as you don't go into a different work coordinate system. My workflow is still the same: home machine, move to work zero position, hit zero button(s) to zero G54, then run from there. Homed, jogged to 100, 100, and hit XY=0 button. It set G54 to zero since it's default, but since the 0,0 I use here would be the same as the 0,0 I use in CAM for this hypothetical job, also defaulted to G54, there's nothing to worry about. There's also no way to get out of it, there has to be a Work Coordinate System offset from the Machine Coordinate System. Just the way it works. Since (and maybe this is a grbl 1.1h (not a typo) thing?) G54-G59 and G28.1/G30.1 coordinates are stored in EEPROM, they'll survive an e-stop, disconnection, even power loss, that may be why those things no longer work. The system resiliency is improved though, so if that is a recent development, it's a good one!
Rob: I have never used work offsets, nor the zero buttons on GRBL Panel position display (X,Y, Z, or Zero XYZ). Never figured out how to use the Machine Position or G54-59. Never needed to. There is no option "not to use G54", I just ignore it. As I said, using them confuses the hell out of me and so I never bothered. Always used Disconnect/Connect with GRBL Panel to zero the machine. That, or Reset on the Arduino, or E-stop, which is the same thing. Having said that, I just installed 1.1H on my machine, and it behaves exactly the same as before. The only difference was that the customer machine was a BB controller, mine is an Arduino Nano with separate stepper drivers. Don't know why GRBL Panel would behave differently with a BB than any other controller. Weird. MG
Sounds similar to how I worked before I had working limit switches on there. Since the controller would always wake up at 0,0,0, you could take advantage of that sometimes. Now I have limits, and I find work offsets are much more useable and powerful. I too have Arduino + drivers, not really one for all-in-one solutions most of the time (I compare it to TV/DVD/VCR combos back in the day... What would you do when one broke?!), so that explains why I also don't see any significant changes. I guess @Peter Van Der Walt might be the person to ask about how/why BlackBox changed?
Maybe I'm missing something? I don't understand? BlackBox runs stock Grbl We only set $4=1 and $1=255 on our prebuilt binaries (so the user doesnt have to remember to do that) - as the drivers on BlackBox needs inverted enable signal, and $1=255 is set so motors are always on (makes troubleshooting easier) - everything else is stock standard FWIW nothing changed between Grbl 1.1 from Dec 2016 till today about how Coordinate Systems or setzero works
Yeah I thought it would be odd if it significantly diverged from stock, because it'd make troubleshooting unnecessarily more complex. I have no idea why that guy's unit would suddenly start working differently, then, unless he changed some settings himself.
Well, Grbl Panel: gerritv/Grbl-Panel hasnt been updated in almost 2 years (; Not even sure it was Grbl 1.1 compatible to begin with
Oh, is that why you guys built CONTROL? I noticed you weren't pushing Grbl Panel like you used to, but I thought that was because you built your own sender, rather than having to build it because they didn't maintain it.
Yeah GRBL Panel hasn't changed, and yes, it was set up to use V1.1. It wouldn't communicate if it wasn't, 1.1 changed some of the communications routines and extended the EEPROM. It is not being updated anymore, Gerrit offered to send the source to anyone who wanted to take up the maintenance tasks, but no takers. It's pretty stable, the only issue I have is that there will be no new features. I have no idea why this guy's machine is acting this way. Disconnect/connect does not zero out the position information. I can't see how a GRBL setting could change this. This one has me stumped. Rob, I don't like the all in one controllers either for the same reason. It's much cheaper to replace a $35 stepper driver than a whole $200+ Black Box or Xpro. MG
I compiled Grbl for an Arduino Nano & came across a simple way to compile it using openbuilds Control software, so I tried it. The 1st thing I noticed is that it was 1.1g & not the latest 1.1h. Have you thought about updating this on your control software? Here is what the console window looks like with the firmware update & then I reflashed it with the Arduino IDE to see the difference in version. [09:16:29] [ update ] You are already running OpenBuilds CONTROL 1.0.258 [09:17:38] [ Firmware Upgrade ] connected [09:17:38] [ Firmware Upgrade ] reset complete. [09:17:38] [ Firmware Upgrade ] flashing, please wait... [09:18:01] [ Firmware Upgrade ] flash complete. [09:18:08] [ connect ] PORT INFO: Port is now open: COM5 - Attempting to detect Firmware [09:18:08] [ connect ] Checking for firmware on COM5 [09:18:08] [ connect ] Detecting Firmware: Method 1 (Autoreset) [09:18:09] [ connect ] Detecting Firmware: Method 2 (Ctrl+X) [09:18:10] [ connect ] Detecting Firmware: Method 3 (others that are not supported) [09:18:10] [ ] Grbl 1.1g ['$' for help] ... [09:18:11] [ $I ] [VER:1.1g.20181112:] [09:18:11] [ $I ] [OPT:V,15,128] [09:18:11] [ $I ] ok [09:18:12] [ connect ] Firmware Detected: grbl version 1.1g on COM5 ************************************************************** ******* After flashing 1.1h Grbl with Arduino IDE ******* ************************************************************** [09:26:10] [ connect ] PORT INFO: Port is now open: COM5 - Attempting to detect Firmware [09:26:10] [ connect ] Checking for firmware on COM5 [09:26:10] [ connect ] Detecting Firmware: Method 1 (Autoreset) [09:26:11] [ connect ] Detecting Firmware: Method 2 (Ctrl+X) [09:26:12] [ connect ] Detecting Firmware: Method 3 (others that are not supported) [09:26:14] [ ] Grbl 1.1h ['$' for help] ... [09:26:14] [ $I ] [VER:1.1h.20190825:] [09:26:14] [ $I ] [OPT:V,15,128] [09:26:14] [ $I ] ok [09:26:14] [ connect ] Firmware Detected: grbl version 1.1h on COM5
It has been on the Todo list, but priorities have not allowed the time to do that - as it involves also merging 1.1h into all the other builds, grbl-servo, etc - quite a lot of work so have to put some time aside to do that See OpenBuilds/control-grbl-buildall - where we maintain the various flavours, and build script, each version with customised MakeFile to make the hex files we include with CONTROL. Control does not compile it, we precompile, test, verify then include the Hex files V1.0.260 and upward (coming out soon) includes the option of using your own Hex files too
It actually can (well, v2.6 and up boards) : See bottom of docs:blackbox:jumper-slaveaxis [OpenBuilds Documentation] We played with it though and find it very finnicky, so much easier to build the frame square About the only use I see for this is Ox style machines with belts on both ends, but we also try to get people to stop building those
