Academic Company Events NI Developer Zone Support Solutions Products & Services Contact NI MyNI

Customer Solutions

IVI State Caching for Groups of Attributes

Author(s):

Ian Dees, Anritsu Company

Industry:

Telecommunications

Product:

LabWindows/CVI

The Challenge:

Write an instrument driver capable of caching the values of multiple attributes that are set by the same command. The driver should avoid sending redundant command strings to the instrument, but must also make sure the instrument always has the correct values.

The Solution:

Using the advanced features of LabWindows/CVI, create shared read and write callback functions, which decide when to send commands to the instrument based on a set of hidden state variables.


Introduction
Anritsu is using LabWindows/CVI to write an Interchangeable Virtual Instruments (IVI) driver for computer-based control of Optical Spectrum Analyzers. One of IVI’s benefits is state caching, through which the driver optimizes performance by remembering the state of the instrument. This feature is difficult to implement for some instrument attributes, which can only be accessed by complex commands that set a group of attributes at once. Anritsu and National Instruments collaborated on an innovative solution, which is able to deliver the performance boost of state caching even in difficult cases when a single command sets many attributes.

Many Attributes Sharing One Command
When a command sets two attributes at once, the Instrument Driver Developers Guide recommends considering one of them to be “dominant” (2-20). When the driver writes the dominant attribute, it picks a reasonable default value for the subordinate one. This method works well for attribute pairs, but larger commands complicate the picture.

Imagine a command that sets five attributes at once. We would have to select a dominant attribute, a “second-place” attribute, a “third-place” attribute, and so forth. For each combination of attributes one through four, we would need to choose a default value for the fifth. The attributes would always have to be set in the same order, lest one default value overwrite another.

National Instruments Driver Support engineer Edward Zhu recommends a new approach: create an integer attribute representing the state of the entire group. This “state attribute” is hidden: the user must not be able to put the driver into an incorrect state. The IVI engine cannot cache this variable, because the write callback must be called every time the state attribute is changed. Both properties are easy to set in LabWindows/CVI.

The state attribute can have one of four values: “1 means no updates (instrument I/O) required and defer all future updates, 2 means future updates required, 3 means update now, and 4 is the do nothing state.” (Zhu) .

To manage the transitions between states, we’ll define three callback routines:

  • The shared read callback is called by the IVI engine whenever a user-level attribute is read. The driversimply has to “do an instrument I/O, parse the data string, and update the cached values of all the attributesaccordingly” (Zhu).
  • The shared write callback is called when an attribute is changed. This function sets the state attribute toinform the driver that the values in memory no longer match those in the instrument (Zhu).
  • The state attribute write callback  is only invoked when our state-cachingcode changes the state attribute. If the driver is in state 3 (i.e., if some attributes have changed), thiscallback sends all the attribute values to the instrument (Zhu)


The state-transition behavior is hidden inside a function the user can call to set all the attributes at once. At thebeginning of this high-level function, we set the state attribute to 1 to hold communications until allattributes have been set. Next, we call the appropriate SetAttribute function on each attribute. At the end of thefunction, we set the state attribute to 3, so that all the attributes will be sent to the instrument (Zhu).

Finishing Touches
We can make writing high-level configuration functions easier by moving the state transition logic into the callbackfunctions. To simplify the process, let’s reexamine the state definitions:


State 1: None of the attributes have been changed (the attributes are “clean”). If any of them change in the near future, don’t send any I/O (the attributes are “locked”).
State 2: At least one attribute has changed (the attributes are “dirty”). The attributes are still locked, so do not send any I/O.
State 3: The attributes are dirty and have just been unlocked. Send the new values to the instrument.
State 4: The attributes are clean and unlocked.

We have replaced the integer state attribute with a pair of Boolean state attributes, Locked and Dirty, both of whichshare the state attribute write callback. Our high-level function (Figure 6) is now simpler: we set Locked to Truebefore changing our attributes. When we’re done, we set Locked to False, and the state attribute write callback
.
In the shared read callback, after we query the instrument, some of the retrieved values may be older than the cached values we’re holding. For each attribute, we call AttributeIsCached to see whether or not its           in-memory value has changed; if the attribute has not changed, we call SetAttribute to update it with the new value from theinstrument. At the end of the shared read callback, a quick check of the “attributeId” parameter tells us which attribute we must return.

Further Improvements
In most cases, the attributes in a group are more diverse than in our five-integer example. Instead of sharing one readcallback and one write callback, the group might share one integer read callback, one integer write callback, one floating-point read callback, and so on. These shared callbacks could call the same implementation function.

Developers who are interested in more complex behavior could easily extend this state-caching scheme. For example, if one attribute’s range depends on another attribute’s value, more sophisticated range checking could be added into the callbacks. Another potential improvement would be to turn off our state-caching scheme when the user wants to disable state caching for the entire driver.

Works Cited
National Instruments. Instrument Driver Developers Guide. Austin: National Instruments Corporation, 1998.Zhu, Edward. [Instrument.Driver@ni.com]. “RE: IVI Question.” Private e-mail message to Ian Dees. [ian.dees@anritsu.com]. 20 October 1999

View the PDF
dees.pdf

View the entire user solution in Adobe Acrobat PDF format.