9.5. Remote control package
When doing event building, it can be useful to have a ReadoutGUI for each data source and then another ReadoutGUI that controls them all. Doing this allows data sources to be worked on independently when it is not necessary to run all of them together to build events. The remote control packages for the ReadoutGUI support this mode of operation.
If you choose to use this approach you must enable the ReadoutGUIs that will be slaved to the master control panel to:
Run a remote control server component that allows the master GUI to tell it what to do.
Run a remote console monitor component that allows the master GUI to relay output that goes to the slave output window to the master's output window.
This is done by adding the following two lines to the slave GUI's ReadoutCallouts.tcl file:
- The remote control software is an optional component. This line incorporates that component into the ReadoutGUI
- An instance of the ReadoutGUIRemoteControl class and OutputClient are instantiated, thus providing the required capabilities for run control and output forwarding. Furthermore, the end proc is renamed to local_end and a new end proc is created that will propagate an end run request to the master ReadoutGUI. This forwarding of the end run may be important if the enslaved GUI runs a filter in conjunction with the Actions package.
To use a slave UI, you must run a readout shell and add data sources with the RemoteGUI data source provider for each slave you want your master to control. You will need to know which system is running the slave GUI and under which user name it is running. Furthermore, the system to be enslaved must have already been started (i.e. state = HALTED) in order for the master ReadoutGUI to enslave it.
At this time you can only have a single master control panel control any single slave control panel. This restriction might be lifted in the future.