User Tools

Site Tools


projects:bpm-sis18:status

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
projects:bpm-sis18:status [2012/07/12 14:40]
rhaseitl
projects:bpm-sis18:status [2012/07/13 09:11] (current)
klang
Line 2: Line 2:
  
 Errors occurring sporadically: Errors occurring sporadically:
-  * the Liberas loose their connection: they appear red in the detailed status panel, giving the status "Software Error" or "BPM Communication Error". The Libera can not be controlled from TOPOS any more. Most of the time, a reboot of the Liberavia ssh helps. +  * the Liberas loose their connection: they appear red in the detailed status panel, giving the status "Software Error" or "BPM Communication Error". The Libera can not be controlled from TOPOS any more. Most of the time, a reboot of the Libera via ssh helps. 
 In at least one case, I also had to restart the FESA classes on the CCCPs to make the system working again. In at least one case, I also had to restart the FESA classes on the CCCPs to make the system working again.
 This happens sometimes during beamtime. Or after the system was not used for a while and is started again (= the GUI was closed for a while and is started again). This happens sometimes during beamtime. Or after the system was not used for a while and is started again (= the GUI was closed for a while and is started again).
Line 10: Line 10:
   * aux BPM confuses the whole system (Start and Stop is triggered "out of itself")   * aux BPM confuses the whole system (Start and Stop is triggered "out of itself")
   * low system performance (switching of mode lasts several seconds)   * low system performance (switching of mode lasts several seconds)
 +
 +Bunch detection / Measurment data errors (KL): 
 +  * Under certain beam/signal conditions, Liberas deliver errernous measurment data. This causes TOPOS to display hard or not usable results.
  
 == Debugging ideas: == == Debugging ideas: ==
Line 22: Line 25:
   * connection to BPM established/lost/reconnected   * connection to BPM established/lost/reconnected
   * debug output at every status change of the system (Initializing, Start, Stop,...)   * debug output at every status change of the system (Initializing, Start, Stop,...)
 +  * logging should use the Log4j framework (from within the FESA class possible with SDLog (HBr))
 +  * the GUI should **not** encapsulate exceptions thrown by cmw / rda into its own Exception class (HBr)
 +  * a detailed documentation of the meaning and reasns for each error message, exception etc. should be made (HBr)
  
 \\ \\
Line 32: Line 38:
   * log any other useful events   * log any other useful events
   * log buffer overflows   * log buffer overflows
 +  * there seem to be logs on the liberas under /var/log. But without timestamps. When a separate network for the Liberas is used, the time can't be queried from a global NTP server. -> Setup a "proxy" on the concentrators?
  
 \\ \\
Line 37: Line 44:
   * put the Liberas into a own network (not the GSI/ACC network)   * put the Liberas into a own network (not the GSI/ACC network)
   * bootfile on CCCPs, static IPs, nfs mount to store debug logs   * bootfile on CCCPs, static IPs, nfs mount to store debug logs
-  * is this a lot of work? does it require changes in the gen servers / FPGA code?+  * is this a lot of work? does it require changes in the gen servers / FPGA code (Change of FPGA code won't be necessary for this issue (KL))?
  
 \\ \\
Line 43: Line 50:
   * Display the connection status and if a command which has been sent, was "acknowledge" by the PTIF. Can give a hint, when the PTIF seems to be reachable by TCP/IP but the FESA class is not sending commands. Test case: Pull network cable and reconnect. System should be able to detect this, if the PTIF cannot be controlled afterwards.   * Display the connection status and if a command which has been sent, was "acknowledge" by the PTIF. Can give a hint, when the PTIF seems to be reachable by TCP/IP but the FESA class is not sending commands. Test case: Pull network cable and reconnect. System should be able to detect this, if the PTIF cannot be controlled afterwards.
  
-**Would it make sense to have simple standalone tool to see if the FESA serversthe BPMs, the gen servers are up and running without an error flag?! In principle this information is provided by the default status panel, but you have to be an expert to interpret some errors. There might be a button to query all devices. **+Have a standalone tool to see ALL system components directly: FESA server classesCCCPs, Liberas (pingable), the gen servers (are up and running?), show error flags. It might be a good idea to have a button for each component to perform a check. E.g. perform a ping for the Liberas and CCCPs. Or perform a data query from the FESA classes. 
 +Some of this information is provided by the detailed status panel, but you have to be an expert to interpret some errors. 
  
-YesI think it does! (HBr)+\\ 
 +GUI improvements for wrong measurement data (KL): 
 +  * A strong indicator for wrong measurment are the window lengths. Two indicatorswhich can be easily identified, are negative window lengths and window lengths bigger than 1.17 us (150 samples). If one of these conditions is met, the relating position can be marked as errorneous. Therefore a concept can be considered, which shows these errors somehow in the GUI.
  
 == Goals == == Goals ==
Line 52: Line 62:
 Provide tools to observe the health status of the system components. Provide tools to observe the health status of the system components.
  
-Some issues (HBr): +
-  * logging should use the Log4j framework (from within the FESA class possible with SDLog (HBr)) +
-  * the GUI should **not** encapsulate exceptions thrown by cmw / rda into its own Exception class +
-  * a detailed documentation of the meaning and reasns for each error message, exception etc. should be made+
  
 Some more considerations (MSchw): Some more considerations (MSchw):
projects/bpm-sis18/status.1342096840.txt.gz · Last modified: 2012/07/12 14:40 by rhaseitl