Questions about limit switch config options.

[Wibis428]

What is the best practice for configuring a TalonSRX to be used without a limit switch? It seems to me that there are a few different options, and I'd like to know if there are actually any differences between any of these.

I'd like to start with this excerpt from the software reference PDF:

This seems to indicate that one way to config your talon if you don't plan on using limit switches is this:

talon.configForwardLimitSwitchSource(LimitSwitchSource.FeedbackConnector, LimitSwitchNormal.NormallyOpen, 0); talon.configReverseLimitSwitchSource(LimitSwitchSource.FeedbackConnector, LimitSwitchNormal.NormallyOpen, 0);

However, the API also provides the following option:

talon.configForwardLimitSwitchSource(LimitSwitchSource.Deactivated, LimitSwitchNormal.Disabled, 0); talon.configReverseLimitSwitchSource(LimitSwitchSource.Deactivated, LimitSwitchNormal.Disabled, 0);

Does this configuration give any different result than the first if I don't plan on using a limit switch? Is one method preferred over the other?

Additionally, is there a difference between having a a limit switch source be "deactivated" and a limit switch having a normal state of "disabled"? In other words, is there any difference between these two config options?

talon.configForwardLimitSwitchSource(LimitSwitchSource.Deactivated, LimitSwitchNormal.NormallyOpen, 0); talon.configForwardLimitSwitchSource(LimitSwitchSource.FeedbackConnector, LimitSwitchNormal.Disabled, 0);

Finally, how does the limit switch override enable fit into all of this? It seems to me that talon.overrideLimitSwitchesEnable(false); makes it so that the talon completely disregards limit switches, no matter the physical state of the switches or how they were configured initially. If that's the case, isn't that just equivalent to the second set of config options I listed (the ones with source = deactivated and normal = disabled)?

What about talon.overrideLimitSwitchesEnable(true);? Does this simply turn on the limit switch functionality so that the limit switch works according to how it was initially configured? Or does this force the limit switch to be interpreted as activated, regardless of its actual physical state?

Thanks in advance!

[ozrien]

Normally Open If there is nothing connected to the feedback connector, leaving the setting as Normally Open is harmless. This is the ideal default, if you want to use limit switches, wire them up. If not, don't wire them and everything works as expected.

Explicitly turning off the feature But if you want to ensure there is no chance of limiting motor output, you can use the "deactivated" source or "disabled" normal selection. This could be an improvement if, for example, you are concerned a student erroneously plugs in a sensor from another Talon, and therefore loses drive-train control because the arm sensor was miswired?

LimitSwitchNormal.Disable Using LimitSwitchNormal.Disable is convenient because LimitSwitchNormal is identically the same setting as the web-based config. So you can tweak it via web-based config. .
Notice the web-based config also uses the matching term "disable", this is deliberate and consistent.

LimitSwitchSource.Deactivated Using LimitSwitchSource.Deactivated will turn-off the feature in a way where the web-config cannot circumvent it. perhaps this is better depending on circumstances. LimitSwitchSource chooses between using the local limit switch input, or a remote one (another Talon or CANifier), or just plain deactivated.

Overides overrideLimitSwitchEnable (and overrideSoftLimitEnable) are convenient ways to force off the feature without calling a config*.

Config params are persistent and have timeoutMs for optional blocking.... Because they are persistent, this ensures a power cycled Talon still is setup correctly. But there is wear-leveling so if you are changing persistent params all the time, there is delay between the last change and when it gets saved. However if you are changing a config periodically, then it doesn't matter since you are updating the setting live. BUT it is an extra frame on the CAN bus that could be optimized.

So if you want to change it in the loop, using the override functions is better because.... -override functions have no timeoutMs. They are periodically sent, so if the motor controller gets power cycled during a match, the override still takes effect. -override functions have an optimization where if you call it periodically but the value has not changed, then there is no call to the roboRIO backend, (because its periodic and cached) so there is virtually no delay. Most set* function works this way.