Difference: RunControl (1 vs. 17)

Revision 16
12 Dec 2009 - Main.JanMichel
Line: 1 to 1
Added:
>
>
META TOPICPARENT name="OutdatedPages"
 

The KISS runcontrol

RunControlSoundServer
Revision 15
24 Apr 2006 - Main.IngoFroehlich
Line: 1 to 1
Added:
>
>

The KISS runcontrol

RunControlSoundServer
 

Users Guide

  1. Current Documentation for the DAQ operator
  2. MEDM Reference Manual
Revision 11
03 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Users Guide

  1. Current Documentation for the DAQ operator
Added:
>
>
  1. MEDM Reference Manual
  2. Alarm Handler Users Guide - alh1.2.10
 

Developers Guide

Added:
>
>
  1. Record Reference Manual
  2. The EPICS genSub Record Reference Manual
  3. IOC Application Developer's Guide R3.14.5
 

Administrators Guide

Currently, quite a few different systems and technologies are
Revision 10
02 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Users Guide

  1. Current Documentation for the DAQ operator

Developers Guide

Line: 29 to 30
  instability seems to be found and fixed, so the whole stuff may be replaced by a simple start of the IOC during system boot.
Changed:
<
<

Event Builder (out of order)

>
>

Event Builder

File Status and Event Rates are monitored by an EPICS IOC in the event builder itself. IOCs under linux normally show up with the process name st.cmd.
ALERT! This IOC is now also started and monitored via the cron daemon, so do not press the button "Run IOC" any more.
  File Status and Event Rates are monitored still by a "Channel Access Server (old style :)" called run_agent on hadeb02. Due to the
Revision 9
02 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

Users Guide

  1. Current Documentation for the DAQ operator

Developers Guide

Line: 29 to 29
  instability seems to be found and fixed, so the whole stuff may be replaced by a simple start of the IOC during system boot.
Changed:
<
<

Event Builder

>
>

Event Builder (out of order)

  File Status and Event Rates are monitored still by a "Channel Access Server (old style :)" called run_agent on hadeb02. Due to the already mentioned stability problems, this is monitored and restarted
Line: 48 to 48
  process name st.cmd.
ALERT! This IOC is now also started and monitored via the cron daemon, so do not press the button "Run IOC" any more.
Changed:
<
<
>
>
 

Oracle

Connection to Oracle run database is done via the tcl_to_ora script.
Revision 8
01 Feb 2005 - Main.BenjaminSailer
Line: 1 to 1
 

Users Guide

  1. Current Documentation for the DAQ operator

Developers Guide

Administrators Guide

Changed:
<
<
Currently, quite a view different systems and technologies are
>
>
Currently, quite a few different systems and technologies are
  involved in delivering data to the run control users interface. Hopefully this may be consolidated some time. In the meantime, here is a short overview.
Revision 7
31 Jan 2005 - Main.MathiasMuench
Line: 1 to 1
 

Users Guide

Changed:
<
<
  1. [[http://www-hades.gsi.de/~hadaq/doc/aug04/daqop.html Current
Documentation for the DAQ operator]]
>
>
  1. Current Documentation for the DAQ operator
 

Developers Guide

Administrators Guide

Revision 6
31 Jan 2005 - Main.MathiasMuench
Line: 1 to 1
 

Users Guide

  1. [[http://www-hades.gsi.de/~hadaq/doc/aug04/daqop.html Current
Documentation for the DAQ operator]]
Line: 49 to 49
  process name st.cmd.
ALERT! This IOC is now also started and monitored via the cron daemon, so do not press the button "Run IOC" any more.
Deleted:
<
<

Oracle (Originally by B. Sailer)

 
Changed:
<
<
Hello all,
>
>

Oracle

 
Changed:
<
<
once again (and after 2 hours, finally), I managed to again restart the program that fills in runs to Oracle (so that they can appear online in the DAQ logbook and analysis can immediately get parameters for the run id).

Basically, the program reads a tcl-file produced by the eventbuilder (currently /home/hadaq/aut04/oper/eb_s.tcl), follows it's progress and dumps every line to Oracle. Frequently check if it is running by

ssh hadeb02 $ ps -fuhadaq | grep tcl_to_ora

if it is not running, You have to check from which point on it crashed (see which was the last run entered to oracle).

The Table daq.run contains all runs (even those not written to file and thus not appearing in the logbook). Check whether a file closing has not correctly written to Oracle (run_stop is (null)) or the run_id has not been set correctly (run_id is (null)). Fix that by pure SQL (or ask an expert for that), then cut the part of the file away, that was already been written to Oracle (probably to a file called "eb_s.tcl__". Now You should stop the eventbuilder process, take the rest and put it to Oracle by

$ cat eb_s.tcl | tcl_to_ora -s hades -e 's/daq_evtbuild/eb1pp/g; s/daq_netmem/eb1gp/g'

then also move this file away, touch a new eb_s.tcl:

$ touch eb_s.tcl

finally restart tracing the file in background by

nohup sh -c "tail -f eb_s.tcl | tcl_to_ora -s hades -p -e 's/daq_evtbuild/eb1pp/g; s/daq_netmem/eb1gp/g'" &

Finally, You can start the eventbuilder process again and check if the new runs appear in Oracle.

-- BenjaminSailer - 24 Aug 2004
>
>
Connection to Oracle run database is done via the tcl_to_ora script.
 

-- MathiasMuench - 28 Jan 2005
Deleted:
<
<
Revision 5
31 Jan 2005 - Main.MathiasMuench
Line: 1 to 1
 

Users Guide

Changed:
<
<
  1. Current Documentation for the DAQ operator
>
>
  1. [[http://www-hades.gsi.de/~hadaq/doc/aug04/daqop.html Current
Documentation for the DAQ operator]]
 

Developers Guide

Administrators Guide

Changed:
<
<
Currently, quite a view different systems and technologies are involved in delivering data to the run control users interface. Hopefully this may be consolidated some time. In the meantime, here is a short overview.
>
>
Currently, quite a view different systems and technologies are involved in delivering data to the run control users interface. Hopefully this may be consolidated some time. In the meantime, here is a short overview.
 

Trigger

Changed:
<
<
Trigger Rates and Busy are monitored by an EPICS IOC on r2f-35. Up to now, this IOC is called foo, not a really good name, but I just start to understand the EPICS naming and directory scheme.
>
>
Trigger Rates and Busy are monitored by an EPICS IOC on r2f-35. Up to now, this IOC is called foo, not a really good name, but I just start to understand the EPICS naming and directory scheme.

This IOC is monitored by a script check_run_agent, which restarts the IOC if it fails. This script itself is called every 10 seconds by the program every, which itself is started during system boot by the script $HOME/etc/rc. This means, that the IOC is started and monitored automatically during system boot. Normally, no intervention should be necessary. On the other hand, if you want to get rid of foo, don't kill the foo process itself, but the every. Remark: The predessor of the IOC (the "Channel Access Server") and also early versions of the IOC itself were quite unstable, therefore this complicated procedure was introduced. The reason for the instability seems to be found and fixed, so the whole stuff may be replaced by a simple start of the IOC during system boot.

Event Builder

 
Changed:
<
<
This IOC is monitored by a script check_run_agent, which restarts the IOC if it fails. This script itself is called every 10 seconds by the program every, which itself is started during system boot by the script $HOME/etc/rc. This means, that the IOC is started and monitored automatically during system boot. Normally, no intervention should be necessary. On the other hand, if you want to get rid of foo, don't kill the foo process itself, but the every.
>
>
File Status and Event Rates are monitored still by a "Channel Access Server (old style :)" called run_agent on hadeb02. Due to the already mentioned stability problems, this is monitored and restarted by a script called watched_run_agent, which itself is started every minute via the cron daemon. Additionally, since the file name cannot be gathered by the run agent, it is extracted from the parameters-store-file eb_s.tcl by the script feedEpics. This is also started every minute by cron. Again, everything is started and monitored automatically. In case of problems, you need to remove the corresponding lines from the crontab by using the command =crontab -e=. Since the EPICS component on the event builder is only a Channel Access Server, it is accompained by an IOC that runs under the "scs" account on lxi015. IOCs under linux normally show up with the process name st.cmd.
ALERT! This IOC is now also started and monitored via the cron daemon, so do not press the button "Run IOC" any more.

Oracle (Originally by B. Sailer)

 
Changed:
<
<
Remark: The predessor of the IOC (the "Channel Access Server") and also early versions of the IOC itself were quite unstable, therefore this complicated procedure was introduced. The reason for the instability seems to be found and fixed, so the whole stuff may be replaced by a simple start of the IOC during system boot.
>
>
Hello all,

once again (and after 2 hours, finally), I managed to again restart the program that fills in runs to Oracle (so that they can appear online in the DAQ logbook and analysis can immediately get parameters for the run id).

Basically, the program reads a tcl-file produced by the eventbuilder (currently /home/hadaq/aut04/oper/eb_s.tcl), follows it's progress and dumps every line to Oracle. Frequently check if it is running by

ssh hadeb02 $ ps -fuhadaq | grep tcl_to_ora

if it is not running, You have to check from which point on it crashed (see which was the last run entered to oracle).

The Table daq.run contains all runs (even those not written to file and thus not appearing in the logbook). Check whether a file closing has not correctly written to Oracle (run_stop is (null)) or the run_id has not been set correctly (run_id is (null)). Fix that by pure SQL (or ask an expert for that), then cut the part of the file away, that was already been written to Oracle (probably to a file called "eb_s.tcl__". Now You should stop the eventbuilder process, take the rest and put it to Oracle by
 
Deleted:
<
<

Event Builder

 
Changed:
<
<
File Status and Event Rates are monitored still by a "Channel Access Server (old style :)" called run_agent on hadeb02. Due to the already mentioned stability problems, this is monitored and restarted by a script called watched_run_agent, which itself is started every minute via the cron daemon. Additionally, since the file name cannot be gathered by the run agent, it is extracted from the parameters-store-file eb_s.tcl by the script feedEpics. This is also started every minute by cron. Again, everything is started and monitored automatically. In case of problems, you need to remove the corresponding lines from the crontab by using the command crontab -e.
>
>
$ cat eb_s.tcl | tcl_to_ora -s hades -e 's/daq_evtbuild/eb1pp/g; s/daq_netmem/eb1gp/g'
 
Changed:
<
<
Since the EPICS component on the event builder is only a Channel Access Server, it is accompained by an IOC that runs under the "scs" account on lxi015. IOCs under linux normally show up with the process name st.cmd.
ALERT! This IOC is now also started and monitored via the cron daemon, so do not press the button "Run IOC" any more.
>
>

then also move this file away, touch a new eb_s.tcl:

$ touch eb_s.tcl

finally restart tracing the file in background by

nohup sh -c "tail -f eb_s.tcl | tcl_to_ora -s hades -p -e 's/daq_evtbuild/eb1pp/g; s/daq_netmem/eb1gp/g'" &

Finally, You can start the eventbuilder process again and check if the new runs appear in Oracle.

-- BenjaminSailer - 24 Aug 2004
 

-- MathiasMuench - 28 Jan 2005
Added:
>
>
Revision 4
28 Jan 2005 - Main.MathiasMuench
Line: 1 to 1
Changed:
<
<
To Mathias: Can we import your web-documentation? Maybe first as an external link?

Already did it, but since it's somewhat complementary to Jörgs stuff, I used the same topic. Needs to stay external first since Alarm Handler has links to it.
>
>

Users Guide

  1. Current Documentation for the DAQ operator
 
Changed:
<
<
Current Documentation for the DAQ operator
>
>

Developers Guide

 
Added:
>
>

Administrators Guide

Currently, quite a view different systems and technologies are involved in delivering data to the run control users interface. Hopefully this may be consolidated some time. In the meantime, here is a short overview.

Trigger

Trigger Rates and Busy are monitored by an EPICS IOC on r2f-35. Up to now, this IOC is called foo, not a really good name, but I just start to understand the EPICS naming and directory scheme.

This IOC is monitored by a script check_run_agent, which restarts the IOC if it fails. This script itself is called every 10 seconds by the program every, which itself is started during system boot by the script $HOME/etc/rc. This means, that the IOC is started and monitored automatically during system boot. Normally, no intervention should be necessary. On the other hand, if you want to get rid of foo, don't kill the foo process itself, but the every.

Remark: The predessor of the IOC (the "Channel Access Server") and also early versions of the IOC itself were quite unstable, therefore this complicated procedure was introduced. The reason for the instability seems to be found and fixed, so the whole stuff may be replaced by a simple start of the IOC during system boot.

Event Builder

File Status and Event Rates are monitored still by a "Channel Access Server (old style :)" called run_agent on hadeb02. Due to the already mentioned stability problems, this is monitored and restarted by a script called watched_run_agent, which itself is started every minute via the cron daemon. Additionally, since the file name cannot be gathered by the run agent, it is extracted from the parameters-store-file eb_s.tcl by the script feedEpics. This is also started every minute by cron. Again, everything is started and monitored automatically. In case of problems, you need to remove the corresponding lines from the crontab by using the command crontab -e.

Since the EPICS component on the event builder is only a Channel Access Server, it is accompained by an IOC that runs under the "scs" account on lxi015. IOCs under linux normally show up with the process name st.cmd.
ALERT! This IOC is now also started and monitored via the cron daemon, so do not press the button "Run IOC" any more.
 

-- MathiasMuench - 28 Jan 2005
Revision 3
28 Jan 2005 - Main.MichaelTraxler
Line: 1 to 1
  To Mathias: Can we import your web-documentation? Maybe first as an external link?
Line: 6 to 6
  Jörgs stuff, I used the same topic. Needs to stay external first since Alarm Handler has links to it.
Changed:
<
<
-- MathiasMuench - 28 Jan 2005
>
>
Current Documentation for the DAQ operator
 
Added:
>
>
-- MathiasMuench - 28 Jan 2005
Revision 2
28 Jan 2005 - Main.MathiasMuench
Line: 1 to 1
Deleted:
<
<
  To Mathias: Can we import your web-documentation? Maybe first as an external link?
Added:
>
>
Already did it, but since it's somewhat complementary to Jörgs stuff, I used the same topic. Needs to stay external first since Alarm Handler has links to it.

-- MathiasMuench - 28 Jan 2005
 
Deleted:
<
<
-- MichaelTraxler - 28 Jan 2005
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)