Our master-based homing will advance to the next phase of the homing routine each time the state changes and remains changed for the duration.
So, this is reasonable, depending on how we define the terms.
What do you mean by “remains changed for the duration” ?
For the duration of that operation? What if it changes (again) before the operation is complete? (That doesn’t make sense to me, but I don’t understand what you’re trying to describe.)
Anyway, regarding the input, there’s a certain amount of flicker that possible when you just start to cross the boundary of the input condition, depending on speeds and the precision of the hardware. I don’t expect to see constant flickering, but if you’re on the very boundary, it’s conceivable that you might see the input change once or twice. (This is not a practical observation, but rather a theoretical expectation of mine.) I do know that debouncing only really slows the rate of flicker, and does not remove it entirely for these “edge” cases where the motor position oscillates very slightly at the edge of where the input hardware will detect its presence.
The details here are not entirely important, except to suggest that some flickering is a real possibility, though probably infrequently.
The troubling thing that I’ve observed is that the RMP homing behavior does some unexpected things, rather than just end the homing routine.
“Consider this scenario…”
I’m homing a motor in the positive direction (negative momentum). The home position (where the switch is) is located at zero. A motor home offset is specified (0.5 units; 1 unit = 1 motor rev in this case).
(The plot is an illustration of data captured from the firmware.)
This is an illustration of a homing routine. The “Positions” plot shows the motor moving to the “home position” (illustrated with a .- dashed line). It gets there and then backs off. The “RawPosition” plot shows the raw encoder position (ignoring the origin position).
The “Status” plot shows various inputs, of importance is the brownish one (labelled “Motor0.PositionSoftInput” in the legend). This is the home switch.
The “Vel/Accel” plot shows velocity (dk red) during the process: max (homing) vel when seeking (stage 1), decel, then reverse vel backing off the switch.
The jump in actual/command position (top plot) represents (I believe) when RMP changes the origin position of the axis to honor the home offset (0.5 units).
You can see how homing behavior looks when the input first goes high, then the input turns off when RMP backs off the switch. After the backoff move decls, then input goes high again (due to “flicker”) and then the weird thing happens: it moves again after applying the home offset, but that isn’t a part of the homing routine I chose.
Why would it do that?