Improved Homing Methods for 10.3.2

[todd_mm]

In fact, while my app is running and not doing anything homing-related, the Home Limit is active.

[todd_mm]

Curiously, my app’s input that corresponds to RSIMotorDedicatedInHOME is low. Its value is the result of DedicatedInGet(...)

[todd_mm]

I guess the “Home Limit” bit isn’t a dedicated input.
Where would I find this bit?

[nikolas]

@todd_mm

What about 10.3.1 → 10.3.3 would change the interpretation of the home limit? I’m not “using” a home limit for this drive, though RMP is surely defining one somewhere. I’m not deliberately using this in any way (that I know of).

10.3.1:
The home method would consider the home limit active if:
The dedicated IO ==HIGH
OR if HomeLimitCustomConfigSet() has been called
The custom config address value == HIGH

10.3.2:
The home method will consider the home limit active it the
Dedicated IO == HomeTriggerStateGet()
OR if HomeLimitCustomConfigSet() has been called
The custom config address value == HomeTriggerStateGet()

Assuming the correct state for HomeTriggerStateSet this shouldn’t have changed your behavior.

@todd_mm

1. Does the Home Limit represent only the dedicated home input on the drive?

No, it should reflect the custom home state if you have one (or its opposite depending on trigger state).

I am working to reproduce your custom config here and see if I can repeat the erroneous behavior. I’ll let you know what I discover.

@todd_mm

Where would I find this bit?

It should be whatever bit you used for your call to customConfigSet. That and the HomeTriggerState should be the only two things that can change what HomeLimitGet() returns.

[nikolas]

Was able to reproduce the issue.
Haven’t fully nailed it down yet but I’ve got a good hunch.
There should be a fix for this bug in 10.3.4

[nikolas]

The fix for this has been merged in and will be in the next release.
Here is one of the graphs we generated as part of our new automated homing tests.