VectorStar and Lightning VNAs provide synchronization with the GPIB by executing commands in a serial fashion. A new command will not be parsed and executed until the previous command has finished processing. Therefore, the synchronization commands stipulated in IEEE 488.2 (*OPC?, *OPC, and *WAI) execute with ease.
Lightning VNAs provide a very large input buffer that permits storing many commands until they can be executed. The VectorStar VNAs can store very large command strings (a series of characters terminated with a line feed), but only two strings at most. This creates a situation where the GPIB bus can go into Not Ready for Data (NRFD) hold off if the controller sends more than two command strings at a time. NRFD hold off will hold onto the controller until it can store the data byte that is currently being transferred. This hold off merely guarantees that no data byte will be lost from a message. Although some controllers can detect this hold off, it's occurrence is of no consequence and it is how instruments are kept communicating at the same rate on the GPIB.
Some commands may take a very long time to execute, such as waiting for the end of a sweep when the IF bandwidth is very low (1 Hz to 100 Hz). In spite of the long sweep time, the controller should avoid timing out because it creates a situation where synchronization and data can be lost. A controller time-out also leaves the GPIB and the VNA in an unknown I/O state. This unknown I/O state may not be responsive because the proper data handshake has been interrupted, thus creating a hung bus.
In many cases, the GPIB parser will also be busy participating in a long event, such as when the commands TRS;WFS are sent. The parser will not be available until the sweep is finished. The only way to get the parser to stop its current task and start processing new commands is to assert the Interface Clear Line (IFC) and issue a GPIB bus command called Device Clear (DCL). These two commands together brings the parser back to the Ready for Data (RFD) state. The commands also reset the input and output buffers, which results in both input and output data being lost.
Below is a sequence that shows how to apply a time-out properly:
SETTIMEOUT(40000); // Sets a longer time-out for the controller.
OUTPUT ; RST // RST (reset) is a command that can take 30 seconds or longer.
ENTER ; ONP // Outputs the number of points. The actual wait occurs here.
SETTIMEOUT(20000); // Sets the time-out back to its normal value.
Setting the proper time-out on the controller is very important to guarantee that the GPIB will be synchronized and data will not be lost. One should choose a time-out that allows most operations to finish without problems and set the time-out to different values on those commands that require a longer time to execute. If time-outs do occur in program execution, the time-out settings for the particular commands in question should be increased. If a time-out is due to an application error, such as sending a syntax error preceding a query or an impossible state is set up such as being in HOLD and waiting for the end of the sweep, the coding error should be fixed and the time-out setting left as it is. Timing out also leaves the bus in an unknown I/O state, so a DCL should be sent to synchronize handshaking. USB or VXI-11 do not provide an IFC, but they do provide a DCL.