Timing issues associated with reading the serial port when I cannot use LabVIEW to determine how often the data is placed on the serial port

[DanNatCorning]

I am writing an application to capture the data sent from an MKS Pico Helium Detector.  Unlike other pieces of test equipment I've dealt with, I am unable to control this particular instrument through the RS-232 Interface.  I only have the ability to read the data sent from it over the serial cable.  Normally, I would set up the timing for whatever interval I wished to query the instrument, use a VISA write vi to send whatever alphanumeric command is necessary to query the instrument, and then use a VISA Read to read the data received from the instrument.  In this case, I won't be able to use the VISA Write to tell the instrument to send data.  The timing controlling how often it sends data is controlled on the front panel of the mks detector.  SO what issues are there, with respect to timing?  When the instrument sends a value at t0, does that value remain on the port until the next value replaces it n seconds later?  If so, I'm assuming that whenever I start my vi, it will capture the last value sent to the serial port by the instrument.  (I'm also assuming that, as long as I set teh instrument to update at least as often as LabVIEW is reading the port, I should be ok).  Are both/neither/1 of these assumptions correct?   

[WNM]

---

When the instrument sends a value at t0, does that value remain on the port until the next value replaces it n seconds later?  If so, I'm assuming that whenever I start my vi, it will capture the last value sent to the serial port by the instrument.  (I'm also assuming that, as long as I set the instrument to update at least as often as LabVIEW is reading the port, I should be ok).  Are both/neither/1 of these assumptions correct?   

---

I would not expect to find a value waiting at the port from before the time when the port was initialized. It may be possible that the port will be initialized during the time that a reading is coming in. So, if it were me, I'd initialize the port and then dump the port buffer (read/discard until no more characters are available). Then I'd start a somewhat independent, asynchronous port-reading routine that just sat there waiting for a complete (determined by time since first [or even last] character or number of characters or read-termination character) reading to come in. The reading routine could have a timeout associated with it to raise a flag if no complete reading was received in a timely manner. The reading routine would always make the last value read (& possibly a timestamp of when it was received or a sequence number) available to the rest of your code but would otherwise always just sit there waiting for the next reading. I could see doing this with a dynamically loaded VI that communicated with the rest of your code using queues or notifiers. It could also be done using a state machine that periodically checked to see if a complete message were available from the port. I've attached a few LV v7.1.1 VISA VIs that may help. It shouldn't be too hard to develop something that satisfies...

[jasonhill]

If you have the same amount of data on each read, you could check the VISA Bytes at Serial Port and decide if you want to wait for more data.

Quick-ey mockup attached:

[chilly_charly]

Another possibility is to set the serial buffer size to 2 x length of the expected data string. That way, the buffer will always contain a valid string that you can slice to extract the required info, assuming that some delimiter (carriage return ?) can be used to detect the start of the valid data.

This will avoid you the problem of synchronization.

[pawel]

Hi

All the data are kept in the Windows buffer, which is quite big. By using serial read you will only read the buffer and get the data from there.

The best way to see if there is any data in the buffer is to use the serial port node and query the buffer for the number of bytes in it.

You can find many useful examples in the examplefinder in LV.

take care

Pawel