Low-Energy Muon (LEM) Experiment  0.5.2
Midas Howto
previous.gif Installation - main - VME readout and Storage of Slow Control data next.gif

Start of Midas clients

After installation of Midas, Root, and the Kernel driver for the VME-PCI interface (see Installation page) the following steps will start the Midas experiment on lem00.

Login as local user nemu on lem00, start a terminal and enter

[nemu@lem00]$ nemu_start_midas


to start the Midas clients of experiment Nemu.

This will start (if not running already) the following clients:

  • odbedit in a new console window
  • mhttpd, the Midas web server as daemon on port 80
  • vme_fe, the VME frontend as a daemon (scaler and TDC V1190 readout)
  • lemvac_scfe, LEM apparatus vacuum control
  • bl_scfe, the beam line slow control frontend as daemon
  • hv_fug_scfe, High voltage of FUG supplies slow control frontend as daemon; connects by psts03 terminal server
  • hv_detectors_scfe, High voltage of MCP's and photomultipliers, MSCB node mscb008
  • mod_cryo_scfe, moderator cryostat devices: Lakeshore 340 temperature controller, West6100, XTC; connects by psts03 terminal server
  • sample_scfe, sample cryostat devices: Lakeshore340, danfysik/Bruker magnet supplies, Bronkhorst flow control; connects by psts03 terminal server
  • scs900_scfe, MSCB modules SCS900 (ADC/DAC) and SCS400 (thermocouples, baking control), MSCB node mscb006
  • scs1001_pump_scfe, vacuum control of muE4 beamline between Sep61 and LEM apparatus, MSCB node mscb009, disabled since April 2007.
  • nemu_analyzer, the analyzer is started as daemon, scaler rates accessible through web page
  • lazylogger Script, active since April 2010, copy raw event-by-event data directly to new PSI archive
  • lemSCW, LEM slow control frontend watchdog to restart automatically hanging slow control process
  • mlogger, the Midas logger which writes the data to the history and data files. Note: this client should always be started as last one.

The beamline slow control must be restarted after changing to the correct tcpip parameters (i.e. host=pc451, port=10000 for muE4). In ODB goto /Equipment/Beamline/Settings/Devices/Magnets/BD and change the host and port values accordingly. The remote control for the two beam shutters KV61/62 is done through the piE1 beam line server pc130.

As run control you may use either odbedit or the web browser interface. For the latter start a Web browser an goto address http://lem00.

Setup of Online Data Base (ODB)

The setup of ODB parameters usually needs some manual work if the experiment is setup for the first time. This can be done either by using odbedit or the Midas status web page.

At begin-of-run the ODB is dumped into the ASCII file last.odb, and at end-of-run it is dumped in a file nemu_%02d_%04d.odb (with 2 digits for the year and 4 digits representing the run number). If the ODB gets corrupted or lost these ODB dumps can be used to recover the ODB (see Recovery of Midas).

Some ODB keys are used by Midas clients. In order to open/create/write/hot-link ODB records by the clients c-structures can be automatically defined by entering 

 [local:nemu:S]/> make

This will create experim.h which is included by the frontend and analyzer clients. So, if the ODB completely gets lost the frontends and analyzer will re-create that fraction of ODB that was used by them.

Stopping and restarting Midas clients

If you have to restart a Midas client you can either use odbedit or the Programs button on the Midas status web page. In odbedit you have to enter 

 [local:nemu:S]/> sh <client_name>

Note:
When re-starting vme_fe and nemu_analyzer it could be necessary to restart the mlogger client as well.

If the shut down of a Midas client fails, you may try it once more. If this still does not work you can either try to kill the client manually followed by entering cleanup in odbedit, or you try a complete Recovery of Midas.

Recovery of Midas

It may happen that one or more clients are hanging, or that there are problems accessing the Online Data Base (ODB). In that case all Midas clients have to be stopped and shared memory segments and semaphores have to be cleaned up. For this purpose execute the shell script nemu_mcleanup. Enter

[nemu@lem00]$ nemu_mcleanup


do stop and remove all Midas clients

Alternatively you an try to do it manually:
In odbedit enter:

      [local:nemu:S]/> sh all
      [local:nemu:S]/> cleanup
      [local:nemu:S]/> exit

Enter mcleanup in a terminal to free shared memory segments and semaphores. You can check it by typing ipcs after mcleanup. There shouldn't be any segments and semaphores left for user nemu. It should look like that: 

[nemu@lem00 nemu]$ ipcs
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
------ Semaphore Arrays --------
key        semid      owner      perms      nsems
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

With Midas clients active it looks like:

[nemu@lem00 nemu]$ ipcs
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x4d400004 458753     nemu      666        1076284    6
0x4d400005 491522     nemu      666        109532     6
0x4d400007 524291     nemu      666        1058108    4
------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x4d400002 524288     nemu      666        1
0x4d400003 557057     nemu      666        1
0x4d400004 589826     nemu      666        1
0x4d400005 622595     nemu      666        1
0x4d400007 655364     nemu      666        1
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages
After a successful shutdown of Midas enter nemu_start_midas to restart the Midas clients.

 

 Note: it can happen that the ODB and its disk dump (the .*.SHM files in the Midas data directory) are getting corrupt so that the restart of Midas clients can fail or is accompanied by ODB errors. In this case after stopping and removing of all Midas clients the .*.SHM files have to be deleted in /data/nemu. This leads to a loss of the ODB. However, at the end of each run an ASCII dump of the ODB is written to disk (lem07_2055.odb, for example). This file can be reloaded to ODB if the ODB was getting lost. Start odbedit and enter 


  [local:nemu:S]/> load /data/nemu/odb/2007/lem07_2055.odb
  
 to recover the ODB of run 2055 of year 2007.

 To recover the last backup-to-PSIarchive information do: 


  [local:nemu:S]/> load /data/nemu/dlog/Script_recover.odb
  
 previous.gif  Installation - main - VME readout and Storage of Slow Control data  next.gif