Axis::Home() Too Fast: RSI_AXIS_HOME_UNEXPECTED_STATE

[todd_mm]

[RMP 8.3.1]

Homing Method: ImprovedPOSITIVE_HOME_NEGATIVE_MOMENTUM

I’m testing various homing scenarios, and I’ve found that if I home “too fast” (a thoroughly subjective quantity), Axis::Home(...) throws an execption.

I’m homing to a custom config (an I/O on another network node). When the exception is thrown, I quickly get the state and actions and put them in the alarm (shown).

Curiously, the decel at the end of seeking-home looks extremely sharp. (Compare it to the nice-looking accel). Is the Axis::HomeDecelerationGet() used here? I guess not?

Can you tell me what’s happening here? I can’t tell that I’ve misconfigured something, and when I slow the home down, it doesn’t complain like this.

If I zoom in to where the home input goes high, it looks like this:

The (position) range when the input (labelled Motor3.PositionSoftInput, brownish color) is high is small (at this velocity). Would this cause a problem? I don’t know how to interpret the error message in the exception.

[todd_mm]

Out of curiosity, when would homing decel be used?

[nikolas]

The exception from your screenshot will happen if you are traveling in the negative direction and the positive switch triggers or vise versa. This could potentially arise from the noisy input previously discussed.

If you are using a longer trigger duration for the switch and a slower homing speed would be recommended to accommodate for the slower switch reaction time.

After a bit of investigation, I’ve come to the same conclusion as you. Homing deceleration is effectively not used the way our master based homing is currently implemented. I will update the documentation accordingly. The only situation it would be used is if the maximum homing travel is exceeded and a switch is never hit.

If you want to change the deceleration of a master based homing method you can use StopTimeSet()

If our master based homing methods are not working for you I’d recommend creating your own homing routine. They are fairly simple to implement. And being able to debug the code directly could save you a lot of time.

[todd_mm]

In the example I’ve described here, the input is going low before the decel from home-seek has completed. I understand that it would be difficult for RMP to know the difference between a jumpy input and a solid one, but it seems like at this stage, there’s no reason why it should pay particular attention to the input (particularly, the falling edge).
Would it be reasonable for RMP to conclude that if the input goes low before it’s finished decelerating from home-seek, that the backoff move should start and expect the input to go high, then go low, at which point the backoff move should decelerate?

I suppose it’s permissible for RMP to throw an exception saying, “This is a totally unsupported situation!” but it seems like there will be some real world situations where the home input has a somewhat narrow band when it’s on and a home operation (for speed/throughput/time savings) would leave that range on the move for phase one. In this scenario, it seems to me that it would be very reasonable (and robust) to pay attention to the rising edge of the home input and decel. Then, start moving in the other direction, looking for the falling edge of the home input (possibly ignoring any rising edge—I don’t know if it would make a difference).

[todd_mm]

…and it also seems reasonable (to me) to think that RMP could behave deterministically here by only paying attention to particular edges of the input signal.

[nikolas]

If you want a master based homing method that pays attention to the rising and falling edges of a switch I’d recommend you look at using Methods 123-130. For those you would need to use the Home input and not a positive or negative limit. It seems like this would capture the behavior you desire though.

As per the diagrams on our website, we expect a positive/negative limit switch to remain high till the physical end of travel. It is very important that we maintain consistent behavior for our other existing customers. This is why we have both the “legacy” and “improved” homing methods. The change you are requesting would be pretty extensive to the back end of our homing methods and require a third set of duplicate behaviors that differ significantly from the DS402 standard methods.

[todd_mm]

We want/need to be able to home using an arbitrary input as the home condition. Using the other methods is not a good option for us.

Regarding the existing behavior and the effects of changing it and the fallout for other customers, which customers would be affected? I’m not asking for names, I’m asking if there are actually any customers who want (or even who might be relying on) the current behavior? If the input stays on the whole time, then any alteration of implemented behavior would not affect them. Do you have customers that would want the home operation to essentially end immediately (or error out) if the input goes low on a stage 1 decel?

You’re right that the (very helpful) diagrams for 119-122 indicate that the input stays high, though I didn’t read that as a requirement for behavior.
Can you explain why this requirement is different for 119-122 than for 123-130?

[nikolas]

The back end behavior of our homing methods are based on a very literal interpretation of our diagrams. The diagrams are based on a fairly strict reading of the DS402 standard.

These are meant to be simple canned methods that work for most situations. If your situation is unique enough you can not achieve desired behavior with our methods as they exist the recommendation would be to write your own homing method.

[todd_mm]

(Homing methods 17-30; DS40211a.DOC, Author:CIA, Subject:dsp, modified 1999)

So, I don’t have an official (or recent) copy of the standard, but one way to interpret this drawing is that if the homing operation starts when the input is high, then the stage one move would be skipped, and the stage 2 move would be the only one that happens. I don’t see anything in this that states or requires that the input must be high the entire length of travel past the home condition. It could be read to say that wherever past the home condition homing starts, the input must be high.

I can appreciate that you’re spending your time chatting with me about this. Thanks for that. I know it’s not cost-free for you to do so.
I’m having a hard time accepting that this is rigidly orthodox behavior for homing. Can you offer some reasoning behind the different between this and the edge-triggered homing methods WRT when the home condition is active? The only meaningful difference that I can tell between 119 and 123 is the presence of the limit input, but only one scenario for that method ever interacts with the limit. Does using 123 require having a hard limit in place?

[todd_mm]

I don’t want to seem rude about this. In the end, your product is your product. I would like you to consider whether the current implementation is the best and most robust, but if there’s no motivation for you to change, that’s entirely within your purview to decide.

[todd_mm]

Referring to the improved homing methods, what’s the difference between 19 and 119 (except that the latter is literally 6 times greater)?

I don’t see diagrammed behaviors for the “standard” methods. What I have in my crusty doc shows 19 looking a lot like 119 except for what happens when you start homing with the input high.

[nikolas]

There is no requirement that there be a hard limit for method 123. The only real requirement as a result of our current implementation is that it doesn’t go low again after it goes high until after the axis reverses. You might be able to use our method if you use a slower velocity and shorter stop time.
An important difference between 119 and 123 is the requirement of a positive limit switch vs only a home switch. This is because without the home limit being active to the end of travel it becomes ambiguous if we are to the left or right of the home limit at start.

We consider the current implementation fairly robust as we can error check against unexpected states. Most use cases can be covered by the current implementation. Other cases not covered by our methods can be implemented fairly quickly with custom code by our end users. Another overhaul of our master based homing methods would take significant software development resources and is not someting I see happening in the near future without some sort of NRE payment.

As per the diagrams, the difference between 19 and 119 is that 119 will reverse back on and off of the switch a second time. This is extra behavior outside of a literal interpretation of the DS402 standard. (We are literal to our diagrams, not the DS402). The reasoning behind this behavior is that it would reduce the effects of any momentum the machine has built up in its first move and ensure that the speed used to get off the switch is the stage 2 speed and not the stage 1 speed (in the back end 119 and 120 are the same and differ only in the argument they take for starting direction).

[todd_mm]

Thanks for the info. I’ll stop pestering you about this.
I’ll even give you the last word…