@Julien thanks for the info. I use a small piece of aluminum shaft that I turned down to .250" for the purpose of machine init with the Bitsetter and using the BitZero to set my X/Y/Z zero points on the workpiece. So it never gets changed in between operations. Once the program is loaded and started, it calls for a tool change in the g code, at which point the first live tool is inserted and run through the Bitsetter. I use that piece of AL because it is guaranteed to be .250 no matter where it is in its rotation as compared to a milling or drilling bit, which could vary based on its rotation with the flutes. That means my X/Y Zero will always be the same. My Z can vary based on how deep I insert it, but it doesn’t change between Machine Init and BitZero operations.
@Microwave_Monkey What you say makes sense. I’m pretty sure I’m cranking the collet down tight, but you never know. (It’s the Carbide Router.) I have the Z-Plus option on my Shapeoko. I have been experimenting with my feeds and speeds. Initially G-Wizard was giving me numbers that the machine just couldn’t keep up with. They were far too aggressive. So I’ve been bringing them down to more reasonable numbers. The last run I made in the material listed above (.375" G10 Plate) was 27100 RPM on the spindle with 15ipm plunge and 30ipm x/y feeds and a .090 DOC. This is with a .250" 2-Flute TaIN Carbide end mill. It is an upcut bit. I do have both up and downcut diamond and chipbreaker style bits coming from MCT, but they’re not here yet. I tried using the values from the Carbide3D Feeds and Speeds chart for G10, but even they seemed to be too much. (DOC .090, 18500rpm, Feed 60, Plunge 28)
I would imagine the z-plus could skip a step (as in the stepper motor is stalling on a handful of microsteps) in a much quieter/ less notable way (totally pulling this out of “you know where” as I don’t have a zplus) than say a pulley skipping teeth on a belt drive. If CC is generating your code that means there is no “lead in” or “ramp in” to the cut and (again, not familiar with g10) but it may be asking a little much of a straight plunge at that speed… maybe try reducing the feed and plunge by 25-30% and play with the feed override and router rpm during the cut to find a happy medium. I am way less technically inclined than others who I hope chime in, but listening and watching the cut and recording notes the entire time has served me pretty well on tricky pieces of wood.
So, in effect, you are doing what @Julien said, you’re taking the first bit setter probe with the blank, then zeroing, then the second bit setter probe and Carbide Motion doesn’t know you changed bits in between bit setter probes. I’m not sure why the first probe is even there. It seems it would make more sense to initialize, insert tool, zero, then bit setter. The way it is now, it’s almost forcing you to have the first tool inserted before you even power the machine on. Maybe @WillAdams can shed some light on the first bit setter probing.
But for now, you need to tell Carbide Motion that you have changed the tool in between probes
@Microwave_Monkey I can rewrite the gcode to ramp in to the material for the milling operations (this is all hand coded), but that won’t help for the drilling operations. This plate has over 100 holes drilled in it, a majority of them with a #50 - .070" drill bit. This is a test fixture plate with a whole bunch of pogo pins for testing circuit boards. I suppose for the drilling operations I will have to slow way down on my plunge rate. I’m going to have to anyway for those smaller bits. I don’t want to break them!
I remember with my first attempt to make this plate, I could see the entire gantry flexing as the spindle came down with the drill bit and made contact with the work piece. Overriding the feed rate and speeding up the spindle seemed to help some, but I think I was still too high on the feed.
@ctdodge I never change the bit. The machine performs it’s initialization routine, which includes an automatic run to the Bitsetter. After that I zero everything with the BitZero probe. This is all done with the .250 shaft which is not moved until I run the program. The program then calls for a tool change, which automatically does another run to the Bitsetter, this time with a live cutting tool. If I ever do change the tool outside of an executing program, I always use the Tool Change command in the Run screen.
The current workflow makes sense for me especially when I use Neil’s post processor from Fusion where I have enabled the pre-loaded tool option - it doesn’t have the first M6 command, so no bitsetter operation at the beginning of a job. I’ll note that going this route, Carbide Motion only recognizes the subsequent tools when it lists which ones are used in the job.
@ejlevy what happens when you prompt a tool change to switch from the Al shaft to the first bit prior to running the job? I’m curious if that makes it cut correctly the first go-around. Obviously, it would make the BitSetting prompt at the beginning of the run seem non-value added.
@RoughDraft40 I tried what you said and it was no different. I did a manual tool change prior to running the program, forcing a bitsetter routine. I also measured the amount of tool protrusion from the bottom of the spindle collet before and after and it didn’t change. The first run failed to cut through the material. The second run (performed in a new location on the test board) did cut through as it should have. The bit was not touched between runs, but because the program calls for it, it did go through the bitsetter routine each time.
I was attempting to run the tests again, but my bit has now reached the point where it is unusable. It has dulled and this time it did try to pull itself out of the collet. I have new bits on order, but I think I am in a holding pattern until then. One note of interest: before the final failure, I sent the router to x0y0z0 on the workpiece after installing the cutting bit and performing the bitsetter routine and it seemed to be correct. To me that points towards the z axis losing steps. But why would it lose steps on the first run but not the second? It’s using the exact same feeds and speeds, just in a different location on plate.
Lost steps are lost, so unless you redo the zero between the first (failed) run and the second (successful) run, it can’t be that. But then again in your last post you mention that the second run was performed in a new location, so you did redo the zeroes ?..
And at the risk of asking obvious questions,
was it also the case in previous tests ? (fail / redo zero elsewhere / rerun)
when you say it’s not cutting through on the first run, how much thickness left are we talking about ? (you must see where I’m going with this…are all failed runs in the same area?)
I’m in the same boat. I’ve get the exact same issue. I’ve seen it vary significantly from a small as .005" to .015" with the bitsetter. I talked to the guys at Carbide3d about it, but haven’t been able to account for why when the tool setter is in play the offset has drift. When I take the toolsetter out of the loop it doesn’t exist so I could remove lost steps. I know that the toolsetter offset or something else in the source code is effecting the tool length such that the depth cut is off. I created gcode in Fusion360, that defined the same tool under 4 different names so that it would require a tool change several times to see if it has a cumulative effect, without ever removing the tool. It was supposed to remove .25" in steps so I could see the difference and see if I’m finding the bottom, over shooting the bottom, or not cutting near the bottom. End result was it always came up short of the bottom thinking the tool was longer than it really was. In 5 other cases it thought the tool was getting shorter each time…never could figure it out. Even factory wear to the endmill, it was to much of a difference to make sense.
I went nuts chasing lost steps and slipping belts and pulleys, only to find out my stock mdf wasteboard was flexing about 1mm in the middle, and less towards the edges. This was giving me the exact same issue
Oh I agree. I don’t think in this case it’s a wide spread issue. In my case I just can’t account for where the error is coming from, is it something mechanical about the toolsetter itself such that it’s being triggered earlier or later than it should relative to the constant length of contact expected? Something in the feedback loop with the position of the Z-Axis that isn’t updating correctly? Bug in the code? I just know currently I can’t use the tool setter for anything that I might need to nail the Z-height because I can’t reliably repeat it. I’m positive the issue in my case is related to something in my specific setup otherwise everyone would experience this.
Let us know your testing methodology and reference this thread in a message to support@carbide3d.com and we’ll do our best to work out how to resolve this.
@Julien I simply edited my gcode to move the operation to a location 2 inches to the right of the original. Nothing else changed. At this point I have added a second duplicate cutout to the program, so now it will cut the first one, execute a faux tool change, then go to a new location and cut the new one. This code demonstrated the above problem. The first cutout did not go deep enough, leaving approximately .030" of material in the bottom of the cut, while the second one went all the way through, about .025" past the bottom of the material. @stutaylo I’m pretty sure my wasteboard isn’t flexing. I would think if it was, it would be lifting up into the cutter and cutting deeper than it should. The wasteboard and target material are sitting on top of three .75" plates of bolted-down MDF (the original Shapeoko bed, the T-Track & Clamp kit, plus an additional tooling plate I installed). It’s bolted down at the corners and in the middle. It should be pretty solid. At least solid enough for this.
I have run several tests of tool changes immediately after machine initialization and continuing onward from there using a dial indicator accurate to .0005". Using this method, I haven’t seen more than a .001" deviation. That’s what I would expect. So I still don’t understand the wierdities I’m seeing when running.
I have noticed that the milling bit I’m using will only insert so far into the spindle shaft before it stops due to a slight interference. I wonder if the bit is getting pushed up after the initial plunge, even though I’m cranking the spindle nut down tight, and stopping at that hang point. I was attempting to measure the before and after stick-out length of the bit on the last run when the bit became too dull to continue. The fact that the bit almost pulled itself completely out of the spindle on that run tells me that the holding force of that collet isn’t that great. It could be getting pushed up and in a small amount on that intial plunge. I’m only plunging at 15ipm, so I wouldn’t think that would be that aggressive. Maybe I’m wrong. Maybe that’s still too much for this little router in this material. As soon as I get some functional bits, I’ll test it some more. If that’s the case the question then becomes what, if anything, can be done about the collet holding strength?
@ejlevy, I think you might be on to something with that “endmill slipping towards the bottom of the collet” hypothesis. That would explain things, except…if at some point you did the whole double-cut again after a machine power cycle, without having changed/reinstalled the endmill (i.e. with it already “pushed all the way to the back”
I have heard about defective collets before, which would not have enough grip on the endmill regardless of how tight you would tighten the collet nut. If this turns out to be the problem, you could use this opportunity to buy high precision/low runout collets (Elaire, or C3D’s)
While you wait for new cutters to arrive, you could still use the worn out one and do test cuts in foam or something similar that cuts like butter, and if the problem disappears it will be another good hint that it’s the endmill slipping and not the BitSetter.
I just bought the bitsetter but have not hooked it up yet. If I had read this post first I am not sure that I would have even bought it. So is this a problem with all users of an the bit setter using fusion 360
I run Vectric Pro 10 software.
I am having same issues. I posted a topic about this not know this issue was wide known. I do multiple jobs with my SO3XXL with BitSetter without powering the machine down (10-20 per day to be exact), a lot of them are multitool. I am experiencing the same issue where the z-height is lost with the bit setter. When I run the machine without it, it is perfect every time. Powering down the machine in between job and initializing it could eat away at valuable machining time quickly.
Is there a way to fix this “pitfall” so that the bit setter alway picks up the correct tool height without powering/reinitializing the machine with the 1st tool?