What exactly do all the serial VIs and functions do and when or how should you use them?

[jreesetmi]

Regarding all of the serial VIs and Functions. Here is a link to the documentation.

The following is a list with comments and questions I have after reading the documentation and testing some things out. I also haven't seen this information all in one place before, just small bits here and there.

1. Configure Port
   • Apparently initializes the serial connection as it sets the connection parameters.
   • Using this, I found I didn't need to use VISA Open.
   • Within this VI, all it shows is the properties of the instrument being set so I'm not sure how exactly it's initializing the connection too.
   • How is it initializing the connection? does the act of setting the VISA resource properties initialize the resource?
2. Write
   • No questions on this one, it seems to just write the ascii string to the initialized port.
   • Haven't found any use for return count. When would that be used?
3. Read
   • Attempts to read the number of bytes specified by byte count on the initialized ports input buffer.
     • If it encounters a termination character it'll stop.
     • If it times out per the configured property it'll stop.
     • If there's no data it should stop?
   • I frequently see bytes at port being fed into the Read byte count. I also frequently see people saying not to use bytes at port.
   • The read buffer output is an ascii string, and similar to Write I haven't found a use case for return count.
4. Close
   • I have been closing my serial connections when I am finished, but I noticed many people don't, or maybe they rely on a higher level vi to close the serial connection.
   • What are the best practices there? Does stopping the vi close the serial connection? does closing the vi close the serial connection?
   • I have seen some errors trying to open an already open serial port and closing it fixed it.
5. Bytes at Port
   • Returns the instrument property of the serial connection for "bytes at port" which I understand to be the number of bytes in the input buffer that haven't been read yet.
   • Does reading those bytes set the Bytes at Port back to 0? Is that a valid way to flush the input buffer?
6. Break
   • Not sure what this does/why or when to use it. Apparently just temporarily breaks the connection.
7. Set Buffer Size
   
   • I read somewhere that windows handles the buffer size on the fly anyway and normally you wouldn't need to touch this
   • Is there any reason to change the buffer size?
8. Flush Buffer
   • clears the input or output buffers
   • I've seen some vis that just read the bytes at port and call that "flushing" the input buffer
   • when do you need to flush the buffers? I've seen a lot of vis flushing the buffers immediately after opening.
   • how would the output buffer accumulate anything?
   • What is going on with the mask
     • What is the default mask if unwired?
     • What does it mean "same as 64" or "doesn't perform I/O"? are they the same or are they different somehow?
       • 16 flushes and discards rx buffer (same as 64)
       • 64 flushes and discards rx buffer (doesn't perform I/O to device)
     • ORing all of them would be 1111 0000 but that isn't accepted. Is it because of the redundant masks? Would it make more sense to do 1100 0000 or 0011 0000 to clear both in and out buffers?

There's also synchronous and async I/O mode on the Read and Write vi. When should you use sync vs. async?

Is VISA Clear (from the VISA palette) applicable to serial connections? it seems like it flushes the output buffer, closes and opens or maybe breaks the connection, then flushes the input buffer.

To clarify - I am calling the input buffer the receive or rx buffer, and the output buffer the send or tx buffer. and as mentioned above, these buffers appear to exist on the machine running LabVIEW and are managed by the OS/hardware/device driver.

[Kyle97330]

I'll address some of these.

For any VISA connection, VISA Open usually isn't necessary, BUT it does sometimes save time.  If you don't run it, whatever would happen when you run it is combined into the next read or write or whatever that you do, so it's standard practice to run it at the very start of your program so that the first communication you do won't have an extra delay on it.  On some VISA connections, like over TCP/IP, VISA open will also output an error if it can't establish 2-way communication.  Serial doesn't have any communications happen on open, but it does reserve the device for your LabVIEW program.

VISA close usually is only a requirement if you want to actively allow other programs to start using the device you just used VISA with.  Good practice to always include it, but not a strict requirement.

Bytes at port is dangerous because of timing.  If you use it immediately after sending a query it always has 0 pending bytes, so it's unhelpful.  If you wait until you get some bytes and then read, you don't know for sure if you get the full message... since serial is relatively slow, you might only get 100 bytes out of a 128-byte reply because you checked the byte count too soon.  If you wait a really long time "just to be sure" then you're both wasting time and you still can't be truly sure.

[jreesetmi]

For VISA Open, I found that it will initialize with some default serial port settings. That is fine if you use a property node to set them correctly after opening, which is essentially what the Configure Serial Port vi is doing.

That's a great point about the timing of Bytes at Port. I have a serial device with simple command response serial communication and some responses are a few bytes while some are 100. It takes about 10ms to write the shorter responses, but then around 40ms for the longer ones.

[crossrulz]

1. VISA Configure Serial Port - Yes, use this instead of VISA Open when dealing with serial ports.  I'm fairly certain the port is opened with the first item in the property node inside of the VI.

2. Write - I don't have a good reason for the return count either.  I'm sure somebody out there uses it, or at least used to use it, for something.

              - Be careful when stating ASCII.  The VISA Write sends the data in a string.  That string may be binary data or it could be ASCII encoded data.

3. Read - Short comment, do not use with the Byte At Port.  See link at the bottom of this post for more details.

4. Close - You really should be using this.  Do not trust the automatic garbage collector to clean up the VISA sessions.  I have been burned by that way too many times.

5. Bytes At Port - Only has one legitimate use: to see if any data is available in the receive buffer.  Do not wire this output directly to the VISA Read.

6. Break - Used by some really old instruments.  I have not used any instruments that did need this.  You are not likely to need it.

7. Set Buffer Size - Generally avoid.  The default buffer sizes are almost always good enough.

8. Flush Buffer - Generally avoid.  Can be used to clear out the buffer in rare trouble issues.  If you consistently need this, you are not keeping up with the data being sent from the instrument. 

For further details, go watch this presentation: VIWeek 2020/Proper way to communicate over serial

[JÞB]

First,  thank you! You have posted a great set of questions that demonstrate that you wish to learn more.

As you know, many of the answers depend on exact implementation.   There are choices to be made that we cannot answer without knowing more about the system.  So, I could say... e.g. use Async when PHY layer latency is high but other busses need attention.    Gobbledygook! True Gobbledygook but, a complete nonsense answer.  Of course, that is exactly why so many options are available to the general user.

Let's try another approach.   Give use a specific use case! We can help you choose a specific approach. 

<sea story> I don't know what to do yet....Yes, I did that before....Well, I repaired X by doing Y....I haven't determined that X failed yet....so doing Y might not help...BUT SIR! YOU CANNOT TROUBLESHOOT THE GENERAL CASE! 

Solving for the "GENERAL CASE" is one of those things mathematicians and theoretical physicists do.  (The common psychology prof tries too) academically helpful but, of limited immediate benefit. 

In the real world... we try to get answers to our needs.

What do you need?

[@Tim] return bytes from Write can REALLY help you when Some Other Developer sent a littoral "\n" rather than 0x0A

[Martin_Henz]

good questions. The complete and correct answers are very long - too long for this forum.

my short and incomplete answers:

(I refer to the windows operating system when talking about drivers, API etc.)

1. confugure port

start using the properties also opens the serial port. I don't know why anyone at NI decided that VISA should
work like this. I personally don't like this any always using VISA Open - looks better for me. The undelaying API needs an explicit open.
BTW: Nothing is wrong, if you just use configure serial port.

2. write
There might be a timeout during the write operation. Then you can use return count to find out how much bytes are transmitted. There might be a practical use case for the return count.

3. read
> If there's no data it should stop?
If you wire an empty string input, the VISA read is doing nothing - it returns to your program as fast as possible.

bytes at port can be used to detect that there are any bytes available or to find out that your program is not able to process the data fast enough (bytes at port grows). I don't think that there are any other use cases. It could be useful in some debugging situatiuons (I needed this several times). Beside debugging situations: I needed the number of bytes in the serial port buffer only once in the past 100 or 200 years - I don't remember exacly 🙂

4. close
LabVIEW automatically closes the serial port in some situations. Others may can give you a better answer. Personally I always use VISA Close and I recomment that you always do the same.

5. bytes at port
see above ... (3. read).

6. break

a seial port break sets the level to 0 (= space, = +3 to +15V) for a longer time (longer than a singe character transmission needs). It looks like a broken line and can be deteced by the other side of the connection. Because this is rarely used, some modern devices/drivers are not able to detect this break condition correctly. They incorrectly reporting a framing error or any other error. A lot of VISA driver versions (even the newer versions) have issues with the break condition. The windows operting system API has a nice and correct working function for the break condition, but NI seems to be working without this function.

7. set buffer size
The default buffer sizes are ok for nealy all situations. I used this sometimes to increase the receive buffer size while debugging the communication during a debug session to prevent a receive buffer overflow while in highlight execution mode. There is normally no need to touch this.

8. flush buffer
The NI help description is strange and might be correct or not. There are normally four modes:

(a) Terminates all outstanding overlapped read operations and returns immediately, even if the read operations have not been completed.
(b) Clears the input buffer (if the device driver has one).
(c) Terminates all outstanding overlapped write operations and returns immediately, even if the write operations have not been completed.
(e) Clears the output buffer (if the device driver has one).

I never tested out what NI VISA is really doing.

Anyway: using bytes at port followed by a read operation to flush the receive buffer is always wrong.

flush buffer should also clear any errors while the read operation does not.

Exmaples:
You open the port while the other side is sending bytes to you. This can cause framing errors or any other error condition because the settings might be different (baud rate, parity, data bits) or you receive an incomplete byte. The VISA read does not clean up this error and your program do not work like expected. flush buffer cleans up this error and your program can receive bytes from the serial port.

[Martin_Henz]

in addition to my previous post:

synchronous and async I/O mode:

read this: Choosing Between Synchronous and Asynchronous NI-VISA Functions - NI

VISA Clear: I don't know what VISA Clear is really doing, but my observation matches to yours

[RTSLVU]

It may not directly answer all of your questions but I recommend you watch this video.

VIWeek 2020/Proper way to communicate over serial