Incorrect operation of backlash compensation when going home
- tpolimer2000
- Offline
- New Member
-
- Posts: 5
- Thank you received: 0
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?
Attachments:
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
- Posts: 17950
- Thank you received: 4817
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)
Attachments:
Please Log in or Create an account to join the conversation.
- tpolimer2000
- Offline
- New Member
-
- Posts: 5
- Thank you received: 0
Are you talking about P = 0.0? I didn't know, thanks, I'll read about this parameter.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
I don't understand why I can't do this with a simple hal module tristate_bit?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
loadrt tristate_bit count=3
addf tristate-bit.0 servo-thread
addf tristate-bit.1 servo-thread
addf tristate-bit.2 servo-thread
net set.index-x.in tristate-bit.0.in hm2_7i96.0.gpio.001.in
net set.index-x.out tristate-bit.0.out joint.0.index-enable
net set.index-x.enb tristate-bit.0.enable joint.0.homingThanks, I'll fix it.3. The stepgen acceleration needs to be larger when backlash compensation is used
(as the comments in the ini file indicate)
I'm afraid to use an unstable version, LinuxCNC is not easy for me.Here is 7I96 firmware that supports stepgen index (this requires LinuxCNC 2.9)
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
- Posts: 17950
- Thank you received: 4817
Because LinuxCNC expects specific behaviour on index detection.I don't understand why I can't do this with a simple hal module tristate_bit?
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.
Please Log in or Create an account to join the conversation.
- tpolimer2000
- Offline
- New Member
-
- Posts: 5
- Thank you received: 0
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.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.
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.
Please Log in or Create an account to join the conversation.
- PCW
-
- Offline
- Moderator
-
- Posts: 17950
- Thank you received: 4817
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.
Please Log in or Create an account to join the conversation.
- tpolimer2000
- Offline
- New Member
-
- Posts: 5
- Thank you received: 0
Tomorrow or the day after tomorrow I'll check a couple more times, maybe it doesn't work.
Yes, that would be great.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 think I can use software encoder. This will require additional inputs, it may be possible to use the P1 connector.
Please Log in or Create an account to join the conversation.
- tpolimer2000
- Offline
- New Member
-
- Posts: 5
- Thank you received: 0
Thank you, I will continue to understand.
Please Log in or Create an account to join the conversation.