Finished parts ending like they were offset some how...

When properly configured, misaligned motors move in unison (so nothing becomes worse) until the first one hits the home switch when it stops and waits for the other side to catch up.

This only works because you have a very "soft" machine and your home switches are mounted almost at the same position. For example, homing with rotary encoder, it is practically impossible to set them at the same position. Imagine what happens when first motor finds its index pulse and the second encoders index is half of rotation away. The difference here can be 10mm or more....

Belive me, I understand gantries a lot better than you think.

As with anything, there is always one way to skin a cat. I think adopting the Joint axis homing and making joints independent of axes was a 3 year project for LinuxCNC and you should accept its not going to change just becasue you don't like it.

I would also recommend that you read the documentation which clearly describes what is going on.
linuxcnc.org/docs/devel/html/config/ini-homing.html

I think LinuxCNC's algorithm is more efficient than the one you describe becasue it starts from an unknown state and alignment occurs on the first move (eg it looks at both X1 and X2 at the same time rather than sequentially).

It is not that I don't like it.

Imagine a rigid machine, that only allows a couple of hundreds of a millimeter of squareness error. It is impossible to mechanically set the two encoders to be at the same position. And it is at the same time impossible for a second motor to find the index pulse when the first one is stopped.

@fixer

I do understand your point of view and i do agree that the actual homing way will not work on a proffessional very rigit machine with linear scales.

I do share your oppinion, that this should be implemented!

Who of you other people is using an index pulse for homing?
If not, IMHO you have not understood fixer!

Sorry for my strong words, but i have the impression, that sometimes some of the users of this forum do not try to reflect other opinions!

LinuxCNC is far away from being perfect, but many of us are working to make it better every day!
So please accept also other opinions!

Norbert

What problem do you see happening? Even with index, racking
should never increase during homing and AFAIK this the case

AFAICS Johns example did the optimum homing possible with 2 home switches.
Do you have a better solution? (and this is by far the most common gantry configuration)

If you have aligned indexes its theoretically possible to remove any racking before homing
if enough distance is available but this is not implemented currently

Wow BigJohn this really moved the water! should this theme be good to open a new topic? due that the title of this one is something off this conversation?.
Best regards to all!

For the very specific circumstance of rigid machines, high resolution scales, large index differences and homing to index
that makes sense but for for the 99% of LinuxCNC gantry uses (routers and plasma machines) the way gantry homing currently works is fine.

Even with high resolution rigid machines its probably better to remove racking on the fly before homing by capturing
the (perhaps adjusted) index offset before the entire home movement.

The problem is, that in practice one cannot acheive aligned switches or indexes.

PCW wrote: Do you have a better solution?

I tried to propose a better behaviour in forum.linuxcnc.org/38-general-linuxcnc-q...?start=10#122722this post , but unfortunately I don't have a knowledge to make it a solution.


as for the 99%, for me it is 100% fine as it is in 2.7.
And I am not expecting that someone will change it because I personally don't like the way it is. I just wanted to get the devs aware of the possible problem. Should probably raise a bug report on git. Or just be silent and do nothing, it doesn't affect me either way, I don't use the functionality.

The problem is, that in practice one cannot acheive aligned switches or indexes.

This is what most users of gantry homing do and the current scheme works well. It does assume aligned
switches (or indexes) This is not an unrealistic assumption except for some very specific cases.

In those cases where this assumption fails, it probable make more sense to break out the homing
function into a custom component to avoid complicating homing setup for most users in order to
accommodate uncommon machine setups.

Hello Guys,

Please see the attached file is the graphic screen after doing the machining it shows how the machining have being shifted and LinuxCNC knows about it! ??
Any suggestion?
Thank you!