Crash with write to measurement

[Scarface03]

I think I have problems when i use write to measurement. When I increase my sample card clock sample I can not save after a short time labview goes crash saying: "The application is not able to keep up with the hardware acquisition.

Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples could correct the problem. "

How can I fix the problem?

[Corey.Rotunno]

Not knowing the type of read task you are using I cannot say definitively. However, the "increase buffer size" or "read set number of values" statements are pretty good hints. 

Again, without any code to look at I would guess you are running a while loop that is trying to execute as fast as it can? If so you are only reading 1 or 2 values per iteration. This is just a guess. I would also guess you are trying to write to your measurement file in the same while loop?

This would be a major no-no. File tasks inherently have huge amounts of jitter and should never be placed in a data acquisition loop. You should be using a producer/consumer where the producer loop gets values (lets say 100 per iteration) and passes said data to a consumer loop that does the file writing. The data should be passed with a queue, or more recently, a "channel" if you are running LV 2016+. That way your file writing loop can process data at it's own pace. You just have to make sure that you queue is adequately sized to deal with slow-downs in the file write process. If you are finding that you need an unreasonably large queue then I would suggest reading more values per iteration. The file operations deal better with larger chunks of data less often than very small chunks of data very often. You should look at the file operation buffers and the like.

[Scarface03]

This is the vi. If I use this at 100khz sample clock it crash.

[Corey.Rotunno]

Hi,

  So as I expected you are doing your hardware reads and file writes in the same loop. This is simply not going to work.

  You are going to need to go to a producer (hardware read) and consumer (file write) parallel loop structure. At 100kHz I would recommend reading maybe 1,000 samples per iteration of your producer loop and put those in a queue. Then in your consumer loop wait for 10,000 values in the queue then write them to file? That way your producer loop would run at 100Hz and your consumer loop would run at 10Hz. These loop rates might not actually be optimal, but I have no way of trying them out right now. Unfortunately I cannot provide an example as I do not have daqMX drivers installed at home and am on the way out of the door so I don't have time to install it.

However, there are ample producer/consumer examples out there, I believe there should be a couple included with LabVIEW actually.

P.S. - I do not know how the "write measurement file" express VI behaves. But if it opens a reference, writes, and closes the reference every iteration it is not going to work for you. You may likely need to get into the TDMS streaming palettes so you can manually open the reference, write many times, and then close it when you are done.

Best of luck!

[Scarface03]

I could use the continuos voltage input file in the example that uses tdms and then convert the lvm file to another vi. I tried with this system sampling at 100khz with 10000 samples but the files are too large and unmanageable. I can not transfer them to matlab.

[Corey.Rotunno]

100kHz is pretty fast if you are doing a "long" continuous record. If you don't need 100kHz then the solution becomes easy, just reduce your rate. Not knowing anything about your application, I can't say. 

If you do need 100kHz then I would suggest doing some sort of triggered recording. So continuously sample your data, when you see whatever start trigger start writing to disk then end the file write whenever you detect some stop trigger or after a set amount of time.

If you really need all that data then, you will need to get creative maybe. or buy better computers? haha I don't know

[Ben]

---

@Scarface03 wrote:

I could use the continuos voltage input file in the example that uses tdms and then convert the lvm file to another vi. I tried with this system sampling at 100khz with 10000 samples but the files are too large and unmanageable. I can not transfer them to matlab.

---

That sounds like a limitation of matlab?

Ben

[Scarface03]

I have to sample a sine sweep that comes up to 20khz and they told me i can only have an acceptable signal by sampling at least 5 × -10x this frequency

[Scarface03]

Hi Ben. The tdms files are very big but I can not load this format into matlab

[Ben]

---

@Scarface03 wrote:

Hi Ben. The tdms files are very big but I can not load this format into matlab

---

There is a free TDMS plug-in for Excel that will let you read TDMS files with Excel. Could you use Excel to save the file in a form that matlab can handle?

Ben