That's pretty much what I mean by proper gantry squaring - the software understands the hardware configuration and does the right thing with both ends of the gantry. The main thing that prompted my question was that the previous post described very accurate mechanical squaring but I wasn't sure how that tied into the software-initiated homing which would be used for normal operation.

I've been using Mach3 for a few years now but I wasn't aware that it understood the concept of master-slave axes. I use Mach3 with a CSMIO-IP/M and it's the motion controller firmware that takes over the homing function from Mach3. Unfortunately that firmware does not include the ability to square a gantry during homing - in effect, it just runs both master and slave in synchronism and you have to find another way to square the gantry. In fact (as someone pointed out on this forum a while ago) you can go into the CSMIO config menu and disable slaving. I then use a specific homing macro that homes X and A simultaneously; both ends of the gantry move to their home position but you do need to separately adjust the two homing sensors so that the gantry is square when it is homed. Once homed, you reconfigure slaving and it all works fine from that point on. Assuming that you don't hit e-stop or that anything serious happens, the gantry retains its "squareness" for the rest of the session, even if rehomed the usual way.

However, you have made me think a little more about this, and I suspect that because I separate X and A for homing, I could use the Mach3 homing offset parameter on A to provide the squaring correction more easily than trying to tweak a proximity sensor. I'll look into that.