Is it homing the slaved axis first because it sees the slaved axis home switch first?
It does not seem to make a difference which switch it hits first, It seems to be looking only for the slave switch on the initial move. I don't
think it's looking for both but I could try pushing the master switch forward and see what it does.
As near as I can tell, during homing it moves the combined master/slave axis towards the switches then stops when it apparently hits the slave switch. It then backs off
both axes together until the slave sensor opens. It then uncouples the axes/disables slaving, homes the slave side again only this time it moves ALONE and SEPARATELY, backs off the slave side till the switch opens, homes the master axis separately until it hits the master switch then backs off and stops. It definitely does a more complex move than if I home it to Y alone and it definitely homes the axes three times. I can hear it move the motors. Once with both motors then each motor separately. I'll see if I can get a video of it in action so I can see exactly what its doing.
The problem I'm having is that when it homes the slave side first it's twisting the gantry slightly in the process. Then it homes the master side releasing the twist in the gantry when it pulls the master side back to square but when it does so it moves the gantry towards the switches enough to trip the prime sensor again. Initially I just disabled the prime sensor as a limit switch and it works fine as long as you don't try to home twice in a row. But if you hit Ref All Home or try to home the Y twice it doesn't detect the prime switch being tripped and tries to home past it, even though it's tripped. Definitely something it should not do and what I consider a bug. I might be able to prevent this from happening by moving the switches to the far outside of the gantry so the twist has less effect. I'll go fiddle with it some more and see if I can get video to post. I may need to report this as a bug.
I wonder how it would work if it sees the other axis home switch first? Could you try that before squaring your gantry? Squaring the gantry mechanically is a must IMO but I would be interested in the results if you do test.
I have tested auto squaring with the gantry out of square before the homing. The machine works fine except if you hit eStop or lock the operator and release holding torque on the motors which, of course, causes lost or gained steps. With the gantry square to begin with there isn't enough gantry twist to move the motors if you hit eStop. I discovered the issue when I was cutting a 3D shape. I hit eStop for some reason and didn't resquare the gantry and it changed the X axis path across the piece. Not enough to ruin it but I could clearly see the horizontal line where it lost or gained a step. What I need are encoders for the stepper motors but I don't think Mach will make use of them even if I install them. I'd only be able to use them to detect missed steps with an external comparator. It would be easy to set up a circuit that counts and compares pulses from the motor and the encoder, setting an error condition if the count is out of sync which I could trap using an input. I think there is just such a board somewhere. Unfortunately Mach does not support feedback steppers, only servos.
Tom
I'm just wondering what the sequence should be and if it will make a difference.
I can push the master switch forward while its squaring and see if it makes a difference.
I think it may well do it and if so, you will want to know before you square the gantry and set your limits.
Brett
[/quote]