LabVIEW
Serial Port Transmit Delay in LabVIEW
Solved!
@Ben wrote:
The right-click option of the VISA Write "Synchronous I/O Mode" when set to synchronous (I Believe) will force the transmit.
Good info in those posts... but I don't think I quite have it ALL in my head yet 🙂
From what I understand right now, it'll make the function wait for the driver to transmit the data, but it won't actually force the driver to transmit *right now*, correct? For example, if the driver does a write when X characters are available OR x ms from the last write, then it'll timeout every time, and your char delay will be dictated by the driver... I think. If you manually flush the buffer, I suspect it'll force the transmit to happen *now*, and your software controlled timing may work a little more consistently.
I could be totally wrong on this though- I fully admit to not understanding all of the nuances of those old threads!
@Ben wrote:
The right-click option of the VISA Write "Synchronous I/O Mode" when set to synchronous (I Believe) will force the transmit.
That's not quite the meaning of synchronous versus asynchronous nodes in LabVIEW. Synchronous nodes call a C function that will consume the calling thread completely and not allow the LabVIEW diagram to reuse that thread for other work until that function has returned. With asynchronous nodes the node doesn't directly call a low level function and definitely not a blocking function. Instead the function employed by an asynchronous node will do something like what Windows calls overlapped operation. With that there is a function called that will start the operation but return more or less immediately before that function has finished. The rest of the work will be done inside the driver in the background. The code behind the LabVIEW node will go into a wait state (with or without timeout) until the lower level driver signals an event.
VISA itself has for all functions that can potentially take some time to complete such as viRead() and viWrite() also asynchronous variants of those APIs (viReadAsync(), viWriteAsync()).
When the node is set to synchronous, LabVIEW will simply call viRead() which will only return after either the required data has been received, an error occurred or the timeout elapsed. Until then the LabVIEW thread in which this VisaRead is executed is completely blocked. For asynchronous read LabVIEW will call viReadAsync() instead which will return a so called jobID that can then be used by the LabVIEW function to wait with low CPU overhead on the completion of the operation and while doing so, the thread can be reused by LaVIEW to execute other nodes on the diagram.
When LabVIEW was single threaded before 5.0, synchronous operation for VISA nodes was a terrible idea. It monopolized the single thread completely and therefore it would not have been possible to do in parallel anything else. Asynchronous operation was the only way to write applications that needed to do other things while communicatiing with a slow device, such as communicating with more than one such device at the same time. There were certain issues with asynchronous VISA nodes as they could consume some CPU resources while waiting for the completion and in addition since they freed the thread to let LabVIEW do other things, they could let LabVIEW run empty do nothing loops at full speed while the application was apparently busy doing instrument communication. These badly understood issues made many people believe that asynchronous VISA nodes were evil (and the occasional VISA bug didn't help that perception either).
After LabVEW supported multithreading, asynchronous VISA nodes weren't very necessary anymore unless you wanted to do an application that needs to communicate with many different instruments at the same time. The single thread calling a synchronous VISA node will be blocked for the duration of the call, but there are other threads LabVIEW can use to execute parallel code in the diagram.
Asynchronous or synchronous VISA nodes should make no difference about the actual communication with the device. The bytes start to be send out when the function is called and the function returns when all the bytes have been sent or an error occured.
@rolfk wrote:
Asynchronous or synchronous VISA nodes should make no difference about the actual communication with the device. The bytes start to be send out when the function is called and the function returns when all the bytes have been sent or an error occured.
Thanks for that information. Is it guaranteed that a transmit will start *immediately* when a serial write is initiated? I would assume this is a driver and/or OS question, as I would guess some driver/OS's would try to batch data before beginning a transfer.
For example, if you're doing writes over Ethernet, the Nagle algorithm (enabled by default) will wait until you have n bytes ready to transmit, or it's been x seconds since the last write, to avoid unnecessary overhead. I'm wondering if serial ports have this issue, hence my original suggestion to manually flush the buffer. I can't remember if the Nagle algorithm affects VISA ethernet writes or just the TCP write functions- maybe both. I ran into that one trying to do some polling of an ethernet instrument- the query was only a couple bytes, so all of the responses were getting delayed by a half second or more since it was waiting until I had written a bunch of the queries before *actually* sending the data to the device.
There is no such guarantee at least not in a strict timing sense. Windows may let the thread execute or not at its own discretion and that can easily mean a delay for several ms to 100 ms depending on a virus scanner deciding to start working, or a huge network frame arriving etc. etc.
In addition a serial port only can send out data when it is enabled. A hardware handshake line could inhibit it, or an earlier sent XOFF character. Your example of Nagle on TCP/IP is another example that can prevent the data to be send out immediately and that are all things, an application can not control itself (well you can disable the Nagle algorithme on a connection or disable handshaking of course but that is not the solution in most cases).
Nagle is by default on on both TCP refnums as well as VISA TCP connections. For VISA there exists a property to disable it, for TCP refnums there are some VIs around to do that. But Nagle has only a delay of 100 to 200 ms, so a roundtrip can at most be delayed about 400 ms. If it is more you have anoher problem.
