Home Behavior for Flickering Input (Method 119)

[RMP 8.3.1]

Suppose I’m using one of the methods “like” RSIHomeMethodImprovedPOSITIVE_HOME_NEGATIVE_MOMENTUM.

  • I have it tied to an input on the network (e.g. Axis::HomeLimitCustomConfigSet(...))
  • I have a home offset (applied via Axis::HomeOffsetSet(...))
  • The input flickers (somewhat, “slowly”)

What should I expect RMP to do when I Axis::Home(...)?

  1. Is the flickering state of the home input likely to cause problems when RMP is doing the momentum portion of the move?
  2. Do I need to guarantee any sort of “steadiness” WRT the input signal?

I’m seeing some very queer behavior that only happens under certain conditions when the input changes state, but I want to have informed expectations first.

You could try HomeDurationSet()
Though I would highly recommend using a more reliable input if the flicker duration or frequency is high.

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. Before we start the next move we will also check to see that we are in an expected state and throw an error if not (if the switch goes low/high we decelerate to a stop, check it is still low/high, and only then reverse off of it).

What is causing your input to be nonreliable? Could you use a different more reliable IO module? Or add hardware debouncing circuitry?

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?

Please see the documentation for HomeDurationSet() “HomeDurationSet sets the duration required before the Home event triggers.”

It essentially behaves like a software debounce. Once the state of the switch changes a countdown of your home duration begins. If the signal remains constant for that entire duration then and only then will the state change register and trigger actions in our homing routine.

Some of our “Improved” (100 range enums) homing methods do have some additional behavior in addition to basic implementations of the DS402 standard. That could be a potential source of the extra move. This is done to ensure that all transitions across the switch happen at the second lower homing speed and in a consistent direction. Though this behavior would happen before the offset is applied.

Are you homing with the move to zero argument set?

See 119 diagram on this page: DS402 Master Based Homing - Docs

We are using 119/121.

Setting the duration may be useful for handling noise in the input. The docs are vague on how it behaves, though. How frequently is it sampling the input? Every time slice? More frequently?

I didn’t think about the move-to-zero argument. We’re using the defaults, which I suppose means that we are specifying move-to-zero.
I don’t know why this would produce the behavior I’m seeing, though. The move to zero doesn’t care about the state of the input, does it? And in my example, the “extra” move is in the same direction as the back off move. I suppose that could be because a home offset was specified, but if that’s the case, why isn’t it getting to zero?

It will check every sample in the firmware. So with a duration of 1 second for example a change in the switch state will not be registered until 1 second after it first changes rounding to the nearest sample. A flickering input would reset this timer.

If your homing switch is flickering while you move to origin it could trigger a stop action. Or whatever action you have your home limit set to. Your drive may also have a stopping behavior that triggers when the home swich flickers. It could be that the flickering is inturupting the return to zero move.

I would recommend trying to home via rapid setup with some reasonable positive time value for your duration and see if the behavior persists.

p.s. Out of curiosity, what utility are you using to generate those graphs?

We’re homing to inputs that are not native to the drive. It’s just an I/O on the network (so we’re not using the actual home input, we’re using the custom config for homing).

The home action is set to stop during this phase of the operation. The funny thing is that it was already stopped when the input went high again. The motor started moving afterward, when the origin was changed. I don’t know what it’s trying to do. I could believe move to zero, but I don’t know why the input would make any difference at that point. It’s an arbitrary/general I/O, not any sort of dedicated input.

Here’s a close-up of the second (unexpected) move.

(And I’m using matplotlib/pandas/python for the vizualization.)

When you use HomeLimitCustomConfigSet that custom input will adopt all the behaviors of the dedicated inputs including limit actions. You can change the action with HomeActionSet()

Another way you could debug for this would be calling Home(false) and see if the behavior persists.

Nice, the graphs look great!