FWIW: statistically speaking, based on threads on this forum, the cases of “the bit hovers above the stock” usually end-up being due to:
an inconsistency between where the zero is defined in the Gcode (stock top or stock bottom) and where the user actually zeroed. A slip of the mouse on the wrong button can happen to anyone, so it is worth double checking the design file. Typically, declaring Z reference at stock bottom but actually zeroing on the top surface (or corner) will result in cutting air.
an incorrect use of the Bitsetter and its workflow, and namely swapping tools without being prompted to do so (it’s an easy mistake), and then the machine cannot properly track the difference in Z lengths between tools and the Z zero ends up not being where it should be.
incorrect zeroing procedure, the one example I have in mind is launching probing, but then inadvertently also resetting zeroes manually in the interface (as one would do when using the paper method). Since the probing movements end with a Z retract, if one clicks to zero Z at that point (after probing completed), you end up inadverently resetting Z zero to that retract height where the tool sits after probing. And that’s a recipe for an air cut too.
There is always the possibility of a bug hidden deeply within CM, and I think it would be very interesting to get to a point where someone is able to produce it in a controlled/repeatable manner, but after years of threads on this, this has not happened yet (so either the bug is really rare, or there is no bug and it boils down to operator errors, I have done my share of those…)
All fair points.
I was just trying to sum up where I think we are with those issues, and I really meant it when I mentioned I would really like to find a case where there is enough data to get to the bottom of things. I have tried a number of times in the past, asked for logs and parsed them for clues, and I was never able to put my finger on something suspicious in the end, or at least the issue went unresolved and nobody was in a position to analyze further.
Personally, to mitigate workflow errors I have developed my own take on the operator checklist Will linked, and I find myself mainly doing two things:
3D-previewing the G-code, always. I wish CM would integrate a G-code preview window, but in the meantime I use a third party (online) option, it’s easy and quick, and it has saved my b*** more than a few times.
double and triple checking my zeroes, and always, always, religiously follow CM prompts for tool changes or use the Change Tool menu when the BitSetter is involved.
Beyond the “checklist” approach, we enter the difficult terroritory of “whatever interlock/condition we could include in the workflow will be appreciated by 50% of folks, and hated by the other 50%”. I really like the fact that I’m not in charge of making those workflow decisions
Ooooh wait a second there, I missed that in your earlier post.
There is of course no good reason why the BitSetter probing routine would do that, and the thing is, CM does not do much. It’s GRBL on the controller side that does all the heavy lifting, and in the case of the BitSetter (or the BitZero, for that matter), what happens is CM only initiates a probing sequence by sending “G38.3” to GRBL, and then it’s GRBL code that does the moving and touching and stopping upon contacting the surface. It’s still CM that triggers the second (slower) probing move.
When you said the Z retracts to the top of the axis, does it stop nominally a few mm before it hits the limit/limit switch? If so,
either there is a rogue G-code command telling GRBL to go to the parking position (unlikely, but I would not want to rule out any possibility too early)
or…GRBL somehow receives a “Feedhold” command after the first BitSetter probing, and what it does upon Feedhold is going to the parking position (top of the Z). I wonder if there could be some kind of electrical issue in your setup where the feedhold and probe input somehow couple into each other.
Please send in a .c2d file, generated G-Code, step-by-step notes on how you are securing your stock and setting zero relative to it and managing all tool changes, and a photo showing an attempt at cutting still in place on the machine.
as a diagnostic technique for years now — I have yet to see a file which when the machine setup matches the file fails to cut as expected on a properly configured machine when nothing goes wrong.
The machines are open loop, lost steps are a possibility, the trim routers only have so much collet, the endmill getting pulled out is a possibility, but usually it’s some error on the part of the operator.
I will reiterate — if someone can provide a step-by-step set of instructions and files which result in a repeatable incorrect result caused by the software and not a failure of the machine, please send it in to support@carbide3d.com.
The great thing about CNC is that given a properly prepared file, a machine setup which matches the file, and nothing going wrong in the cutting, a part will be made correctly.
The awful thing about CNC is that a part will only be made correctly if the file is prepared properly, the machine setup to match the file, and nothing goes wrong in the cutting.
setting the Z-axis safety/retract height in the CAM program (Job Setup | Machine | Retract Height in Carbide Create) to a value greater than is available above where the machine expects the top of the stock to be, resulting in the machine bottoming out against the top stock, thinking it is too high, then plunging down too far in an effort to travel down as far as that failed effort would allow. Setting the origin to the bottom of the stock/wasteboard surface, while setting the zero to the top of the stock may also cause this problem
Will,
With respect to securing the stock, on the planing I used cam clamps on all 4 sides, the stock was tight with no movement and flat to waste board. I used 2 business cards on 2 opposite corners to prevent wobble.
With the shop clamp file I used the T-Trak hold down clamps on top of the stock. As above everything applies other than the business cards.
Initially on both separately run projects Zero was lower left. Bit Zero was used to set Zero and the magnet was placed on probe. As a matter of personal practice I hold the Bit Zero snug against the stock. When I clicked on run for either project the router retracted and moved from zero to the start location. The router itself was approximately 1" above the work surface, in that position it proceeded with the cut with the router not plunging down to the stock. Both times I clicked pause and then stop.
I closed CM and then reopened it, the machine went through connect and initialized to the NW corner. Using I manually set Zero using the paper method at the bottom left of the stock, loaded the file, hit run and everything worked fine both times.
The 2 were done hours apart. Both project only involved 1 tool so no changes were involved during the operations.
Hope this helps explains what and how I did things.
I’m not confident BitSetter (or CM’s interpretation of what comes out of BitSetter) is wholly accurate.
I ran a project with a second toolpath using a longer end mill (than the first) to cut a deep hole into a piece of stock. The tool change process worked well enough and the BitSetter did it’s thing, but the retract height wasn’t quite enough to clear the stock and scratched across the surface of it. When I pressed the feed-hold button to pause the cut, it retracted clear of the stock - not by much, but it was still higher than the height it retracted from the BitSetter!
which when removing all the clutter (status lines, delays, N0) becomes:
M56P0 = disable Parking
M5 = stop spindle
$h = home/initialize
<Home|MPos:-3.000,-3.000,-3.000|Bf:14,128|FS:0,0>
M5 = stop spindle
M56P0 = disable Parking
M5 = stop spindle
G0Z-5.0000 = retract to top of Z minus 5mm
G0X-209.5000Y-399.0000 = go to X0, Y0 (happen to be set at -209,-399)
M56P0 = disable Parking
M5 = stop spindle
G0Z-5.0000 retract to top of Z minus 5mm
G0X-7.0000Y-384.3250Z-5.0000 = go above BitSetter X,Y location, still at top of Z
G0Z-15.0000 = move down 10mm along Z
G38.2Z-155.0000F800.0 = initiate first probe movement, down to max Z= -155, at speed 800mm/min
[PRB:-7.000,-384.325,-32.625:1] = probe result, contacted at Z=-32.625mm
G0Z-28.5300 = retract before second probing,
G38.2Z-183.5300F50.0 = second probing, potentially down to Z=-183.5, at 50mm/min this time
PRB:-7.000,-384.325,-32.610:1] = (more accurate) probe result, found at Z=-32.61mm
@jepho Was it on this initialize BitSetter cycle where you saw the rise to the top prior to the second probe? Or did it happen after setting your work zeros?
