I am currently trying to read the value of the absolute encoder in the through bore encoder via the spark max client but I am not able to read anything. The encoder is wired through a REV alternate encoder adapter. I am on spark max firmware 1.5.2 and spark max client 2.1.1. The spark max is configured with kDataPortConfig set to Alternate Encoder and I have tried both brushless and brushed operation. The only reading I could get from the encoder is when it is directly connected into the JST encoder port on the spark max, and set to brushed and sensor mode “encoder”, but reading the Position value on the Run tab only reads relative values. When set to the alternate mode, Alt Encoder Position only ever reads 0.0000 RPM. Is there something I am doing wrong?
The SPARK MAX in alternate mode does not actually use the index/absolute pin. (See note a here) I’m not sure why it won’t give you a speed.
Has anyone been able to successfully read anything from an alternate encoder using the Spark Max windows/usb client? I have tried setting kDataPortConfig to Alternate Encoder in the client and reading the Alternate Encoder position and velocity, but without any success.
I am using the Rev Through-bore encoder plugged into the Spark Max data port using the alternate encoder breakout.
I am able to read values In my code (which is essentially one of the Rev examples) but I am reading 2x the “position” I think I should be reading (two for every revolution). I want to see what the Windows/usb client reports, but am unable to figure out how to get it to work.
TBH, we ordered 4x of the through bore encoders back in January and were unable to get any of them to output ANY data regardless of how they were hooked up (not even reading directly via the Spark MAX USB interface with no motor connected). Ultimately we gave up and used different encoders (or the hall-effect sensors on the motors).
By far the most needlessly complex encoder I’ve ever tried to use, why these aren’t just plug-and-play on a SparkMax is beyond me; no other encoder I’ve used (including ones connected to the SparkMax via the 10-pin port on top) have ever had any issues.
They work fine when connected directly to a roboRIO DIO pin and accessed via the DutyCycleEncoder class. We use one on our turret. That narrows down the issue to the Spark Max or how the encoder interfaces to the Spark Max, I guess.
Did you email REV about this?
I think at one point our programmers were in touch with them trying to figure it out, but I don’t know the details. My job was just to make sure it was wired correctly.
And to be clear, our programmers are very familiar with using other encoders both connected via the SparkMax and otherwise, so it’s not a lack of experience, it seems to be an issue isolated to these specific encoders.
By the end of the build season most of the motors on our robot were Falcon500s, so it became a moot point.
To connect a Lamprey encoder with a SparkMax, you can only use the the analog output on the encoder and the analog input on the SparkMax’s alternate encoder input. You should then be able to read this data from the roboRio. I’m not sure about reading it via USB. I have found that the USB connectivity is not particularly reliable, and I seem to recall the REV folks agreeing to this point recently and suggesting that a future update will improve that.
You should also read this thread about the encoder, and in particular, my comments around March 11 which describe some of the other nuances with pairing a SparkMax with a Lamprey.
As for why they are not more plug and play with the SparkMax, if I remember correctly, (And take this with a grain of salt, because it was a while ago) the encoder was released before the SparkMax announced their alternate encoder functionality. And the SparkMax’s input for alternate encoders doesn’t match the “standard” set by the CTRE products.
Spent some more time this morning trying unsuccessfully to get non-zero values of Alt Encoder Position and Alt Encoder Velocity to display on the SPARK MAX [usb/windows] Client. If it is possible, I cannot figure out how to do it.
I have submitted an inquiry to [email protected] asking if this should be possible.
I would expect it should be possible to get data based on the quadrature alternate encoder inputs on the data port, but unfortunately not based on the absolute pwm input at this point.
Follow up: The inability to read Alt Encoder Position and Alt Encoder Velocity using the Windows/USB client (v2.1.1) has now been acknowledged as a bug.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.