Difference: RunControlBrainStorm (1 vs. 8)

Revision 8
02 Jun 2005 - Main.SimonLang
Line: 1 to 1
Added:
>
>
META TOPICPARENT name="RunControl"
 

Run Control Brain Storming

  • Call browser windows from MEDM for input into database (like OV-NNM WebLauncher)
Revision 7
16 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Run Control Brain Storming

Changed:
<
<
  • Call browser windows from MEDM for input into database (like
OV-NNM WebLauncher)
  • Put status of hardware (init, running, ...) into one call and
one variable.
>
>
  • Call browser windows from MEDM for input into database (like OV-NNM WebLauncher)
 
  • Writeup and new thoughts on RunControlStates
  • Need device support for several record types:
    • Analog Input - Statistics (currently "bar")
    • Multi-Bit Binary Input / Output - State(s)
Changed:
<
<
-- MathiasMuench - 11 Feb 2005
>
>
  • Use one variable for issuing commands (init/reset/start/stop) and reading status (Unknown/Reset/Running/Stopped)
 
Added:
>
>
-- MathiasMuench - 11 Feb 2005
Revision 6
16 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Run Control Brain Storming

Changed:
<
<
  • Call browser windows from MEDM for input into database (like OV-NNM WebLauncher)
  • Put status of hardware (init, running, ...) into one call and one variable.
>
>
  • Call browser windows from MEDM for input into database (like
OV-NNM WebLauncher)
  • Put status of hardware (init, running, ...) into one call and
one variable.
 
Changed:
<
<
>
>
  • Need device support for several record types:
    • Analog Input - Statistics (currently "bar")
    • Multi-Bit Binary Input / Output - State(s)
  -- MathiasMuench - 11 Feb 2005
Added:
>
>
Revision 5
11 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Run Control Brain Storming

  • Call browser windows from MEDM for input into database (like OV-NNM WebLauncher)
  • Put status of hardware (init, running, ...) into one call and one variable.
Changed:
<
<
  • Create writeup on HW status
>
>
 
Deleted:
<
<

Some thoughts about init/reset/start/stop

Up to now, it is well definied what transitions from state to state are possible. Interesting enough, only the transtions (init, reset, start, stop) are defined, but not the states themselfs. Additionally, the behaviour during the transitions and inside the states is undefined.

For existing electronics, this writeup may be too late, but for future developments, some clarification may be helpful.

Transition Diagram

                     +----------+
                     | Unknown  |
                     +----------+
                          |
                          | init
       +---------------+  |   +----+
       |               |  |   |    |
       |             +-v--v---v-+  | reset
       |             | Reset    |--+
       |             +----------+  |
       |                  |        |
       | reset            | start  | reset
       |                  |        |
  +----------+       +----v-----+  |
  | Error    <-------| Running  |--+
  +----------+ error +----------+  |
                          |        |
                          | stop   | reset
                          |        |
                     +----v-----+  |
                     | Stopped  |--+
                     +----------+

Transition Matrix

State Unknown Reset Running Stopped Error
Unknown - init - - -
Reset - reset start - -
Running - reset - stop error
Stopped - reset - - -
Error - reset - - -

Meaning of the states

Unknown
As the name says. This state is normally reached after a power cycle or hardware reset, i.e. no configuration is loaded yet.
Reset
The "Reset" state only plays a role as a predessor for the "Running" state. Its importance lies in reaching a well defined state while at the same time being "deaf", so that this state cannot be changed from the outside.
Running
The measure mode, the module reacts to signals and generates signals itself.
Stopped
The module is "deaf" again while keeping the last internal state during measurement. It allows for access of status and debugging registers. This state is important to allow for a "post mortem" analysis.

Behavior during the transitions

init
This operation brings the module into the "Reset" state after a power cycle.

Input/Output during the transitions

transition inputs outputs
init deaf undefined
reset deaf undefined
start active quiet
stop deaf quiet

Remarks: The above defined behavior shall allow for maximum parallelism during the setup of the hardware for measurement. During init and reset, all modules may put arbitrary signals on their output lines, but since no input is accepted during these phases, they may be done completely in parallel.

The transition into measurement mode switches the inputs to active (per definition). Therefore, during this phase, no module shall generate any output on its output lines. Since all modules are quiet, the start transition can also be done in parallel. The forst input seen on the active input lines is the "begin run trigger".

While the measurement mode is reached via a two step procedure (reset/start), the halt of the system is only one step. Therefore during that phase, the modules shall put themselfs into deaf mode in order not to change their internal state. Also, for not disturbing other modules that may still be in state "Running", the modules shall be quiet on their output lines.
 

-- MathiasMuench - 11 Feb 2005
Revision 4
11 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Run Control Brain Storming

  • Call browser windows from MEDM for input into database (like OV-NNM WebLauncher)
Line: 11 to 11
 

For existing electronics, this writeup may be too late, but for future developments, some clarification may be helpful.
Changed:
<
<
>
>

Transition Diagram

 
Added:
>
>
  +----------+
Changed:
<
<
unknown
>
>
Unknown
  +----------+ | | init
Changed:
<
<
| +----v-----+
reset
>
>
+---------------+ | +----+
       
| +-v--v---v-+ | reset | | Reset |--+
+----------+
   
| reset | start | reset
   
+----------+ +----v-----+ | | Error <-------| Running |--+ +----------+ error +----------+ |
 
| stop | reset
 
+----v-----+ | | Stopped |--+
  +----------+
Changed:
<
<
| -- MathiasMuench - 04 Feb 2005
>
>

Transition Matrix

State Unknown Reset Running Stopped Error
Unknown - init - - -
Reset - reset start - -
Running - reset - stop error
Stopped - reset - - -
Error - reset - - -

Meaning of the states

Unknown
As the name says. This state is normally reached after a power cycle or hardware reset, i.e. no configuration is loaded yet.
Reset
The "Reset" state only plays a role as a predessor for the "Running" state. Its importance lies in reaching a well defined state while at the same time being "deaf", so that this state cannot be changed from the outside.
Running
The measure mode, the module reacts to signals and generates signals itself.
Stopped
The module is "deaf" again while keeping the last internal state during measurement. It allows for access of status and debugging registers. This state is important to allow for a "post mortem" analysis.

Behavior during the transitions

init
This operation brings the module into the "Reset" state after a power cycle.

Input/Output during the transitions

transition inputs outputs
init deaf undefined
reset deaf undefined
start active quiet
stop deaf quiet

Remarks: The above defined behavior shall allow for maximum parallelism during the setup of the hardware for measurement. During init and reset, all modules may put arbitrary signals on their output lines, but since no input is accepted during these phases, they may be done completely in parallel.

The transition into measurement mode switches the inputs to active (per definition). Therefore, during this phase, no module shall generate any output on its output lines. Since all modules are quiet, the start transition can also be done in parallel. The forst input seen on the active input lines is the "begin run trigger".

While the measurement mode is reached via a two step procedure (reset/start), the halt of the system is only one step. Therefore during that phase, the modules shall put themselfs into deaf mode in order not to change their internal state. Also, for not disturbing other modules that may still be in state "Running", the modules shall be quiet on their output lines.

-- MathiasMuench - 11 Feb 2005
Revision 3
10 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Run Control Brain Storming

  • Call browser windows from MEDM for input into database (like OV-NNM WebLauncher)
  • Put status of hardware (init, running, ...) into one call and one variable.
  • Create writeup on HW status
Added:
>
>

Some thoughts about init/reset/start/stop

Up to now, it is well definied what transitions from state to state are possible. Interesting enough, only the transtions (init, reset, start, stop) are defined, but not the states themselfs. Additionally, the behaviour during the transitions and inside the states is undefined.

For existing electronics, this writeup may be too late, but for future developments, some clarification may be helpful.


 +----------+
 | unknown  |
 +----------+
      |
      | init
      |
 +----v-----+
 | reset    |
 +----------+
      |
  -- MathiasMuench - 04 Feb 2005
Revision 2
10 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Run Control Brain Storming

  • Call browser windows from MEDM for input into database (like OV-NNM WebLauncher)
Added:
>
>
  • Put status of hardware (init, running, ...) into one call and one variable.
  • Create writeup on HW status
 

-- MathiasMuench - 04 Feb 2005
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)