fast analog input on cDAQ

[PaulOfElora]

I'm trying to dive just a little deeper into DAQmx than I've swum before.  My goal is simple - to suck an analog input out of a NI 9215 card and pop it into an FGV just as fast as I can.  I probably went too cheap on this little board, it doesn't have many bells & whistles for triggering, but it is rated at 100k samples/second.  I'm using Windows 10 & LabVIEW 2019, NI-DAQ 19, and *SIMULATED* cards until I get my real hardware in.  I've been fiddling with the sample mode, source, # of samples, etc. etc. but I just can't seem to find the key to the puzzle.  I just use the 'Loop Count' for estimating speed of the loop.  I get all sorts of bizarre looking results, unless I try the 'wrong' combination and get the outrunning-the-buffer errors.  Can anybody explain to me what I'm doing wrong? Much thanks! paul

[didje007]

Simulated hardware does not behave like the real hardware especially in terms of timing.

I cannot open your code as I'm using LV 2018 but you cannot rely on the result of the hardware simulated

[Kevin_Price]

I'd also recommend that you *DON'T* write the data directly to an FGV.   Read up on the Producer Consumer architecture and deliver your data to other parts of your app with another mechanism.  FGV's are blocking calls, and it's possible that the readers will get in the way of your attempts to write.  Such collisions don't occur with queues, notifiers, user-defined events, or channel wires.

(Realistically, the FGV will probably work, but why not take this time while waiting for hw to learn a new technique that will serve you well in other situations?)

-Kevin P

[oscarfonseca]

I will also add that the code as it is right now has no mechanism to control the speed at which the loop is running. Since you are not wiring an amount of samples to the DAQmx Read.vi, the code fetches all the samples available when the execution arrives to that call. Therefore, it leaves up to the Windows OS how fast the code can run and consumes high CPU power. I would try wiring a specific amount of samples you want to read, or add a timing (Wait) to the loop.

I recommend starting from an example to see in a more clear way how the DAQmx driver performs its operations of initializing, configuring, reading/writing to the physical card, and closing tasks. You can find them in LabVIEW Help tab > Find Examples.. > Hardware Input and Output > DAQmx

All the best,

[PaulOfElora]

Thanks Kevin - I'm using this in a P/C type architecture, I've just always used FGV's to move & hold data.  You're suggesting a data Q used to ship the data off to a process that can handle at least as fast I'm enqueuing, right? Paul

[PaulOfElora]

I'm afraid you're right, didje007, sigh, will have to wait for my hardware to arrive... paul

[mcduff]

---

@PaulOfElora wrote:

Thanks Kevin - I'm using this in a P/C type architecture, I've just always used FGV's to move & hold data.  You're suggesting a data Q used to ship the data off to a process that can handle at least as fast I'm enqueuing, right? Paul

---

What do you want to do with the P/C architecture? If you are using it just to log data, then use the built in DAQmx logging functions. Using them I can stream 8 channels at 2MSa/s over the USB bus, while saving data continuously. You can use a lossy P/C architecture to display the data if desired.

mcduff

[PaulOfElora]

Thanks Oscar - well, not finding any examples that run screaming fast like I need (well, pretty fast - 100kS/s).  But - are you suggesting that I put like a 1ms Wait in the loop, then try to grab 100 samples per loop, to get the 100kS/s the card is rated for?  Guess I thought (with no evidence) that maybe the call to the hardware, processing, etc. would take some time, which would then clock the loop...

[PaulOfElora]

Thanks McDuff - I'm controlling a hydraulics system.  If I'd thought thru the requirements a little more, I'd have bought a card with analog triggering.  But I'm trying to run the analog in as fast as I can to quickly detect the force from a load cell, and then respond with analog out (NI 9363), in a PID-ish control loop.  I'll display only decimated data - the user doesn't need to see 10uS stuff (card is supposed to run at 100kS/s).  Good to know that I can get the data over USB speedily.  I definitely don't need to keep all the data - when I get the fast analog in stuff working, I'll add some file logging, but again, only decimated data at maybe 100ms intervals.  Does this all make sense to you? paul

[mcduff]

---

@PaulOfElora wrote:

Thanks McDuff - I'm controlling a hydraulics system.  If I'd thought thru the requirements a little more, I'd have bought a card with analog triggering.  But I'm trying to run the analog in as fast as I can to quickly detect the force from a load cell, and then respond with analog out (NI 9363), in a PID-ish control loop.  I'll display only decimated data - the user doesn't need to see 10uS stuff (card is supposed to run at 100kS/s).  Good to know that I can get the data over USB speedily.  I definitely don't need to keep all the data - when I get the fast analog in stuff working, I'll add some file logging, but again, only decimated data at maybe 100ms intervals.  Does this all make sense to you? paul

---

Can you post your VI in an earlier version?

To run at higher speeds I found you cannot query the instrument much faster than 10-100 Hz, otherwise the overhead results in timeouts. In my application, I can an array of data points every 10 Hz. so for a 100kSa/s rate, 10kSa of points. For triggering purposes this is too slow.

mcduff