Most message-based instrument communication is just a series of simple synchronous writes or queries to your instrument. However, by understanding instrument status registers and using service requests and polling techniques, you can improve the robustness of your instrument control applications.
This application note describes situations and solutions that use instrument status registers with service request or polling techniques to handle situations where simple VISA write and read operations are not sufficient for robust instrument control.
The shipping example Simple Serial.vi can be found in LabVIEW Help Find Examples Hardware Input and Output Serial. Make sure to set the Serial Settings to match the instrument’s requirements. Refer to your device’s user manual if needed. If you experience communication issues with the shipping example, contact NI Support.
This application note uses the VISA application programming interface (API) in LabVIEW to show the application-side control mechanism for asynchronous communication. Furthermore, it assumes you are familiar with using the VISA Read and VISA Write operations as well as the VISA property node to set or get commonly used properties, such as Timeout. While this application note uses VISA, many of the concepts also apply to instrument control applications that use other APIs, such as the traditional NI-488 and VXI interfaces. Additional references noted at the end of this document use these other APIs.
This application note focuses on IEEE 488.2-compliant instruments that are compatible with service requests and serial polls, which includes the majority of instruments that use one of the following VISA resource classes: GPIB INSTR, USB INSTR, or TCPIP INSTR. While many of the concepts described in this document apply to other buses, the exact behavior of VISA and the instrument might differ.
This application note describes the instrument status registers, which are used to set up the instrument for asynchronous communication. Because many instrument status registers are unique to a given instrument, this application note focuses on the core registers used in IEEE 488.2-compliant instruments and briefly describes other types of instrument status registers.
Examples
This application note references several accompanying examples. All of these examples are in the Status Registers and Service Requests.llb. The examples that include 'learn' in the name are designed for interactive instruction. The block diagrams of these 'learn' examples typically use low-level VISA commands. The examples that include 'program' in the name are designed to learn from the programmatic implementation. The block diagrams of these 'program' examples often include utility VIs that you can reuse in your applications. These utility VIs are also in Status Registers and Service Requests.llb. View VI Tree.vi to see all the examples and utility VIs.
Need for Advanced Instrument Control Techniques
For most message-based instrument communication, synchronous writes and queries are sufficient for robust instrument control. The diagram in Figure 1 shows how the VISA API can perform a DMM voltage configuration and measurement.
In this simple example, the instrument is instructed to take a single measurement. The instrument can respond immediately to the commands and process each command quickly so there is no apparent delay in reading the measurement response.
While this simple write-read model is sufficient for most instrument control use cases, you can quickly run into situations where you need more control over the timing of instrument operations. Consider a situation where you want to control a DMM to take a multipoint measurement of 500 readings. Such an operation may require several minutes for the instrument to obtain the data. Instead of performing the read operation immediately after the write operation, a better solution is to ensure that data is available before reading. With IEEE 488.2-compliant instruments, there are commonly used techniques to ensure that the data is available before reading. Before we investigate solutions, we will first identify and categorize the types of situations where more sophisticated communication is needed.
Categories of Instrument Control Situations
Although thousands of instruments perform a variety of different measurement and stimulus operations, there is commonality in the types of instrument control operations you perform. Therefore, it is convenient to categorize the situations so that you can identify the solutions that address your particular need. For example, the multipoint measurement scenario described previously is an example of query synchronization. This application note defines the following categories of instrument control operations:
Query Synchronization
Query synchronization is when you want to ensure that the instrument response is ready to be read before retrieving the data from the instrument output buffer. Query synchronization involves first sending a query command to your instrument. For example, you might send the command FETCH? to retrieve data. You then want to be notified that the data is available in the instrument output buffer before attempting to read the data from the instrument. Typically, query synchronization is used when the response from the instrument is not immediate. Below is a list of common situations where you might need query synchronization:
Although you can use query synchronization in situations where the instrument response is immediate and deterministic, it often adds complexity to your instrument control application. For example, because instruments typically can respond immediately to an identification query, *IDN?, you would not need to implement special query synchronization techniques. In this case, a simple write-read operation would minimize code while ensuring sufficient robustness.
Command Synchronization
Command synchronization ensures the completion of one instrument operation before the start of a second operation. Typically, command synchronization is used when the result of the second operation depends on the completion of the first operation. For example, to instruct an oscilloscope to perform an autosetup routine followed by a query for the waveform data, ensure that the autosetup routine is completed before retrieving the waveform data.
Below are common situations where you might need command synchronization:
Some instruments process commands synchronously as they are received. In these cases, no special command synchronization is necessary because the instrument itself ensures synchronization. However, to more efficiently process commands, many high-performance instruments can process commands in parallel. If your commands are not dependent on each other, no special command synchronization is necessary. For example, setting oscilloscope horizontal settings can generally be performed in parallel with setting the vertical settings. Instrument Error Handling
Instrument error handling notifies you of an instrument error. You can successfully send and receive data from the instrument without realizing that an instrument error occurred. For example, a command error is an error that occurs while the instrument is parsing a command or query.
Watching and Responding to Events
Watching and responding to events is the catch-all for handling various instrument events whose condition is set in one of the event registers. All IEEE 488.2-compliant instruments can watch for and respond to standard events such as instrument error conditions. However, many instruments also have instrument-specific status registers with which you can respond to measurement-specific events. For example, when using a DMM, you might want to be notified when a voltage overload condition occurs. On an oscilloscope, you might want to be notified when a trigger event occurs.
Note: Command and query synchronization are special examples of watching and responding to events. With command synchronization, you respond to the operation complete event. With query synchronization, you respond to the message available event. With instrument error handling, you respond to error events in the Standard Event Status Register. Similarly, depending on the situation, you can choose one of multiple approaches to respond to the event.
Programmatic Approaches to Accessing Instrument Status
Just as we categorized the instrument control situations, it is convenient to categorize the different types of programmatic approaches you can use to handle the various situations. This application note defines the following programmatic approaches to handling the instrument control situations defined earlier:
The general concept of each technique described below. The specifics of using each approach in LabVIEW are described later in the Programmatic Approaches section.
Long Timeout
When waiting for the instrument to respond with data, you can often get away with just setting a long timeout for your read operation. This approach is simple to conceptualize and implement. However, it is only applicable for query synchronization, where you are waiting for data to become available. It is not applicable for command synchronization or checking for instrument events, such as error conditions.
Serial Poll
Serial poll is a special bus operation where the instrument controller obtains the status byte register value. This is accomplished without sending a message command to the instrument. Besides being more efficient than an instrument query, you can also use a serial poll while an instrument query is pending.
Note: A serial poll returns only the contents of the status byte register. However, because the status byte register is a summary of other registers, you can use enable registers to monitor other desired instrument events.
A serial poll is not compatible with all bus interfaces. However, the VISA Read STB could still be a valid operation with some serial instruments. If the VISA IO Protocol property is set to Serial-TCPIP/488, the query *STB?n is sent to the instrument to retrieve the status byte.
Service Request
A service request is a mechanism that enables an instrument to asynchronously notify the host computer or controller. Use enable registers to determine which instrument events assert a service request.
Query Status
The query status approach is nothing more than sending query commands to the instrument to read the instrument status registers.
Note: You should query the status of an instrument only when no other queries are pending. Sending a status query to an instrument before reading the response to an existing query results in a query error. To check the status of an instrument after sending an instrument query, you should use the serial poll or service request event handling.
1. Loopback Test to Verify Hardware Operation
There are three ways to verify the operation of the serial port: LabVIEW, HyperTerminal, and LabWindows/CVI. All perform a loopback test on the serial port by shorting out the Transfer and Receive pins on the cable connected to that port. Step 1 is the description for shorting the pins and is the first step to all three. The LabVIEW procedure is listed below, and both the HyperTerminal and LabWindows/CVI procedures are linked at the end of the page. Use the following procedure if you are using LabVIEW.
Most problems are in the program, not the hardware. Always use example programs as a reference point for ways to wire the diagram panel. Use the sample VIs shipped with LabVIEW under Help>>Search Examples or from the VIs located in the Examples Program Database linked at the end of the page.
Port Referencing: In LabVIEW, ports are numbered starting at zero. Therefore, port 0 in LabVIEW is COM 1 on a PC. [PC: 0 = COM1, 1= COM2,... Mac: 0 = Modem, 1 = Printer,... Sun: 0 = ttya, 1 = ttyb,...] Timing In Program, Hanging: Many times, a read operation is performed on a port that results in the Serial Port Read VI stopping and waiting or 'hanging.' One way this can happen is if a read operation is done to the port and the program specifies a certain number of bytes that the Serial Port Read VI should get. The Serial Port Read VI was told to get a designated number of bytes; if there are not that many bytes in the serial port receive buffer, it waits until more bytes are written to the serial port. If no more bytes are written to the serial port to complete the operation, the program hangs and waits indefinitely. This can be eliminated by using the Serial Read with TimeOut VI in Help>>Search Examples>>Serial Communication. Another method is to use the Bytes At Serial Port VI to check the port and see how many bytes are in the buffer. Wiring the result as the input for the number of bytes to read ensures that the read operation completes. Looking at the examples under serial communication in LabVIEW is an excellent starting point. Timing In Program, Incomplete Transfer: A common problem is when a read operation is done on the serial port and it does not get the complete string of information expected. This may happen when you have a read operation happening before the write operation has time to complete. This could be resolved by using a Sequence structure or by using data flow dependency. Using a Sequence structure with the read after the write will make sure the data is completely written first. Using data flow requires a wire to be connected to the read VI after (downstream) the initial write VI. Instrument's Termination Character: Serial communication can be very tricky when trying to communicate with devices, because the serial port will output exactly as programmed. This means you must know and program the exact sequence of code, including termination characters, to ensure the instrument operates properly. Common problems occur in not using the termination character required by the instrument or by leaving an extra space/character in the instruction string. There is a new standard for communicating with devices in LabVIEW called Virtual Instrument Software Architecture (VISA), a single interface library for controlling VXI, GPIB, RS-232, and other types of instruments. If you are having problems with serial I/O, VISA is a great way to help eliminate termination character errors and make your code reusable and interchangeable between devices in the future. 3. Virtual Instrument Software Architecture (VISA)VISA is a single interface library for controlling VXI, GPIB, RS-232, and other types of instruments on all LabVIEW platforms. VISA is a standard endorsed by the VXIplug&play Systems Alliance, which includes more than 35 of the largest instrumentation companies in the industry. The VISA standard unifies the industry to make software interpretable and reusable over time and regardless of instrument I/O operation. Linked below is a page to help with VISA questions. VISA VIs for LabVIEW 4.x are linked at the end of the page. See Also: 4. Printing Reports & Error 37LabVIEW 5.1 for Windows includes Report Generation VIs that allow you to send text to the printer. For an example of how to use the Report Generation VIs, select Help>>Search Examples>>Advanced>>Report Generation. For printing with serial communication and earlier versions of LabVIEW, see the link below. If the printer is connected to a local parallel port as LPT1 (or LPT2, etc.), you can use the Serial Port Write VI. For more information, see the Serial Port VIs chapter in your LabVIEW documentation. If the printer is a network printer, you cannot use the Serial Port Write VI; you must use other methods to print, such as one of the following:
For problems with Error 37, follow the link below to check the settings in the labview.ini file.
See Also: 5. Modem Communication in LabVIEWCompanies in the Alliance Program support modem communication in LabVIEW very well. National Instruments recommends these companies because of their quality work. See Also: 6. User Support NewsgroupsThe Developer Exchange newsgroups are Usenet newsgroups covering National Instruments products, as well as general fields of science and engineering. You can read, search, and post to the newsgroups to share solutions and find additional support from other users. Past questions and solutions are also stored at this site for search purposes. 7. Advanced Troubleshooting of COM Port DataAdvanced users who want to analyze the exact bits being transferred over the serial port to detect differences between programs (for example, LabVIEW vs. HyperTerminal) can use a program called Portmon. System Internals provides Portmon, and the company's Web site provides you advanced utilities, technical information, and source code related to Windows 9x and Windows NT/2K internals. See Also: Related Links: Testing Serial Communication using HyperTerminal Testing Serial Communication using CVI Loopback Test for Serial Port Using the VISA classes in Measurement Studio to Perform Serial Communication Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2022
Categories |