Dear Friends, i am developing a lv project, that makes and controls an engine dyno system. Hardware is CRio 9022 with other cards and also 9205 for the AI. There is an angle encoder attached to engine shaft with 3600 devisions per revolution, and also an index to indicate completion of one revolution. the encoder output is measured by card 9411. The engine speed is 1500 RPM. I have to measure the pressure data and torque data when i recieve a 'tick' from the rotary encoder. this means my sampling rate for pressure and torque each is 90K/sec. but i have not been successful in implementing this. The program is large and i can show them, but i feel there is a problem in the hardware selection for the task. Along with pressure and torque data from the 9205, i also measure the other channels for temperatures and mass flow controller outputs. Thus in all i am using 8 channels of the 32 available. But only the pressure and torque are aquired at sample rate governed by rotary encoder. the rest are aquired about 5 times a second. Since the 9025 is a multiplexing ADC, the sample rate 250K is devided into the number of channels being accessed = 250K/8 = 31K samples/channel. With this observation i decided to acquire the data of pressure and torque with every 3rd tick from the rotary encoder, basically sampling at 30K samples/sec. However i see a great amount of noise. So i decide to average the cycles over 1 second (so the engine rotates at about 25 cycles/sec, i average over this number). The resulting pressure and torque graphs do not match with those measured by an oscilloscope in terms of amplitude but the frequency and shape is correct. I notice an interesting feature in the graphs. When i switch of interpolation between the points, i see many curves made by points instead of a continious locus of points. Thus i conclude that the aquisition is slower than required, and so there are less number of points being sampled than required. these points are un-synchronized over the 25 cycles which i average and hence the seperate 'curves'. this is due to the possibility that some points repeatedly recieve higher number of 'contributions' (while adding), than neighbouring points. so i conculde that the 9205 is not fast enough to do the job. also the noise maybe due to crosstalk or gosting when the mux changes channels. the impedences of the pressure and torque outputs are in the range of 10 K ohms. the outline of Labview code: Well there is an FPGA vi, that takes ticks from rotary encoder, and sends a signal when every 3rd tick occurs. The signal contains of a 16bit integer, indicating the tick number. this signal is sent to a 1 element FIFO. This fifo is read in a parallel while loop, where it keeps waiting for a new element. The while loop reads the fifo when data is available, takes a measurement from pressure channel. A memory method node is called to provide data according contained in index number equal to the fifo signal tick number. Then it adds the current pressure reading to the reading from memory, and stores the sum in the same memory location. thus an array of 1200 elements is formed, where each elemnt is a sum of values taken over 25 cycles. Then this memory is transferd to a dma fifo and read on the host side. same is done for torque measrement. on the host side the fifo is read and devided by 25 to get average. this average is displayed on a waveform graph. please check the attached file to get an idea of the problem. Sorry for the lengthy post. Please suggest if you understand the problem, and have suggesstions or solutions.

Dear ThiCop, thanks for waiting so long. So finally the 9215 has solved the issue. I following pictures show that. The hardware was as usual. I didnt have all the engine and test bench so i just input sine wave as the pressure signals and the same for torque signals (hence the two graphs). The timing clocks were also generated by another function generator(external) . the pressure graph (top) was aquired by NI 9215, and the torque graph (bottom), was aquired by 9205 at 8 microsecond conversion time. both were sampled at 90 K samples/second. As you can see the difference is stark, there is excessive cross talk in the 9205. This crosstalk diminishes if i dont sample more than 1 channel. i tried that and it behaved almost like 9215. Also note that the amplitude of 9205 is wrong since this is an averaged output, over 50 cycles and each time a cycle is averaged, the points dont add up correctly, ultimately increasing the error. So conclusion, if you want good signal at high sampling rates, dont use a multiplexing card, and if you do, please common all the inputs to ground to reduce impedances and maybe you will have better signal (didnt work for me).. I am attaching my code so that if someone wants to not repeate the mistakes i did, which is however the real learning 🙂 Thanks for the help!!

LabVIEW

Max sample rate with NI 9205 - Problems

Solved!

https://decibel.ni.com/content/thread/19145

Message 21 of 21

(698 Views)

LabVIEW

Max sample rate with NI 9205 - Problems

Re: Max sample rate with NI 9205 - Problems