error reading data from shaft encoder

[tzj]

I am currently using a shaft encoder to get the position of a piston inside of a combustion engine. The encoder has a circular disk that spins, with perforations on the side of it. A laser shines through the perforations and hits a photosensor that puts out a voltage. This puts out a square waveform that can be converted into a position (using good old trig). The model I have has 360 perforations, which means for every 1 rotation there will be 360 changes in voltage. The voltage output is either 0 or the input of a DC power supply (I have it set at 5). I was running into problems where I would sometimes get a really small offset. As the engine ran, this offset increased with each rotation of the shaft. Because the engine is running at 500rpm (which will increase up to 3500rpm when I fix this problem) even an offset of 1 degree every rotation will throw the measurement off. The way I tie this into LabVIEW is by reading in the data (at about 10kscans/s) into a scaled array, I feed this array into a for loop with shift registers. If the current value is above a certain threshold and the previous value (obtained from the shift register) is below a certain threshold my angle variable is to increase by 1. 1 full rotation will correspond to 360 in my angle variable. This is not happening. I tried increasing the sampling rate, changing the voltage inputs to reduce rise and fall time, all to no effect. Any help would be appreciated, I have attached my sample code.

Hardware:
PCI-MIO-16E-1
BNC-2090
AccuCoder 715
LabVIEW 8.5

[G_Lo]

tzj,

I would highly recommend using a producer/consumer architecture.  The producer loop would be reading analog input, place the data in a queue, and the consumer loop would remove and process data from the queue.  Your coding architecture is not very efficient because the analog read waits until the inner most for loop is complete.  A producer/consumer template can be found selecting File>>New and expanding the following folders VI>>From Template>>Frameworks>>Design Patterns>>Producer/Consumer Design Pattern (Data).  Also, remember to clear your analog input task by using AI Clear.vi.  Let me know if this assists or if this seems to be a hardware issue.

[tzj]

Thanks G Lo
I wrote up this code as a basic idea of what I'm doing, but I will try the producer/consumer loop. Still it seems to be a hardware issue as there is a constantly growing offset that is throwing off some of my calculations.

Tim

[johnsold]

Tim,

After a quick glance at your code, I think I see where the offset may be generated. The middle shift register (Angle) compares the result from the previous iteration to 360 degrees. If you run this with some test data I think you will find that you get one rotation every 361 degrees. Make the limit 359 and see if the offset goes away.

Another note: If this becomes a subVI of your Producer/Consumer architecture, you may need to initialize the shift registers.

Lynn

[tzj]

The code does compare to 360 degrees, but it is a less than. So the output of the selector will be 0 if the angle is 360 (360 is not less than 360). I have posted a new code using the producer consumer structure, it still generates an offset. At first I thought it was the sampling rate, but I cranked it up to 4x the expected frequency of the signal and it still didn't work. I might try creating a square waveform and feeding it into the consumer loop to see if it is a hardware or software problem. I have posted the code, any suggestions would be greatly appreciated.
Thanks!
Tim

[G_Lo]

tzj,

Using a square wave is a great way to tell if it is software or hardware.  I have also attached a test vi that I utilized to see how many counts occur from a point that is above the high threshold and the previous value is below the low threshold.  It has changes from your original code but it might spark more architecting idea.  Also, make sure to initialize your shift registers as Lynn said.  This will ensure that you always will start at a count of zero.  Let me know what the results were from the square waveform test.

[tzj]

So I think I have found a solution. I have found that plugging in a square wave works pretty much 100% of the time, even when I threw in some random noise (at levels much higher than what I would encounter when actually taking data). I set the thresholds for Vhigh and Vlow to equal each other (I used a value of 1 for both, with Vmax=5 Vmin=0) and somehow this eliminated the offset. I do not conceptually get why this is, it may be because of the rise/fall time of the encoder. I am now running into the problem of there being a very large delay between my producer and consumer loop, a lag of about 5 seconds. I admit I have not yet really looked into this problem, so I will post here if I can't figure out a solution.

Thanks for the help!
Tim