LabVIEW
reading issues with incremental encoder
I am using the RLS RM08 encoder to measure the position of my motor. It's an incremental encoder.
However, I am encountering two issues with my measurements that I haven't been able to resolve.
For all the tests I've conducted, my motor runs at a constant RPM, and I have isolated the encoder reading from the rest of my main VI (I attached the isolated VI).
- The first issue occurs at the start of the acquisition. I begin collecting data from the moment the encoder VI is launched (with the motor already running), and I’ve noticed that, systematically, the first revolution is incomplete, the encoder ticks do not reach 4096. However, all subsequent revolutions correctly range from 0 to 4096. You can see this problem for three different RPMs in the following figure. This is a significant issue for me because it prevents me from maintaining an accurate starting position.
- The second issue is more prominent at higher speeds. Occasionally, the encoder skips data, as shown in the following images, where jumps appear in the values read from the encoder.
I had two hypotheses for this : vibrations causing misread values, although that would likely cause horizontal shifts rather than vertical jumps, or inconsistencies in acquisition timing, however, I checked the delta t, and it appears consistent.
A colleague suggested that it could be related to the DAQ I’m using, specifically the FIFO value of my counter, but he couldn’t provide further assistance.
I am using the PCIe-6363.
@PaskalM wrote:
I am using the RLS RM08 encoder to measure the position of my motor. It's an incremental encoder.
However, I am encountering two issues with my measurements that I haven't been able to resolve.
For all the tests I've conducted, my motor runs at a constant RPM, and I have isolated the encoder reading from the rest of my main VI (I attached the isolated VI).
- The first issue occurs at the start of the acquisition. I begin collecting data from the moment the encoder VI is launched (with the motor already running), and I’ve noticed that, systematically, the first revolution is incomplete, the encoder ticks do not reach 4096. However, all subsequent revolutions correctly range from 0 to 4096. You can see this problem for three different RPMs in the following figure. This is a significant issue for me because it prevents me from maintaining an accurate starting position.
- The second issue is more prominent at higher speeds. Occasionally, the encoder skips data, as shown in the following images, where jumps appear in the values read from the encoder.
I had two hypotheses for this : vibrations causing misread values, although that would likely cause horizontal shifts rather than vertical jumps, or inconsistencies in acquisition timing, however, I checked the delta t, and it appears consistent.
A colleague suggested that it could be related to the DAQ I’m using, specifically the FIFO value of my counter, but he couldn’t provide further assistance.
I am using the PCIe-6363.
Looking at the graph we see that the discontinuities seem to jump backwards over X .
You should be able to change the plot properties to get a clearer picture!
This makes ME think that a buffer is being overwritten. You should investigate that the Reads are happening fast enough. A 127byte FIFO buffer will need to read frequently.
Sorry for the confusion, but no, it is not jumping backwards along the X-axis. The X-axis simply represents the iteration number. I added markers to help visualize the discontinuities. Here's a zoomed-in view of one discontinuity.
The results I’m presenting were obtained in a while loop with a timer set to 0 ms (which I assume is the same as having no timer at all), so this is at the highest frequency I can have.
