Summing Z axis on bridgeport

Todd, that's similar to the current situation. In the cam software all the tools are set to the same length, then when loading the tool, gmoccapy auto touches them off to a toolsetter and this sets the true tool length for that instance, so linuxcnc manages the tool offsets automatically and the cam just provides controlled point the same for every tool.
But If the manual knee is moved by a stepper or cranked up and down, the z height config of the toolsetter & difference to z height of workpiece have to be reconfigured manually for the toolsetter automation to work correctly. if these values can be altered automatically on the fly from the result of a offset calculated from a knee position value that would make life a lot easier. Probably the manual crank/encoder will be quicker to do and actually get done in a reasonable time frame.

I'll read up more, thanks.

So I've been thinking more about this, and playing with my autoprobing setup and got it all working smooth and... I feel dumb. I already have a encoder that measures the height differences between movements and plumbs it into the offset calculation. The toolsetter.

Now I properly understand how gmoccapy touch off works, i.e, I have the height above the bed as a parameter, and the height above the bed of the toolsetter touch off mechanism. Nowhere is the bed height itself defined, and it measures this every tool change as part of the automation.
So I can call a tool change for a long tool, drop the knee down a few cranks without being precise about how far, as long as its enough to fit it in the travel, and when it touches off the tool, it does all the calculation to heights and offsets automatically.
Its really simple for this use case, and I've been testing it the past few days.

I only need to do more once I add a stepper to move the knee, and even then the toolsetter touch off will deal with precise positioning and I could do something like tell the knee to move and how far for a tool change if its over x length and let the toolsetter deal with it in travel.

I can imagine a situation with a thick workpiece and a short tool where the machine might not be able to reach the toolsetter.
A spindle-mounted probe to find the top of the work might help there. Especially if you were to switch to defined-length tools. There are lots of neat systems for the BP, you don't have to live in the stone age with R8 collets.

(Though the flint R8 collets were rather fragile)

No R8 Its on QC30, so swap R8 issues for having cheap tool holders come loose because the flange thickness doesn't conform to the QC specs. Or pay for genuine BE or German QC30 holders that don't have this issue.

The toolsetter is one of those generic ebay four wire ones and sits with its top 80mm above the bed on a mount and I could always mount it on a taller block to raise it up further if the occasion ever demands it.

Years back, when I was using Mach, I ran into the same situation. I put a servo on the knee and defined it as a separate axis. I then used custom M6 code to send the tool length offset ONLY to the knee, the quill still handled all the cutting up/down feeds. On toolchange, the knee would lower so that the final move was always up. It worked out extremely well.

If it could be done in Mach, I am sure LCNC can do something similar.

gmouer wrote: I put a servo on the knee and defined it as a separate axis. I then used custom M6 code to send the tool length offset ONLY to the knee

You could do this in LinuxCNC by having the knee as a W axis and having a W offset for each tool (this could be tweaked with a Z-offset by the toolsetter, if required)