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.
You say you have an incremental encoder but seem to treat it as an absolute encoder. Most likely this is done through interpreting a quadrature encoder signal through a counter in your DAQ board together with a Z signal. The Z signal tells the counter to reset to the NULL position.
The problem with that is, when you startup your program the counter starts at 0 but your motor is really at a random position. The counter starts counting, then sees the Z pulse and resets and after this is synchronized to the motor position.
You basically have two options.
- If you need to know the relative position of your motor in relation to the 0 point, you have to live with this imperfection for the first rotation of the motor after starting up your software or change to an absolute encoder ($$$$)
- If the relative position to your motors 0 position is not important, then disable the Z pulse and if you insist on having a counter position that wraps around at 4096, use the Quotient & Remainder function to do that. Otherwise you get a continuously incrementing position, which might be quite useful depending on your application.
As to the missing portions, the counter on the DAQ card obviously seems to count further but your reading software is not fast enough the read the FIFO before it is full and then looses samples. There is really only one possibility to fix that and that is making the part that is reading the FIFO faster. And adding proper error handling to actually notice that there is data missing. Your DAQ Counter Read function for sure returns a warning to that fact. But if your programming is not properly investigating returned error cluster information but instead just blissfully ignores it since it otherwise only messes up your data acquisition routine anyhow, you will keep running into this kind of problems with no idea what is actually happening.
DAQmx supports buffered counter operation so you can actually configure the DAQmx task to use a larger software buffer. This will allow the DAQmx driver to serve the hardware interrupt and get the data into this buffer at a much higher rate than what your software needs to service reading from that buffer. Basically having your software read 1000 times per second 128 samples from the DAQmx task takes a lot more CPU and performance than having it read 10 times a second 12800 samples. Same data but a lot less effort for your application. But that also means that you need to configure the DAQmx task to use a buffer of at least 25k samples or more. This buffer is independent and in addition of the FIFO on the hardware. The DAQmx driver can service the hardware relatively fast and efficiently to transfer the data from the FIFO into the task buffer. It is your application that takes a lot of performance to call into the DAQmx driver to retrieve data. In terms of performance the effort to read 128 samples is nearly the same than to read 12800 samples. So by reducing the number of times you need to call DAQmx Read in your application by reading more data per call makes all the difference. DAQmx allowing to configure software buffers on a continuous acquisition task makes this possible as this buffer works as an additional software FIFO between the hardware and your application and can be much larger (basically as large as your memory in your computer allows).
