Need help Homing sequence in H-bot( CoreXY) system

Since to move in the X axis both joints must turn in the same direction, and to move the Y axis the joints must turn in opposite directions. I think the only way joint homing might work would be to home to flags mounted somehow on the belt.

Another option might be to use immediate homing to get out of joint mode then probe your x and y home switches and reset the home position to that point.

The movement is diagonal (equal movement in x and Y).

Hello, Sorry for the delay... I was at a weeding this weekend

@andypugh : I already tried synchronize=-1 on both joints. But the rotation direction after the 1st joint has homed, needs to be reversed. So no luck...

Also could you explain me your proposal in your last post (the home signal). It seems an interesting option, but I have not understand it, sorry...

@Todd: I was also thinking about waht you proposed:

Another option might be to use immediate homing to get out of joint mode then probe your x and y home switches and reset the home position to that point.

Could you explain how to set-up the second part (probe x and y limit switches and reset the home positions) ?
I think it may be my best option until LinuxCNC is able to directly manage the homing of corexy machines...

Thanks a lot for your help.
Best regards,
Bernard

Been busy and haven't had time to reply today either.

For the plan of probing the home switches as a secondary task, using the limit switches will be slightly problematic. You will have to create a probing routine subprogram (there are example g-code files around you should be able to look at.)
If you want to use the limit switches, you will have to use some hal trickery to disable them while the probe routine runs. Should be easily done with a couple of custom M-codes.
Then after both the x and y home position has been probed the home probing routine can re-enable the limit switches and reset the home position of the joints using a custom M-code that toggles the hal pins halui.joint.0.home and halui.joint.1.home.

The biggest down side to this I can foresee is that your homed indicators will always show homed (even when they are not). But you may be able to rig up a separate one in a vcp panel that would be triggered by your home probing routine.

Hello,

Thanks a lot for your replies. I appreciate, and it's very usefull for me.

My machine is a CoreXY configuration. I'am using teh kinematics=corexykin option.

Would it be possible to modify the LinuxCNC homing C code to correctly manage homing of corexy machines (for example homing along X and then along Y instead of Joint 0 and then join 1) and then reintegrate this update in the main dev branch ?

If not, my best option will to try solving the homing problem using andypugh proposal. Then I will not have to launch a post homing script. I'll go the other way (Todd's proposal) if I'm not successful with the first option.

What do you think ?
Thanks in advance.

Hello,
I'am currently looking into control.c and homing.c to understand the homing stuff.

One idea I'am looking at coul be to add a configuration parameter in the INI file to choose between homing on joints, or on world XYZABCUVW.
The idea behind is to allow the homing.c code to optionnally call the "InverseKinematics" function while homing in order to allow to move all joints according to the machine architecture as described in the kins files (like corexykins.c for me).
I think this way, the homing function and strategy can be more versatile for different kinds of machine architectures... Indeed, some may have thier limit/home switch on the joint, some other machines may have their limit/home switch on the XYZ... world.

What do you thinks about the idea ?

Btw, should I open a new topic in the DEV part of the forum to go further in this discussion ?

Thanks in advance.
Best regards, Bernard