DAQ update frequency slower than requested

[Mrhighsky40]

Equipment:

    NI 9189 cDAQ

    NI 9209 Analog Input Module

    NI 9264 Analog Output Module

    Strain Gage

Issue: 

    Previously the attached Labview file (Labview file called "Dyno Main Program") worked for collecting data at a frequency greater than 1000 Hz, this was using a USBX Series DAQ. I have moved the setup over to the system listed above and the frequency shows to be 1000 Hz on the Labview screen but the graphs and save data updates around 1 Hz max. When deleting all but one data task in the Labview file the frequency ~doubles so I don't think the amount of data we will be requesting is the main issue but it may be, I am not exactly sure how Labview interacts with DAQs and requests data. Any advice on how to increase the acquisition frequency is appreciated.

[BertMcMahan]

You didn't attach any code, but I can tell you that the NI 9209 can only sample at 500 Hz total, which means if you have 2 channels you can do 250 Hz, 5 channels can do 100 Hz, etc.

https://www.ni.com/en-us/support/model.ni-9209.html

[Mrhighsky40]

Sorry about that, I have attached the file. Your mentioned issue accounts for most of the problem though there are currently 7 input channels in the code which would bring the max frequency down to 3.9 Hz

Ignore the math here I for some reason decided to just continue to divide it by 2 for each channel.

[BertMcMahan]

500 / 7 = 71 Hz, so that's not it.

I have to say your code is quite rough; you should try to keep a single VI no larger than one screen's worth of real estate. When you find yourself using the same piece of code more than once, make a subVI that does it. There is so much going on in your VI that I couldn't begin to diagnose where the slowdown is happening, but if this seems to be a good enough fix for you then I'm glad it helped.

Just FYI, NI is currently still offering their training for free due to COVID:

https://learn.ni.com/training

[Mrhighsky40]

Yeah we are trying to make this as we go so we haven't simplified it down enough yet. The guy who initially made it didn't know labview well enough for subvi's and I've been trying to clean it as we go. I am sorry about the mess, but that does account for some of the slowdown. So thank you for that information. I wasn't sure what the 500 S/s meant but that makes a lot of sense.

[BertMcMahan]

S/s is Samples per Second and is usually an aggregate number for the device as a whole. S/s/ch is Samples per Second per Channel, which means that device can sample at that rate regardless of the number of channels used.