J. Garcia, J. Kissel
After the addition of the USER DACKILL to the model last Thursday, we Jeff's added some new information to the overview screen, as well as modifying other parts for ease of use. Details below. This change effects the following screens:
${userapps}/release/sus/common/medm/quad/
SUS_CUST_QUAD_OVERVIEW.adl
SUS_CUST_QUAD_R0.adl
SUS_CUST_QUAD_DACKILL.adl # new!
and the changes have been committed to the SVN. Note, that these screens have been tested with no other QUAD besides H2 SUS ETMY, so please be patient while we propagate to others.
Details:
Take a look at the .pdf attachment, which shows the overview screen, with a bunch of areas highlighted. This is what I'll use to walk you through the changes.
* ORANGE This (finally) shows (beginnings of) elucidating the many, many layers of "protection" that prevent the user from getting a digital drive signal out to the suspension coils. From left to right (in the orange box),
WATCHDOG -- hooked up to watch the "first thing off the ADC" OSEM signals, both AC BLRMS and raw DC, as well as the "last thing out to the DAC" AC BLRMS of the digital drive. As we've (re-)learned from the 2012-03-01 ISI/CDS Badness, this isn't *actually* the last thing in/out of the model; there's an extra layer of digital IOP between the signals that are watched by this 'dog. So, these signals are the first/last thing in/out of the QUAD user model.
USER DACKILL -- eventually meant to be similar to the new ISI "rogue excitation monitor," where if the USER model detects badness from itself (using the monitor chassis' coil driver readbacks), it will send a request to the IOP to shut down its DACs. Currently -- because we wanted to get something in quick, and we don't yet understand the monitor chassis signals enough to use them as a watchdog, the DACKILL's input is the same "M0/R0 Tripped" flag that's sent to the ISI.
IOP DACKILL -- This is the "temporary software version of the hardware watchdog." It actually watches the first thing off the ADC: the raw OSEM counts at full data rate, as they come into the IOP model, without any signal conditioning. These watchdog thresholds are (supposedly) set to be much looser that the WATCHDOG thresholds, and therefore should only trip when something really bad's happening. NOTE, this does not watch the drive signals, only sensor signals.
TEST/COIL ENABLE -- This is not originally intended as a watchdog; it's the hardware switch between the "test" and "coil" input on the front of the coil driver chassis, controlled by the digital Binary Input/Output (BIO) system. When the BIO bit is flipped to "test," (i.e. 0, the default, non-powered chassis condition) the coil driver switches to taking input from the "test" DB9 spigot of the front of the chassis, which normally has nothing connected to it. When flipped to "coil," (i.e. 1) the coil driver switches to taking input from the DAC, because this port has cables connected to the AI chassis, and is the normal signal path out. So, unless the BIO is ON, functional, and flipped to 1, there's no way you're getting any digital signal out to drive the suspension.
NOTES:
- The USER DACKILL and TEST/COIL layers are why I put quotes around "protection," 'cause at the moment, I'm not sure they're doing anything but interfering with completely normal drives. The USER DACKILL will be made into a more useful watchdog shortly. The TEST/COIL, I guess, is "protecting" against a non-function BIO system, but the BIO system isn't essential / dangerous.
- The dotted lines extend out to exactly where the various layers "protect;" The USER and IOP DACKILLs shut down all of the DACs from that QUAD's user model, whereas the WATCHDOG only stops output at a given stage.
The hope is that, once we have a hardware watchdog, we can consolidate this "protection" system a little better. But I wouldn't hold my breath. Since we're looking for 0% failure, it's always going to be this hard to get a drive signal out. The key is having all the layers clearly visible and understood, such that one doesn't forget layer number 4 of 6, after not having looked at a given SUS for a while.
* RED A button that opens up the new DACKILL screen; see dackill.png attachment. Should be pretty self-explanatory: as currently hooked up, the M0 and R0 watchdog flags are summed, then (a) sent off to the ISI, when 0 is OK, non-zero is BAD, and (b) inverted, such that 0 is BAD, non-zero is OK, and piped into the DACKILL part. Again, this is not the final implementation, but it should be good enough for now.
* YELLOW At the advise of the SEI team, I re-purposed the epics variables
$(IFO):SUS-$(OPTIC)_COMMISH_STATUS
$(IFO):SUS-$(OPTIC)_COMMISH_MESSAGE
to be used by automated scripts as well as users. Now, when the $(IFO):SUS-$(OPTIC)_COMMISH_STATUS channel is switched to 1 (controlled either by the ON/OFF button, or a caget/ezcaswitch call to that channel by a script), that little box starts to blink yellow, and says "IN PROGRESS." Note that I've removed $(IFO):SUS-$(OPTIC)_COMMISH_MESSAGE from the screen, but not from the model. Formerly, it was used as place to inform people who to talk to during a measurement, but it proved cumbersome and ineffective. We'll remove it from the model the next time it's convenient -- it's not hooked up to anything, so it makes no difference whether it's in the model but not-visible on the screens.
* WHITE At the request of those using the screens all the time, I've separated the R0 watchdog out from the R0 screen button. This allows for easy, less-clicking, access to the R0 watchdog screen.
