Data storage interruptions with Signal Express

[jfsaft]

I am running a data acquisition program written in Signal Express.  When the program is configured to save data to a file, there have been occasions where data storage just stops for no apparent reason in the middle of the test, leaving a truncated file.  I've considered all the obvious reasons, such as network interruption, but none of these apply.  Are there any general reasons this might be happening, and do you know the best steps to prevent this from happening?

[alcava.cr]

Hi jfsaft, are you getting any kind of error message like a timeout? Or you are having an issue similar to this one "SignalExpr​ess Stopping..​."? If we are talking about a timeout that means no information is being received from the device that you are using to acquire data, in this case I would recommend checking the connectivity with the hardware.

[jfsaft]

Hi Alejandro --

The program never freezes up, never times out.  It continues running and getting new data (you can see the updates on a graph on the screen) even though it's no longer saving the data to a file.  There are no error messages and no apparent problems with the hardware.  The only way you can tell there was a problem is after you've finished the test and you look at the data file and you see that the data stopped being recorded at some point during the test. 

We're commanding the data to be saved at a very slow rate -- usually one data point per 10 seconds, or one data point per 1 second at the very fastest.  I believe we're sampling at a few hundred points per second.  

Thanks for your help.

[alcava.cr]

No problem, In that case have you check your Recording conditions. Make sure that the conditions (both: start & stop) are in compliance. Here is a couple resources for reference on this feature:

- Recording Options (LabVIEW SignalExpress 2010 Help)

- Attach is the SE getting started, please take a look at chapter 4.

Also, consider this scenario: A conflict occur when SE tries to perform a save operation to a file that is already open, this happens because in order to manipulate a file, a program needs to reserve its reference. So, if you are viewing the TDMS file in excel and at the same time SE tries to log, no information will be save.

[jfsaft]

We're actually not using the Record function.  We want the data in an ASCII text file and the ability to start and stop data storage at any time, so we added a "Save to ASCII/LVM" step to the program.  When the operators start the program, they use the "Run/Stop" button rather than the "Record" button, and they press the "Save" button to start storing data.  The file type selected is Generic ASCII, and the Overwrite option is set to "Overwrite once then append to file".  The operators always change the file name before they run a new test, so the overwrite shouldn't be an issue.  The files are set to be tab-delimited.

[OKors]

This sounds familiar... About a year or so ago I logged some temperature vs. clamp load data over the course of a week. Acquisition rate was very slow as well (1sample every 5 min or so).

Before I try and make any suggestions would you mind attaching the .seproj file?

Also, what version of SE are you running? 

[jfsaft]

The .seproj file is attached.  The version is SE 2010.

[OKors]

Unfortunately I'm getting a "Missing Log File" error and am unable to open the project. But based on the files that are 'missing' they appear to be .tdms files which are used to link to Recorded data.

A few things come to mind that you mentioned in your post earlier:

---

We're actually not using the Record function. We want the data in an ASCII text file and the ability to start and stop data storage at any time, so we added a "Save to ASCII/LVM" step to the program. When the operators start the program, they use the "Run/Stop" button rather than the "Record" button, and they press the "Save" button to start storing data.  The file type selected is Generic ASCII, and the Overwrite option is set to "Overwrite once then append to file".  The operators always change the file name before they run a new test, so the overwrite shouldn't be an issue.  The files are set to be tab-delimited.

---

If properly configured to only save to ASCII there should not be a prompt to "save" once the Run button is clicked. A save prompt would occur when Record is selected and asks if you want to change the title description of the log file (this would output the TDMS file that appears to be missing).

Be sure in the Recording Options under Signal Selection you have nothing checked to "Record". Also under Log Summary be sure "Prompt for title/description when log is created" is unchecked.

Under Timing Settings in the DAQmx Acquire step set Acquisition Mode to "Continuous" and choose the desired sample rate. When you click Run you should select "Run Continuously" (you may have to click the drop-down and select it manually if you've diabled the prompt).

Log some data and see if that helps.

A few other things to ask:

Where are you writing the data to? Network location, local hard drive, usb hard drive? You may have a bottleneck issue if logging to usb drive.

Also as Alejandro mentioned, be sure there's nothing interrupting the read/write IO to disk as data is being logged.

[jfsaft]

None of the signals are checked under Signal Selection in Recording Options, and the engineer in charge of the test tells me that the operators never use the Record button anyway.  (The one time they did, they filled up the hard drive with the TDMS file.)  The acquisition mode is set to Continuous under Timing Settings in the DAQmx Acquire step.  The only thing the operators haven't tried yet is select "Run Continuously" when they press the Run button.  I told the engineer to make sure they do this the next time they run a test, and we'll see what happens.

The data is being written to a local hard drive.  I originally thought network interruptions might be the cause, but it turns out that's not an issue.  Nobody tries to open a file while it's being written to.

Thanks for all the advice!