User Limit as a Timer: Example?

I couldn’t find any example code (or documentation) regarding using a user limit as a timer. One of the trigger types suggests that this is possible: RSIUserLimitTriggerTypeTIMER.

Can you tell me how I could use this?

  • Will UserLimitConfigSet(…) interpret the duration parameter as the period (in ms) of the timer?
  • Is anything about ConditionSet(...) applicable for this trigger type? There’s not really any other condition than the timer duration, right?

I will investigate. What do you need the application to do with this user limit timer?

Well, I want to “invert” an input, but there’s not a built-in thingy for that, so I think I have to respond to the interrupt, get the value of the input, invert it, and set a user buffer bit.

Essentially, I want to respond to the interrupt every time it comes in. There’s no other condition. I want to get hit every time slice.

You can’t really respond to every 1ms interrupt in Windows.

If you’re trying to invert an input, how about configure the UserLimit to monitor the input, then use its status bit (MotionController.AddressGet(RSIControllerAddressTypeUSERLIMIT_STATUS , userLimitNumber)) as the “inverted” bit?

If this is related to homing, I think your needs have exceeded the standard RSI master-based homing methods and you really should write your own. Think of the possibilities!

Yeah! The possibilities! Think of how many wheels I could reinvent! (-8
What I want is “mostly” standard, just mildly tweaked.

When you say “monitor an input,” is there a way to monitor whether a bit/word in memory changes (without reconfiguring the user limit every time it changes—BTW constant/frequent reconfiguration has caused me all kinds of grief with RMP, issues that have not yet been resolved)?

Can you describe how I would monitor the input with a user limit? Perhaps I misunderstand what you’re telling me.

You can’t really respond to every 1ms interrupt in Windows.

Can you help me understand this (practical/actual ??) limitation?

I meant configuring a UserLimit so its status is TRUE when the bit is OFF (and vice versa) using the mask and value in one condition. You would wouldn’t need to change the configuration or get interrupts. Then use the value of the UserLimit status (it is 0 or 1 for false and true) as the inverted input.

Since the UserLimit runs every cycle, your inverted value will always be updated.

Well you could theoretically respond to every 1ms interrupt in Windows, but your won’t actually get them precisely every millisecond. I’d guess if you ran for 24 hours, you might see some arrive 10 or 25 or 50 milliseconds late? In those cases you’d be writing things to the UserBuffer much later than they actually happened.

1 Like

I don’t think a UserLimit will work for monitoring changes in an entire word. Of course you could configure two UserLimits for each bit (one for ON, one for OFF).

For monitoring an entire word you could use the Recorder to record the words and detect changes in the word as records are available.

Our homing methods were not designed for more than one axis (electronic gearing or MultiAxis).

Could you possibly do multi-stage homing by using multiple calls to Home() using some of the simpler RSIHomeMethods?

1 Like

Well, 20/22 (monodirectional, stop on input) isn’t implemented.

The conclusion is probably that I’ll just have to home all on my own.

Back to my original question: how could I (were I so reckless) configure a user limit to operate as a timer?

In particular, what do I set for the condition parameters?

If I neglect to call UserLimitConditionSet(...), I get this exception:

Parameter invalid :: {userlimit.c, line 2388} : MPIUserLimitCondition: Specified type (0) is not a valid type. (Error 2) (RSI::RapidCode::Impl::MotionController::UserLimitConfigSet) (Object 0) (File …\source\motioncontroller.cpp) (Line 5106) (Version 8.3.1 for 04.04.02.RMP)

I called UserLimitConfigSet(...) with

	triggerType = r::RSIUserLimitTriggerTypeTIMER;
	duration = 1; // every time slice
	action = r::RSIActionNONE;
	actionAxis = -1;
	singleShot = false;

I’m unfamiliar with TriggerTypeTIMER. You might want to try setting a Condition 0 that would always be true?

I’m guessing your unfamiliarity is related to the reason for the documentation’s brevity.


Looking at the guts of it, it seems to be an attempt to setup a SINGLE condition trigger where the condition is always true.

1 Like

Thanks, Scott.

Out of curiosity, would TIMER behave any differently than a SINGLE_CONDITION trigger with all the (other) parameters to condition/config set identically?

Yes, that’s the expectation.