Why is happening? It is a common occurrence that I see about 25% of the time I use my machine. If it is a small number I usually just press on.
I follow the same process each time. I initialize the machine, clamp down the work piece probe the BitZero and use the BitSetter. The entire purpose of BitSetter plus BitZero is to prevent this type of thig from happening. I don’t need advice on how to fix this one instance. I need a method to prevent it from happening in the first place.
This is a warning as noted at:
https://carbide3d.com/blog/carbide-motion-bounds-checking/
Usually it is caused by a mismatch between job setup:
https://carbide3d.com/hub/courses/create/job-setup/
and how origin is set relative to the stock:
https://carbide3d.com/hub/courses/running-shapeoko/movements-zeroing/
I find that opening the .c2d file up and drawing a box which matches the specified dimensions (draw up the cut in profile if need be) or moving the machine to the origin and then using a tape measure to measure out the dimension(s) in question will make clear where things aren’t lining up.
That said, the solution is two-fold:
A permanent fix would be to only use tooling of a consistent length with depth collars and to never deviate from that tooling offset length
The problem with the Z bounds check is that it cannot really know for sure if there will be a crash until the tool change happens and the true offset is found.
The warning is usually accurate if all of the tools have a similar length to the tool currently in the spindle. If you have a mix of tool lengths, it’s less reliable.
Because of that, the Z bounds check will be removed in the next release. Feel free to skip it.
All that is fine. But this error pops up on a regular basis. Looking through these forums there’s a new post about every other month. That tells me the issue is persistent enough that carbide 3D needs to do something about it.
I’ll go over the links that you posted, I’m pretty certain that I’ve done all that already.
My point is, why do I have a bit zero and a bit setter if I have to go through all the steps that you’ve proposed in order to get the machine up and running? Are these tools not designed to find zero and accommodate for different sized bits?
So instead of fixing it, you’re going to remove The z-bound to check? That sounds like a recipe for disaster.
I’m not trying to be rude. I’m telling you there’s a problem with the machine. The combination of bit zero and bit setter should be all we need to make sure that the machine is zeroed out and I get accurate cuts.
I can’t say that I’ve ever run into this issue. I’m not running my SPROXXL constantly every day, but when I do use it I’ve never encountered the Z-bounds check warning - or at least not for a good couple years.
A more detailed step-by-step procedure of how you set your job up may provide some insight.
The bounds check is a relatively new feature. The Z check will be redone in a different way in a future release. The future version will not be based on the current code, so the existing Z check can be eliminated now. The X and Y checks are solid.
Correct, and there’s no problem with any of that. There’s a problem with the implementation of the Z bounds check that leads to false positives.
Only pay attention to it if the first but in your job is already in the spindle and has already been measured. Otherwise the difference in length (stick out really) from the bit currently measured and the first in the job leads to misleading info in the error.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
