Incorrect operation of backlash compensation when going home

Hello.
Please help me solve the problem of backlash compensation when going home.

3 axis milling machine. Mesa 7i96 controller, LinuxCNC 2.8.2.
There are servos on all axes. I use the zero sensor plus the servo index to search for home.
The hal and ini file in the attachment.
 
 

If I use backlash compensation, then LinuxCNC works in 2 variants.
1. Before sending to home, we go in the opposite direction from the zero sensor. After that we go to home. 
In this case, the axis stops at a new location each time. I checked with optical rulers and an hour-type indicator
2. Before sending home, we go towards the zero sensor. After that, we go home.
In this case, the axis stops at the same place every time. I checked with optical rulers and an hour-type indicator.
If we remove the backlash compensation, then there will be no problem. We will always stop at the same place when we go home.

How to make go home with backlash compensation always work correctly?

 

There are more problems than backlash here:

1. The P term is 0, this means there is no stepgen feedback so the position will slowly
accumulate errors during motion. Normally the P term would be 1/servo-thread-period,
or 1000 for a 1 ms servo-thread-period

2. Homing a step/dir system to index needs either encoder feedback,
(since encoders support the index logic), firmware that supports stepgen
index, or a hal component that simulates index operation, Here is a link
to a post of someone that did a related  hal component:
forum.linuxcnc.org/24-hal-components/463...der-m19-g33-1#246815

3. The stepgen acceleration needs to be larger when backlash compensation is used
(as the comments in the ini file indicate)

Here is 7I96 firmware that supports stepgen index (this requires LinuxCNC 2.9)

 

1. The P term is 0, this means there is no stepgen feedback so the position will slowly
accumulate errors during motion. Normally the P term would be 1/servo-thread-period,
or 1000 for a 1 ms servo-thread-period

Are you talking about P = 0.0? I didn't know, thanks, I'll read about this parameter.

2. Homing a step/dir system to index needs either encoder feedback,
(since encoders support the index logic), firmware that supports stepgen
index, or a hal component that simulates index operation, Here is a link
to a post of someone that did a related  hal component:
forum.linuxcnc.org/24-hal-components/463...der-m19-g33-1#246815

I don't understand why I can't do this with a simple hal module tristate_bit?  To input hm2_7i96.0.gpio.001.in encoder index is connected. And so for each axis. With these settings, going home works fine if you turn off the backlash. But I can't remove the backlash mechanically, so I use backlash compensation.

3. The stepgen acceleration needs to be larger when backlash compensation is used
(as the comments in the ini file indicate)

Thanks, I'll fix it.

Here is 7I96 firmware that supports stepgen index (this requires LinuxCNC 2.9)

I'm afraid to use an unstable version, LinuxCNC is not easy for me.

I don't understand why I can't do this with a simple hal module tristate_bit? 

Because LinuxCNC expects specific behaviour on index detection.

The way LinuxCNC homing to index works is that LinuxCNC asserts index-enable
when it wishes the external hardware to search for index. When the hardware
detects an index with index enable true,  it does two things, it clears the position
register to 0.0, and de-asserts index enable.

Because LinuxCNC expects specific behaviour on index detection.

The way LinuxCNC homing to index works is that LinuxCNC asserts index-enable
when it wishes the external hardware to search for index. When the hardware
detects an index with index enable true,  it does two things, it clears the position
register to 0.0, and de-asserts index enable.

I don't quite understand. I thought LinuxCNC was looking at my inductive sensor home, when it is triggered, it is waiting when it receives a signal from the index encoder. 

In your description, everything is somewhat different.  And if I was sure before that the home search works by the encoder index (I checked with optical rulers and an hour-type indicator), now I'm not sure.

Thanks, I need time to double check go home. And understand how it works.

Ideally LinuxCNC would support a "coarse --> fine" homing system
that would work with general purpose inputs and did not involve
changes in the feedback position from the hardware.

Currently however, LinuxCNC expects the index behaviour
described in my previous reply.

I understand what you said. And I understand that my solution cannot work. But I don't understand why it works for me.
Tomorrow or the day after tomorrow I'll check a couple more times, maybe it doesn't work.

Ideally LinuxCNC would support a "coarse --> fine" homing system that would work with general purpose inputs and did not involve changes in the feedback position from the hardware. Currently however, LinuxCNC expects the index behaviour described in my previous reply.

Yes, that would be great. 

I think I can use software encoder. This will require additional inputs, it may be possible to use the P1 connector.

You're right, it doesn't work for me either. I was wrong. 
Thank you, I will continue to understand.