Command interface triggering
A command interface trigger occurs when:
• A GPIB GET command is detected (GPIB only)
• A VXI-11 device_trigger method is invoked (VXI-11 only)
• A *TRG message is received
• A USBTMC TRIGGER message is received (USB only)
Use trigger.EVENT_ID to monitor for command interface triggers. To ensure that commands and
triggers issued over the command interface are processed in the correct order, a trigger event is not
generated until:
• The trigger command is executed
• trigger.wait() retrieves the trigger command from the command queue before it would
normally be executed
Command interface triggering does not generate action overruns. The triggers are processed in the
order that they are received in the 2600B command queue. The 2600B only processes incoming
commands when no commands are running. Unprocessed input triggers can cause an overflow in the
command queue. It is important to make sure a script processes triggers while it is running.
The command queue can fill up with trigger entries if too many *TRG messages are received while a
test script is running, even if the script is processing triggers. You can avoid this by using the
localnode.prompts4882 attribute (see TSP command reference (on page 9-1) for more
information), and by using trigger.wait() calls that remove the *TRG messages from the
command queue. If the command queue fills with too many trigger entries, messages like abort are
not processed.
Trigger generator
The 2600B has two trigger generators that you can use to generate trigger events. Use the
trigger.generator[N].assert()function to directly trigger events from the command interface
or a script (for example, you can trigger a sweep while the instrument is under script control).
The trigger.generator[N].EVENT_ID constant is an identification number that identifies events
generated by this generator. To have another trigger object respond to trigger events generated by
this generator, set the stimulus attribute of the other object to the value of this constant.