[RSI 8.3.1]
I see a commented-out CPP macro in rsi.h: RSIHomeMethodPOSITIVE_HOME_1
Is this homing method implemented?
I’m implementing a form of homing for slaved motors, and I need the slaves to behave differently (but similarly) to the master. In particular, I don’t want a back-off-the-switch move (because the home condition is based on the input for the master motor, NOT the slave motor(s).
It seems like method #20 is what I would want.
There is no implementation for method 20.
If you invert the polarity of your switch 19 would effectively do the same thing.
Could you elaborate more on how you want the master and slave axes to behave differently? As our homing methods are blocking, customers who have an electronically geared follower axis typically write their own homing method instead of using our canned methods so that they can fix any skew in the machine.
Homing two or more motors (that are mechanically geared/linked) simultaneously really need to have a common reference for what-is-the-home-condition. In other words, the home input for the master motor is that common definition of where-is-home.
Because we have been trying to use RMP’s homing methods, I cannot do anything between the various home movement stages (like sync motor positions, etc.).
The “standard” (and sensible) back-off-the-input move that RMP implements for most of its methods is kind of nonsense for the slave to do, because I can’t guarantee that the slave will be performing those moves at the same time as the master, and thus, waiting on the input is at best not very meaningful, and at worst, perilous to the homing sequence (RMP will complain if the input goes low at the wrong time).
Using one of the other homing methods and “simulating” being on the other side of the home switch is an intriguing idea that I didn’t think of. How can I invert the polarity of an existing, immutable RMP input (specified in HomeLimitCustomConfigSet()? I don’t see a place for “value” or inversion in the parameters. Would I have to create a separate user limit that sets a bit (in a user buffer or some other firmware location that I control) when the corresponding input goes high? Is there an alternative to this (not including “do homing yourself, silly”)?
Let’s say I wanted (which I don’t) to implement my own “homing” routine. If I’m commanding all the motion, etc. Is there a good reason to actually put the drives into homing (operation) mode? Does this buy me anything?
Do you have a limit switch at the other end of travel or is your home switch the only one?
HomeTriggerStateSet() Is the method to invert the logic polarity for that input. On second though though you’d also need to invert the starting direction which we don’t support.
No, homing operation mode is just for drive based homing.