Documentation for the UIUC Trigger GUI

Goals of the trigger GUI

The goal of the trigger GUI is to make diagnostic and control information for the trigger device more easily observed and edited.

How to use the GUI

The user should understand how the layout they see enables the functionality they want. The right side of the GUI has folders you can click on. When a particular crate is running with its server, these folders will contain representations of the crate, as well as the boards, registers, and eproms within the crate. Although each of the servers can run inside any of the crates, incorrectly placing the servers inside of the crates will cause the user to observe the data for one crate as though it belonged to another crate.

Once the user selects options on the right hand side, buttons will appear on the left hand side of the GUI. These buttons provide information about the features described on the buttons. Expert users can also click the check box at the bottom of the left hand side. These bring up special components such that the user can edit values inside of the crate.

To refresh the list on the right hand side in case you beleive some component has failed during the time you've been running the GUI, restart the GUI client.

For more information, read the numbered list below entitled, "Types of events describing typical user interaction with the TriggerGUI and its results."

Structure of both the GUI and its environment

The trigger GUI is part of the CLEO online software, specifically the Slow Control portion. Slow control is designed to be the human-level interface to the control hardware. It is called slow control because the timing constraints are much looser for human interaction than for event gathering or machine interaction. The trigger GUI is designed to inherit from CLEOGUI, a method within the SessionManager package of Ohio-state university. This method redefines the trigger GUI's interaction with its surroundings, such that it is neither an applet nor an application, but instead handled as part of the SessionManager GUI.

The trigger GUI and its servers have functions to allow connecting to different crates, depending upon which server was spawned within wich crate. It is the responsibility of whoever calls the server code to make sure the right crate is matched with the right server. The servers create name-to-slot lists, which map the client end to a directory structure, by iterating across the slots within the crate. The server also provides get and set functions, which the user can connect to by choosing a component, which in turn allows the GUI to parse the available choices, using this name-to-slot device. The server end maps to hardware interface code contained throughout the TRIGDAQ folder, specifically those classes found in the TriggerCrate, TriggerBoard, and Eeprom folders. Here is a table which illustrates the naming convention used througout the GUI:

Commonly used TriggerGUI names

Crate names
informal name Crate Label Spawn Command Client-side CORBA name name-to-slot list client-server label
Test crate Crate: Test sp TriggerGUIStart testCommands testCrateSlotToType TRSC
Level One crate Crate: Level One sp L1DGUIStart levelOneCommands levelOneCrateSlotToType L1TRSC
Axial crate Crate: AXIAL sp AxtrGUIStart axialCommands axialCrateSlotToType AXIALTRSC
Stereo crate Crate: STEREO sp SttrGUIStart stereoCommands stereoCrateSlotToType STEREOTRSC
CCD crate Crate: CCD sp CCDGUIStart ccdCommands ccdCrateSlotToType CCDTRSC
Permission server n/a n/a permissionCommands n/a n/a
most recently selected crate currentlySelectedCrate n/a valueCommands currentSlotToType n/a
Other important names (self explanitory)
currentlySelectedSlot currentlySelectedEprom isExpert (boolean)


Types of events describing typical user interaction with the TriggerGUI and its results:
  1. The user opens the TriggerGUI. This causes the client to bind to all the crate servers that are currently active, and attempt to create a slot-to-type list for each crate. The client will also attempt to build a tree for the user to click on the right hand side of the screen, using the same data.
  2. The user selects a folder from the right side. Data about the user's selection, possibly including the slot number, eprom number, crate name, and so forth, as well as the users expert status, are used to create the options the user has available on the left hand side.
  3. The user selects the checkbox for expert status. The user will have to select a new component on the right hand side in order to see the expert components, but the user can immediately switch back to whatever folder they were at. To leave expert status is a similar process, and again the user must click a different folder on the right side to rebuild the left side.
  4. The user selects an option on the left side. This actually sends a message to the current crate server that will get and set trigger values. Notice that the client gets this information by parsing the label the user clicked on.
The concept of generic components is key in understanding the code behind the TriggerGUI. Generic components are physical parts of the GUI that can change their results when activated. If a component is a JButton or a EditableDataPanel (a label, text field, and two buttons), then it most likely generic. These components are declared and allocated when the GUI is just started. Then, depending on what the user selects, the visibility and labels of these features change. When these components are clicked on, they send their labels or another stored constant to getValue and setValue. These function lables do not exactly correspond with these titles. Instead, getValue is called by buttons or by the Refresh button of an EditableDataPanel, while setValue is called by the Set Value button of an EditableDataPanel. The advantage to these behaviors is that new features can be added easily.

Summary of main points

These are the fundamental concepts behind TriggerGUI. For a more detailed reference of internal details, please observe the comments for these files. Here is a summary of the main points:
High Energy Physics at UIUC, Last modified August 8, 2000
Return to the software index