I’ve successfully dove straight through and ruined two work pieces with this issue…but then did something right, fixed the issue and ran the job successfully. Long story short is I think my issue is the “clear all offsets” function. Sometimes I click it, sometimes I don’t…and I don’t really know what it does, not sure why or how I even started using it? Is that something that I even need to worry about for a basic, 20 minute job with 1 tool change? Or do I just need to set all my zeros then upload my file? Thanks for any help you can provide!
In my opinion, it would be more critical when you do it rather than if you do it. Right or wrong, I don’t clear all off sets. Having said that, I don’t run production so my set ups change each time.
From my understanding, people tend to clear all offsets right after the initialization/homing sequence, and what that does is resets the relative position. Instead of the relative position being the pull off distance from the homing switches (set in GRBL commands), they start at 0, 0, and 0. Since you’re setting your origin point after initialization, especially for a one-off short operation, I don’t see the benefits of clearing all offsets.
If you’re running production and you have a location that you always set as your point of origin then whether you clear all offsets can be critical. If you first set your origin (ie 90 deg corner) using clear all offsets, then next session, run without clearing all offsets and without manually re-zeroing, I believe you run the risk of being off of your original origin point by the pull off distance. I think this scenario would play out if you entered the coordinates into the MDI.
Anyways, it’s critical when you do it and how consistent you are with it rather than if you do it, for non-production work, in my opinion.
I don’t know if you’re wrong or not, @RoughDraft40 , but how does that compute with the last-known X, Y and Z zeroes being ‘stored’ in CM?
After starting up and initialising the machine - and if it completes it’s BitSetter shenanigans, if there’s one installed/enabled - you could Rapid Position to X and Y zero, and/or Z+6mm and, technically, be at the same stock zero the machine was at, before being shut down.
The machine stores it’s last point of origin. I’ll have to observe the machine, as I’m curious what the machine reads after pull off. I suppose it’s probably operating with the last coordinate system established and reads a funky negative number. This is where clear all offsets would be good to do if you were going to establish for a new repeating job that you’ll keep coming back to.
Thanks everyone for the suggestions/help. I wised up and put some MDF on my table to test a few things…much cheaper than Purple Heart! From what I can tell, if I don’t touch “clear all offsets” and just use the zero function, the machine dives straight down on the Z axis through my work piece, without any sign of stopping, as if there was no limit to the Z axis. If I re run the same job, but hit clear all offsets then zero everything there is no issue. Should this be the order of operations that I follow?
I don’t know about offsets either - and I’ve only used the clear all offsets command when instructed by the installation manual…and things work for me.
But this is a good example of how good engineers can write poor documentation. There is an assumption that you, the user, already know GRBL lingo and already understand the purpose of offsets. As I understand it, “Offsets” are set in GRBL G54-G59 and are used to position the piece (and maybe tool length?). The Clear All Offsets command exists - but unless you already know GRBL, you don’t know what it is or what it does. Consequently, you can use it at the wrong time - or not use it when you should.
Clearer explanations of all of the commands would be really helpful.
FWIW, I’m pretty sure “Clear Offsets” is only documented for use in the BitSetter documentation (use it before setting the BitSetter coordinates) — otherwise, it shouldn’t be needed, though it is available for advanced users who have a need for it in their workflow.
I talked with Carbide support and they said that “Clear All Offsets” shouldn’t be necessary either…but alas, my Z-axis dove through another piece of Walnut and another piece of MDF this morning after just using the Zero All function. I am starting to feel really frustrated and discouraged…anyone have a suggestion as to why my Z axis would be diving straight down? Running SO4XXL with Carbide Create/Motion with a Bitsetter. I ran multiple tests last week and could not get the machine to dive, but now it’s doing it when I’m trying to run a job with hardwood stock and I really can’t afford to keep ruining pieces! Thanks for all the help!
Tyler
CrookedWoodTex
(Tex Lawrence (Don't Mess With My Texas!))
11
Tyler, this is the first mention that you’ve made about having a Bitsetter, and you’ve made no mention of going through the BitSetter dance with establishing installed tool lengths.
Please. Document each step that you make to start cutting your part (or spoilboard as it were). It is important that you go through this, and it seems by the results that you aren’t following those BitSetter procedures.
I myself have never found a use for the “Clear All Offsets” button.
What I have come to realize in the two deep plunge cases I’ve experienced is that in both cases I was running the same very short V bit. My depth of cut was putting that bit at the limit of downward travel on Z so I’m thinking I lost Z steps or pulled the bit out of the collet just a tad. Which ever the case, I now use a short waste board on top of my waste board when using that bit to be sure I can easily reach my target DOC. That fixed it for me.
I know that I did not use “Clear all offsets” here, but I am hoping to confirm that this is the correct order of operations and I can avoid ruining stock!
In carbide create, Is your stock zero height set to stock top or bottom?
When I’ve come across random intermittent problems like this, ive found it useful to set the z zero high above the workpiece then run the job in the air to see that the file runs properly before ruining my stock.
The problem I’ve had doing this (or cutting in a piece of scrap to check the cut first) is it doesn’t necessarily prove anything - as the deep plunge effect (DPE) is random.
I’ve had the DPE happen on the very first cut and on a subsequent cut (i.e. after a successful initial cut) where I hadn’t turned the machine off, but only re-zeroed the X, Y and Z heights.
CrookedWoodTex
(Tex Lawrence (Don't Mess With My Texas!))
19
Are you using the BitZero to perform this step? Are you never using BitZero? When you say “Zero” do you mean X, Y and Z zero?
Are you using the change tool button to change the bit? I was having a similar issue when I first got my SO3. I was using the clear offsets too. I have not had the issue and I don’t use clear offsets at all. But every time I change the bit, I do it from the command. My thinking, I could be wrong, is that changing the bit without carbide motion knowing you changed the bit somehow throws it off. I’m no expert here…. Just explaining that i had this issue several times and I’ve convinced myself that this workflow solves it for me…