out of sync

[nas1]

I have written a short vi to collect data coming in from a microcontroller connected to a fluorometer.  It sends a very short data string (a number between 0.00 and 5.00 followed by a carriage return and line feed). I expected this to be pretty simple to collect and graph, however my vi gets out of sync and occasionally and instead of reading 3.97 it only gets 97 or .97.   I know the microcontroller is outputting the entire number because I have run it data logging into procomm without any difficulties.  I have worked in labview before but don't work in it enough to be overly proficient.  I am attaching the vi.  Thanks in advance.  This was created in 8.5 but I am working in 2010 now.

This is a section of a file collected by the vi showing the bad data point

3.99
3.99
3.98
3.98
3.98
3.98
3.99
3.98
3.98
3.97
3.96
3.96
3.96
3.96
3.98
3.98
3.98
3.99
3.99
3.99
3.98
3.99
3.99
3.98
3.99
3.99
3.97
3.98
.98
3.97
3.99
3.99
3.99
3.99
3.99
3.99
3.99
4.00
3.99
3.99
3.99
3.99
3.99
3.99
3.99
3.99
3.99
3.99
3.98
3.98
3.98
3.99

[smercurio_fc]

Your problem is that you have the serial port configuration and the flush inside the loop. Those do not belong inside the loop. Initialize and flush before entering the loop, read inside, and then close the serial port when the loop completes. Which will complete correctly once you use an actual control instead of a constant, which creates an infinite loop, right?

You also have no way of knowing you're actually going to have 6 bytes there.  Since you use a CRLF to end the data, configure the serial port to use LF as the termination character (this is actually the default configuration), and then just specify a large value for the VISA Read for the bytes to read (like 20). The VISA Read will end once it sees the LF character.

[nas1]

Smercurio,

Thanks for the quick response but after implementing what I think you suggested, I now have a loop that gets frozen on the initial value.  ie if the microcontroller is outputting 4.01 when the vi is started then I change the output of the controller to 2.5 the loop stays at 4.01.  I guess I missed something.

[smercurio_fc]

The Bytes at Serial Port property node performs no useful function there, so it's superfluous. Are you getting an error out of the VISA Read? You do not have the error wired for it.

How fast is the microP sending out this data?

[aeastet]

Something like this

[nas1]

Smercurio,

There is no error and I removed the bytes at serial port.  It was left over from an earlier version that I forgot to remove, thanks.  You bring up a good point or the output rate.  It outputs at 1 second intevals,  I need to be able to change the rate at which labview samples this, which is why I have a sample rate control built in.  I did a bit of experimenting and it seems as though it was sampling out of the buffer. I moved the flush back inside the loop and this seems to be working for now.  I will let it run overnight to test.  Thanks

[smercurio_fc]

---

@aeastet wrote:

Something like this

---

That won't work correctly if the read rate is slower faster than the rate at which the micro puts out the data, which is why I asked about the rate at which the micro sends out data. With that method you could have something like "3." in the buffer during the first iteration if it just so happens that the read occurs fast enough. During that iteration you'd get 3.00 out of the string conversion, but in the next loop you'd have "98CRLF", so the string conversion would give you 98.

It's also a bit inconsistent to configure for termination characters and use Bytes at Serial Port. If you have a termination character, then that's what should be used, not Bytes at Serial Port.

---

@nas1 wrote:

I moved the flush back inside the loop and this seems to be working for now.

---

This is OK, as long as you are willing to accept lost readings, which is what you are effectively doing if your micro's output rate is fast enough for the serial buffer to fill up with more than one sample before you read it out. When you flush the buffer, anything there will be gone, and you will only get the next reading. In effect, you'd be doing sampling of your micro's output data.

And also do not create infinite loops which require you to use the Abort button on the toolbar. To paraphrase someone's signature, stopping a VI like that is like stopping a car by running into a tree. The car will stop, but there are consequences.

[aeastet]

OK corrected verison.

[smercurio_fc]

OK... Except that's exactly what the same thing the poster coded up in the last version he posted (VISA Configure Serial Port is set up by default to have termination character enabled, and use LF as the termination character). The issue is the rate at which the information is being read out of the serial buffer vs. the rate at which it's being put in. If the two are disparate enough, such as the micro putting the data into the buffer at a faster rate, then it will appear on the LabVIEW side as if nothing is changing since the LabVIEW code is still pulling out "old" data. If the read rate is much faster, then you could get timeouts.

Since the rates can vary, and you it's possible for both scenarios (LabVIEW reads faster than micro, micro sends faster than LabVIEW reads) a more robust approach is to disable termination character for the VISA session, and use a shift register to hold "leftover read data". In the loop, you read whatever is in the buffer using the Bytes at Serial Port, chop off at the last LF found (there's probably a fancy-schmanzy regex for this instead of doing it the hard way), take the stuff before the chop and convert that into an array of values, sending whatever characters are left after the last linefeed into the next iteration to be prepended into the next read. If you got values, then write to file (I'd suggest using the Write to Spreadsheet File since that accepts an array). The chart can accept an array of values. As for the single numeric controls you'd need to decide what to display, like perhaps the last element of the array.

[nas1]

Smercurio_fc,

I am absolutely ok with losing some of the reading it is sampling faster than the response time of the system we are monitoring.  As for using the abort function, I never even considered stopping the vi with a control button on the front panel but I will work on that after I get this issue sorted out. (unless you think it could be triggering this somehow but doubt that.

Well, I was very hopeful that this might solve the problem but unfortunately it hasn't.  I adjusted the sample rate of the vi to 1min for the overnight logging (microp still outputting every 1 second) and have attached the data file.  I will try to get a screenshot to post today as well.  The first 5.00 in the data is corect it was me messing w the fluorometer.  However the following 84 , 5 , blank line , and 5 are erroneous.  I will also attach the current VI.  I really appreciate your help with this.  This community is amazing.