I picked up the Dog River Tools BitZero alternative and the AstroCNC BitProbe (BitSetter alternative) which has been mostly great. However, I’ve been having issues with maintaining the Z.
Several times, when I start, the machine pings the BitProbe/Setter properly and then plunges to the moon instead of to the desired depth. It’s like it’s losing the set Z.
I’ve started probing the Z, then using Motion to go to Z+6 mm before I start, using the tool I intend to use. It is correctly set. Start the program, it hits the button and starts, but plunges straight down
The only oddity I can think of is I’ve been having issues with how I setup the BitProbe. It uses the BitZero for it’s connection (which I kind of hate - I feel like it should be connected to the machine). I’ve had issues with it not registering and have started testing it by pushing the button manually, early in the BitProbe/Setter portion of the setup.
Is the machine initialization setting the Z on the Probe/Setter? If so, my guess is I’m interfering with the setup, resulting in the machine thinking the Z is higher than it should be.
Probably a dumb cascade, but curious if anyone has suggestions.
The BitSetter works by detecting relative differences in tool length, so it relies on having a valid reference (length of the tool that was previously used for zeroing). Which means it requires to follow the recommended workflow,
BitSetter probing at machine initialisation time
following the CM prompts at tool change time
Never swapping the tool without using the Change Tool button in CM
So this:
is probably messing with the very first measurement, and then later relative measurements could be off
I’ve heard this mantra many, many times, but I’ve rarely done this. The only time I did this, to change the BitZero probe for an end mill, the BitSetter initiated the workflow again, at the start of the cut.
For me, the BitSetter is designed to initiate the bit change workflow when the GCode requires a bit to be changed. The only time I see the Change Tool button being required is when a bit breaks, perhaps, and needs changing ‘out of sequence’.
Under what other circumstances would the Change Bit be needed, other than having put the wrong bit in, in the first place?
This mantra is just short for “if you happen to physically swap the bit in the router outside of the normal workflow, the previous tool length value that CM memorized will not be valid anymore, and bad things will happen, while if you stick to only ever following the prompts or using the change tool button, CM will always refresh the tool length and then life will be good”
I agree that there aren’t many usecases where one would use the Change Tool button anyway, besides the one you mentioned, but there are many posts about incorrect Z depth that turn out to be due to incorrect workflow around the BitSetter, so the mantra is a way to get things right always. And then again there are the few elusive cases where the workflow was ok and there was still a depth issue, and then we try to investigate, but none of those has resulted in detecting an actual bug in the BitSetter management so far.
I think you are getting the sense of this advice around the the wrong way - at least slightly.
It’s not really telling you that you need to use the Change Tool button, or that the Change Tool button is very useful.
It’s really telling you to never try to change the tool when not prompted without using that button.
It’s like telling someone never to get out of a car whilst it’s moving. It’s the correct advice regardless of the number of times it is useful to get out of a moving car.
EDIT: I’ve only every used it when the bit that was in the machine when it initialized was a 0.2mm bit and I neglected to swap it when prompted, and then didn’t want to probe Z with such a fragile bit. Maybe only twice in year, though
That’s a bit worrying (I’ve seen those posts too), but I guess it would be almost impossible to know why the Z depth is ‘off’ after being zeroed, unless it’s a flaw in the projerct design - and no-one’s infallible, but this should be fairly easily identified. If, however, this is a random bug (the worst type of bug!) it might be useful to understand if it happens after using the Change Tool button or not, but I don’t envy the person who has to bebug a random, rare and unrecorded bug!
I use change tool in this situation (which happens sometimes):
I initialize with the bit I think will be the first bit needed for the project
I load the project
The first bit is NOT the bit I thought it was. I want to Zero using that first bit, so I want to change the bit before starting the job.
I use CHANGE TOOL to swap to the correct first bit
I zero
I start the job…it asks for the bit change to the first bit - which is now in the router…so this step is meaningless
In general, my workflow makes the first bit change in the job run redundant…because I either already have the first bit in there from initialization, or I’ve changed it before running the job using CHANGE TOOL before zeroing the bit.
EDIT: I realize that I could zero with the bit that I initialized with and then change to the first bit when prompted by the run job startup - but, I don’t know, I feel better zeroing with the first bit of a job…so I accept the redundancy.
Thanks, everyone. @GJM’s explanation really nails it home for me.
Part of the dilemma is the wiring on the BitProbe. AstroCNC (who’s support is amazing, by the way - email responses late on a Saturday night!) recommends wiring to the bottom of the their holder. Not sure about the BitZero, but the Dog River unit has the cable offset to the right. The AstroCNC is a bit tight around the cable.
I soldered a section of stripped solid connect wire, added two holes on the side of the holder and ran the wire down the inside for a larger surface, higher up. Now, if the Dog River probe isn’t all the way at the bottom, it will still connect.
I need to think about how I might rewire it to be more similar to the BitZero setup. I think relying on the puck is a failure point for sloppy operators (like me).
