Convert an NI-VXI API program to NI-VISA

For many applications controlling VXI devices, the biggest difference between a program using the NI-VXI API and one using NI-VISA is in the calls made at the beginning and the end. The most significant differences between the two APIs affect programs that route and handle events such as VXI triggers, interrupts, and signals. This topic first discusses the basic changes common to any NI-VXI API program, then discusses some of the specifics for register-based and event-handling programs.

One good resource for converting NI-VXI API programs to NI-VISA is the NI-VXI help, which includes a section about each group of VXI operations, sorted by functionality. (For example, one section discusses high-level register-based programming.) At the beginning of each group overview is a table listing the NI-VXI API and NI-VISA functions associated with that group's operations. You can use the table to match any NI-VXI API function with its NI-VISA equivalent.

Starting Your Application

Typically, an NI-VXI API program calls InitVXIlibrary() to begin the program, and then perhaps FindDevLA() to get the logical address of a specific device to begin communication. In NI-VISA, a program calls viOpenDefaultRM() to initialize NI-VISA, then viFindRsrc() to find the device and viOpen() to get a handle to it.

Performing VXI I/O

For a message-based VXI device, the calls to read and write blocks of data, as well as other message-based communications, have a simple mapping between NI-VXI and NI-VISA: WSwrt() becomes viWrite(), WSrd() becomes viRead(), etc. For Word Serial Servant functionality, use the SERVANT resource in NI-VISA.

Likewise, register-based I/O is performed using NI-VISA functions that are very similar to their NI-VXI API counterparts: viInX() instead of VXIin(), viMoveX() instead of VXImove(), etc. In general, NI-VISA attributes control access parameters from the NI-VXI API. Note also that a VISA session to a given device provides automatic offsets and bounds checking: If you require absolute addressing, use a session to the VISA MEMACC resource. Low-level register-based I/O operations such as MapVXIAddress() and VXIpeek() are also provided in VISA, with corresponding functions like viMapAddress() and viPeekX(). In NI-VISA, only one mapped region is allowed per session; open multiple sessions to a given device to map multiple regions for low-level access.

Asserting and Handling Events

NI-VISA provides operations such as viAssertIntrSignal(), viAssertTrigger(), etc. to support the same functionality offered by AssertVXIint(), SrcTrig(), etc. in the NI-VXI API. These functions may use a VISA attribute to replace a feature provided by a parameter of the corresponding NI-VXI API operation.

The difference between the NI-VISA API and the NI-VXI API is most noticeable when programming to handle events such as VXI interrupts, signals, and triggers. The functions to enable and disable events are quite similar: NI-VISA provides viEnableEvent() and viDisableEvent() to correspond to the NI-VXI APIs proliferation of Enable...()/ Disable() functions such as EnableSignalInt(), etc.

You can use both APIs to receive events asynchronously with a handler (also known as a callback) or to put the event into a queue. In NI-VISA, viInstallHandler() and the VI_HNDLR mechanism for viEnableEvent() indicate that a callback should be used, versus VI_QUEUE for queued events. This corresponds to the NI-VXI API list of Set...Handler() functions such as SetVXIintHandler(), etc., and the RouteSignal() function, which allows signals to be routed to a queue. Retrieving events from a queue is very similar: viWaitOnEvent() replaces WaitForSignal() and related functions.

You can also use both APIs to handle VXI interrupts and signals together, with NI-VISA providing the VI_EVENT_VXI_SIGP event type (which combines interrupts and signals) and NI-VXI providing the RouteVXIint() operation.

Closing Your Application

At the end of the application, use viClose() to close the handle to device, and viClose() again on the default resource manager session to shut down NI-VISA, instead of CloseVXIlibrary().

In summary, using NI-VISA instead of the NI-VXI API to control VXI devices will seem very natural for most applications. Although porting the code from NI-VXI to NI-VISA is not always completely straightforward, the easier and more powerful API and VISA's ability to provide compatibility across interfaces should be worth the change.

Note  Some functionality, such as 48-bit Extended Word Serial protocol commands and SEMI-SYNC triggers, is available only in the NI-VXI API. If you require this functionality in your VISA program, contact National Instruments. We would like to hear more about your application and help you find a VISA-oriented solution.