Losing data while writing to spreadsheet

[will.nevis]

I've been working on a VI to acquire data from two instruments and write them to a spreadsheet. For this, I wrote two sub-VIs to acquire the data -- one for a scale, and another for a conductivity and temperature meter. Independently, each sub-VI works fine; however, the conductivity meter sometimes writes a 0 value to the spreadsheet in the main VI. I thought it might have been a problem with the sub-VI, so I wrote a little section to catch and eliminate any 0 results it produces (I have it set up to collect an array of results and get the mean to reduce noise). This didn't work and every 5 or so points of data it writes NaN or a strange value. I think there's some data loss in the main VI caused by one of a couple things:

- The response time of the scale is on the order of milliseconds, but the response time of the conductivity meter only sends a signal every 5 seconds. Could this difference cause a loss in data?

- Within the main VI, the scale read sub-VI is set to run a for loop to generate the array within the main VI. On the conductivity sub-VI, I have it set up to run the for loop within the sub-VI. Would this difference cause a loss?

I've attached some photos of the block diagram to help.

Thanks for the help, guys!

[altenbach]

So, what is the question?

(It is difficult to debug pictures. Why don't you attach some real VIs instead?)

[will.nevis]

Sure thing!

My question is why does the main VI print odd values to the spreadsheet when the sub-VIs generate values without issue independently?

[will.nevis]

I've also attached the Scale Read sub-VI here to compare it with the conductivity sub-VI.

[will.nevis · Accepted solution]

I figured it out. By running the for loop inside the sub-VI rather than in the main VI, it was losing some data as it came out (?). In any case, once I set it up similar to the Read Scale VI, everything worked fine. I think, anyway. It might not look like you guys did anything, but forcing myself to put the problems on paper helped out tremendously. Thanks!

[altenbach]

Why are you constantly flushing the IO?

Well, in the lower loop you are doing parallel I/O on a single serial port (COM3). Most likely you get a race condition because the execution order of the two calls varies.

[will.nevis]

Yeah, that's kind of silly. It was originally configured to take data from two different scales -- one increasing, one decreasing. Those are on different serial ports. I just switched it temporarily since our current tests only use one scale and I didn't want to re-write half the VI.

As for flushing the IO, the signals that get sent to the computer by the scale and meter are sometimes a little glitchy -- they'll occasionally read halfway through a signal, and because it comes in ASCII, it can scramble the interpreter I have written. It's just easier to make sure that I have a full string of data to work with. Are there memory benefits to constantly flushing the buffer?