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”)?