I have wasted 3 days of piddling around on with masking and painting only to have the last operation screw up the whole piece because something was missed in the Bitsetter process. Damn it!
Just one thing wrong in the process and there goes the damn bit digging to China.
And there’s no way to tell where I went wrong (or even if I did go wrong.) I’ve been using it for more than a month on some complicated bit changes without a problem, but all of a sudden my piece is off zero.
Now there’s a hole in the piece and I’ll have to come up with some kind of patch to fix it. DAMN IT ALL!
Any chance your remember your workflow steps ? There has been a few similar mishaps recently and I wonder where the pitfall is, probably somewhere in the ordering between zeroings and bitsetter probings, but I can’t quite pinpoint it yet. It would be interesting to get to the bottom of this such that CM can be made robust (to user mistakes)
As far as I know, I didn’t vary my workflow. It has something to do with bit changes, but I don’t recall any difference in what I was doing.
The machine starts in the same place, moves to the same places, hits the bitsetter the same way.
It has done this to me before, but I was distracted then by the fact that I was testing a cut and couldn’t figure out why it was cutting too deep.
This time it got me good. Now I’ll have to mill out the spot, replace it with a plug and repaint. Crap. And I’ll have to spend a lot of time testing to see if I can recut and/or cut the other two items.
Oh no! The bitsetter has been amazing on my end. I did have the set screw on mine become loose once but that didn’t ruin anything. The only time I’ve ever had my bit “digging to china” XD was when my retract plane was set above the possible Z travel. Here my motor quietly stalled and then lost its zero reference and dug into my part. That day I was cursing the fact that carbide motion didn’t send a flag when the limit switch was tripped…
I’m assuming your file is running along smoothly before changing the bit and digging into your part? that would remove the possibility of poor initial zeroing.
Ahhh. Think your problem then is that you put your V bit in after the bitsetter recorded the tool length already. You need to put the V bit in at step 2 so the bitsetter records the tool length of the tool your about to set your machine zero with.
this is the problem. you MUST have the bitset measure the new bit between you changing it and setting the zero… without that it will measure it later and adjust the zero for the tool difference.
the easiest way to do that is by using the “change tool” button in the UI, that will cause the right thing to happen
I noted the same thing before I ever installed it, based on others having problems.
I’m sick of this ad-hoc way of documenting how the damn thing works! They go to all the trouble of making prompts that don’t really help, and then its so easy to screw everything up.
I’ve been using it successfully, and then all of a sudden something changes and it all goes to crap.
PS. Thanks for the help, but it doesn’t help, really. I don’t mean to be critical of you folks.
I had to learn a new habit after getting it wrong a bunch. My new habit is “never change the bit without using the “change tool” button”.
that takes care of it for me.
I think there is more to this issue. I had a similar problem and ended up ruining a 5 hr carve after a bit change. Interestingly the bit penetrated far deeper than I would have expected even if the previous “zero” position was off. I am using the HDZ and the bit penetrated all the way down to the bottom Z limit, fortunately short of my metal table…
I have to agree with @CrookedWoodTex here: something should be changed in the workflow/instructions/prompt texts such that using the BitSetter becomes 100% foolproof.
@fenrus explained it quite well, and his workaround works fine (forcing yourself to do “load new tool” each and every time time you…load a new tool), but still, that is not bullet proof, humans will make mistakes/forget.
Unless I am mistaken, the intended workflow is:
Turn on machine, connect, “Initialize machine” => CM Prompts to “load a tool” and triggers a BitSetter probing to establish an initial tool length reference.
the underlying assumption is that “a tool” is in fact “the first tool for the job you are about to load/run, or at least the one you are about to set zeroes with, or you should use “load new tool” if you later decided to change it”
Let user set zero, hopefully with that same tool
possible user mistake here: changing tool here without doing “load new tool”, and zeroing.
User chooses to “Start”: CM will prompt to install the first tool for the job (specifically mentioning its name/number) and will force a new BitSetter probing
at this point, the Zero will be adjusted by the difference between this probing and the earlier one (done upon machine initialization or upon “load new tool”). In the nominal cases this difference should be zero, so this probing is currently useless IF the first tool for the loaded job was installed upon the first prompt during machine initialization or during a “load new tool” operation.
When the time comes for a tool change during the job, machine goes to tool change location, prompts for the second tool (name shows up in the prompt), measures its length with the BitSetter, adjusts Z Zero by the difference in length, and proceeds: this always works because there was no (credible) opportunity for the user to make any mistake between “Start” and that tool change.
The “incorrect” workflow is what we have seen people reporting: “mistakenly” doing the very first probing with whatever tool was in the machine at power-on time, then changing to the actual first tool for the job WITHOUT using “load new tool”, zeroing, and proceeding to start. Which as @fenrus explained will mess up the Z zero, by an amount equal to the difference in length between the “old” tool that was there at power-on, and that first tool used for setting zeroes.
So what if we had the following workflow instead :
Don’t bother probing tool length at machine initialization.
Drop the “Load new tool” button altogether.
Let the user install the first tool for the job and set zeroes with it: I think everyone does this naturally, and when you don’t have a BitSetter, you do this also.
(if you change the tool again after setting zeroes and before running the job, and forget to re-set zeroes, then it’s your fault, like it was before BitSetter times. But in my opinion this is much less likely to happen)
When starting the job, and ONLY if it contains multiple tool changes, go and probe to initialize tool length reference then, in anticipation for the subsequence tool changes.
Can anyone pinpoint what user errors would not be covered in that workflow ?
At least that’s how I would do it (and how I happen to use my BitSetter with CNCjs )
Sorry for the rant post, but I just lost a job that I worked on for more than three days!
I paid C3D $150+ for a tool that purports to “automate” the steps involved in bit changes, but it actually obfuscates many of the necessary steps that one would normally perform to get the job done. This is because why?
And now here we are trying to improve a product that they just dumped without completing it, hoping that their customers could beta-test and actually improve it.
We don’t have control over that “ONLY” part. Bitsetter is going to do the length reference measurement no matter what we want to do. It seems their engineers aren’t sophisticated enough to know whether a loaded job file (gcode) has tool changes or not.
I understand the frustration, and justifying why things are the way they are won’t help you at this point, but to be fair, you should know that the BitSetter did go through a closed beta testing phase before launch, the topic of what the “ideal” workflow should be came up, and there were debates. It’s a difficult game balancing the various risks of errors and anticipating what users may or may not do.
My intent in this thread is only to figure out if there could be a better workflow that would be less prone to user mistakes, since, and again I agree with you, it’s all too easy right now to get caught in that pitfall of not clicking on the “load new tool” button.
And no one caught the fact that the prompts from the program border on ridiculous?
“a probe”, “spindle” (instead of router or actually detecting which is installed) and probably more.
This is what happens when users are testers. We’re so excited about getting one for free, we don’t evaluate objectively. “This is the greatest tool in my pouch now!”
I don’t have a bitsetter but my all problems with weirdness after changing bits and probing my z block trace back, I believe, to using the table as zero, instead of the top of the workpiece.
Carbide Motion has always been in a state of development…I think that’s what anyone would want.
The workflow never made sense to me, and I moved on as soon as I realized I could. I agree that the implementation of the BitSetter in Motion leaves a lot to be desired, but…
The BitSetter is a piece of hardware that works. Your issue is with Carbide Motion (and is a valid one.) You are free to use other software.
)
