The sequence of actions is correct (assuming you did exactly that, nothing less and nothing more), it should not have led to a problem.
Are you able to reproduce this, if you replay the same sequence of actions with the same file, as an air job ? This would be paramount to understanding what went wrong
Can you also upload the c2d and g-code file here is possible ?
You can click on the “Position” label at any time to toggle between relative coords and absolute coords in CM
Was the tool also loaded when you initialized with the bitsetter in the first step?
This Z crash seems to be happening a lot, and I’m no closer to finding out why it does this.
The main problem is it appears to be quite random - and they’re the worst things to try and resolve.
Good luck! 
Pete
Yes tool was loaded up even before the machine turned on, far as I recall. Going to try and reproduce. I suspect something weird was going on with state management… not sure but I am obsessed with figuring this out because it was the finishing touches on a piece with many hours in it. Will keep you all posted!
Is your program edited for G91 or G90 (Absolute or Incremental) Programming??
What is the purpose of clearing the offsets? I believe the Shapeoko will remember zero regardless. You can turn it off and back on again and zero will still be set…without clearing offsets. Can anyone verify this, please?
Lack of experience, lack of knowledge, and refusal to read the instructions… Would be my guess.
Let me guess… Z plus on that Shapeoko?
Things which can cause a problem with that sequence of events:
usually the other cause of difficulty here is changing the tool at a time when the program isn’t expecting it.
If you could provide a .c2d file, generated G-Code, step-by-step notes on how you are securing your stock and setting zero relative to it, and a photo showing an attempt at cutting still in place on the machine we will do our best to assist.
did this get solved?
My best (only) guess is that this is the actual course of events…
This tool change in step 2 above is the mistake. If we change tools we must re-run the Bitsetter routine because otherwise setting zero sets an incorrect z offset.
It feels redundant since the Bitsetter routine JUST ran when the machine booted up, and then it will run again when the job starts, but it is required if the tool changes length between boot and setting up zero.
Will continue to be on the lookout for some kind of actual bug.
In your original post, after the machine did it’s initialisation, including the BitSetter (I still struggle to understand why this is necessary) you didn’t change the bit, and the BitSetter did it’s thing again, when you ran the program. This is how it should work, but in you latest post, you’ve explained things slightly differently, i.e. changing the cutter and not using the BitSetter?
How did that happen, or did you disable the BitSetter in Settings?
Well so far there are only two solutions for this crash. A) There exists some phantom bug which no one has mentioned here and I can’t manage to reproduce or, more likely B) I did not remember all of the steps leading up to this crash.
The crash is all I have proof of, because it left a hole in my work piece. The steps up to that point, however, are a bit more of a guess since I don’t have a security camera watching my workbench… although… given my disreputable memory that may be a good idea… 
I (here showing the after effect of a crash because I didn’t realise the change to the Z height had happened and another example here) have raised this before as they’ve experienced a similar thing. The real problem is the issue can’t be reproduced - which is extremely unhelpful for the developers.
The only way to confirm if this is program-related, is to run the CM Log every time I’ve asked for that to be considered as a Feature Request).
It’s quite possibly person-related, but I’m pretty sure I’ve repeated exactly the same steps and the project has run without an issue.
Possibly, this could also be an EMI issue causing a small glitch rather than stopping the process dead in it’s tracks?
Yep, I’ve got that t-shirt, too!
Me neither, but it might be an idea to write down your steps as you do them - but when you do, you’ll realise that ‘input’ side of this hobby is quite protracted!
Good luck!
You jest about the camera but…
I have found using a camera, anything that will do basic video, even a mobile phone on one of those cheap bendy arm holders, to be a very useful way to go back and review my sequence of ops and exactly what I did to cause a problem.
Of course you’ll probably also get the “on camera” bias where you make some completely different mistakes due to knowing you’re being recorded but you might catch your sequence error. If it’s not a sequence error then a video of what you did in job setup may help the Carbide support team find the bug if it’s there.
Try to get the machine and the Carbide Motion screen in frame.
I stumbled across this while browsing and it reminded me, this has happened to me twice so far (had the shapeoko pro since Friday).
I am/was willing to chalk it up to user error but to the absolute best of my memory those were my same steps other than ‘clear all offsets’. Turn on, initialize (home & bitsetter), zero to stock, load and run program which touches off on bitsetter again, then it plunges like 10mm+ too deep on its first path.
That it did it twice to me makes me doubt it was user error. This post is making me even more suspect.
Sadly I can’t reproduce it on demand though. Each time I shut the machine off, swap out my screwed up stock, and repeat the same steps with the same gcode and run the job just fine. Never has happened twice in a row.
My best guess was maybe I didn’t click the “zero all” button like i think I did (missclick or something) if its user error. But doesn’t it complain if you go to run a program without setting zero? thought I saw that dialogue pop up once.
The complaint about setting zero is if you Jog to a position, then leave the Jog screen
ah gotcha, knew I’ve seen something like it pop up before while messing around! Thank you
For those not sure whether you they are occasionally inconsistent in their job setup and missing a step, the Japanese brought us ‘point and call’ as a way to perform these tasks with lower error rate. (I suspect @WillAdams may like, or already know about this)
If you put up a list near the machine of the steps, initialise, bitsetter, zero, new bit, bitzero, run job etc. and then as you go through the physical motion of each task, reach for the collet to change the bit etc. actually say it and refer to the list, you’ll build a different level of procedural and muscle memory.
I had a little problem for a quite a while, sending the new bit into the workpiece by forgetting to re set the Z, my machine was covered in “PROBE Z” stickers for quite a while. Muttering to myself as I get the collet spanners to remove the bit, put the bitsetter on the workpiece, insert the new bit, tighten, reset Z, put bitsetter away has reduced my error rate quite a bit.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.