Why is my VI not taking enough points?

[Punchy_Cupcakes]

I've written a program to measure 30,000 points of voltage data over a specified amount of time (Called "sweep time"). When the sweep time is set to <=8.33 seconds, the program works without any difficulty. However, when sweep time is set to >=8.34 seconds, only half of the required data, 15,000 points, is taken. This sweep time corresponds to about 300 pps, so I thought it might have something to do with my hardware, but when I rewrote the program with a virtual voltage channel the same thing is happened. What could possibly be causing this?

I've attached the VI in question. Any help would be greatly appreciated.

[Punchy_Cupcakes]

I forgot to mention: The data is printed onto a spreadsheet whose default location is "C:\Users\localadmin\Desktop\test_print". This can be changed in frame 2 of the stacked sequence. This spreadsheet file can be opened with Excel, which is how I have been determining the number of data points being recorded. (When the problem occurs, you will see a 0 on the last 15,000 voltage data).

[DollaBrillz]

Hi,

I understand you configured a virtual channel and experienced the same behavior, which leads me to believe that it is either a setting or part of the program architecture that is causing the issue. Below, I have included a link to a community example on our website.

https://decibel.ni.com/content/docs/DOC-32502

I would recommend trying this code and setting the clock to finite samples (30000) to see if you still encounter the same error.

I hope this helps!

[Norbert_B · Accepted solution]

Do you get errors?

Important note: Stop using the stacked sequence structure and local variables!

Regarding the stacked sequence structure, there is the idea to remove it from LV and i hope NI is giving in for that idea (as "in beta" indicates)!

What is the purpose of the second TDMS file?
The first TDMS already contains an implicit time channel.....

Why don't you use a for-loop for aquisition as you KNOW the number of samples? Why do you let the user choose how many number of samples are read in each iteration if you have to fetch all 30k samples within 10 iterations (no variance in the last two values!)?

Why is your sample rate input control defaulted to 25k while the indicator "actual sample rate" is defaulted to 2k5? This doesn't fit well together, it seems that you defaulted the values for the elements at different times...... (why defaulting for indicators at all?????)

You have a big, ugly race condition in your code which can explain your issue:

Get rid of it!

There is no need for "Sample Rate" as control in your setup!

Norbert

[Punchy_Cupcakes]

Thank you for the response!

Those are all good suggestions; I removed the local variables, and stacked sequence (Although I have no idea why this would be any worse than the flat sequence), and replaced the sample number variable with a constsnt. 

My hardware does not have enough native memory to hold all 30,000 points, hence the DAQmx Logging VI (and not a for-loop). The second TDMS file is needed because DAQmx Logging does not have an option to write time-stamped data, so this file serves as a time column.

Unfortunitally the problem persists. Any other ideas? I am thoroughly confused.

[Dennis_Knutson]

A TDMS file certainly does log time information. I can't look at your VI but the number of samples should be less than the sample rate and you should be acquiring and logging in a loop. Better would be to use a producer/consumer design where a loop just does the acquisition and passes the data to a queue.

[JÞB]

---

Punchy_Cupcakes wrote:......... I am thoroughly confused.

---

Yes, you are thoroughly confused.

I would rather respond to your instructor. Privately!  Please, have your instructor contact me.  And, ask your schoolmates to stop posting for a small time.  We are volunteers here.  But, your classmates are asking questions any google search could answer.  Your English is much better than my mandarin or cantoneese (My Russian is poor too)

I would like to know what school you all are attending. 

[Punchy_Cupcakes]

So, it turns out that the issue had something to do with the read timeout not being long enough for 3000 samples. However the error message was not displaying because it occurred halfway through the while-loop operation, which then competed printing zeros and finished without displaying an error message. Replacing the while-loop with a for-loop logged one data point ata time and made the read timeout an irrelivant quantity. Thank you to Norbert B for your constructive feedback.

If anyone is interested in seeing the version of the VI that works properly, let me know.

To respond to Dennis Knutson: The number of samples and the sample rate are related quantities, but you cannot compare them directly since they have different units. Good idea with the loop acquisition though; that ended up solving the issue.

To respond to Jeff Bohrer: I am not programming as a student, and have no schoolmates posting. Having my boss contact you would not be productive, as he does not write labview code (This being the reason I was tasked with this in the first place). Please forgive my ineptitude; I am not a programer by trade, only a scientist trying to take data. Thank you for volunteering your time and expertice. It is very much appreciated.

[Dennis_Knutson]

My point was that the number of samples requested should be less than the number of samples on the samples/sec setting. This avoid a large buffer and the ui is actually responsive.

[JÞB]

No harm- no foul!

Sorry punchy.  There has been a rash of recient posts on theses forums lately and I (Incorrectly) guessed you were the standout "English" student amid the crowd.

Of course we are interested in seeing the vi that works!  please, do post it and mark your own solution.  It might help another poster.