Contact us

Live Chat with Tek representatives. Available 6:00 AM - 4:30 PM

Call

Call us at

Available 6:00 AM – 5:00 PM (PST) Business Days

Download

Download Manuals, Datasheets, Software and more:

DOWNLOAD TYPE
MODEL or KEYWORD

Feedback

What is the sequence of steps for event handling in Tektronix oscilloscopes?

Question :

What is the sequence of steps for event handling in Tektronix oscilloscopes?

Answer :

Event Handling Sequence

faq1

Figure 1 Event Handling Sequence

Device Event Status Enable Register (DESER)

First off is the Device Event Status Enable Register (DESER).  This is a read/write register where you can determine which events will pass through the mask to the next step.  You can write the mask using DESE and read the mask setting using DESE?  Refer to Table I for the register contents.  By sending DESE 128, the only event that will pass through this register would be the PON event showing that the scope powered up or completed its diagnostic tests.  Sending DESE 0 won’t let any events pass through to the next step.



Bit Number

Decimal ValueSymbolFunction
7 (MSB)128PONPower On.  Shows that the scope was powered up or that the diagnostic tests completed.
664URQUser Request.  Shows that an application event happened, which could be a front-panel key press.
532CMECommand Error.  Shows that an error occurred when the scope received a command or query.  Usually related to a syntax error in the user software.
416EXEExecution Error.  Shows that an error occurred when the scope was processing a command or query.  Related to a hardware or configuration problem.
38DDEDevice-Dependent Error.  Usually related to a firmware or diagnostic problem.
24QYEQuery error.  Shows that either an attempt was made to read the output queue when no message was present, or a message in the output queue was lost.
12RQCRequest Control.  Not used.
0 (LSB)1OPCOperation Complete.  Shows that all pending operations have completed following a *OPC command.  Used to synchronize the controller with the scope acquisition process.

Table I

Device Event Status Enable Register (DESER) Contents

Standard Event Status Register (SESR)

Next up is the Standard Event Status Register (SESR).  Note that the word ‘Enable’ doesn’t show up in the name, so this is not a writable register.  It’s a read-only register that’s read by using our old friend *ESR?  The bits have the same definitions as the DESER register that we just covered.  The idea is that any events that make it through the DESER will be stored in the SESR so they can be read.  Remember that the *ESR? query reads the register status, clears all the bits and lets pending events flow into the event queue.  If the response to an *ESR? query was 1 (i.e. binary %0000001) that would show that the Operation Complete bit was set, indicating that all pending operations had completed.  Similarly, a response of 48 (i.e. binary %00110000) would indicate that a Command Error (bit 5) and an Execution Error (bit 4) had occurred.  Then you would read the events in the event queue to find out more detail on exactly what the problem was.


Event Status Enable Register (ESER)

Those events that made it this far pass into the Event Status Enable Register (ESER) where we have another chance to mask the bits off.    Why do we need another chance to set a mask?  The first register (DESER) determines those events that get put into the event queue.  This register (ESER) will determine those events that generate a Service Request (SRQ) which will interrupt the controller.   Picture this: the controller software is rolling merrily along, doing anything, when all of a sudden an instrument generates a Service Request.  Instantly the controller interrupts what it was doing to find out who generated the SRQ and why.  Now you have interrupt-driven event handling.  Getting back to the masks, maybe you want all the events to go to the event queue, but only a few very specific events to generate an SRQ.  The DESER and ESER registers give you that option.  The bit definitions are just like they were in the DESER and SESR.  The register is written using *ESEand read using *ESE?

Status Byte Register (SBR)

Now we come to an interesting register: the Status Byte Register.  This register shows if there are any messages in the output queue, if a SRQ is set, and those events that made it out of the SESR past the ESER.  It’s read using either a *STB? query or a serial poll.  The only way to clear the bits is to use a serial poll or deal with the errors that are setting the MSS bit.

Bit NumberDecimal ValueSymbolFunction
7 (MSB)128-----Not used.
664RQSRequest Service.  Shows that the scope is requesting service from the controller.  Read via a serial poll.
664MSSMaster Status Summary.  Shows a summary of the MAV and ESB bits in this register.  It’s read using a *STB? Query.
532ESBEvent Status Bit.  Shows that events have flowed into here from the SESR.
416MAVMessage Available.  Shows that there are messages in the output queue.  After a query, for example.
38-----Not used.
24EAVNot used.
12-----Not used.
0 (LSB)1-----Not used.

Table II

Status Byte Register (SBR) Contents

Status Request Enable Register (SRER)

Finally we come to the Status Request Enable Register (SRER), which is our final writable register.  This register determines which bits in the SBR loop back and cause a SRQ or set the MSS bit.  These bits have the same definition as the SBR bits in Table II. Note in the flowchart in Figure 1 that the register output loops back to bit 6 of the SRB.  It’s written using *SRE and read using *SRE?  Writing a value of 48 means that any time there’s an error or message available, an SRQ is generated.


This FAQ Applies to:

No product series

Product:

FAQ ID 53591

View all FAQs »