LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bytes at Port Property Node. When to use it and when not?

Solved!
Go to solution
0 Kudos
Message 11 of 46
(2,740 Views)

@mcduff wrote:

I am most likely doing thing wrong as I typically always use the Bytes at port property. I have used too many serial instruments that do not follow procotol. For example, one gave a multiline response at times with the termination character in between lines, others have had multiple termination characters. I found the bytes at port handles the odd corner cases better than the standard read until termination character.

 

The snippet shows what I usually use. But now I am a bit worried as it goes against the knights' advice.

 

Cheers,

mcduff

 Snippet.png


It may work for you but I don't see how this could be very robust. The first loop simply waits until there is at least one byte in the buffer and that number is equal to the previous one or the timeout occurs and then it goes on to read the number of bytes you have determined in such a way. It simply assumes that the device never will delay its data in any way for more than 50ms until it has finished sending the entire message. It could stop midstream for 50 ms and your entire logic goes havoc. I definitely wouldn't use it blindly with any new instrument before I made sure that it is fast enough to never delay sending data midstream.

Rolf Kalbermatter
My Blog
Message 12 of 46
(2,730 Views)

@rolfk

 

Thanks for your insight.

 

I agree with what you said. However, for some of the instruments that I need to use, I do not have a better solution. These are the edge cases:

  1. Binary data stream, the number may have a termination character in the binary stream.
  2. Instruments give "multiline responses", ie, if the termination character is \n, a response may have multiple \n.

For 1, I can always switch and turn off the termination character, than after the byte stream turn it on, for 2, I guess, I can have mutliple reads for queries that I know produce mutliple lines.

 

I am not crazy about the fixes. Smiley Frustrated

0 Kudos
Message 13 of 46
(2,729 Views)

@mcduff wrote:

@rolfk

 

Thanks for your insight.

 

I agree with what you said. However, for some of the instruments that I need to use, I do not have a better solution. These are the edge cases:

  1. Binary data stream, the number may have a termination character in the binary stream.
  2. Instruments give "multiline responses", ie, if the termination character is \n, a response may have multiple \n.

For 1, I can always switch and turn off the termination character, than after the byte stream turn it on, for 2, I guess, I can have mutliple reads for queries that I know produce mutliple lines.

 

I am not crazy about the fixes. Smiley Frustrated


I have never seen an instrument that uses both Binary and ASCII unless there is a specific command for switching.  99% of the binary stream instruments have a very strict protocol, typically containing a start byte, command code, length, data, and checksum.  So for those, use the protocol (read a byte until you find the start byte, then read the command code and/or length, read that many more bytes for the data, read the checksum and verify).  As previously stated for the multiline ASCII, just do a read for as many lines as you expect.  Making a generic VI to handle all of these situations is just adding  complications and inefficiencies.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 14 of 46
(2,710 Views)

I have never seen an instrument that uses both Binary and ASCII unless there is a specific command for switching.

 

For example, oscilloscopes that have a serial port. (There are some at my work, surprisingly, but they are a dying breed) Commands & responses in ASCII but want the raw data in bytes, otherwise an ASCII data stream is really slow.

 

But point taken, will look into changing my go to IO VI.

 

mcduff

0 Kudos
Message 15 of 46
(2,703 Views)

I have used bytes at port for almost all my RS232 comms, usualy reading inspection devices, micrometers etc.

I will write the command to the device and then monitor the bytes at port unitl it is equal to or greater then the reponse I expect, then I can trigger the read with the same number of bytes, so nothing gets left behind. If I try to read 1 byte more than is at the port it produces an error. It is easily cleared but prefer not to have it.

 

This method means I am not relying on delays and I can read the data as soon as it is ready. If the exact length of the data to read is not constant then I look to see if the number of bytes has increased since the last iteration, if it has stopped changing then it is ready to be read. Usually I look for the number of bytes to be the same for a few iterations in case the device stalls for a few moments and check the result is fully formatted to avoid collecting wrong readings. This method is not as smooth but gets the job done.

 

If I put the write command in a case structure that is set to true by the read command then I can get a stream of readings as fast as the equipment can manage and it copes with any inconsistancies in response times without giving false/incomplete readings. I sometimes use this stream of readings to animate a graphic of the device on screen while the operator is using it.

 

I have attached a crude vi to show how I use it. It does not have any timeout mechanism if the device does not respond, it is crude but just to illustrate my use of bytes at port.

0 Kudos
Message 16 of 46
(1,813 Views)

A lot of work for something that VISA Read does automatically for you. If you know the number of bytes to read already, use that. VISA Read returns as soon as that many bytes are available, your polling of bytes at serial port never will be able to react faster! If the device uses variable sized responses it should also append a specific termination character to each message such as <CR> carriage return. Enable the termination mode for the VISA session and set the according character (the VISA Serial Port Init function defaults to enabling the carriage return termination character already) and you can again simply use a VISA Read, this time with more characters to read than the longest possible response can be.

If your device uses variable sized messages without a fixed size header and no termination character, you should grab a flogger and flog the manufacturer of it. They created a worthless device no matter how precious its measurement techniques are! But I only know such devices from hearsay, usually from people defending the use of Bytes at Serial port. 🙂

Rolf Kalbermatter
My Blog
0 Kudos
Message 17 of 46
(1,801 Views)

Since this thread has been brought back from the dead I might as well add some useful information:

 

Please watch this video for a very good explanation of when and where to use "Bytes at Port" (very few places) and where not to use it. (most places)

 

VIWeek 2020/Proper way to communicate over serial

========================
=== Engineer Ambiguously ===
========================
Message 18 of 46
(1,794 Views)

@mcduff wrote:

 

For example, oscilloscopes that have a serial port. (There are some at my work, surprisingly, but they are a dying breed) Commands & responses in ASCII but want the raw data in bytes, otherwise an ASCII data stream is really slow.


Many oscilloscopes I have used had that even if they had no serial port. The way it usually works is that they have a command with which you set the data stream format (ASCII comma separated data or binary data bytes). Then the according measurement read responds in that format. You set the format and send the command to respond, so you know the format that it will respond in. If that is binary, disable the termination character for VISA, read the header that says how much data will follow, this is usually in hex ASCII numbers, convert that to the number of bytes (the instrument header may indicate the number of samples and/or that there are multiple channels), then read as many bytes with VISA Read and after that enable the termination character again. Don’t make the error to wire the error cluster from the VISA Read to the property enable node, you always want to switch back to termination mode, even if VISA Read failed.

Rolf Kalbermatter
My Blog
0 Kudos
Message 19 of 46
(1,774 Views)

More useful information:

 

Never discuss politics, religion, or "Bytes at Port". 😀

Message 20 of 46
(1,767 Views)