Hello, we’re wanting to purchase a BitSetter for the use of our dragknife.
We’re going to add a cast aluminum 5/8" baseplate soon, and want to automate Z probing.
Was wondering what Gcode would be required to automate probing the Z height for the blade since we will know the distance from the top of the cast baseplate to the top of BitSetter/trigger point (or can find out at least with some trial and error).
I also just realized the dragknife might be too tall to be able to reach the top of the BitSetter
Our desired workflow:
• Power on machine
• Initialize/home
• Manually jog to XY starting point for cut and set X and Y zeros.
• Load our manually created gcode file
• Said gcode file also probes the blade and sets correct Z.
• Program continues and cuts out the shape.
I mean BitSetter, as was titled. We already use a BitZero and want to reduce time significantly. Should be no technical reason why the BitSetter couldn’t be used for what we want.
OK…Then I’m misunderstanding what you’re trying to do. It sounded like you were trying to zero out your Z after initializing the machine and before cutting.
Sorry, in advance, if what I’m saying you already know…but the initialization sequence will use the bitsetter to determine the length of the bit you have in the machine at the time you start it up. Then, you need to zero your Z (I use my BitZero to do that). Then you start your project. Whenever a tool change is required, the bitsetter is used to measure the difference in tool length, so that your Z remains at the right zero point even though the tools are different lengths. But zero-ing the tool in the first place is not done with the bitsetter.
Yes we’re aware of the normal documented BitSetter intentions, but we’re wanting to use it for a totally handsfree automatic Z height setting for all jobs, since the dragknife always stays in and that’s the machine’s only job is to cut shapes from the same material.
So…I’m not sure why you would need the bitsetter. When you start up your Shapeoko, it remembers your last XY and Z. When you go to run your job, CM will warn you that you haven’t set your zero and give you the option to use the previous Z. I believe that will be correct if you haven’t changed the bit and are still using the same dimension stock. No?
OK> I don’t know what happens to the Z setting when power is cut. I would have to experiment. I have both the BItZero and BitSetter…
Hopefully a Carbide guru will chime in…
Your position before you power off and the Z carriage drops, should still be relative to the homing switch so after turning back on and initialization the origin should technically be the same (relative to the homing switch still).
Edit: It should be pretty quick to do a test to develop some confidence in that procedure.
the Z zero value is persistent across power cycles, so if you happened to have a workflow where the stock is always exactly the same (thickness), positioned the same way (using a jig), you could just run the job over and over without re-zeroing.
the workflow described in the first post is doable using G-code macros…but CM does not support them yet. CNCjs (and other) alternative G-code sender would support that. If you know the stock thickness and it remains the same always, you could indeed use the BitSetter as a probe, harcode the absolute Z value of the wasteboard+stock thickness, probe the BitSetter, get an absolute Z value from that, and do the math in the macro to automate Z zeroing.
The problem is, this would be a specific probing scenario which would require to trig a probing move AND read the resulting Z value from the stream of text that the controller sends back when queried. A predefined set of commands in a G-code file can trigger the probing, but cannot “read” the resulting value and use it as a parameter for computing something else. CM does leverage probing info from the controller, behind the scenes, but it’s implemented to do one precise thing (the probing for zeroing on the BitZero, or the probing on the BitSetter for adjusting too length), so you won’t be able to modify its behavior to have it do what you want. Once you enter the realm of custom probing routines, using a more generic/hackable G-code sender will soon become unavoidable.
Then the simplest solution is probably to zero once manually, never reset Z zero, and try multiple cuts. You should get a very decent precision because everytime the machine homes, it starts from a known position and goes to the stored Z zero from there.
Here also, a custom macro could address this by having the router/blade do a predefined move around/above the obstacles. I do understand that it’s not fun to have to learn a new G-code sender just for this though…
What I was referring to is that the BitSetter itself would be an obstacle that can’t be worked around, since I have my doubts that the dragknife setup with the Z axis all the way up will be able to be safely above the top of the BitSetter plunger.
