Homing back-off doesn't work as expected

[FlyingLotus1983]

Hey Karl,

Posting this here rather than emailing you as this should be easier to track (it's a bug tracking system after all, haha).

Homing back-off doesn't work in the way that I would think it would. There isn't much documentation on what exactly backoff is used for, so it's hard to tell if this is a documentation problem or a code implementation problem. Either way it has caused confusion not just to myself, but some others have made the same incorrect assumption that I mad.

The behavior that I'm seeing from homing backoff is: Set homing backoff to "0". Then move to a given raw coordinate, say, 1500. Mark angle to where the arm traveled to. Now set backoff angle to some othe rnumber, say "500". Go to same raw coordinate (1500). Measure the arm angle. What we are seeing is that the arm is at a different position, depending on the backoff value.

The wiki / documentation doesn't say this explicitly, so I'm not sure if this is the intended behavior or not. What I would expect is that you could set the backoff to some value, but the raw-position-to-actual-posiiton correlation shouldn't change. Others that are helping me have came to the same assumption, correct or not.

Are my assumptions correct or incorrect? What is the intended behavior? And can the documentation be expanded to better explain what it does? I don't mind making the change but need to get clarification here before I get the scalpel out.

[firepick1]

Neil, the latch backoff serves one purpose only. It is a small number designed to cancel optical limit overshoot caused when the interruptor slams into the opto-limit stop at high speed. In other words, a high speed trigger might be different than a low speed trigger. The backoff is just the amout to move away from the limit switch before probing slowly and carefully.

After getting a more accurate limit switch value, the code currently backs off again after the slow accurate move to prevent high speed overshoot into the limit switch on what might be a perfectly good delta move. For example, if you whip the arm to the limit coordinate, it should never trigger. That's what the backoff is intended for. It's not really a homing angle adjustment, although that's actually how it's implemented.

We have two choices:

1. keep as is and use small values (500 seems a bit large. I initially though 32 would be fine)
2. eliminate the second backoff and never do high speed moves close to home

WDYT

[firepick1]

Comment posted. Curious to hear your thoughts.

On Tue, Aug 11, 2015 at 5:28 AM, Neil Jansen notifications@github.com
wrote:

Hey Karl,

Posting this here rather than emailing you as this should be easier to
track (it's a bug tracking system after all, haha).

Homing back-off doesn't work in the way that I would think it would. There
isn't much documentation on what exactly backoff is used for, so it's hard
to tell if this is a documentation problem or a code implementation
problem. Either way it has caused confusion not just to myself, but some
others have made the same incorrect assumption that I mad.

The behavior that I'm seeing from homing backoff is: Set homing backoff to
"0". Then move to a given raw coordinate, say, 1500. Mark angle to where
the arm traveled to. Now set backoff angle to some othe rnumber, say "500".
Go to same raw coordinate (1500). Measure the arm angle. What we are seeing
is that the arm is at a different position, depending on the backoff value.

The wiki / documentation doesn't say this explicitly, so I'm not sure if
this is the intended behavior or not. What I would expect is that you could
set the backoff to some value, but the raw-position-to-actual-posiiton
correlation shouldn't change. Others that are helping me have came to the
same assumption, correct or not.

Are my assumptions correct or incorrect? What is the intended behavior?
And can the documentation be expanded to better explain what it does? I
don't mind making the change but need to get clarification here before I
get the scalpel out.

—
Reply to this email directly or view it on GitHub
#3.

Karl Lew
FIREPICK SERVICES LLC
karl@firepick.org
www.firepick.org

[FlyingLotus1983]

Thanks, Karl. I'm going to sleep on this, and we will gather some more data in the morning. It appears that my assumption was wrong and therefore we're going to have to go back and capture more data before we can get back to you on this.

Your points are re-assuring as that functionality is the same thing that Marlin and other firmwares do. I think the first thing we'll try is to run with zero backoff with a ridiculously low homing speed.. If we get the same rotational position after doing that, then I would agree that your software is working as intended, and it was only a communication problem in the documentation.

Will be in touch... thanks.

[firepick1]

Ah. I just remembered something else.

Since reading limit switches takes time, FireStep reduces the number of reads on high speed operations such as {"mov"}. The latch backoff is therefore also a safety zone for those non-reads so that it doesn't go too deep into the limit switch.