Array data missing with streaming hardware

[ucbecpe]

Hi,

I am trying to extract pressure readings from a serial monitor (manual attached) which prints data at 1s intervals, in the form of time, pressure1, pressure2, pressure3, TransPressure. I can look at this data in a hyperterminal like program seemingly fine, but for other purposes I want to capture this data at a user defined interval.

However my VI (attached) seems to be running into issues getting data. It seems to miss it often, and even returns blank results. The return count seems to fluctuate often, and I get error code 1073676294 often.

The VI works fine in highlight execution, so I assume is reading and clearing the data too fast, but even under a timed structure it seems to miss items.

I'm fairly new to LabVIEW (although I'm immensely enjoying and getting some successful applications albeit a bit spaghettified, but functional at least), so any help would be greatly appreciated.

Thanks.

[Hooovahh]

Congrats on getting started with LabVIEW.  There are a few ways to go about doing what you want, and they will be half guesses without having the hardware in front of me to test with, on which is the best approach.

Crossrulz and others are proponents of using the synchronous VISA reading functionality based on a terminating character.  With this you can tell the VISA API that your message will end with something like the 0x0A byte.  Then when you read you just say to read until that is seen (or timeout) and read those bytes and parse them.  This simplifies your application since you just let LabVIEW and the VISA API handle when the full message is there but relies on your device to send something like a carriage return at the end of a payload.

I'm more of a fan of the poll often method of VISA reading due to the flexibility it gives on when to end.  This can be on multiple bytes, or having specific data.  It also has better scaling when it comes to having something like 16 VISA reads all at once since the synchronous method may serialize reads between devices due to hardware limitations.

If you search the Help >> Find Examples for VISA Sync you should find the Continuous Serial Write and Read.vi for the first and easier method.  I don't have a good example of the continuously polling method but it is basically checking to see how many bytes are at the port, reading that many, then seeing if the message is complete (containing all sensor data) and if not loop back to read more.

[crossrulz · Accepted solution]

---

@Hooovahh wrote:

Crossrulz and others are proponents of using the synchronous VISA reading functionality based on a terminating character.

---

Close.  I do not use the Synchronous option on the VISA Read.  I just use the default Asynchronous setting.  But for ASCII protocols like we have here, I am a fervent believer in the termination character.  It just makes life too easy.

---

@Hooovahh wrote:

I'm more of a fan of the poll often method of VISA reading due to the flexibility it gives on when to end.  This can be on multiple bytes, or having specific data.  It also has better scaling when it comes to having something like 16 VISA reads all at once since the synchronous method may serialize reads between devices due to hardware limitations.

---

You would love to see my "actor" based library I use for terminals (SSH, Telnet, and serial).  Class based, logs all data coming in, able to do searches.

Back to the issue at hand...I would call this a streaming ASCII protocol, so we just need to set up the port before our loop, do the read based on the termination character inside the loop, and close the loop when we are done.

[ucbecpe]

Thank you very much. 

In the solution Crossrulz, does keeping the port set up within the loop partially clears the data coming in? In other applications I had those details contained within the loop, but the reading for that hardware required a command to print, so I never needed to be concerned about it.

What I did add to your suggestion is a flush I/0 buffer within the loop prior to the data read, I noticed that labview was pulling older data reads from the device rather than at the time interval that a user defined. Seems to work fine! Hope it isn't something that may cause grief later on though.