I’ve sent this exact email to the CTRE folk, but they likely are swamped with issues at this time. Due to lack of time available to our team before competition we’re trying to seek another thread to get some answers. My apologies if CTRE finds this offensive.
It would greatly simplify our algorithm if we didn’t allow the position to wrap and stay in the 0 - 1023 range. However, nothing we’ve tried seems to disable the wrapping.
We’ve tried the following:
1.) Using Phoenix Tuner under Config we applied the setting for FeedbackNotContinuous and saved it. We rebooted the RoboRio and pushed code and found it was still wrapping.
2.) We went into the config for the spin motor controller settings and toggled this setting.
And saved it
then pushed the code and found it was still wrapping.
3.) We even tried the granular approach, but documentation on this particular one is fairly non-existent so not sure if we used it correctly.
This also didn’t stop the wrapping behavior.
Did we stumble on a bug or are we doing this wrong?
Just to be clear, setting FeedbackNotContinuous to true should keep the range inside [0, 1023].
How are you reading the sensor data? I believe this value only affects the analog input when using getSensor with analog as the selected sensor, and has no affect on getAnalog. However, getAnalog provides both values, so you can use that if you need to (note, however, that by default the analog sensor status frame updates at a fairly slow rate).
If you provide more information on what you’re trying to accomplish, I can point you towards a more specific solution.
I’ll be gathering data shortly to provide a clarified reply to @thatnameistaken. The machine I’m on and the test hardware are behind on version updates so getting that done quick as I can.
@hamac2003 we did use the Modulus block and treated the resulted calculation as an offset to be added into the OV value as the new GoToPosition, but had a washing machine effect as a result. We discovered a bug that we can’t recreate in test code where the Modulus block remainder outputs > 1023 when it should not be possible. We plan to submit this to NI as a bug, but having difficulty recreating without including a whole FRC project.
