Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Is NI 9229 suitable for data acquisition for long durations?

Is NI 9229 input card suitable for data acquisition for long durations?

The reason I am asking this is because Ia doing the same thing and after around 22 min, lag in data acquisition is observed and fluctuations in ethernet speed is also observed at the same time.

Please help!!!

0 Kudos
Message 1 of 8
(2,568 Views)

The device is suitable, your code may not be.   

 

Post it if you can (and "save for previous version" if you're using LV 2018 or 2019, more people will be able to look).   If not, a typical suspect to look for in these situations is an increasing demand for memory usage, such as an array that grows unbounded.  

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 2 of 8
(2,497 Views)

I am using NI cDAQ9188XT with NI 9229 as input card for data acquisition from a Kistler triaxial accelerometer. I am acquiring data using nidaqmx python library. The problem that I am facing is that I observe a lag in data acquisition after running the program for around 22 minutes(happened several times, around same point of time). Also, fluctuations in ethernet speed starts around the same time, which I observed using Task Manager. The DAQ is connected to my PC using ethernet cable.

I am using python code(in which nidaqmx library is used) for real-time data acquisition and plotting of raw data.If I keep acquiring the data for longer times(even after observing the lag), the buffer fills up and halts the program, showing error.

I have tried following things:

  1. Reserving and unreserving task object after 500 seconds, because there is 30 seconds idle time in the process for which I am acquiring data, after every 500 seconds and then did the same for further loops.
  2. Starting and stopping task object after 500 seconds and then doing the same in the further loops for the same reason as above.
  3. Reserving and unreserving device(DAQ) after 500 seconds and the doing the same in the further loops.

But none of the above solved the problem or affected in any other manner. The fluctuations and lag started around the same time, in each of the above cases.

 

Do you know anything that might work or fix this problem?

 

Feel free to ask for any other information needed to assess or solve the problem.

 

Been trying to fix this since a week.

Please help!!!

 

Thank you.

0 Kudos
Message 3 of 8
(2,491 Views)

1. I have limited ability to help with details -- I'm not a python user.

2. I have had (and read about here) numerous successes running NI devices via DAQmx continuously for 100+ hours.  Almost invariably, problems similar to what you describe turn out *NOT* to be an inherent problem or limitation with the DAQmx driver.  The solution is usually found by changing the poster's application code, or sometimes there's an issue in the OS or other aspect of the computer platform.  Data management, file operations, complex GUI updates & manipulations, etc. are among the typical causes.

3. You tried several things aimed at giving your DAQmx tasks a fresh start every 500 seconds.  None of them helped.  

   From my vantage point, this seems like further evidence that the problem is less likely to be inherent to the device or DAQmx.

4. All that said, the consistency with which the problem arises around 22 minutes into the run is probably a very important clue.  It sure seems that some kind of threshold / tipping point keeps getting reached or exceeded.

   I'd be looking really closely for things like growing memory consumption during those 22 minutes.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 4 of 8
(2,478 Views)

When you used NI DAQmx for more than 100+ hours which type of sampling mode did you use?

The sampling_rate that I am using is 5kHz. I tried it in LV 2019. The buffer fills up in a matter of seconds with Continuous sampling mode, with 5kHz sampling rate. This does not happen with Finite sampling mode.

 

Any suggestions or idea, why?

 

Thank you.

0 Kudos
Message 5 of 8
(2,445 Views)

You will need to share your code if you want some detailed help.  But if you are using continuous acquisition (as you probably should), then make sure the Samples Per Channel on the DAQmx Timing is unwired.  This will maximize the buffer size.  The next thing to look at is your loop rate.  This is often determined by other things in your loop such as logging.  You can use a Producer/Consumer

 setup to make so only the aquisition is happening in the loop as fast as it can (based on number of samples per read and data rate).  Then parallel loop(s) can handle the logging and processing.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 8
(2,439 Views)

Thanks for your response.

 

Should I share the python code, which I used before? In that I set the buffer size to 10^6 and used continuous acquisition mode. The problem with that is that fluctuations in ethernet speed start after around 22 min at 2.5kHz sampling rate and number of samples per channel, both. I suspect that the fluctuations also trigger lag(observed during data acquisition) in data acquisition and after some 5 min the buffer also overflows. The nature of fluctuations is highly periodic and the ethernet speed's crest is 544kbps and trough is 272kbps. I checked for RAM consumption, and the increase always ranged between 5% to 10% during the entire run of program which stopped when buffer overflowed. The RAM in my PC is 16GB.

I love python, and I'd really like to code it in python, successfully.

 

Feel free to ask for any other information.

 

What is the meaning of


@crossrulz wrote:

Samples Per Channel on the DAQmx Timing is unwired?

 

0 Kudos
Message 7 of 8
(2,416 Views)

@pythonista wrote:

What is the meaning of


@crossrulz wrote:

Samples Per Channel on the DAQmx Timing is unwired?


In your previous post, you said you were trying in LabVIEW 2019.  The DAQmx Timing VI has an optional input for Samples per Channel.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 8
(2,409 Views)