Corrupted data at sub-Hz sample rates when using repeated logging. Also, data lost when out of memory.

[samik99]

I'm logging 24 channels at 0.1Hz sample rate for up to 3 days. After a day or two, SignalExpress will complain "Not enough memory to complete this operation", crash and lose all data. As a workaround I select "Automatically export log to ASCII file = Yes" and "Prepare log data for logging = Never", and set start and stop conditions so that I get, say, eight logs of 6 hours worth of data each. However, in the end only the first ASCII text file will contain full data, and the remaining files contain only the data of the first channel. When I try to "Make Log Viewable" in SignalExpress, SignalExpress freezes and has to be killed with task manager.

Is there a workaround for either of these problems? 

I have plenty of memory (3GB RAM + 10GB swap), and the (brand new) computer is dedicated only for this measurement. Windows XP + NI-6224.

[simoji]

I hope I found a workaround: Sampling 100 samples at 10Hz, using a statistics step to average these to yield a set of mean values every 10s, and save to ASCII step to stream the mean values to a file on the fly. In case of an error the data up until the error will be safe. As a bonus, the corruption problem with repeated logging does not occur when sampling frequency is over 1Hz, so the logs are again viewable. I'm still searching for a way to add timestamp and/or index to the data.

The split ASCII files now all have a correct number of rows, although the last row (of other than the first file) appears still to be lost. Instead, the header is repeated N times after the data. However, I hope these ASCII files are now not needed as all data can be extracted from the ASCII step save file

And, forgot to mention, the SignalExpress version I use is 3.0. I sincerely hope it will still be supported and updated. I was expecting to have a quick solution to an extremely simple measurement task, but instead have found myself spending many hours working around performance 'features' and losing two days worth of valuable data.