Logging multiple analog and counter signals with the same sampling rates

[P-Train]

Right now I am working on a flowbench set up that I have almost all the way there. I am using Labview 2011 and two PCI cards linked with an RTSI cable. The first card is a PCI-MIO-16E-1 that I'm using to measure all of my analog signals. The second is a PCI 6601, I'm using that for the counter inputs. The counter inputs are being used to read a X4 quadrature encoder, that I am trying to get an RPM reading from. I've been able to set up a way to run and log all of my analog signals at 10kHz continuous sampling. But I have only been able to read my rpm value on on the screen and not log it/ not sample it adequately. 

To get all of my measurements to log I've tried a variety of different methods, The first I tried was using the quadrature signal to get my RPM value from a "Two edge separation" signal. This got me the closest because I was actually able to log RPM along with all of my analog signals. The problem with this was it made the flowbench not very user friendly at 0 RPM conditions when the encoder wasn't reading any edges and it would cause labview to timeout. It was also not sampling the rpm signal fast enough because the only way I could get it to work was by sampling the "two edge separation" signal on demand. This would leave us with huge gaps in RPM data when post processing.(See attached Numerical Flow Control guad test.vi)

The only other method that I tried worth mentioning, was by taking an "angular position" measurement from the quadrature encoder. I would take that signal and run it through a timed loop and convert it from a count to RPM. This was fine for when I only wanted to log the analog signals and just use RPM as a visual referennce. Along with the similar sampling rate issues I was having with the other VI, whenever I would try to log RPM. (going loop to loop) The whole thing would freeze and give me errors. (See attached Numerical Snubber testing.vi)

I've been fighting with this for a while now so hopefully someone will be able see where I'm going wrong here. I'm open to any suggestions, hardware wise, and/or methods to achieve my desired results.

Thanks,

-Pat

[Emily-C]

Hi Pat,

This forum post offers suggestions for taking the RPM measurement of a quadrature encoder: http://forums.ni.com/t5/Counter-Timer/RPM-Measurement-using-Quadrature-Encoder-and-PXI-6602-counter/...

If you start from the Meas Dig Frequency-Low Frew 1 Ctr example VI, you can determine the frequency of a digital input. You can use simple math from there to convert the frequency into RPM (freq*60/pulses per revolution of encoder).

I hope this helps!

[P-Train]

Thank you for the help Emily! I tried what you suggested  and it put me roughly back in the same place as where I was, I was able to acquire and record a frequency signal using the frequency feature of the DAQ Assistant. (I'm not as familiar with DAQmx). The main issue I'm having now is with sampling rate. I am logging all of my analog signals at continuously 10kHz, while I can only record the RPM (counter) signal by sampling on demand0 which doesn't provide the resolution I need in post processing. I'm essentially getting one RPM sample for every 10,000 analog samples. Would you have any insight into that issue? I've been searching around and I feel like I almost need to get a PXI card that would allow me to use a HW Timed sample rate to sync analog and counter signals?

Thanks again, 

Pat

[Emily-C]

Hi Pat,

Because you are currently concerned with sampling rate, I would suggest you move to using the lower level DAQmx functions, as shown in the example I linked you to. The DAQ assistant has a lot of overhead, and putting it inside a while loop will really slow down your application.

Are you sure you can only record the counter signal by sampling on demand? I set up a DAQ assistant with a Counter Input set to Frequency, and was able to do continous sampling. Where were you not able to change the settings to continuous?

Thanks!

[P-Train]

Are you saying I can run DAQ assistant outside of a while loop? I'll give that a try. I'm far from a expert with this and I was under the impression that the daq assistant had to be within the while loop. 

I tried running it continuously and for N Samples and both times it would freeze and then timeout, telling me that it had overwritten or not obtained samples (somthing along those lines. I don't remember the exact error). The only way I could get it to run for any length of time was by setting the sampling to on demand.

I will also try running it with DAQmx. 

Thanks,

Pat

[Emily-C]

Hi Pat,

If you're doing continuous sampling your DAQ assistant should be inside a while loop. What I was trying to say is that all express VIs (the blue box functions) have extra overhead. They're often doing a lot more work in the background than a similar lower function VI would do. I attached a screenshot of a simple example of an express VI you could replace with a lower level function VI for better performance. Having as many express VIs as this application in a while loop could be causing performance issues. For this reason, I suggest that you try following the example I linked to before to use DAQmx functions instead of the DAQ Assistant. This could help resolve your timing issues.

Could you please send me a screenshot of the exact error you're seeing? This may also help narrow down what's causing this issue.

Thanks!

[P-Train]

Hi Emily, 

I understand what you're getting at now. I've attached the screen shot of the error. When I set both DAQ assistants to run at 10kHz continuously this is the error I get. The DAQ assistant that is reading all of my analog signals is the one that gets highlighted which I thought was odd because I didn't change anything in that one, I only adjusted the sampling rate in the frequency measuring DAQ assianant.

Thanks, 

Pat

[Emily-C]

Hi Pat,

Error -200279 "Attempted to read samples that are no longer available" occurs because samples have been overwritten by the DAQ card. This KnowledgeBase document, "Why do I get error -200279 from my DAQmx read VI or property node?" offers more insight into the issue: http://ae.natinst.com/public.nsf/web/searchinternal/ab7d4ca85967804586257380006f0e62?OpenDocument?Op...

In particular: "Often processing done in an acquisition loop causes that loop to run too slowly. This may be by writing to a file, doing extensive calculations on the acquired data or displaying the data in a manner that requires too much time from the processor." You sampling rate is running so much faster than your loop that by the time you start your loop again you've acquired so many samples that your buffer has overflowed. The KB link above explains some possible steps to take to resolve this issue, such as changing the sampling rate or samples to read. I suggest you look through these possible solutions. However, in your situation I also suggest you try to simplify some of the code in your while loop, in particular cutting out express VIs when possible, to decrease the execution time of your loop.

Another KnowledgeBase document, "Why do I receive buffer error -200279 during a continuous, buffered acquisition?" also gives further explanation on changing the sampling rate or samples to read: http://ae.natinst.com/public.nsf/web/searchinternal/7ad4854943bf344186256d6500807935?OpenDocument

I hope this helps!

[P-Train]

Thank you for all of the help and the information! I've been tied up with other tasks so I haven't had a chance to go through everything yet. I'll try simplifiing my VI and I'll read though that info and report back when I get a chance.

Thanks again,

Pat

[P-Train]

Hi Emily,

So I think I've just about got this. I think my biggest issue was my basic understanding of how Labview collected and logged the data. The information you provided was just what I needed! After tweeking the buffer size and sampling N samples I was able to log all of the data at 10kHz the only issue with that was the the display would take two seconds or so to reflresh. I never could get it to work continuously.   I also managed to get rid of all of the Express VI's execpt for the DAQ assisants and Write to file. This didn't have a huge effect though. At this point it's just a matter of finding the the way of recording encoder data that out simulations engineer likes best. 

I tried something a little different yesterday, trying to log angular position (essentially the count of degrees, because we were only spinning one way) logging just the raw signal. When I attempted to log this at 10kHz using N samples the same way I didn't with calculated RPM, it logged at the correct rate but it would also refresh every 4X my buffer size(samples to read) instead of continuously counting. If i did set it to run contiuously I would have the same issues as before. Would you have any insight into this issue as well?

Thanks, 

Pat

P.S. I've attached a plot of the angular position data vs time to give you and idea of what I was saying.