@DCFYI you need to zero your stock with the same tool used during the very first touchdown on the bitsetter (edit: after initialization). If you change this tool and then zero and the length sticking out is either less or more (longer/shorter) then the initial tool that first touched the bitsetter this would result in either air cutting or plunging.
I have used the probing pins but BitZero tells you that you don’t need to use the pins. You can use an endmill. V cutters won’t work to probe X and Y with the BitZero but a straight cut bit will.
@WillAdams @Gerry I agree it is probably a user error on my part, and the others who are having the same issue. I do not doubt you, just trying to understand the differences.
I think what might be confusing people. It’s the fact that when your first initialize the shapeoko, the machine homes, and touches off the bitseter. Then after you zero the machine off the project, it touches off the bitseter again as a part of the “run job” sequence. Intuitively you would think that the bit height would be corrected after the shapeoko touches off the bitseter the second time.
1 Like
It is my understanding that the initial measurement is needed to determine the initial offset.
The big thing is, only change when using the interface, or when prompted.
2 Likes
Measuring the tool the first time creates a length which later tools can be offset from.
1 Like
Thanks for the help @WillAdams . Three questions. Why is touching off the bitseter required after you initialize the machine? Why is touching off the bitseter required after you zero the machine as a part of the “run job” sequence? Shouldn’t the initial offset be captured when you zero the machine off the project piece?
I don’t mean to be a pest, but I think we’re onto something here. My senses the issue that @mynamejefff and others are having Is related to a user error. I believe Your responses to the above questions will help resolve the issue. Again thank you so much for your patience and help!
When the machine first starts up, it determines the home position (top, right, back), then, in order to use the BitSetter it has to determine where the tip of the endmill is in relation to the top position — the initial measurement of the endmill determines that.
When one changes an endmill, this is handled as an offset length from the original endmill, so one has to measure again — even if the offset is zero.
1 Like
@WillAdams It sound like we are saying the same thing. I think 
I’ll record my process and send it to caribe support. Thanks again for your help.
First double check… hell triple check everything mechanical. If everything checks out 100% then you might need to run calibration test for the entire machine. Once you know the machine is running accurately then double check zero after you set it with the BitZero. Run the rapid to X&Y and then Z+6mm. Jog it down manually 6mm and make sure it’s exactly right before you start the job. Here is a step by step tutorial on calibrating each axis.
3 Likes
It’s similar…
However, from the time you turn the machine on until you turn it off, every time a tool touches the BitSetter the difference between the distance in Z it travelled this time is compared to the last time it touched the BitSetter, and that offset is added/subtracted from the current Z-Zero. Every single time. That offset number is never reset - not by loading a job, or setting zeros.
So it doesn’t matter what you do if you change the tool without telling CM. Setting Zero, loading a Job, are all meaningless. It will modify your Z-Zero by the difference in tool length since the last BitSetter touch, each and every time it touches the BitSetter.
4 Likes
I tune and clean my machine every time I use it and last year while working with support they sent me a file to run in order to gauge the results relative to calibration, accuracy and consistency of the machine. I was able to run that program with no issues and the proper calibration was confirmed. The point being that my machine is calibrated and tuned correctly and I know how to operate it. EMI issues and Z failures seem to be random, uninitiated events in my case and unfortunately for me they occur with a frequency that is unacceptably common.
My point it this…again. If I am running the same file, with the same workflow, placed in the machine on the same spot with the same clamping method, on the same day and in the same environment 20x but I have ~3 depth failures how can that be user error. All factors are the same. I am operating correctly, my machine is operating correctly, it is simply not consistently reliable.
I’ve heard a lot of discussion about tool changes so to be clear, I am in the habit of installing the end mill that I intend to use on my first job before I even initialize the machine and once running I do not change the end mill unless prompted by CM.
For those who are keeping score I have been in an email thread with support trying to trace this issue since December 4th 2020. I have worked with four different techs now. After that time and effort we still haven’t been able to solve the problem. If it were as simple as my workflow surely we would have identified that by now.
1 Like
My fault if I misunderstood.
Your previous post seems to say you put the correct endmill for the job into the machine after the BitSetter probe and before zeroing Z, which is something you can’t do and expect it to work.
It’s a problem with a forum - people only have what is written to go by and it’s easy to misunderstand.
5 Likes
True. And the same point applies to finding the actual root cause of what you are seeing: if it was a simple bug in the software or hardware, it would have been fixed by now. I can only imagine that the extreme difficulty for support is having enough information at once to be able to pinpoint a cause. I’m not on the support side, but on the forum side every single time we started a community quest to find the cause, AND no root cause was found in the end, we also never managed to capture a fully documented example of an occurrence of the problem. For a good reason: it’s extremely tedious for anyone to capture ALL info required to debug, all the time, so have them when bad things happens. Basically to hope and find something wrong we would need:
- a full video capture starting from a powered off machine
- notes about actual stickout (measured manually) of each endmill being inserted in the router, actual stock thickness, etc…
- the full GRBL logs covering the time from machine being turned on to the unexpected plunge.
- a measurement of tool stickout and offset from expected Z0 immediately after the incident
More often than not, we miss one or several of these or folks just go silent (understandable…but we are then left in the dark).
I like puzzles as much as the next guy (and probably more), but we need data to dig into…and yet I fully understand that some users have other things to do than collecting them to have their problem sorted out. There is no easy way out of this situation…
3 Likes
Indeed this is not very convenient right now. The only mean for now is to have the Log window open, check the box to filter out status messages (and then again they may help later, but for a first run they can be left out), reproduce the issue, and then “copy all” and paste that into a text file. I don’t know the max depth of that log though, but I think it should cover the time span between a machine initialization and the first (erroneous) plunge into the material.
1 Like
My bad, I think I was writing a little too hastily. Easy to lose in translation but no, I don’t do that.
No doubt it’s a complicated job for support to solve these problems remotely. I empathize with that but my empathy evaporates when they get stumped and start ignoring communications.
I work with airplanes for a living and at work our most hated failures are the intermittent ones. A hard failure can be identified but intermittent failures are extremely difficult to track. You’re right that data is our friend when it comes to these intermittent faults but I’m not interested in continuing to work with this fault to track down data while my business continues to suffer. I for one am done.
Coming from someone who doesn’t have any of the BitSetter / BitZero add-ons, I wonder how much of the issues can be side-stepped if the members just cut their loss and avoid the accessories? I understand the majority of people use them without problems, but in the end would the rest rather live without these features or the odd chance of screwups? Particularly those without any machine and machining experience; this hobby / company / product is not at the point of being an appliance yet (3D printing is closer to that stage), and layering on more accessories / complexity doesn’t necessarily help. Consider that at your community college, being a CAD/CAM technician is a two year program. Even a general machinist apprenticeship is an one year program.
Yes, I understand that at least for some they are coming from experience and have natural inclinations to tinker and solve problems, similar in vein to what I heard about some police detectives, that they view solving the crimes not as a pursuit of justice / order, but rather as a puzzle and an challenge to their intelligence. But at the end of day, if it is taking a toll on you, is tossing out a $130 device so bad?
1 Like
I’ve been thinking about this statement and I would argue that an intermittent problem like this likely means that the bug is not so obvious. I would also argue that a workflow issue would become obvious much sooner than a software issue. With that said I don’t know anything about coding and I have no ability to dig into the software. I have applied a fix to every aspect that I have control over, software coding is an area that I do not.
In the effort to isolate the Z0 issue I have disabled both and still seen the Z0 malfunction though.
How much is it off in those cases? Exactly the same as before, or by different amounts?