multiple, parallel, asynchronous, continuous Serial VISA reads

[lmd2]

We need to read up to 32 serial ports in parallel; asynchronous 16 bytes/port, continuously. This can not be done with the old NI Serial Port Initialize/Read VIs as they are full of globals and can not be run reentrantly. We have been trying to implement the reads using VISA.

We have succeeded in reading various ports singularly. That is where our success ends.

The posts on the developer zone suggest that many people are having many difficulties with VISA, and I have not found an example implementing parallel reads.

To start with, I have these questions:



- NI Spy lists an attribute which checks "the bytes available at the global buffer". Is there a single global buffer, or one per VISA reso
urce?

- Why does VISA always return a warning [1073676294 ] when reading normally on a single port? We are requesting 16 bytes, and reading 16 bytes, why the warning?

- Why do two ports read independently BUT NOT in Parallel?

- Why do the bytes at a given serial port run away after another port times out when trying to read in parallel? (When trying to initiate a read on ASRL1::INSTR and ASRL8::INSTR, com port 8 times out and the apparent bytes available on com port 1 seem to back up, climbing into the many hundreds).

- Can we force the parallel reads to each run on a different thread (NI Spy says that the multiple calls are running on the same thread even though multithreading is enabled)?
- What EXACTLY does "allow undefined names" mean? Should this be selected or not?

- With regard to VISA CLASS, should we be using Serial INSTR? Or the default generic INSTR?



And is there an example of an implementation using parallel asynchronous [continuous] reads? Is this ev
en doable?

[Dan_Mondrik]

You ask a lot of good questions, and I'll try my best to answer them.

You should be able to run multiple VISA Read operations in parallel when they are using different VISA resources. This should work fine with LabVIEW 6.0.2 and higher, and NI-VISA 2.6 and higher. We have seen them work fine in parallel, as long as you ensure each VISA Read icon is set to be run asynchronously (you can right-click the icon and specify synchronous or asynchronous behavior). If they are synchronous, then that is the reason you are not seeing the parallel behavior you desire.

The bytes available are counted per Serial port, which is the same thing as per VISA resource. Each buffer is maintained by the OS, not by VISA. Querying a given buffer and reading from it does not affect any other buffer, even on error conditions like timeout, unless you've encountered an OS bug. But I doubt that.

The status code you are seeing, 3FFF0006, is technically a "success code" and not really a warning. We have modified the description for that status in the upcoming version of NI-VISA to say this: "The number of bytes transferred is equal to the requested input count. More data may be available." In other words, the read operation did not terminate early because of a termchar, so it doesn't know whether you're really done.

You cannot currently force the execution thread of each VISA call unless you put it into a separate VI with the VI set to run in a specific execution system with a specific priority. If they are all on the same diagram, it is up to LabVIEW to decide where to execute each call and in what order to do so. That is a current LabVIEW limitation.

Whether you enable "undefined names" specifies whether you want to let a user type in a resource that they know about, even if it is not currently configured in NI-VISA and/or MAX. For example, they could type in an ENET-Serial address if they wanted to use it (for example, "ASRL::my-enet-box-ip-address::2::INSTR"). The option is currently selected by default, so unless you want to restrict the user to using just the ports that NI-VISA can automatically detect on the machine on which it is running, then it is best to leave that option checked.

The class is purely a compile-time check. The Instr class works with almost all functions. If you know that you are using only Serial, then it makes sense to make the class Serial Instr. However, the current version of LabVIEW has some VIs that are not polymorphic (that will be fixed), so you may end up with a broken wire if you use Serial Instr.

If you continue to experience problems, feel free to post your own VI. All you should need to do is have 32 VISA Read operations on the block diagram with no data dependencies between them, and LabVIEW and VISA ought to perform as you expect. If not, then please be sure to specify your OS and the version of LabVIEW and NI-VISA.

Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments