I believe that these variables to be extraneous, and the functionality associated with them can be done with the ReadPin.
I think that the issue we had during the last debugging session was caused by the AuxBMS thinking that it's calling isContactorSet with the wrong number of contactors. This behavior is linked to the hasCharge/DischargeBeenSet variables, so I did some digging.
These values are set by the isContactorSet call in normal operation, but when the car is nearing it's charging limits, we manually reset the variables ourselves. My guess is that the logic at:
Isn't firing correctly, causing the numbering mismatch.
Looking at the usages of the variables, I think that instead of using these, I think we can directly read the sense pins to see if we need to call isContactorSet with 2 or 3 contactors set.
I believe that these variables to be extraneous, and the functionality associated with them can be done with the ReadPin.
I think that the issue we had during the last debugging session was caused by the AuxBMS thinking that it's calling
isContactorSet
with the wrong number of contactors. This behavior is linked to the hasCharge/DischargeBeenSet variables, so I did some digging.These values are set by the isContactorSet call in normal operation, but when the car is nearing it's charging limits, we manually reset the variables ourselves. My guess is that the logic at:
Isn't firing correctly, causing the numbering mismatch.
Looking at the usages of the variables, I think that instead of using these, I think we can directly read the sense pins to see if we need to call
isContactorSet
with 2 or 3 contactors set.(hopefully) Fixes SFT-134