Improved Homing Methods for 10.3.2

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

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

I guess the ā€œHome Limitā€ bit isnā€™t a dedicated input.
Where would I find this bit?

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.

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.

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.

1 Like

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

1 Like

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.

1 Like