From:                                         Davis, Mark

Sent:                                           Tuesday, September 25, 2012 8:55 AM

To:                                               Morris, Dan

Subject:                                     LLRFTurnOn module change

 

As I understand it, the change you asked for is as follows:

·         Stop asserting the Soft RF ON signal whenever the PLC RF ON signal is not being asserted

·         Do not allow the Soft RF ON signal to be re-asserted if the PLC RF ON signal is not being asserted

 

The change to the code for this is trivial (already done).  However, I am concerned that the result may not be what you want (may, in fact, stop the module from working at all).

 

One of the functions of the existing logic is to generate reset signals to the PLD that is part of the LLRFTurnOn module and to the external LLRF module, WHENEVER the Soft RF ON signal is asserted and the PLD RF ON signal is not. 

 

If memory serves correctly, one of the key reasons for this existing logic is so the module automatically recovers from intermittent problems.  The change (as you described it, or at least my understanding of it) completely eliminates this functionality.

 

Assuming that this is indeed the intention, the key question is, what drives the PLC RF ON signal?  If it truly is independent of anything this module is doing, then at least the change won’t stop the module from functioning at all (NOTE that any dependencies must include the effect on the LLRF module, since this module currently sends it reset signals and won’t do so – at least not automatically - after this change).

 

Summary of my concerns regarding this change:

·         Is the elimination of one of the key features of the module (automatic recovery from some faults) intentional, or an un-intended consequence?

·         After this change, will the manual method of resetting the faults (the “Reset Faults “ button on the LLRFTurnOn dialog – and possibly some buttons on some PanelMate screens?) still function?

·         A (minor?) operational one:  Will people know that they have to enable the Soft RF ON for this module after everything else is enabled?  Or will they wonder why the RF is not turning on when everything else says it should be on?

 

My thoughts and assumptions regarding these issues:

·         The fact that automatic recovery from some faults was part of the original design for this module suggests that intermittent problems DO occur and that the intention was to avoid the need to manually acknowledge and reset every such fault.  Assuming such intermittent problems do in fact occur, completely eliminating the automatic recovery capability will result in the RF shutting off (and now staying off) under conditions this functionality currently deals with.

·         The existence of the “Reset Faults” button on the dialog box implies that you CAN reset the faults (including anything that stops the PLC RF ON from being asserted) while the Soft RF ON signal is NOT asserted (since the Reset .  If true, then at least this change does not create a Catch-22 where you CAN’T reassert the Soft RF ON because the PLC RF ON is not asserted, and the PLC RF ON cannot be reasserted because the Soft RF ON is not asserted.

·         Assuming that the Soft RF ON hasn’t been enabled and just left that way for months at a time (I haven’t scanned the logs to verify this one way or the other), then this change will not cause total confusion (although the loss of the automatic recover for intended circumstances could become a major issue).

 

An alternative suggestion that would avoid entirely eliminating the automatic recovery feature but still address the issue of having the RF come back on when it wasn’t expected/intended:

·         Basically, just add a time limit:  Add a (configurable) limit to how long the Soft RF ON signal will be asserted when the PLC RF ON signal is not.  This way, the module will continue to generate the reset pulses for up to the configured time after the loss of the PLC RF ON signal, or after someone presses the RF ON button for the Soft RF ON signal.  If the specified limit is reached after one of these events and the PLC RF ON is still not asserted, THEN it will stop asserting the Soft RF ON signal (and stop generating the reset pulses).

 

So:  Thoughts?  Questions?  Clarifications?  Who initiated the request for this change, and are they aware of the ramifications?

 

Mark

 

 

NOTES from the code regarding the inputs and outputs for the module itself and the PLD that is part of the module:

 

//    Inputs to the module:

//      - 2 Spark Detector inputs

//      - 2 "roll call" inputs indicator which Spark Detector inputs actually

//        have something connected

//      - 2 Fault inputs (LLRF and a Spare)

//      - PLC ON

//

//    Outputs from the module:

//      - RF ON

//      - LLRF Reset

//

//

//    Module contains a PLD that uses the following digital inputs:

//      - The 2 Spark Detector inputs to the module

//      - The 2 Fault inputs to the module

//      - The PLC ON input to the module

//      - An ON command from the RCM

//      - A Fault Reset command from the RCM

//

//    and provides the following digital outputs:

//      - 2 Spark Detected states

//      - RF ON command

//

//

//    Inputs to the RCM (Rabbit Core Module) (i.e. what it can monitor):

//      - The 2 Spark Detected state values from the PLD

//      - The 2 Roll Call inputs to the module

//      - The PLC ON input to the module

//

//

//    When the RCM receives an ON command, it asserts the ON command that is

//    one of the inputs to the PLD.  The PLD in turn asserts its ON output if

//    the following are all true:

//      - ON command from the RCM is asserted

//      - The PLC ON input is asserted

//      - None of the Spark or Fault inputs have been active since the

//        last Fault Reset from the RCM

//

//    Whenever the RCM sees a fault, it records the time the fault occured.

//    The RCM waits at least resetDelayMS after the most recent fault and then

//    sends a Reset pulse to the PLD and the LLRF module as soon as the RCM is

//    actively asserting the ON command.

//

//    The result is that a steady stream of reset pulses is sent to the PLD

//    and the LLRF module whenever the RCM is asserting the ON command and the

//    PLD is NOT.