Cheryl observed an instance of H1 being dropped out of OBSERVING due to SDF changes tracked down to the Computer/SDF Node:  sysecaty1plc2

(This was for the Yarm.  We noticed this same issue a week ago for the analogous Computer/Node for the Xarm:  sysecatx1plc2.)

I continued the work of figuring out who is our pesky channel dropping us out of OBSERVING.  The first thing I did was look at the (3) channels Keita found for X last week and see if the Y-arm counterparts changed today---found nothing in dataviewer.  I then ran the scripts Cheryl ran and came with the same result of seeing a change with the channel H1:FEC-1031_SDF_DIFF_CNT.  But this is just a name for a channel SDF uses.  

I then just went to where sysecaty1plc2 is on medm.  This is related to Beckhoff, so maybe the channel can be tracked down by snooping around medm land.  To get to a baseline/starting point, I went to:

SITE MAP / SYS / EtherCAT overview / H1 Y1 PLC2 /

From here you have several different subsystems (Als, Asc, Isc, Lsc, Sys).  So, I went through all of these subsystems and the screens nested within them.  The first thing I did was to find the "*_ERROR_FLAG" status box for each subsystem (it's green for all, and I reckon if there was a change to the system, it would go red).  So I grabbed this channel for all the subsystems mentioned above, and the only one which changed when we dropped from OBSERVING was the Als one.  I then played the same game--go into the nested windows within and trend "*_ERROR_FLAG" channels for each component within Als.  Ultimately, I ended up finding a single channel which had activity around the time in question.  It was found here:

SITE MAP / SYS / EtherCAT overview / H1 Y1 PLC2 / Als / Y / Fibr / Lock / Temeraturecontrols  (i.e. H1ALS_Y1PLC2_Y_FIBR_LOCK_TEMPERATURECONTROLS.adl)

And on this medm, the channel in question is:  H1:ALS-Y_FIBR_LOCK_TEMPERATURECONTROLS_ON

I'm not saying this is the ONLY channel which could be culprit for the OBSERVING drop, but this is one I saw drop out at that time (see attachment#1), BUT there is a caveat.  If I look at 20min before the Drop, the ALS channel in question had some similar drop outs (see attachement#2).  For the earlier one, the drops only lasted about 10sec (attachment#3).  For the drops which took us out of OBSERVING (attachment#1), after 15sec of drops, then we dropped out of OBSERVING (& overall the ALS ON switch went off/on for about 40sec).  So maybe the SDF changes have to happen for a certain amount of time before latching us out of OBSERVING?

As another check, I looked at the last 12hrs of this lock and the only time H1:ALS-Y_FIBR_LOCK_TEMPERATURECONTROLS_ON had these fits of turning OFF for a handful of seconds were in that 20min time period when we dropped out. 

Question:  Is this enough to warrant NOT MONITORING H1:ALS-Y_FIBR_LOCK_TEMPERATURECONTROLS_ON?  Or should we keep searching?