Hey all, The background is I have an Ox modified to run leadscrews that's been running ok on a TinyG board for a couple years. I decided to go to external steppers (TB6600's from Sainsmart) and an Arduino Nano (clone) running GRBL 1.1F because I've got some high-torque 425 oz.in. Nema 23's from Longs Motors on it. I'm also trying to get away from Chilipeppr as it's just not commonly used any more. I'm using Openbuilds Control, it connects fine and I've got the X and Y directions reversed so that it jogs in all the correct directions (including Z). I've connected my NC homing switches which are in Zmax, Xmin and Ymin locations on my machine. When I try to home all, the Z goes in the wrong direction (into the spoilboard instead of up to top of travel). Behavior is the same using UGS. I've tried reversing the Z-home location setting with the same results. I'd almost think that it would be a problem with the Z Direction wire to the driver except that it jogs up and down correctly. Any suggestions as to a setting or wire connection where I should be looking? @Metalguru I hope you don't mind me tagging you but I believe you run the same drivers and board.
You have the steppers wired straight and using grbl's built-in direction port invert mask $3 (=3)? Not sure I was completely following that part, sounded like it was intrinsic to the control software. You shouldn't need to touch z if you're not inverting its direction. You could try $23=4 and see if it works, but that would be a hack to cover something else wrong.
I'll post my grbl settings tomorrow when I'm back in the garage for reference, but yes I've used the grbl mask to reverse the X and Y movement directions instead of reversing a pair of wires. From what I recall grbl's standard homing position settings are Z top, X right and Y back, where as I have my X home switch on the left and Y home switch on the front because of the limited access to my bench. Regardless it homes Z first so I was surprised to see it move in a negative direction towards the spoilboard instead of towards the top of travel.
Been a super busy week with the kids, finally got a chance to get back in the shop. Jogging works correctly, but the Z homing always goes towards the spoilboard whether I have $23=4 or $23=7. Switches confirmed as working correctly in the troubleshooting section of Control software. I tried another Nano, flashed it with Control, but it has the same results. [11:22:06] [ $$ ] $0=10 ;Step pulse time, microseconds [11:22:06] [ $$ ] $1=255 ;Step idle delay, milliseconds [11:22:06] [ $$ ] $2=0 ;Step pulse invert, mask [11:22:06] [ $$ ] $3=3 ;Step direction invert, mask [11:22:06] [ $$ ] $4=0 ;Invert step enable pin, boolean [11:22:06] [ $$ ] $5=1 ;Invert limit pins, boolean [11:22:06] [ $$ ] $6=0 ;Invert probe pin, boolean [11:22:06] [ $$ ] $10=1 ;Status report options, mask [11:22:06] [ $$ ] $11=0.010 ;Junction deviation, millimeters [11:22:06] [ $$ ] $12=0.002 ;Arc tolerance, millimeters [11:22:06] [ $$ ] $13=0 ;Report in inches, boolean [11:22:06] [ $$ ] $20=0 ;Soft limits enable, boolean [11:22:06] [ $$ ] $21=0 ;Hard limits enable, boolean [11:22:06] [ $$ ] $22=1 ;Homing cycle enable, boolean [11:22:06] [ $$ ] $23=4 ;Homing direction invert, mask [11:22:06] [ $$ ] $24=25.000 ;Homing locate feed rate, mm/min [11:22:06] [ $$ ] $25=1000.000 ;Homing search seek rate, mm/min [11:22:06] [ $$ ] $26=250 ;Homing switch debounce delay, milliseconds [11:22:06] [ $$ ] $27=1.000 ;Homing switch pull-off distance, millimeters [11:22:06] [ $$ ] $30=1000 ;Maximum spindle speed, RPM [11:22:06] [ $$ ] $31=0 ;Minimum spindle speed, RPM [11:22:06] [ $$ ] $32=0 ;Laser-mode enable, boolean [11:22:06] [ $$ ] $100=199.100 ;X-axis steps per millimeter [11:22:06] [ $$ ] $101=199.100 ;Y-axis steps per millimeter [11:22:06] [ $$ ] $102=199.100 ;Z-axis steps per millimeter [11:22:06] [ $$ ] $110=2000.000 ;X-axis maximum rate, mm/min [11:22:06] [ $$ ] $111=2000.000 ;Y-axis maximum rate, mm/min [11:22:06] [ $$ ] $112=500.000 ;Z-axis maximum rate, mm/min [11:22:06] [ $$ ] $120=200.000 ;X-axis acceleration, mm/sec^2 [11:22:06] [ $$ ] $121=200.000 ;Y-axis acceleration, mm/sec^2 [11:22:06] [ $$ ] $122=200.000 ;Z-axis acceleration, mm/sec^2 [11:22:06] [ $$ ] $130=600.000 ;X-axis maximum travel, millimeters [11:22:06] [ $$ ] $131=770.000 ;Y-axis maximum travel, millimeters [11:22:06] [ $$ ] $132=70.000 ;Z-axis maximum travel, millimeters [11:22:06] [ $$ ] ok [11:22:06] [ $I ] [VER:1.1f.20170801:] [11:22:06] [ $I ] [OPT:V,15,128] [11:22:06] [ $I ] ok
I just tried something else to try to narrow down the problem. I tried setting $23=0 and the Z homes correctly. Of course X and Y don't work because I have the switches on the wrong ends of the machine for GRBL default. So either the masking is incorrect in Control, or there's an issue with GRBL. Now that I know it's a software issue instead of a wiring problem, I can continue using the machine until I move the homing switches, although I really don't want to have to.
There is no software issue, it's Pilot Error. You use the $23 to initiate homing in the desired direction for each axis. This is independent of the jog directions you have set with $3. It doesn't matter where the switch is located, you set the direction that the axis (any axis) moves on initiating Homing . Then, as soon as it hits the switch at that end of the axis, it stops. So, if you have limit switches on both ends of all the axes, you can home to any quadrant. Read the Homing section here: gnea/grbl I have also noted, if you are using GRBL Panel, if the Z axis starts out with a negative position (ie z=-10mm), sometimes the axis will try to home in the wrong direction. MG
Thanks for the response. The homing issue behaved the same with Openbuilds Control and also UGS. I had been using single homing switches on each axis along with soft limits while running the TinyG board, so that's what I was trying to do with the Nano & GRBL. My machine is currently disassembled while I replace the 3D printed brackets from my Ox-Metal build with aluminum ones (thanks to Dazthegas for his pattern uploads). When I reassemble it, I'll switch the A pair wires on the X and Y axis drivers so that I don't have to invert the direction in $3 setting and see if it still homes the Z in the wrong direction if the $23 X and Y homing direction flags are inverted. If so, I'll just move the homing switches which won't take long. I've spent hours learning about the homing directions masking when I set up my TinyG so it would home correctly, so I'm pretty confident about my understanding of how they work. I see that my setting as shown was $23=4, where as I think it should be $23=3 for where my switches are($23=3 Bottom left from the wiki). I will have to check to see what it's set at by OB Control as I don't recall exactly when I copied those settings during my trial and error changing of the settings. I can do that tonight actually, I haven't disassembled my Z-axis yet.
Hi SugarJ No, you are still not getting it. $3 bits have to be set so your axis goes positive when you hit the Jog+ button. That's back for Y, right for X, and up for Z. Period. No other way is correct. Having said that, reversing one of the motor windings will accomplish the same thing, it's just easier to do it in software. Absolutely nothing to do with homing. Bits are 00000ZYX. 0 is one direction, 1 is the other. What these are set to will depend on how you wired up your motors. If the axis moves the wrong direction, toggle the bit for that axis. Doesn't matter what software you are using, these settings are in GRBL itself, on the Arduino, not in the software. The software only provides a means to change the settings. Now on to homing. $23 does not change the inherent axis direction set in $3. It only reverses the direction the axis begins to move when you hit the Home button. For instance, when you hit the Home button, the X axis needs to move right if you have your homing switch on the RHS of the machine, it needs to move left if your switch is on the LHS. The axis needs to move toward the relevant switch when the Homing button is pressed. If it moves the other way, it will expect to find the switch, but it doesn't see it, and crashes against the axis end stop. Hit the home button, and note which way each axis goes. If it is moving toward your switch, leave it alone. If it moves away from the switch, toggle the appropriate bit in $23. Bits are the same order as $3, 00000ZYX. Note that Z axis always homes Up or positive, never down. This is completely different from reversing the axis direction using $3, and has nothing to do with the default axis direction using jog buttons. If you don't understand this and get your axes set up correctly, it will never work properly. This is a case of two wrongs do not make a right. MG
That IS how I've got it set it up and it works as you note and GRBL intended. Perhaps my explanation above wasn't clear. I have $3=3 so my machine jogs in the correct directions when I hit the X and Y jog buttons. Right for X+, Away for Y+, Up for Z+ and the reverse direction for the X-,Y-,Z- buttons. Which is why I was so surprised when the Z starting home seeking in the negative direction, and thus the whole reason for the thread. I started thinking I might have a wiring issue, and now it's obviously a configuration issue. I'm absolutely sure that my $23 bit mask for homing needs to be 3 instead of 4 based on where my homing switches are currently, so I will check that in a couple hours when I get home. I'll set it manually to see if it works as it should, then try setting it again in OB Control GRBL Settings and see what number it writes to the Nano. Thanks for the detailed explanation. It confirms what I had learned about how GRBL handles bit masking previously.
I just reread the thread and double checked the wiki and yeah, $23=3 should solve all of your problems. Z goes positive by default, 3 is invert X, invert Y, don't touch Z- 0x0000011, as @Metalguru said. $23=4 is 0x0000100, ie. move negative for Z and stay positive for X and Y. Since the machine is otherwise moving correctly, that should be it. On to calibration! Not really sure why I didn't get it in the first place, upon re-reading, I don't think it's worded badly, I just got hung up on the G-code senders rather than the grbl behaviour.
No problem. Sorry, it sounded like you were unsure of how things worked. Or maybe I was unsure of what you were trying to say... As I said, sometimes GRBL Panel software will move the Z axis in the wrong direction if the value of Z position is negative when you press the homing button. Not sure if other programs do this, but it may have something to do with your problem. Perhaps try zeroing out the Z axis before you press home... I don't know if this is a bug or normal behaviour. MG
I really appreciate both your help. I hope I'm not sounding snippy when I respond as that's not my intent. My formal post-secondary schooling was in Robotics and Automation, but that was close to 30 years ago and things have sure changed since then. That's why I started building hobby machines a couple years back, because I never actually got to work in my field. I end up working building and repairing computers before it became obvious that they'd hire anyone to do it for far less than I wanted to get paid.
So, the problem is with OpenBuilds Control, not my hardware or my understanding of the masking. Look at the dropdown, note that 3 and 4 should be reversed according to the grbl homing wiki linked above...... 3 should be X and Y reversed homing with Z normal, 4 should be X and Y normal with Z reversed. I set it to 3 and my machine homes properly like it used to with the TinyG board. @Mark Carew @Peter Van Der Walt Edit: Opened an issue on Github as well
They have obviously tried to reverse the apparent order of bits in Openbuilds Control to make it a bit more intuitive. In GRBL, the bits are arranged ZYX, not XYZ. I'm used to directly editing the GRBL binary flag byte (or decimal equivalent) for these values, not a 3rd party interpretation of it. The decimal numbers actually represent the decimal value of the 8 bit flag byte, or at least the first 3 bits of it. If you reverse X,Y, and Z bits in #3, it actually is decimal 4. If you reverse bit order in their #4, it is actually decimal 3. I haven't used OB Control at all yet. How do you like it? I wasn't impressed by the software staying resident in the taskbar all the time. I've got enough junk running there without adding to it. I wonder if any of the other flag byte settings, like $3 have this same issue? Nice catch, anyway. Funny nobody noticed this before now... MG
I haven't even run a job on OB Control yet. There's a list of changes I wanted to make to my Ox variant, and setting up the Nano and discrete drivers was number one. It's now about 50% disassembled as I continued teardown after testing the homing direction stuff earlier. OB Control staying resident in the taskbar hasn't bothered me yet, my garage PC only gets turned on when I'm pushing a job to the router or 3D printer, or when I'm researching something while working on a machine. Although I will admit to listening to the odd football, baseball or hockey game while I'm working on something. I'm sure you could kill it in the Task Manager if it was eating up too much memory or just bothering you.
No, it loads a TSR (terminate and stay resident) driver that is always in the taskbar even if you close the program. Have no idea why they did this, it is certainly not needed with modern Windows. MG
So I got a notice from Github: "v1.0.157 or later will have this fixed!" That confirms I was correct and OB Control was wrong!
So I can confirm we are on the same page here, closing the app window isnt what I'm talking about. Right clicking on the icon in the tray and then selecting "Quit OpenBuilds CONTROL ( disables all integration until started again)" kills all processes from what I can see. What am I missing?
Sorry, I thought you were just talking about closing the main app window. Still, an unnecessary extra step, IMHO. The only other programs I have seen doing this are antivirus, bluetooth, etc that need to be running all the time. Why would your machine driver need to run all the time? Just more junk cluttering up an already crowded list of Windows crap running in the background sucking up resources. MG
For the integration calls from OpenBuilds CAM Gcode Creator - Public Beta ( See the bottom right corner of CAM with CONTROL shutdown, with it outdated, with it running etc and see how CAM knows whats going on - that depends on it being active ) -> it can launch the UI for new users and you can send GCODE to CONTROL without first having to remember to start control. Also, there are more upcoming features in the pipeline that depends on having CONTROL active. Like opening workspace files locally, Fusion360 Post integration (Send GCODE to CONTROL button possibly) and a lot of other groundbreaking ideas Think of it as a "printer driver" - its there to interface with your machine when you need it And when you don't theres a super easy Right click on the Icon -> Quit that will take it away for you till next reboot (Its not a TSR - TSR stays in memory even once terminated and is an old DOS thing. Its not even a service. its just a application that starts on boot and sits in your system tray till you need it - so quit really does quit all of it) Love it or hate it, the goal is to make it easier for users new to CNC. CONTROLs only goal is to make things easier. Every decision about its functionality is run through that test first, if it adds complication, its never going to make it in. If you need advanced software, we dont want you to use CONTROL (; . Control is there to make it easier for people to get started! In background mode thats going to be soooo little you'll never even know it
Allright, I concede... And I realize the TSR thing is from the DOS era, so am I. I just didn't know what the current name for it is. MG
