1 of 11

Context vs. Configuration Group

2 of 11

2

In this tutorial you will learn about the purpose of a Context group vs a Configuration group

  1. This tutorial assumes you have launched ‘first_demo’ using the Start/Reset Tutorial, and you know how to access Normal Mode and Wiz Mode through your web browser.
  2. For this tutorial, we will access Context and Configuration groups from Wiz Mode. Note that you can access Context and Configuration groups in Normal Mode if you add the Configure web app to your desktop - the Add a Desktop Icon Tutorial will show you how to do that. For help launching Wiz Mode see the Wiz Mode Tutorial.
  3. Once in Wiz Mode you should see these icons:

4. Click the Configure icon

3 of 11

3

The Configure web app looks like this:

4 of 11

4

What is a Context Group? What is a Configuration Group?

  • If you are here you might find the otsdaq Configuration Primer useful.
  • A Context Group is a group with member tables that define the context in which your daq system lives, e.g. icons on your desktop, where applications should run, etc.. Context groups should be created and activated before starting otsdaq in Normal Mode (because your active Context Group defines how Normal Mode should launch).
  • A Configuration Group is a group with member tables that define how you want to customize or configure your system. Configuration groups should be created before Configuring the State Machine. When the State Machine is successfully Configured, the full Configuration Tree is active.
  • One way to think about is the Context Group defines your “containers” (i.e. how many applications/supervisors/processes, where, and of what type), and the Configuration Group defines what you want in your containers (i.e. how many plugins, what type, and what parameters).
  • The active Configuration Group can be changed during run time by halting and re-configuring the state machine.
  • The active Context Group can only be changed before launch Normal mode.

5 of 11

5

Finding your active Groups

  • The active Context Group is always shown in the Configure web app at the top.
  • The active Configuration Group is also always shown, but it is critical to note that the active configuration shown in the Configure web app is only relevant for editing purposes!
    • The active Configuration Tree from the perspective of all components in your system is only defined once you configure the State Machine by selecting a Configuration Alias and executing the Configure transition.
    • Fore more on Configuration Aliases see the Using Configuration Aliases Tutorial.
  • Note that in the System View of the Configure web app, there is additional information on which Configuration Group was last used for a State Machine configure transition and a State Machine start of run transition.

6 of 11

6

  1. For a simple example of the purpose of a Context Group, click the Tree-view of your active Context
    1. For more on the Tree-view, see the Using the Tree-view Tutorial.
  2. Hover your mouse over the XDAQContextTable.
    • Click to expand it
  3. Expland LinkToApplicationTable

    • These are the applications/supervisors/processes to be launched at the specified computer address:port pair (defined by environment variables $HOSTNAME and $OTS_MAIN_PORT).

Example Context Group use case..

7 of 11

7

  • Suppose you want to move your Gateway Supervisor “Supervisor” to another computer (e.g. because it is better at handling user traffic, or faster at compiling (the Code Editor is managed by the Gateway Supervisor)).
  • You could modify the Context Group (see the Using the Tree-view Tutorial) to look like this:
    • Steps:
      1. Create new record in “>>” menu of XDAQContextTable named “gatewayContext”
      2. Change the “gatewayContext” Address to specify the gateway computer.
      3. Create a new LinkToApplicationTable GroupID like “gatewayContextApps”
      4. Select the “Supervisor” app to be a member of the group.
      5. Remove the “Supervisor” app from the “mainContext”’s “testContextApps group
  • Save and Activate your new Context Group and the next time you relaunch ots in Normal Mode, you will have your specified environment.

Example Context Group use case continued...

5a.i. new record

5a.ii. new address

5a.iii-iv. Add Gateway to link to app group

5a.v. Remove Gateway from link to app group

8 of 11

8

  • For a simple example of the purpose of a Configuration Group, click the Tree-view of your active Configuration

  • Expand your Tree-view to FEInterfaceTable/ExampleInterface0/LinkToFETypeTable:

Example Configuration Group use case..

  • This is an example Front-end interface plug-in. Imagine a piece of hardware accessible on your network an IP address and port (in this case the expected IP address/port is 127.0.0.1/4000).

9 of 11

9

  • Suppose you want to test a new piece of hardware now, one at IP address/port = 192.168.1.1/4000
  • One way to do this is modify the Tree-view IP/Port
  • Then save the Configuration Group as a new alias (e.g. “NewHardwareAlias”)

Example Configuration Group use case continued..

    • now in System View you have two Configuration System Aliases

  • And now in your State Machine you can, dynamically during run-time, pick “defaultSystemAlias” to test your original hardware, then halt and reconfigure with “NewHardwareAlias” to test your new hardware.

10 of 11

10

That’s it! You now know the purpose of your active Context group vs your active Configuration Group!

  • Remember, the Configuration Group is setup at run-time by the State Machine, and that dynamically fully defines the Configuration Tree for all configurable components in your system.

11 of 11

Related Tutorials

11