If you did not reset zeroes in CM, and did not power cycle, then chances are CM has nothing to do with it since Z zero is (mostly) managed in GRBL at the controller level.
I can imagine three possible causes:
Z axis skipping steps during the previous cut (unlikely in your case if you were using a 1/16th endmill, and with standard plunge rates)
The tool length probe sticking slightly, throwing off the probing by 0.7mm.
the bed OR stock not being level to the machine axis and perfectly flat. Did you get that 0.7mm offset working off a freshly surfaced stock ?
and then again it could be a bug, what would help is if you could come up with a detailed list of steps that produce the problem in a repeatable manner.
It feels like a bug, but it’s happens so consistently that I’d be really surprised that others aren’t reporting it. That makes me think it’s something consistentaly wrong with my process. Here’s what I do…
Set up job with fresh 6x6x0.5" stock, referenced to front left corner at wasteboard. X&Y get referenced by eye, since I have lots of extra stock, and I don’t need ot be on the money there. Z gets referenced to the wasteboard, by tramming to within the thickness of a sheet of paper, then down an extra 0.025"
Start job with roughing and cleanup paths - CM does its dance to calibrate Z based on the bit placement, etc.
After roughing, change cutters, and proceed. CM again calibrates the new cutter length, and goes on to clean up and finish the job perfectly.
Tram the Y carriage back 40 mm to a fresh spot in the stock, and re-set Y zero to this new position.
Insert the roughing cutter, and prepare to re-run the same job.
At this point, my Z will have changed, because I moved cutters in the spindle. If I do a reality check vs. the wasteboard, it’s obviously different, since CM doesn’t know how deep I installed it. When I run the job, the startup check vs. the plunger probe doesn’t seem to re-cal my cutter-to-spindle position, but possibly just uses the position gathered from the original plunger probe scan from the previous job. The result is that the spindle will either cut air, or crash, depending on whther I installed the cutter higher or lower than in Job #1.
Am I missing a step here? It seems like CM should re-cal my Z when it does its startup “dance” at the beginning of a job, but I don’t think that’s happening. Do I have to run with the touch probe?
Workaround for me: If there’s an easy way to cut & paste duplicates of a part in MeshCAM, that would work for me. I can fit 4 pieces in my stock, so if I could combine them into a single job, then my zero would hold for that entire run, until I switch stock.
Thanks for the help here - this forum and support from Carbide have been top notch.
Yes, but only after the first job completes (successfully) and before the second one starts. Maybe I shouldn’t change the tool immediately after #1, but only when prompted between scan #1 and scan #2 of the second job?
I’m not really clear why the Nomad3 does its bit length check 2x at the start of a job. Maybe this is the source of my trouble. Should I leave the old bit installed when it does the first Z plunger scan, and then only change back to the roughing cutter after that, and before it does its second plunger scan?
OK - I’ll trust you there, and try shortly, since I’m about to finish a job and start a duplicate.
But can you explain what the Nomad3 is doing on these two probe routines when a job starts? Seems like the second one verifies the depth of the tool in the spindle. And I assume that probing between tool changes does the same. But what does the very first one do?
When you start the job, it measures the length of the tool you left in after you did the zeroing, then prompts for the tool for the job. Then it measures that tool to see the difference in the length between the zeroing tool and the job’s first tool. If those tools are the same, it does appear like it is measuring the same tool twice.
Just a quick additional note to let you know that the machine doesn’t actually ever measure the tool.
It just ticks downwards until it gets a signal. It’s no idea how long the tool is in mm. It just knows that the next time it ticked downwards, it didn’t tick as far or it went further, so whatever is in the probe is x mm more or less than the last thing that was in it last time.
But it does not know how long the tool is.
You can stick a pile of coins on top of the Nomad’s probe post, and it would all still work happily since there are no absolute measurements, only relative ones.
Hopefully that helps - I originally thought that the nomad was precisely measuring the tool length until I realized it wasn’t
Yes - very helpful. I guessed it was a relative measurement of the tool tip, but I didn’t realize that the double probing was to measure “old” and “new” lengths, to calculate a delta. For a single job, it’s redundant, since there’s no “old” tool. But this might be what I’m missing when moving from Job 1 to Job 2.
I’ll try shortly, and let everyone know if that’s the key.
Understood. That sort of makes sense, though you can still probably do both passes in one file. That is, copy the principal elements and move them 40mm in your design tool, and then generate the toolpaths to rough out both, then do cleanup for both.
That’s what I’ve been doing to get through this batch, and it works, except for the re-zero issue which has been met with suggestions that I’m in the process of trying.
Question though… Winston Moy shows some of the “C” lenses for the touch probes being manufactured on a Nomad. At what point in the design → generate → mill procress did these parts get arrayed?
I’m starting with a STL file out of Fusion360. If I’m 3D printing, then I can drop copies of this single element into the Makerbot software, which then generates the new slicing file for this array of parts. It would be nice to be able to do the same thing here - drop copies of a completed object (STL) into MeachCAM, and then generate G code for the batch. Then I don’t have to change my design file if I want 1, 3, or 50 of something - I just generate new G code for the array.
Possible feature add for MeshCAM if it’s not there already?