NI cDAQ long term data logging buffering probblem

[sanilj]

My setup NI cDAQ 9178 Chasse with NI 9219 measuring Voltage from 2 channels,  NI 9210 (miniTC) measuring 3 Thermocouple, NI 9265 supplying excitation current from 2 channels and NI 9263 for setting voltages on 2 channels. the setup is a closed loop acquisition system.

the squassation is running using the Lab view Write to measurement file and the global loop is running at 500ms wait delay, also the sampling frequency for the DAQ assistant is set to 500mHz ~ 2 seconds

As this test runs for longer then 40 minutes it is observed that the data observed on the dashboard and the control loop starts drifting from the current value (some thing like a buffering effect. 

Can there be a fix to this long term problem?

[GerdW]

Hi sanilj,

---

@sanilj wrote:

Can there be a fix to this long term problem?

---

Yes, sure!

Easy fix: don't use ExpressVIs! (Like WriteMeasurementFile or DAQAssistent…)

[Tom_Powers]

Or use express VIs to get something started then convert them to code so you can figure out what they are doing then you can change the code to do what you want.  Plus for this case I would just do the express VI for collecting the data right click on the express VI and select convert to DAQmx code so that you can see what it is doing.  Then write the rest of the code starting from scratch.

[sanilj]

 I am already using express VI DAQ assistant and Read to measurement File to capture Process and then store the data. but the Runtime drifts after long term testing  

[johntrich1971]

---

@sanilj wrote:

 I am already using express VI DAQ assistant and Read to measurement File to capture Process and then store the data. but the Runtime drifts after long term testing  

---

Both GerdW and Tom_Powers told you not to use the Express VIs and Write to Measurement File vi. Use DAQmx functions and primitive write functions. The Write to Measurement File is likely causing major problems because it opens and closes the file each time it writes. As the file gets larger it will take longer to complete this process. It's usually best to separate file writing from data acquisition using, for instance, a Producer/Consumer architecture.

[Tom_Powers]

"but the Runtime drifts after long term testing"   What does this mean?

The other point is what you have is not working.  You need to step back and try a different approach. That means start writing real code and stop using the express VIs.

I am a state machine guy.  I can program in other styles but I generally do state machines.

For something like this I would have the following states.

Init . . . generally make sure all of the controls are set in the correct space.

Write file header . . . put my column headings into a .txt file . . . don't close the file pass out the file ref num using a shift register for later use.

Option 1. Get the data this includes create the task set everything up get the data and close the task often times this will work just fine otherwise.

Option 2.  set up the acquisition. after write file header

                start the acq wait for the buffer to be full, get the data then do something else passing the data to the write data to file state using a shift register..

Write data to file.  This is generally convert the data to a text string. Point to the end of the file then write the data to file.

Return to option 1 or the start the acq and get the data state.

Exit state.   Close file, close Acq task.

[Mackenzie3365]

---

@sanilj MyEnvoyAir wrote:

My setup NI cDAQ 9178 Chasse with NI 9219 measuring Voltage from 2 channels,  NI 9210 (miniTC) measuring 3 Thermocouple, NI 9265 supplying excitation current from 2 channels and NI 9263 for setting voltages on 2 channels. the setup is a closed loop acquisition system.

the squassation is running using the Lab view Write to measurement file and the global loop is running at 500ms wait delay, also the sampling frequency for the DAQ assistant is set to 500mHz ~ 2 seconds

As this test runs for longer then 40 minutes it is observed that the data observed on the dashboard and the control loop starts drifting from the current value (some thing like a buffering effect. 

Can there be a fix to this long term problem?

---

One possibility is that you are overwriting or underwriting to the buffer of your output module, which can cause errors or delays in your data generation. You might need to adjust the buffer size and sampling rate according to your needs.

Another possibility is that you are experiencing drift or noise in your measurements due to environmental factors, such as temperature, humidity, or electromagnetic interference. You might need to calibrate your modules or use shielding or grounding techniques to reduce the effects of these factors.