Input Inversion (and Homing)

RapidCode API
,
1

Home to Falling Switch

So, I want the behavior of POSITIVE_HOME_NEGATIVE_MOMENTUM/NEGATIVE_HOME_POSITIVE_MOMENTUM but with an active low input.
Based on the documentation, I might hope that FALLING_HOME_POSITIVE_START_NEGATIVE_MOMENTUM/FALLING_HOME_NEGATIVE_START_POSITIVE_MOMENTUM might do what I want, but they don’t. (At least, not quite—they use the stage 2 velocity for what I would consider to be stage 1 of homing, which can be a really long move.)

So, I’m trying to use the “rising home” methods but invert the active low input.

Is there a recommended way to invert an input?

Up until now, I’ve been using a pair of user limits, one to trigger when the input is 1 and set a separate user buffer to 0, and another to trigger when the input is 0 and sets the user buffer to 1. (FWIW, I don’t like this strategy, but it did, at least, work. This kludge was crafted before the existence of math blocks. I could probably use a single math block to accomplish what I want.)

Errors

Recently, under some conditions, I’ve been getting RMP errors.

Switch state and expected state did not match. This method should only be used for Home Setups which are High to the Negative Limit. (Error 1000000030) (Axis::Home) (Object 0) (File axis.cpp) (Line 4131) (Version 10.6.4.0)

I’ve most often seen this when the home input goes low before the stage 2 move begins. I don’t see any evidence of that particular event happening.

To complicate matters, I’m trying to home the two motors of a gantry simultaneously. Both have separate “home” inputs (not the RMP kind, just an arbitrary EtherCAT I/O that we use for homing). Both are using the same homing method, but are looking at separate user buffers as their custom config input.

What I observe is that after the home input for one of the axes changes state, the other axis will frequently throw an exception from inside Axis::Home(...): RSI_AXIS_LIMIT_UNEXPECTED_STATE

  • I’ve inspected the addresses used for the API calls, and the two axes are not using the same input address.
  • It doesn’t always happen at the same time, but almost always the user limit for one axis triggers near (25-100ms) when the exception happens.

Question #1

What circumstances can cause RMP to throw this exception?

In the past, when I’ve seen this, it happens because the input goes low before RMP starts the stage 2 move (e.g. overshooting the switch).

I can’t prove that the input ever changed around the time that the exception happened.
Monitoring the firmware values for the inputs as well as the user limit statuses (using recorders) doesn’t show any change.

image
image1002×866 37.1 KB

The blue dotted line is when the input changed. The red dot-dash line is when the exception happened.

Question #2

Are there things I can do that would influence this behavior? IDK why both user limits are changing status when they do. I would have expected only one to do something when the input changes. I’m sure this depends on how I’ve configured them, but the description above is accurate.

2

We look forward to hearing any new data, per our phone conversation.

Taking a step back, have you tried or used HomeTriggerStateSet(bool state)? This doesn’t invert the input but it allows you to specify which state is considered active.

3

I haven’t tried this.
Does this work with HomeLimitCustomConfigSet(…)? I thought this was only an option if you were using the home input configuredin NodeInfo.xml?

4

In the homing methods implementation, it uses a combination of HomeSwitchGet()==HomeTriggerStateGet() to determine what it thinks is the active home state. HomeSwitchGet() uses the custom home bit if you’ve specified one.

5

I tried this, and the behavior I observe is that RMP starts homing doing a stage 2 move directed away from the home switch (the opposite of what I want).

6

FWIW, Here are the two user limits for one of the axes.

#20                                         #21                                    
    Trigger Type : 1                            Trigger Type : 1                   
    Duration     : 0.0                          Duration     : 0.0                 
    Single-Shot? : False                        Single-Shot? : False               
    Condition #0                                Condition #0                       
        DataType     : 3                            DataType     : 3               
        Logic        : 0                            Logic        : 0               
        Address      : 0x5e8aed0                    Address      : 0x5e8aed0       
        Mask         : 0x1                          Mask         : 0x1             
        Limit Value  : 1                            Limit Value  : 0               
    Output                                      Output                             
          Enable       : True                         Enable       : True          
          Data Type    : 9                            Data Type    : 9             
          Out Address  : 0x42409f8                    Out Address  : 0x42409f8     
            AND Mask   : 0xfffffffe                     AND Mask   : 0x0           
            OR Mask    : 0x0                            OR Mask    : 0x1           
          Out Value    : 0                            Out Value    : 1             
          In Address   : 0x0                          In Address   : 0x0           
    State     : False                           State     : True                   
    Enabled   : True                            Enabled   : True
7

Hi Todd,

The Exception (RSI_AXIS_LIMIT_UNEXPECTED_STATE) happens when you’ve hit a state that shouldn’t be possible for the home method provided.

image
image1006×734 44.8 KB

The first two homing methods you mention are only valid in a system where it isn’t possible to be in a more positive position than the home switch. The Home stays active all the way through the Positive Limit. Can you confirm that is how the system is setup?

Our Master Homing methods are just RapidCode customized to match the DS402 Homing documentation. There isn’t any firmware magic happening internally. Creating your own custom homing routine might be in the cards.

The exception you are seeing is just our packaged RapidCode Function getting confused as to the state based on it’s expectations.

HomeStagee 2 Velocity should be used as soon as it detects the Home the first time.

Example for RSIHomeMethodRISING_HOME_POSITIVE_START:

if (HomeTriggerStateGet() == HomeSwitchGet()) {
  homeStage = (int)RSIHomeStage::RSIHomeStageSTAGE_TWO;
}

For your UserLimits, it looks like you are writing to the same address and same bit. They are set up such that you expect to see 0 or 1 in the output location correct?

8

The Home stays active all the way through the Positive Limit. Can you confirm that is how the system is setup?

Based (only) on recorder data for the raw home input and the user buffer in which I store the negated value of that input, I cannot prove that either changed during the stage 1 move or its decel.

For your UserLimits, it looks like you are writing to the same address and same bit. They are set up such that you expect to see 0 or 1 in the output location correct?

The pair of user limits are employed to “negate” the active low home input. My intention is that when the input is 1, one user limit fires and writes 0 to the output, and when the input is 0, the other user limit fires and writes a 1 to the (same) output. I expect that neither of them would fire at the same time.

9

Hi @todd_mm,

Based on your chart, the user limits are working as intended. What HomeMethod # are you using?

10

Based on the (configurable) homing direction, we use either

  • RSIHomeMethodImprovedPOSITIVE_HOME_NEGATIVE_MOMENTUM
  • RSIHomeMethodImprovedNEGATIVE_HOME_POSITIVE_MOMENTUM
11

I’m happy enough with the behavior of these two methods, except it seems that I can’t use it with active low inputs.
I did a quick test of calling HomeTriggerStateSet(...) using an active low input, and what I observed is that Axis::Home(...) started with a stage 2 move away from the home switch. (I can’t go back in time and double-check that I did everything correctly, so I’m willing to try it again if you tell me that what I observed is “Inconceivable!”)