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

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

Event Handling Sequence

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.

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.

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.