Section 9 - Understanding MDSplus Events
Temp. text (was in sect. 3 - Command Line Interfaces)
If, for example, an action is intended to plot some data taken after a pulse, that action will be instructed to "Wait For the EVENT" (WFEVENT) that is broadcast by the data acquisition action when it completes reading the data. SETEVENT and WFEVENT are described more fully in the MDSplus DCL Commands Reference Manual.
WFEVENT Example:
$ wfevent my_data_ready
! The process stops until it detects the my_data_ready event on the cluster
SETVENT Example:
$ setevent my_data_ready
! Typical event generated when a data acquisition action completes
MDSplus events are useful tools and are frequently used to update scope displays. This works because, in general, a scope is always open when shots are being taken and will therefore see the broadcast of the event on the network and do the scope update. The downside to MDSplus events is that the process that you want to wait for the event must be active and waiting when the event is broadcast or it will never see the event and will never continue execution. Hence the reason that scope updating works is because they tend to be always active during runs. In addition, if a scope misses an event, it is easy to get the trace you want simply by entering the shot number manually at the bottom of the scope window.
The command SETEVENT <event_name> can be issued interactively at the command level, by a batch command file or any procedure that has access to the MDSplus shared library including nodes in the model tree. Figure 1 shows a C-Mod node that broadcasts the event "BUSHV_L8212_1" when its store action completes. The command WFEVENT <event_name> is the way to instruct a process to wait for the broadcast of an MDSplus event. Figure 2 shows the "Setup data source..." for one of the panels in a scope - this panel waits for the MDSplus event named "MAG_TRAQ".
For inter-process synchronization though, MDSplus events are not usually used for synchronization because of the requirement that the dependent process be active when the event signal is broadcast. A process that is waiting for an event might have been started after the broadcast of that event and will therefore never execute. See Section 7.b for a discussion of a better method for process synchronization using the DCL SYNCHRONIZE command.
Figure 1
Figure 2