What is the difference between doing a VISA read asyncronous vs syncronous?

[Ben]

If I pass a byte count of say 10 to the VISA read configured as syncronous and there are less than that number of bytes waiting at the serial port, Will the node wait until the required number of bytes show?

Support just got done telling me that the whole LV app will hang until that number of bytes have arrived. Is this correct?

The time out is set for 10 seconds and I have disabled the termination character.

These are serial reads.

Ben

[Dan_Mondrik]

Ben:

I noticed you posted this in more than 1 place; I hope you see this reponse.

Your first question is whether the *node* will wait. The answer is yes. If you don't want it to wait, then what you should do is first query the number of bytes available at the port, then pass that value to the VISA Read. That will always return pretty much immediately.

Your next question is whether the *whole LV app* will wait. The answer is no, not usually, so let me explain. If you are running LabVIEW in single-threaded mode, and the VISA Read is synchronous, then yes it will block the entire app. But if LabVIEW is in multi-threaded mode and the VISA Read is synchronous, then only the thread that called that operation will block. If the VISA Read is async
hronous, which it should be by default in LabVIEW 6i (6.0) and higher, then the rest of your application will not block, regardless of whether it is single- or multi-threaded. Only that portion of the diagram which is downstream (ie, has a wire or frame depending on VISA Read completing) will be affected.

Does all this make sense?

Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments

[Ben]

HI Dan,

I was hoping you would answer this question!

So, if I am set for multi-threaded, only the down the down stream code will wait for the read to complete.

Then is there any difference between sync and async when I am running multithreaded?

I am missing what is the distiction between the two modes when I am runnign multi-threaded.

Ben

[Dan_Mondrik]

Ben:

When you are running in multi-threaded mode, the only time you would see a difference between sync and async is if your VI has multiple potentially parallel actions it is performing. In that case, async would allow the other portions of the diagram to continue, whereas sync would not.

If you are writing a VI that you would potentially share with others, and you don't know whether they are running LabVIEW in single- or multi-threaded mode, then I recommend that you always use async I/O.

But if your VI is not doing anything else at that point, and you are always running in multi-threaded mode, then making that call to VISA Read be synchronous is probably more efficient on your system. This is because LabVIEW will make only 1 cal
l to the VISA driver, whereas it will make several (potentially many) calls when using async I/O.

Regardless of whether you choose sync or async I/O, the system resource utilization (amount of memory, CPU usage, etc.) should not differ significantly as long as you have NI-VISA 2.5.2 or higher.

Dan Mondrik

[Ben]

OK I am am getting closer.

If I am multithreaded and
doing reads from two serial ports where the first port has all of the bytes I am requesting ("ready") and
the other port does not have them all yet, and
both reads are set for syncrounous

then if the VISA read from the "ready" port executes first it will get it data and the down stream code for that read function will only hang until the data is fetched. (still running withthe same scenario) The non-Ready port will then execute but because the bytes are not there yet, it will wait. Durring this wait for data on the non-ready port, only my down stream code (of the non-ready) will be not be executed.

Now if everything is the same, but this time the VISA read (syncronous) for the non
-ready port executes first, nothing will happen on either port until the bytes show up on the non-ready port (assuming no time out).

In both of the above cases, the other VI's I have running that services the GUI, rad from the DAQ, and talk to the RT system will NOT be affected by the madness occuring on the serial ports.

Do I have this right?

If this is correct, then it seems that making the VISA read syncronous sounds like it is executing like it is set as non-Reentrant.

Ben

[Dan_Mondrik]

Ben:

I really thought I understood you on the previous emails, but this one has me a little confused.

If the synchronous VISA Read executes on your non-ready port, your VI will block. The VISA Read is a LabVIEW primitive and is therefore reentrant. So if your code that was about to execute on the ready port is in a different VI (or if it's your same VI being executed from another thread and your VI is marked as reentrant) then that VI will also call VISA Read at the same time and that call will execute immediately.

You may have confused the async/sync setting with the reentrant/non-reentrant setting, but they are different. The VISA I/O functions are reentrant regardless of whether they are sync or async. But yo
ur code must be running in multiple threads at the same time for you to notice.

Does this make more sense? Feel free to contact me via email at dan.mondrik@ni.com if you'd prefer to continue this discussion off the DevZone site.

Dan Mondrik

[Ben]

HI Dan,

If you do not mind, I would prefer to keep this thread going on the the D-Exch so I have access to it from the web and to help others.

I think you are right in that I was confused. This is probably do to how I have things set up in my app.

Let's see if I can take a couple of minutes to give you a better idea of how things are set up and see if I have a better idea of how the sync/async setting affects my app.

The app works tightly with a RT app that simulates a complex system. In this project the RT app keeps a number of PID loops closed and deterministicly polls a device on two RS-485 ports. The Windows app. (the part i am questioning) performs 5 major functions. It uses DAQ to monitor 120 channels at 1000 Hz, supports user selctive monitoring of these channels, while also monitoring status messages from the RT system via ethernet, and also collects and displays the responses returned by the device under test to the RS-485 poll requests that were issued by the RT system. It also provides logging, snap-shot, and averaging.

The logging functionality is invoked using a run VI and runs at low priority. Aside from that, no other priority and thread assignment has been done. The rest of the windows app runs a parallel loops inside the main VI. There is a seperate loop for the GUI, snap-shot, DAQ and serial.

The serial loop watches both ports for waiting data by checking the number of bytes at the serial ports. As the app. sits at the moment, the greater of the two waiting byte counts is then used to do two VISA reads, both on the same diagram in parallel. Both of these parallel reads are set as syncronous.

The app. performs its functions well but I have noticed some sluggishness in the the GUI responding to clciks etc. If you just watch the app. and do not touch it, you would never suspect anything odd.

The memory is good and stable. The CPU takes some spikes periodically but consistently runs below about 35% utilization.

With all that having been said I would like to now try to apply what I think you have been telling me to what I am seeing.

CHECK THAT! I may still be confussed. Let me back up.

If the the two syncronous VISA reads are in the same VI they have to be running at the same priority.
Because the two calls are running parallel (i.e. two seperate "error cluster" sequenced strings on the diagram) they CAN run in different threads.
Is this correct?
Can I be certain they run in different threads?

I understand that if they are both in the same thread and the non-ready executes first, the ready will have to wait.

Do I have to wrap the the VISA reads up seperately and set the wrappers to run in different threads?

Do you think the way I am handling the VISA reads has anything to do with the mistereous sluggish-ness?

I am resonably sure it the most recent version of VISA (don't remeber the version off-hand) but the app was developed after I remeber you stating the VISA read hangs the CPU problem was fixed.

I appreciate your patience with my inquiries. You posting answers here and on info-Labview have been very enlightening. Around our office when I mention "VISA Dan" they know I am talking about something that you said.

Enough of that stuff.

What do you think about what is happening with the app?

Gratefull for your answers this far,

Ben

[Dan_Mondrik]

Ben:

This time I had to go talk to the real LabVIEW experts!

Your 2 calls running in parallel on the same VI will be at the same priority. Whether they run on the same thread or different threads is totally up to LabVIEW. The only way for you to control it is to do as you suggest: wrap the VISA reads into 2 separate VI's and put them either at different priorities or in different execution systems. Then LabVIEW will be able to always run them in parallel. (As long as LabVIEW is set in multi-threaded mode, of course.)

But let me reiterate an earlier suggestion here: use async I/O. Not wrappers. That will let your I/O run in parallel and not block anything else LabVIEW needs to do. It will b
e easier and more understandable than wrapping the VISA Read calls. Besides, you take a small performance hit every time you call a sub-VI that changes priorities or execution systems.

The CPU sluggishness may or may not be the result of VISA. The LabVIEW gurus think you might have another VI (which might be your VISA VI) running in the user interface execution system. That could certainly cause the effect you describe. So check each VI's execution system, and don't have them use the user interface system unless you really need to. (And I know I certainly cannot help you determine whether you really need to. That would be a separate post!)

I hope this helps.

Dan Mondrik

[Ben]

Thank you Dan,

This is certainly above and beyond!

I intend to change the VISA reads to async the next time I get my hands on it.

The prioriy issues will be investigated the next time I am on-site because i will have to do a little experimenting to make sure I don't break something while trying to "make it better".

Ben

[JÞB]

Wow, I know this is an old thread! I Just read the Readme for LabVIEW 2011.  I have often been forced to learn a bit of extra detail on when and how the VISA function performance differs between Sync and Async calls.  So- I'm breaking out the duct-tape to wrap my head with- 

• How will updating drivers that used to request Async VISA calls by completed synchronously be affected by this bug fix?
• Will all async calls now complete asynchronously?
• Is an update to the KB The Effect of Asynchronous vs Synchronous VISA Write and Read Functions forthcomming?
• What to watch for (when can I expect a behavior change between Versions?)