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

nbremond wrote: 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

I think it would be both possible and desirable.

I am just not entirely sure how to go about it.

The trick might be to have the homed-state as an input to CoreXYkins so that it drives the joints differently during homing.

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

A better place to ask this question may be on the developers mail list.

OK. Thanks

nbremond wrote: 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 optionally 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).

That might work, but it would involve diving in to code that is currently working well and that it is hard to test without a vast collection of real hardware. I am not saying that it couldn't be done, but it would be really hard to be confident that it hadn't broken something out there in the real world of installed machines.

If you look at the corexy sample config, that is set up for immediate homing, which gives two (not entirely elegant) solutions.

A.) Push the tool to a known position against hard-stops with the power off and home-all

B.) (After offline discussion with Dewey, this sequence can be demonstrated in the corexy sim config provided as part of the LinuxCNC installation)

The procedure is a little tricky:
1) Machine on, Estop off
2) Home-All (immediate), auto-switches to teleop mode with X=0,Y=0
3a) teleop jog X to 'X-home-switch' position (do not alter Y=0)
3b) Home All
4a) teleop jog Y to 'Y-home-switch' position (do not alter X=0)
4b) Home-All

Notes:
a) Home-All or executing distinct home joint 0, home joint 1 will work
b) the X,Y order does not matter, e.g., sequence 3a,b and 4a,b can be switched
and you could teleop jog to desired X AND Y position
and Home-All

The jog moves could be configured as probe moves as part of a scripted homing sequence (probably in Python). The key here is that when set for immediate homing home-all sets the current position to home and also switches immediately in to world-mode and out of joint-mode.

C.) We think that having joint.N.is-homing inputs to coreXYkins would also work. In that situation corexykins would drive the axes in the coordinated mode even though it was still in joint mode, but only if the is-homing input was set. This is actually equivalent to your suggestion of calling a different kins mode during homing, but moves the decision logic in to the kins rather than homing.c
I want to try this but would need to build a coreXY machine to test it on. This is something I have actually considered doing several times, but I don't see it happening in days, more like months-if-ever.

andypugh wrote: C.) We think that having joint.N.is-homing inputs to coreXYkins would also work.

Sorry, this was a misunderstanding on my part.
Kinematics is not involved in homing at all, so this is a non-starter.

A system of mux2 components driven by "is-homing" HAL pin might be a solution, or a custom HAL component to do the same thing.

Consider a HAL compionent that takes as input joint.0.motor-pos-cmd, joint.1.motor-pos-cmd and the homing state for each joint.

if homing state is 0 for both then in = out for both joints.
if J0 is homing then half the delta in J0-cmd from the point where homing started is sent to each output (one inverted) and the same (but different calcs)in the other case.

A reverse path for the feedback value would also be required to prevent f-error.

Flags on the joints (could be a hole drilled through the belt for an opto sensor) might be easier, though.