Much user frustration can be eliminated when running a brand new software
package by having some basic understanding of the inside of the software. Is is
always nice to know what the program is suppose to do at any given time to
anticipate its reaction. SusiQ performs two major activities:
1. Check for event to be read.
2. Check for keyboard activity.
After these two tests, SusiQ will automatically do its internal house
managment which results in the update of the screen to reflect any new run
status. This check loop ought NEVER to be broken to ensure SusiQ a proper
servicing to both parties ( acquisition, user).
* SusiQ first reads the setup file file.DFT, loads and checks all the
definition files, then presents the SusiQ page on the screen. If failure occurs
during loading messages, will be displayed on the screen to help you trace the
problem.
* At this point SusiQ is waiting on the keyboard for user inputs. The system
will be in a standby mode looking at the keyboard for user interaction
and refreshing the screen depending on the refresh rate parameter ([s]
status)
* A normal SusiQ operation will request a begining of run. SusiQ will then
verify if all the definition files were loaded properly and only if so will
proceed to the next stage of starting the initialisation of the run. (BOR
phase, [c] begin)
* When the run is started, SusiQ goes into polling mode for LAM or user
intervention. Because SusiQ does not run in a multitasking environment, it will
be either serving a LAM request (acquisition of an event) or a user request
(user command).
* When a LAM occurs, the CAMAC acquisition sequence will take place, followed
by the analysis and histogram incrementation procedure for that event. Only
then will SusiQ return to the user/refresh job.
* When the run is ended (automatically or on request [c] end), SusiQ will take
the appropriate action for closing the run and resume the user/refresh job.