I have a problem with writing measurement to excel after 15s do-while data acquisition

[IanS]

Hi Ken,

I'm not sure why it would only log for .25s.

Perhaps you could upload your VI as an attachment, and I'll take a look at it and see why it would do that.

[ken84]

HI Ian

Thank you again.

Please see attached for the VI .

I look forward to hearing your response.

Best

Ken

[IanS · Accepted solution]

Hi Ken,

The cause of the problem is that you can't execute the VI fast enough to acquire all the data. Firstly, the write to measurement file pops up a dialog box to ask for a filename. Don't let it do this. If you need to make new files, you can always wire your control into the filename input.

Also, change the number of samples to read inside the DAQ assistant. I found that increasing this from 1 to 100 meant I got all the data (3100 points)

This is because every iteration of the loop, labview has to load the excel file from hard disk, and save it back again, so it is much faster to write larger amounts of data at a time. This is still a quick fix, and there are better ways to program the whole vi, but I expect this will resolve your problem for the moment. 

Incidentally, you could use the "Time has Elapsed" output instead of checking the elapsed time > 15. 

Let me know if this sorts it out for you.

[JÞB]

---

@IanS wrote:

Hi Ken,

The cause of the problem is that you can't execute the VI fast enough to acquire all the data.

---

Exactly.  Thats the only drawback to those big blue Express vis.  WAY TOO MUCH overhead.  they are pretty though but, a skilled developer can code circles around them.

Heck, even a novice could Right-click the DAQmx Express vis and select "Generate Code!"  Note that the elapsed time and Write to measuremenst files were NOT replaced

Elapsed time is one of the very few Express vi's without signifigant overhead.  I use it all the time!  Write to measurements file DOES have a large performance penalty If its outside a loop or timing isn't important it offers some really cool options that would require you to write a whole bunch of code to duplicate (at little if any improvement in performance)  The DAQ assistants on the other hand are devil's spawn!  "Generate Code" from them!

[ken84]

Hi Ian

Many thanks for your kind help.

Yes the problem is solved by changing 1 to 20. I can log in 3000 samples exactly.

However, I am a bit confused by the number in "samples to read" under the "continuous samples" acquistion mode,

How do I know it should be 20? I don't know, It was a lucky guess.  Setting "samples to read" at 1 gets about 150 samples, 20 gets 3000 samples, 100 gets 3100 samples. 

I can't tell any correlation between them. 

Your explanation would be much appreciated.

Thank you

Ken

I

[crossrulz]

---

ken84 wrote:

However, I am a bit confused by the number in "samples to read" under the "continuous samples" acquistion mode

---

When in continuous mode, I usually just leave the number of samples to read unwired or set to -1.  This results in reading all of the available samples.

[IanS]

As mentioned previously, it is all to do with the timing, and how long the VIs take to execute. 

1 sample per read was too slow.

20 was fine

100 samples, it must have just missed the 15s cutoff, and read another 100 samples. 

Setting to -1 wil acquire about 3000 samples, but maybe not exactly.

As I suggested, this was a quick fix so I'm glad it works as you want. As Jeff mentioned, there is overhead using the express VIs, and for future projects you could look at using lower level programming, it's not too difficult to pick up. You can start off with the DAQmx examples (In LV, Help->Find Examples... Hardware Input and Output->DAQmx).

All the best for your project