I am trying to use the Rev Through Bore Encoder in Absolute Mode for seeding a position and then use it in Incremental mode as the the feedback device for the SparkPIDController. This is what I have below. Is this even possible using the REVLib API and if so am I doing it correctly?
But the encoder itself has a switch on it, and it needs to be physically switched to be in either absolute or relative mode. I don’t think that changes even if you use the data breakout board.
Also, does your mechanism rotate more than one full rotation? If not, you can simply keep the encoder in absolute mode, and use that for feedback. And you can use the REV software (the hardware client) to zero the absolute encoder in whatever position you wish.
The switch isn’t for in-field use, it is setup for SSI/SPI when you put it in the ‘S’ mode. the ‘A’ mode will output both the A, B and ABS on the cable bundles, you just need to use the appropriate PIN/adaptor board depending on if you are using the RIO direct or via the SparkMax (and in theory other motor controller as well).
You can also increase the frequency of the appropriate CAN status message to get the updated position of the encoder more often. But since the Spark is directly connected to the encoder it can read the sensor on its own plenty fast, it just reports on the CAN bus at a slower rate.
I’ve never actually looked at all the output pins on the encoder but if they are just passing the same signal straight out from the chip (after buffering), you should absolutely be able to use the Index and the A/B at the same time. Will have to do some programming to use the Index as a reference point and then the A/B on top.
Can grab the application note off their website and look at the signal outputs -
I should just be able to use these two connection modes to use both encoder readings at the same time. The A B goes to the controller and ABS to the RIO. In REVs explanation video they described that teams could plug in all 4 cables depending on their use case.
You should but be careful your use-case and the differences in timing. i.e. things coming over the CAN bus will have to be part of the CAN refresh or if you are using it as any sort of PID on the SparkMax, then that sampling will also be a lot faster. {unfortunately we never done any sort of split use like this, there’s certainly a lot of information to be learned here}.