This bug has been observed on UR10e and it exists at least in the newest Polyscope 5.11.10:
- Use an external device (motor, etc.) that has a 2-channel hall-encoder output (quadrature encoder)
- Setup the quadrature encoder pulse decoder with the following URScript command:
encoder_enable_pulse_decode(0, 1, 8, 9)
- Run a program that prints out the encoder ticks while the motor is running and the encoder provides valid pulses:
encoder_get_tick_count(0) - will return the encoder position continuously
- Press the robot Emergency stop while the encoder is providing the pulses
- While in Emergency stop state, stop the motor that is equipped with the encoder
- The encoder is no longer providing valid pulses
- Release Emergency stop, press Play to continue the program
- The program proceeds with printing out continuously changing ticks although the external motor and the encoder is steady
- encoder_get_tick_count(0) is drifting away forever, apparently a connection to the pulse decoder is lost and the function keeps updating itself from the last valid read data
- Start the motor again to get encoder pulses
- encoder_get_tick_count(0) seems to return valid data again
We suspect that the function encoder_get_tick_count(0) does not directly read the pulse decoder from the Controller, but extrapolates its return value based on cached ‘last known position and speed’ or something like that. After releasing the emergency stop, this ‘cached data’ is not initialized again, making encoder_get_tick_count(0) return an invalid and drifting value.
Is this a known bug, and are there any workarounds possible? For example, could we somehow access the physical (raw) value of the pulse decoder, for example, in a (probably hidden) MODBUS register, so we can skip using encoder_get_tick_count?