Thanks, @patofoto! That’s a great starting point.
I upgraded my Nomad to grbl 1.1f over the weekend and had a play around with CNCjs. I ran some jobs that didn’t require tool changes, which worked out really well – I’m very impressed with the software and feel like it’s a step in the right direction for me.
Tonight, I gave your TLO macro some testing and you’re right – it almost works, and I think I have a plan for bringing it up to 100%.
After tweaking your macro for the 883 Pro’s tool probe location, I pulled out some gnarly old 1-2-3 blocks and zeroed Z on one of them. Then I just ran the tool change macro over and over (without actually changing the tool in the collet) to see what the numbers looked like. Then I repeated with actual tool changes.
The results were quite interesting. They ended up being quite close – my work zero would almost always be about 0.2mm - 0.05mm above the tip of the tool, regardless of whether I actually changed the tool during the course of running the macro. This tells me that the tool length calculation is correct and the offsets are being applied properly, but there’s some non-repeatability in the actual measurement.
Some digging in grbl’s github issues led me to this: https://github.com/grbl/grbl/issues/464
Specifically, this quote regarding grbl’s G34.2 behavior:
Whatever probe you design should be able to handle some over travel, the Z movement likely won’t stop immediately. Some sort of spring arrangement would do.
I think what’s happening here is that the macro is issuing G34.2, hitting the tool length probe, and then experiencing some small amount of over-travel before finally coming to a stop. The macro is then doing its length calculation based on where the machine stopped as opposed to where the probe switch was triggered, which results in it thinking the tool is shorter than it really is.
Probing twice at different feedrates the way Carbide Motion does, and doing some sort of math on the results may yield a more accurate tool length, or maybe just probing at a much slower feedrate. It’s also possible that just applying some sort of fudge factor proportional to the probing feedrate may eliminate the error. Either way, I think that this problem is solvable.