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.
|7 (MSB)||128||PON||Power On. Shows that the scope was powered up or that the diagnostic tests completed.|
|6||64||URQ||User Request. Shows that an application event happened, which could be a front-panel key press.|
|5||32||CME||Command Error. Shows that an error occurred when the scope received a command or query. Usually related to a syntax error in the user software.|
|4||16||EXE||Execution Error. Shows that an error occurred when the scope was processing a command or query. Related to a hardware or configuration problem.|
|3||8||DDE||Device-Dependent Error. Usually related to a firmware or diagnostic problem.|
|2||4||QYE||Query 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.|
|1||2||RQC||Request Control. Not used.|
|0 (LSB)||1||OPC||Operation Complete. Shows that all pending operations have completed following a *OPC command. Used to synchronize the controller with the scope acquisition process.|
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 Number||Decimal Value||Symbol||Function|
|7 (MSB)||128||-----||Not used.|
|6||64||RQS||Request Service. Shows that the scope is requesting service from the controller. Read via a serial poll.|
|6||64||MSS||Master Status Summary. Shows a summary of the MAV and ESB bits in this register. It’s read using a *STB? Query.|
|5||32||ESB||Event Status Bit. Shows that events have flowed into here from the SESR.|
|4||16||MAV||Message Available. Shows that there are messages in the output queue. After a query, for example.|
|0 (LSB)||1||-----||Not used.|
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.
Diese FAQs beziehen sich auf:
FAQ-ID 53591Alle FAQs ansehen »