Write to Measurement skipping data

[Engineer_Jim]

I've read and tried a multitude of things, but am still not having success. 

I'm reading 20 channels from a DAQ and then they are written to a spreadsheet using the Write to Measurement Express. They've timestamps. Recording at 10 Hz. Works perfect. 

The issue comes when I grab 18 of those lines, run them through some math (slope-intercept for some, single digit multiplier for others(subVI)). The processed lines don't always get recorded into the spreadsheet with the raw data. 

I've tried adding a case or for loop for just the processed lines, the entire collection, just the WtM. I tried a producer/consumer. All failed.

Bottom line, it would appear that my while loop is not completing everything in the loop before starting the next loop.

Thoughts?

[Bob_Schor]

Sorry, I won't even look at complex code in a PNG.  Attach the VIs, and if there's a Project, go ahead and compress its folder and attach the entire .zip instead.

You almost certainly have an over-loaded critical loop, doing "too much" before exporting the Producer data to its Consumer loop.  It will be much easier to analyze this with VIs instead of pictures.

Bob Schor

P.S. -- sorry to unload on you.  Here's an analogy -- send pictures of 1000 lines of MatLab code instead of sending the .m file ...

[Engineer_Jim]

I'm not going to upload my VI as my boss doesn't approve. 

When I tried the producer/consumer, I strictly passed the raw data from the producer loop into the consumer loop that then did the processing and recording. Producer = DAQread, Consumer=NumberCrunching and Saving to file.

What is shown is exactly in one while loop (no other loops, no prod/cons) which is almost the standard DAQ Example. The one subVI in my png is literally a slope formula (there just happens to be multiple slope formulas the user can select and a multiplier).

To me this code is simple:

In one single While Loop:

1) Use an NI DAQ to read a voltage.

2) Take that voltage and plug it into a formula (y=mx+b, where m and b are provided, voltage = x, producing y).

3) Send both original (x) and result (y) values to the WtM Express.   

4) Repeat in parallel for 9 other channels. 

This maybe looks more complicated because there is one other single digit multiplier and there are a lot of wires. 

In troubleshooting, I gutted this from 20 channels to 2, replaced the subVI with an actual formula (that only pulled from one channel), and it is still the same issue:

- all raw data recorded at the specified 10Hz

- all the data pulled/then processed hick-up'd/skipped in being recorded

Regardless of the Sample Rate:Number of Samples Ratio (changing both), lines of processed data are skipped.

I know one solution, as I'm using Python to call this VI and then do some other things for some other parts of my project, would be to just record this raw data and let Python do all processing, however, my LV should be able to do this.

[RTSLVU · Accepted solution]

DO NOT USE EXPRESS VIs

Express vi's were put in for those three hour LabVIEW sales pitches seminars so they can show you how fast you can "just throw something together", but for serious use they will fail you.

Put all your measurments into a numeric array and use the "Write Delimited Spreadsheet vi".

[Engineer_Jim]

Okay. I'd seen not to use Express in my searches, but it appeared that it was for pre-LV2015 versions(?). My bad (and possibly laziness).

It also seemed like it was all over the place on how people created titles for columns, (large massive VIs and then ones with hardly anything that didn't work as expected) whether they wrote to spreadsheet, text, used \t or , etc. 

I found a couple different examples and collected pieces to put together something that works and that I like. Attached is the gutted version of my main I built to test functionality. I need to correct for the loss of the precision by converting to string, but I can handle that. 

My Python adds new column headings, so I won't need to add 50 column headings, only one to leave an empty row. Update Python a little.

I'm not totally digging this solution in that, with Express, the 10Hz raw data recorded was based on the Sample Rate being at 10Hz and the timestamp claimed it was accurate to the millisecond.  With this solution, it records based on the Wait in the While Loop and the millisecond floats. For this, it is not important about the accuracy of the millisecond. But that my Sample Rate isn't driving my recording frequency??? (I know I can just add a wire and a multiplier from the Sample Rate to the Wait, but something doesn't feel right, sure there are multiple solutions).

Bottom line, I'm not losing 30% of my processed data and it took just a little modifying my VI...this is a win. 

I'll implement the solution on the master version and keep going.

Thank you.

[RavensFan]

Don't use the current time function to get the time.  There is no correlation between when that value was grabbed and when the data was acquired from the DAQ device.  I'm suprised that you are within a millisecond.

The real timing information already exists in the waveform array that is coming from the DAQmx Read.  Just unbundle the waveform components to get the t0 value and also the dt between values.

[Engineer_Jim]

Awesome! I will get that implemented!!