Anyone know the maximum possible value of encoder_get_tick_count(index)?
I’m using a quadrature incremental encoder.
It depends on the range_id set in the encoder_enable_set_tick_count(encoder_index, range_id)
As far as I can understand from my testing trying and erring that is only for use with absolute encoders and it does not work with an incremental encoder decoder setup.
I tried the command you mention but after setting that the tick value stuck at 0 because it expected the ticks to be set via the separate command for this.
Have I misunderstood?
mvh Harald Ellingsen
I see. I am not aware of that. I did a small test with the unwind function. If that is the reference, there seems to be no wrap around…
Yes seems to be no wrap around. I stuck my encoder in the drill to try to run to max value but ran out of battery before max. Reaching 25851752 ticks. Indicating more than 16bit value…
Would be nice to know the actual maximum capacity and also how to zero the encoder tick value?
now at 1 148 769 664. may be a 32 bit value. I observed that the decoder was running even when the program was in paused and stopped state. I wonder how this value is stored.
Currently using an e-series ur10.
I tried using encoder_enable_pulse_decode() to disable encoding and enable it again, but it still did not reset the tick count…
I read in the manual that the unwind function was to be used in cases where the bit size of the encode was known – in my case it’s an incremental encoder hence that does not apply like when you have an absolute encoder.
I can see the it restarts with a power cycle. So it must be stored in the firmware on the SCB. If it is a big deal for you a possible workaround could be to swap A and B signal while you are using the inverse feature for the tracking. In that way you will get same robot behavior, but it will start counting in the other direction. You might be exposed to loose the ticks that are happening within the time of one sync().