95x Series Operating Manual - May 17, 2022
Page
151
of
155
PROGRAM AND RUN A SEQUENCE RATHER THAN INDIVIDUAL STEPS
When setting up and running a test sequence the user is recommended to run it as a sequence in the 95x, rather
than running individual steps one at a time.
The 95x will remember the sequence, even if it is not stored, as long as power is not removed from the 95x. The
user only needs to program the sequence once; it can then be run multiple times as needed. There is no need to
store the sequence into non-volatile memory; although the user may do so if needed (stored sequences are limited
in length to a maximum of 254 steps whereas the interface sequence is limited to a maximum of 999 steps).
The 95x remembers the results of each step performed; the user can extract all of the test results as needed after
completion of the test sequence.
By running a sequence, the 95x can operate at its
own speed, the computer does not have to “keep up” with the
95x.
The recommended flow is as follows
–
•
Send a
NOSEQ
command to ensure there is no active test sequence.
•
Send
ADD,…
commands as needed to program the desired sequence. After each command send the
*ERR?
command to check for any incompatibility between the requested test step operation and the 95x.
The 95x will append each
ADD,…
test step to the active sequence, so the user should send each desired
step in the correct order.
•
Send the
RUN
command. The 95x will now run the sequence.
•
Poll the 95x at intervals to detect completion of the sequence. The selection of the polling interval is up
to the user, for short test sequences this could be as fast as every millisecond, for long sequences perhaps
every 100milliseconds or longer would suffice. Either the
STEP?
or
RUN?
Commands can be used, the
STEP?
command is recommended as it provides more information in the response. If needed, the user
could also program
MEASRSLT?
Command(s) to extract actual measurements during execution of the
sequence. If multiple measurement results are required during execution, the user should send multiple
MEASRSLT?
Commands as a set of commands, the 95x responds with all of the measurement results as a
single set in the same order as requested. In this manner some interface time is saved, and it is
guaranteed that all of the measurement results are consistent in time with each other. When using
asynchronous timed polling the user should be careful as the OS may cause undesired operation
–
o
If the user calls for an asynchronous timed event from the OS which is handled by the user code
sending the query command(s) and fetching the response(s) then command overrun can occur if
polling is too fast. The 95x may slightly delay either the command or the response to beyond the
time interval being used for polling, also the OS itself may delay the transmission or reception. In
some OS’s calls are made regardless of the completion of the preceding call –
so the second call
will cause commands to be transmitted even though the responses from the first call have not
been received yet. The user should use some sort of software interlock to prevent this if needed.
o
This issue does not occur if the user uses synchronous coding
–
i.e., send the query command(s)
–
wait for the response(s)
–
wait for a delay
–
repeat.
•
Once the test sequence has completed (e.g., the response to the
STEP?
command is 0) the user should
request for the test results. There are various methods of achieving this, which the user chooses is
dependent on the level of detail which is needed. The following query commands are recommended
–
o
RSLT?
–
responds with the overall test status, giving overall pass/fail information.
