We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
Reaching out to the gurus when it comes to GRBL and setting up a new machine. I’m posting this in the inventables forum here, but my concern is actually in building a OX metal machine. I don’t think the concepts would change. GRBL allows you to change the homing position datum point of the machine pretty easily, but what about changing the readout? How does GRBL determine where zero, zero, zero is? I get when you first turn the machine on that’s 0,0,0. but after you run a homing cycle, shouldn’t that become 0,0,0? When I zero my machine out to the bottom left datum point, my readout is just the opposite, like -800,-750, etc. I’d like for it to read 0,0,0. If I simply home the machine, turn it off and on, then okay, I’ve got 0,0,0, but if I enable soft limits, the second I tried to move the gantry, it thinks it’s at the far limits of the machine and won’t move.
Is there a way to change the reference zero of the machine? Where does this information come from? The machine thinks that the top right datum point represents zero for x, and y, but where did that information come from and can it be changed?
There are two times that determine Machine Zero when using grbl.
When you first apply power to start grbl running, it has no idea where the spindle/laser is positioned, so it defaults Machine zero to the location where the spindle/laser sits when power is applied.
when you home your machine.
The co-ordinates are set to the negative quadrant by convention in the “real” CNC world so grbl does that also. You can change the co-ordinates to positive space with a grbl compile time option.
Machine Zero (Homing position) sets a reference point.
Since a CNC is typically a “carver” aka takes away material the reachable space is in the negative domain.
Work Zero can be anywhere inside the negative domain.
Work Zero is the user-defined start point of the design (XYZ0)
What do you expect to achieve from setting Machine Zero as XYZ0?
I believe it’s version 1.1. After doing a little more research, it appears this is mostly tradition, and yes I kind of get a cnc is removing material, but still not very logical to start out with negative numbers to me. If it’s not too difficult I would like to change it.
And to answer the other person’s response, I don’t hope to achieve anything by doing this other than it makes me smile to see the numbers at zero, because that’s where my mind, and the perfectionist in me, thinks they should be.
CNC’s are all about precision, and starting out with a coordinate system that seems broken doesn’t sit well. If it’s difficult to change, then I probably won’t bother, but if it’s something very simple to change than yes, I’d like to change it.
Thanks, no clue as edit a hex decimal file, and a bit scared to try. If an edited version of the file exists I think I can upload okay with Xloader, but otherwise I think I may be opening a can of worms. I’m still struggling with G-code at this point. LOL.
Normal humans don’t do that anyway. It’s all regular text before it gets compiled. Don’t want to suggest it’s better than uploading the pre-compiled hex, but it helps me to understand what’s going on in the “black box”. grbl/grbl/config.h at master · gnea/grbl · GitHub
As wonderful a thing open source is, I have found that many new people get into trouble trying to jump in and modify things for their system, when all they really want is a solution to their problem.
If you build grbl from source there are many pitfalls that come into play and you quickly become more of a computer specialist than a carving demon (not mentioning any names).
I’m most willing to help people with the low level stuff if that is what they want.
So, I tend to try and give them the candy, and also the S**t if they ask for it.
I get that, but grbl is really well documented. For some (never really know who’s on the other end of these usernames), the source provides more use than the “candy”. If the OP doesn’t want the info, no big deal. If one person gains from these posts,
In this case, in the doc I linked: // After homing, Grbl will set by default the entire machine space into negative space, as is typical // for professional CNC machines, regardless of where the limit switches are located. Uncomment this // define to force Grbl to always set the machine origin at the homed location despite switch orientation. // #define HOMING_FORCE_SET_ORIGIN // Uncomment to enable.
You’re right that all I’m really after is a solution. I don’t want to get into the ins and outs of changing programming. With that said, I’m also willing to pay anybody willing to do this for me a reasonable amount for their time. For someone who knows what they’re doing this sounds like it should take a few minutes to do.
You can private email me to discuss your terms if you’re willing to tackle this. Seems like the uploading part is pretty basic. Otherwise, I’ll just live with it the way it is. It’s not that big of a deal.
Yes, I get that, but there’s more to it. Namely the build environment.
Just as an example, Inventables shipped the x-controller for a couple of months with a version of grlb that would not successfully compile with the Arduino IDE (what most end users use to build grbl).
I frequently have to ask new users to download a “known stable” version of grbl to test out their problems and then they can move back to whatever release/build they want to use knowing if it doesn’t work, it is a problem with the build that they want to use because they have seen it work correctly with a known build.
A really good example of this is the UGCS “nightly build” versions.
The default version does not do what I need it to do and would have to be modified Larry. I know there’s no cost for the actual program. What I was saying is if you are anyone else wants to make the modification, I’d be willing to pay for that. I don’t think uploading it would be that big of a deal, but I’m not savvy enough to make the modifications myself and don’t need to open a can of worms due to my own ignorance.
Fair enough, but realise that after a homing sequence the machine will still be at X1 Y1 Z1
This is because the machine will pull off the switches 1mm (defined in the $27=1 parameter)
Interestingly, this was not the case in practice. I upgraded the file earlier today, and after doing a zero homing, the machine and work position showed 0,0,0. I think I have my pull off/retract set to 4 or 5mm, so I’m at a bit of a loss to explain.
Even if it did read X1,Y1.Z1 . That’s the actual position of the bit. It’s real and tangible. The machine has physically moved 1 mm, and the display shows its move 1 mm. Not -849 or something crazy that doesn’t make sense.
No question some of this is just psychological, but there’s no denying it’s also logical (to my brain at least). The display matches the actual movement, and I like that. I guess you could argue that -849 is quantifiable too and logical, but it’s certainly not logical or meaningful in practice. The gantry is moving forward and the display is reading negative.
Imagine if your gas gauge moved more toward full as you drove, your odometer moved backwards. I’m use to things working in a logical way. The world makes more sense now after this change!
To me, the machine position is irrelevant and not something I need to consider during a carve.
I only pay attention to where I set my work zero, rest is arbitrary - to me
My Machine Zero and Work Zero is never in the same spot.
