Ferdi Franceschini 2007-02-28 18:29 SICS is NOT a safety system! It will allow you to do tasks that may damage persons and the instruments. DO use the STAR principle. STOP. THINK. ACT. REVIEW Familiarise yourself the location of the Emergency Stop buttons located near the cabin exit, or in several places within the instrument enclosure. Familiarise yourself with the instrument and its safe operation. DO NOT do anything with SICS that may risk damage to persons or the instrument. DO NOT rely on these commands to stop motors or close shutters. If in any doubt, use the Emergency Stop button. The commands in this chapter may fail for a variety of reasons. SICS has crashed Your network connection to the SICS is blocked, due to network congestion or failure The motor controller is no longer accepting connections or has a rogue process running Neutron scattering experiments require control of motors for instrument configuration, control of histogram memory for counting neutrons, and control of sample environment. SICS is a program that accepts human readable commands, and converts these to commands that devices understand. For simplicity, much of the control for an experiment is done in a sequence (synchronously), requiring that an operation completes successfully before the next is commenced. SICS can also be used asynchronously, but more care has to be exercised by the operator to ensure the desired result. Instrument control is based on a client server architecture, each instrument has a dedicated server, called SICS,  which receives commands from client applications and then executes them by issuing control sequences to the hardware.  SICS was originally developed at PSI to control the SINQ spallation source instruments.  Drivers and site specific extensions have been developed at ANSTO to control and provide status information for motors, sample environment and histogrammed neutron event data from the detectors. Driving a device synchronously is done using the drive command. The device could be a motor or sample environment e.g. temperature controller. Driving a device asynchronously is done using the run command. Stopping the device is done using the stopexe command. Counting of histogrammed neutron events is done using the histmem command. Running scans that are a linear sequence of driving, counting and file saving tasks is done using the runscan command. Creating a new file is done using the newfile command, and saving data to the file is done using the save command. Detail for using each of these commands is provided in the next chapter. SICS provides many other functions, but we won't cloud the issue at this stage. In general, the Bragg Institute instrument scientists manage SICS for the instrument users. SICS should be running when you come to the instrument, and you should only need to run the Gumtree program, which is a graphical user interface. You should read further if you think that SICS is not running and you want to start it, you want to command a device directly with SICS (the first half of this manual), or you would like to change the instrument configuration (the second half). SICS runs on an ICS computer (instrument control server). All ICS computers run the Linux operating system, and have a name that looks like ics1-echidna.nbi.ansto.gov.au. If you have an account on the NBI network, you can use that username and password to login. You must login using ssh from a unix computer, or using an ssh client on a Microsoft Windows computer like putty or F-Secure To control the instrument, the SICS software must be running on the instrument control computer. First, check to see if SICS is already running by calling the runsics status command as shown below. Note: the "echidna@ics1-echidna:~>" is just the command line prompt. echidna@ics1-echidna:~> runsics status SICServer running SICS script validator running This example shows SICS is already running. In this case, you should proceed to login to SICS. If the reply is echidna@ics1-echidna:~> runsics status SICServer NOT running SICS script validator NOT running then use the runsics start command echidna@ics1-echidna:~> runsics start Starting SICS 29087 SUCCESS Starting SICS Script Validator 29091 SUCCESS Most users won't want to login to SICS. However, if you do need to get to the SICS command line, then use the sicsclient command at the Linux prompt. echidna@ics1-echidna:~> sicsclient OK Now you'll have to login to SICS with your role and password. The role is spy, user or manager, and the instrument scientist will provide you with the password. sics_username sics_password Login OK When a correct username and password is entered, SICS announces that the login was successful. SICS commands can now be entered. To start SICS you have to log on to the instrument control computer and then cd /usr/local/sics/server and launch the server in the background with a command similar to the one shown below cd /usr/local/sics/server nohup ./SICServer xxx_configuration.tcl & where xxx is the instrument name. The '&' is important, it runs the server in the background, nohup logs output from SICS to a file called nohup.out and ensures that SICS continues running when you logout. The .tcl file specified on the command line is the configuration file for your instrument, replace the xxx with your instrument's ID.  The configuration file may source other .tcl files. You might be thinking, "What is the validation server used for?". You don't want to run a script on the instrument control server that might be syntactically incorrect, or hits the limits of the hardware. The validation server runs to allow scripts to be tested without moving any hardware. The validation server runs with hardware that is simulated in software. The validation server has its own set of configuration files. It is important to keep these files synchronised with the instrument control server, however there are times you may want to have a different configuration on the validation server. To synchronise the validation server > socat READLINE,history=$HOME/history tcp4:127.0.0.1:60013,crlf Login to the validation server using sics_username and sics_password Synchronising is slow but you can get feedback if you issue the following sequence of commands when you synchronise getlog command getlog value sync You will see something like the following feedback on the validator connection as the sync command is running, Executing -> sync <- from socket 16 Executing -> restore ../script_validator//log/status.tcl <- from dummy socket pa_top = -102.499977 pa_bottom = -104.000000 pa_top = -102.499977 pa_bottom = -104.000000 pa_top = -102.499977 pa_bottom = -104.000000 pa_left = -24.699976 …. New en position: 46.434 New qm position: 6.048 Simulation Server has SYNCHRONIZED! Fixed motors may not have correct positions SICS is installed on the /usr/local/sics/ directory of the instrument control computer.  It has the following subdirectories /server This contains the SICServer and the *.tcl configuration files /data Data files are stored here /log Server log files are stored here along with the status.tcl file.  The status.tcl file preserves variable settings and some parameter values from the last session with the SICServer /tmp The server keeps temporary files here SICS is configured via *.tcl files which initialise the command objects which clients use to control the hardware.  Also,  the server's functionality can be extended by defining new commands in the configuration files, we can do this because SICS embeds a Tcl interpreter (hence the .tcl extension).