The Effect of Asynchronous vs Synchronous VISA Write and Read FunctionsPrimary Software: Driver Software>>NI-VISAPrimary Software Version: N/A Primary Software Fixed Version: N/A Secondary Software: Driver Software>>NI-488.2, Driver Software>>NI-VISA
Problem: How does choosing Asynchronous vs Synchronous VISA Write and Read functions affect my application? Solution: Note: In LabVIEW, choosing between Asynchronously vs Synchronously VISA Write and Read functions is done via a right-click on the function itself, whereas in a text-based environment there are separate functions for Asynchronous and Synchronous functions. What do the terms asynchronous and synchronous mean in this context? The term synchronous here is NOT to be confused with its use when defining whether a given hardware connection shares a common clock or timebase. Rather, these terms refer to how the VISA functions behave with respect to their calling threads. More specifically, choosing between asynchronous and synchronous determines when the calling thread which executes a given VISA read or write function is released to allow other code to execute; this is discussed more specifically in the third section below. How do I choose between asynchronous vs synchronous functions in LabVIEW? LabVIEW 8.0 and earlier Right-clicking on a VISA Write or Read VI will yield a menu item; it will state either Do I/O Synchronously or Do I/O Asynchronously (See image below). What you see in the menu at any time is exactly opposite of what is currently applied to the function; selecting, for example, to do I/O synchronously will put the function into that mode (after which you would have the option to switch back to asynchronous by again right clicking and selecting to do I/O asynchronously). Please see the screenshot below for a visual indication of how this is done with a VISA Write function. Setting Asynchronous and Synchronous mode are also set by right-clicking on the VISA Write or Read VI. Go to the sub-menu Synchronous I/O mode. A check mark will appear by the mode that is currently set. See the screenshot below for an example of this setting.
How does choosing Asynchronously vs Synchronously VISA Write and Read functions affect my application? First, it is important to note that for each type of resource, such as a serial port, there is memory from which data is actually transferred to the resource bus; in the case of a serial port, this would be the UART FIFOs. This memory is not the same physical memory as the CPU memory (RAM), which stores data for use in an application running on a given computer. Moreover, in order for an application to communicate with a given resource, data must be transferred back and forth between the resource memory and RAM. In this case, VISA is an intermediate layer which has independent memory for handling data transfers. To understand the distinction between the asynchronous and synchronous VISA Write and Read functions, we need to realize that memory is transferred from the development environment memory (such as LabVIEW), to VISA memory, to the underlying driver memory (VISA calls the OS to determine what fundamental driver exists for the hardware specified by the resource name), to the physical resource memory (such as the UART FIFOs in the case of a serial port). Consider a VISA Write function; the following events occur:
The question now is: "When is the calling thread unlocked?" The answer, as alluded to above, is determined by the choice to perform the Write operation asynchronously or synchronously. If the operation is performed asynchronously, then the calling thread is unlocked between events 2 and 3 above (immediately after VISA receives the data). However, if the operation is performed synchronously, then the calling thread is unlocked between events 4 and 5 (just before the function returns). For the read operation, the situation is similar, where the difference is the direction in which data is being transferred. In this case data is being transferred from the resource hardware to VISA, and choosing between asynchronous and synchronous read operations amounts to choosing between releasing the calling thread before or after, respectively, this transfer is complete. When should I choose to perform my VISA Write and/or Read operations asynchronously vs synchronously? There are two important variables to consider regarding the VISA Write operation: 1. the amount of data being written by the function and 2. the number of threads available to the application in which to schedule operations. Consider the amount of data being written by the function; if a large amount of data is being written (say thousands of bytes to a serial port) then the thread will be locked for the duration of the transfer of those bytes to the hardware driver. If this takes longer than your application can manage without the calling thread, then performing the operation asynchronously can significantly improve overall performance. On the other hand, if your application requires that the data be transmitted as soon as possible to the resource of interest, then performing the operation synchronously will dedicate the calling thread to that duty until VISA has at least transferred the data to the resource's driver memory. Now consider the number of threads available to the application. If this number is small relative to the number of parallel processes required by an application, then choosing to perform a given VISA write operation synchronously may significantly affect performance. The reason for this, of course, is that the calling thread will be locked until the data is transferred from VISA to the hardware driver, which can take longer than is tolerable for other processes requiring the thread (especially if the amount of data is large). Thus choosing to perform the operation asynchronously in this case would be best. As a specific example, the LabVIEW Runtime Engine has 4 threads to use to distribute LabVIEW parallel processes by default. If some of those processes involve VISA write functions, you can select the function as asynchronous in order to release the corresponding thread from exclusively servicing that resource sooner; this will generally yield an overall application performance increase by virtue of making the thread available to other processes sooner. If, however, the you would like a given resource to be serviced as much as possible until completion, and you are not consuming all 4 threads in LabVIEW, then performing a Write operation synchronously will lock the calling thread and be certain to service that resource. Contrastingly, if the number of available threads is large and your desired functionality is not compromised by splitting CPU time across multiple threads (and the corresponding overhead associated with a thread swap), then performing the Write operation synchronously should not have a negative affect on performance. For VISA Read operations the considerations are similar, where if you are receiving large amounts of data, then performing the operation synchronously can lock the thread for relatively long periods of time, which is particularly important if the number of threads that the application has access to is small relative to the number of parallel processes it requires. Related Links: KnowledgeBase 3D9B7L4B: The Affect of UART FIFO Sizes on Serial Application Performance Attachments:
Report Date: 09/10/2004 Last Updated: 09/10/2009 Document ID: 3D9B8E4B |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
