Personal tools
You are here: Home EGO ITF Software Support&Maintenance IMMS (Old)
Navigation
Log in


Forgot your username or password?
 
Document Actions

IMMS (Old)

by Bernhard Lopez last modified 2009-12-28 05:34

This page seeks to gather information related to the daily support and maintenance of the IMMS, plus Hints & Troubleshooting.

IMMS Main Project Page - ( IMMS2 has replaced this see https://workarea.ego-gw.it/ego2/ego/itf/software/support-maintenance/imms2-1.)

Click here to go to the IMMS main project page.

IMMS on-call hints when Detector Monitoring System is Grey

When something goes wrong with monitoring system it may be fixed by starting and stopping the system. Hints on how to isolate and hopefully fix problem are provided here. These are extracted from the User Manual (CVS access).

The first indication of a problem problem with the monitoring software may be a grey area in the “Detector Monitoring System" (Grey – No data is coming into monitor, Dark Grey – Corrupted data is coming into system).

The following checks could be carried out in order to check where the problem lies:
  • Check if the DAQ Slow Frame Builder (FbsMoni) is running and that it is reading the IMMS DAQ Interface Server by checking the DAQ Cl-Client for the Collect Line. If there is a missing channel try a "Reload config" and see if that solves the problem.
  • If the problem persists check if the DAQ Interface process is running. For this issue:
# cm names | grep IMMS
IMMS_DaqIfServer
If you do not get this output try to restart the IMMS_DaqIfServer as indicated below.
If the server is seen at Cm level check that it is responding by issuing (as virgorun):
# checkSms IMMS_DaqIfServer
You should get a list of SMS data, otherwise restart the process as described below.
  • If the problem still persists check out the IMMS data-display web page in order to see if the values of the different channels look reasonable, or if there are error messages. If there is a problem you can try to restart, at a last resort, the Monitoring Process as described below. Remember to restart also the DAQ Interface afterwards.
  • If the IMMS_DaqIfServer at checkSms answers you only the status (that should be equal to 2), maybe the problem is related to the Monitor server running on imms-server2 machine. In this case check if the sceen is "Detached" and Re-Attach it using the procedure showed before.
  • If even after a Monitoring restart some channels still indicate strange values deeper investigations have to be carried out, most likely the problem could then be related to networking or electronics.imms

Restarting the Monitoring Process

  • Start-Up:

Log into “imms-server2” as user immsops. Then launch the following command:

immsops> cd /usr/local/IMMS/iocBoot/iocMonitoring

immsops> ./launch.sh

Then select the option “1” in order to start the Monitoring. The script will also restore all values stored in the backup files and run the Monitoring IOC via the script “st.cmd” (located at iocBoot/iocMonitoring/) inside a new “screen” session.

Now identify the “screen” session the Monitoring has been started in by opening another terminal windows (as user immsops) and issuing:

immsops> screen -ls

The output should look similar to this:

There is a screen on:
1601.pts-0.imms-server2 (Attached)
1 Socket in /tmp/uscreens/S-immsops

In order to detach the “screen” session, so that you can close the terminal window without stopping the Monitoring, issue:

immsops> screen –d <screen_session_ID>
e.g.

immsops> screen –d 1601.pts-0.imms-server2

Once detached you can safely close all open windows and the Monitoring IOC will keep running.

  • Shutdown

As the Monitoring is started inside a “screen” session first identify the screen session by opening a terminal windows (as user immsops) on imms-server2 and by issuing:

immsops> screen -ls

The output should look similar to this:

There is a screen on:
1601.pts-0.imms-server2 (Detached)
1 Socket in /tmp/uscreens/S-immsops

In order to re-attach the “screen” session, so that you can close the terminal window safely, issue:

immsops> screen –d –r <screen_session_ID>
e.g.
immsops> screen –d –r 1601.pts-0.imms-server2

You should then see the Monitoring EPICS shell interface where you can finish the IOC by just issuing:
epics> exit

IMPORTANT: Whenever you restart the Monitoring afterwards also restart the DAQ Interface!

Restarting the DAQ Interface

Management of the IMMS_DaqIfServer server is now possible via the IceWM menu on ctrl1. An alternative is to long on imms-server2 with immsdaq login (gravwave). The control panel can be found in:

IceWM > EnvMon > IMMSDaq >

The IceWM menu should be used to manage the IMMS_DaqIfServer server. If it is not working or not available then the following commands should be completed manually.
  • Startup:

1. To START the IMMS_DaqIfServer choose IMMSDaq Start on the menu. This opens an xterm on imms-server2, as user immsdaq and executes the following commands:

immsdaq# cd /usr/local/IMMS/bin/linux-x86

immsdaq# ./DaqIfServer IMMS/DaqIf/DaqIfCfg IMMS_DaqIfServer &

2. To CONFIGURE the IMMS_DaqIfServer choose IMMSDaq Configure on the menu. This executes the following command:

immsdaq# cm send –to IMMS_DaqIfServer –type SETSTATUS –text CONFIGURED –handler SETSTATUS_RPLY

3. To set the IMMS_DaqIfServer to ACTIVE choose IMMSDaq Active on the menu. This executes the following command:

immsdaq# cm send –to IMMS_DaqIfServer –type SETSTATUS –text ACTIVE –handler SETSTATUS_RPLY

4. The xterm opened by the IMMSDaq Start can now be closed without problem as the server will continue to run regardless.

5. It will almost certainly be necessary to reload the configuration of the DAQ collect line FbsMoni, which will probably be reporting the IMMS_DaqIfServer as lost. Ask the Operator to do this.

  • Shutdown:

To STOP the IMMS_DaqIfServer choose IMMSDaq Stop on the menu. This executes the following command:

immsdaq# cm send –to IMMS_DaqIfServer –type SETSTATUS –text ACTIVE –handler SETSTATUS_RPLY