Tipps für die Rufbereitschaft - Device Access

Achtung! Diese Seite wird im Moment (März 2018) grundlegend überarbeitet!

Siehe auch Device Access Developments using Maven and SCons und dort u.a. Administrate Nameserver und Administrate UfcServer



Allgemeine Tipps

Tools

Alle Tools, in der Regel für die Commandline, sind unter CSCOFE Tools Overview kurz beschrieben. Dort findet man auch die Preconditions, um die Tools nutzen zu können.

Alle Tools (nun, fast alle) haben eine Kurz- und eine Langbeschreibung. Einfach mit <tool> -h bzw. <tool> -H aufrufen.

Für den Zugriff auf alle Properties eines Gerätes gibt es das graphische Tool prophelper. Der prophelper entspricht in etwa dem FESA-Explorer. Aufruf: prophelper und dann Gerätenomenklatur im Fenster eintippen, oder Gerätenomenklatur beim Aufruf angeben: prophelper <Gerätenomenklatur> .

Architektur

Device Acces und FESA sind recht ähnlich aufgebaut (mit Unterschieden im Detail): Geräte werden über die Nomenklatur identifiziert, Eigenschaften über Properties modelliert, Daten sind zumeist gemultiplexed (nach virtuellen Beschleunigern), und die zeitlichen Abläufe werden über ein Timing-System getriggert.

Einige Einzelheiten: Siehe bei Aufbau Device Access.

Liste der Terminalserver

Die Liste der Terminalserver, deren Ports direkt mit einem GuP oder einer SE verbunden sind.

Mit telnet kommt man damit
  • direkt auf die Konsole des GuP oder
  • auf das lokale Display der SE mit der Möglichkeit der Bedienung über ein Menü.

Beispiel: telnet kp1ct01.acc.gsi.de 2011

Die Terminal-Server selbst erreicht man via Browser (Firefox) über z.B. kp1ct01.acc.gsi.de.

Tipps für Server-Programme

Nameserver administrieren

Der Nameserver verwaltet alle Nomenklaturen in Device Access. Weiteres siehe Nameserver administrieren und warten

UfcServer / Userface administrieren

Siehe Userface und Userface Server administrieren und warten

Tipps für den PPC-GuP

Administration des DevMan

Auf den Front-Ends, die unter RH6 (acc6) laufen, gibt es keinen service mehr wie auf RH5, mit dem der DevMan gestartet werden kann. Zur Administration des DevMan ist direkt ein Script auf dem jeweilingen Front-End aufzurufen:

/etc/init/boot.d/95_devman [status|start|stop|restart]

oder direkt auf einer asl-Maschine

ssh root@<GuP> /etc/init/boot.d/95_devman [status|start|stop|restart]

Zu Front-End Systemen, die unter RH6 laufen, sind einige Einzelheiten auf einer eigenen Wiki-Seite beschrieben.

Service Devman

Hinweise dazu gibt es in Devman unter Linux administrieren/warten unter der Überschrift Service DevMan.

Unter RH6 haben die GuPs (fast) keine NFS-Platten mehr. Die Software wird beim Boot von Linux als ZIP-File vom Server (asl-Cluster) geholt, vor Ort ausgepackt und anschließend der Devman gestartet.

Achtung: Ein /etc/init/boot.d/95_devman restart holt keine neue Software vom Server! Das geht nur mit einem reboot auf <GuP> oder mit ssh root@<GuP> =/sbin/reboot von einer asl-Maschine aus.

Mit cdcpu <GuP> auf asl73x kommt man zum Verzeichnis, von dem der GuP das ZIP-File holt.

Auf diesem Verzeichnis liegt auch die Konfigurationsdatei <GuP>.dbs, die ebenfalls beim Boot von Linux vom Server geholt wird. Nutzt man dbsgen <GuP> und dbscopy <GuP>, dann kopiert dbscopy die Datei <GuP>.dbs auch direkt zum GuP. Zum Einlesen der Datei reicht in diesem Fall also /etc/init/boot.d/95_devman restart.

Gerätezugriffe nicht mehr möglich

Das kann verschiedene Ursachen haben.

1. No device(s) found

Nomenklatur ist dem Nameserver nicht bekannt. Es hat sich bisher nie ein Gerät dieses Namens beim Nameserver angemeldet. Ist die Nomenklatur korrekt geschrieben? Alle echten Geräte-Nomenklaturen beginnen mit einem G, GuPs und SEs nicht.

2. ODA-E-CORBATRANSIENT, Caught CORBA::TRANSIENT exception

Nomenklatur und Objekt-Referenz sind dem Nameserver bekannt, aber das Objekt existiert (zur Zeit) nicht im Kontrollsystem. Das kann daran liegen, dass der Devman nicht mehr läuft.

Wie sieht man das? Auf dem PPC-GuP einloggen. Zum Beispiel von asl730 aus:

asl743$ ssh root@kp1cg01                                                                                                                                   
root@kp1cg01's password: 

und den Process Status angucken

  [root@kp1cg01 ~]# ps -A
    PID TTY          TIME CMD
    ... ...      ...
   6821 ?        00:02:16 devman
    ... ...      ...
  18764 ttyp2    00:00:00 bash
  18802 ttyp1    00:00:00 ps

in dessen Liste man den Devman finden muss. Ist die Liste lang, kann man auch

[root@kp1cg01 ~]# ps -A | grep devman
  278 root       0:00 /bin/daemon --noconfig --name=devman-daemon --pidfile=/var/run/devman.pid --chdir=/ --inherit --unsafe 
                                  --respawn --errlog=local0.err --dbglog=local0.info --output=local0.info --stdout=local0.info 
                                  --stderr=local0.err --core -- /bin/devman --persistent
  279 root      77:29 /bin/devman --persistent

versuchen.

Der /bin/daemon überwacht den Devman und startet ihn gegebenenfalls wieder, falls er einmal abgestürzt ist. Nach mehreren kurz aufeinanderfolgenden Startversuchen bricht der Dämon ab. Den Grund sollte man in Logstash finden. Ist der Grund beseitigt, sollte man mit reboot ganz neu starten.

3. XSR-E-DEV_UNKNOWN, Gerät ist unbekannt, Geräteadresse nicht vorhanden

Die Nomenklatur und die zugehörige Interfacekarten-Adresse (Log Dev) sind dem GuP bekannt, es wurde aber auf keiner seiner SEs, die die entsprechende Geräte-Software enthält, eine Interface-Karte (IFK) mit dieser Adresse gefunden.

Gründe können sein:
  • Das Gerät mit dieser Interfacekarte ist komplett, also inklusive Interface, ausgeschaltet und war seit dem letzten Init der SE nie eingeschaltet.
  • Der Nomenklatur wurde eine falsche IFK-Adresse zugeordnet. Dann müsste man mit ecconfig eine IFK-Adresse mit der Nomenklatur NODEVICE auf einer der SEs des GuPs finden:
    Log  IFB                   Support  Active             Therapy   Master      Slave       Therapy
    Dev  Address   Device      Status   State   Workmode   Lock      Error Cnt   Error Cnt   Mem.Offset
    ---  --------  ----------  -------  ------  ---------  --------  ----------  ----------  ----------
    133  163/0xA3  NODEVICE    known    0x0000  normal     unlocked           0           0  0x00000000

4. XSR-E-DEV_OFFLINE, Gerät ist offline

Das Gerät mit dieser Nomenklatur war schon mal online, seine IFK ist im Moment aber von der SE nicht erreichbar.

Es lohnt sich, in diesem Fall mal mit ecconfig auf die EC/SE zu gucken. In Ausnahmefällen ist das Gerät dort nämlich online:
  1. mit devdesc NOMEN den EC/SE-Namen herausfinden
  2. mit ecconfig EC_NOMEN auf EC/SE schauen:
Log  IFB                   Support  Active             Therapy   Master      Slave       Therapy
Dev  Address   Device      Status   State   Workmode   Lock      Error Cnt   Error Cnt   Mem.Offset
---  --------  ----------  -------  ------  ---------  --------  ----------  ----------  ----------
133  163/0xA3  GTK1MU1     online   0x0000  normal     unlocked           0           0  0x00000000

Dann sind GuP und SE mit der Geräteliste durcheinandergekommen. Das passiert, wenn eine SE inklusive Neuaufbau der Geräteliste initialisiert wird, z.B. mit vmeboot -i <EC/SE-Nomen>. In diesem Fall hilft ein Restart des Devman:

$ remotegupcmd kp1cg01 "service devman restart"          # nur im acc7 cluster
$ ssh root@kp1cg01 "etc/init/boot.d/95_devman restart"   # im acc6 und acc7 cluster
5. XSR-E-DEV_DOUBLE, Geräteadresse ist mehrfach vorhanden

Das Gerät mit dieser Nomenklatur ist bei zwei SEs angemeldet.

Mehr Information mit
$ double-devs EC_NOMEN

Beide SEs initialisieren mit vmeboot -i.

GuP Geräteliste neuaufbauen wie 4.

Devman Logs und Alarme

Devman logged komplett in Logstash. Als Filter kann man z.B. logsource:kp1cg01 angeben.

Will man sich nur Alarme angucken, dann in Logstash oben rechts das Load-Icon ("Load Saved Search") anklicken und "Alarm" auswählen.

Devman Core Dump debuggen

Stürzt ein Devman ab, dann sollte er einen Core Dump anlegen. Diese Datei liegt auf dem CPU-spezifischen Verzeichnis /opt/acc/cpu und heißt core.<pid>, wobei <pid> die Prozess-ID des abgestürzten Devman ist.

Mit dem GDB kann man sich angucken, was passiert ist.

  bash-2.05b# cd /opt/acc/cpu
  bash-2.05b# gdb library/devman core.1234

Das Kommando backtrace beschreibt, welche Funktionen vor dem Absturz aufgerufen wurden. Die letzte Funktion die aufgerufen wurde, hat die Index Nummer #0.

  (gdb) bt
  #0  0x1002d354 in DeviceAccess::StatusUpdThread::run(void*) (this=0x100e73b0) 
      at statusupdthread.cc:54
  #1  0x0fad4e58 in omni_thread_wrapper () from /usr/local/lib/libomnithread.so.3
  #2  ...

Im Internet kann man sich unter Analyzing Core Dumps eine kurze Einführung angucken. Näheres muss noch erforscht werden.

MAC- und IP-Adresse eines PPC-GuPs

MAC- ( HWaddr) und IP-Adresse ( inet addr) bekommt man mit

[root@kp1cg01 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:40:42:01:54:7D  
          inet addr:140.181.128.62  Bcast:140.181.191.255  Mask:255.255.192.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:143809 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38327 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000 
          RX bytes:23405266 (22.3 MiB)  TX bytes:4721140 (4.5 MiB)
          Base address:0x8400 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

auf dem fraglichen PPC heraus.

Auf welcher SE befindet sich ein Gerät?

GuP und SE eines Gerätes findet man mit devdesc heraus. Dabei sind auch die Wildcards * und ? erlaubt.

$ devdesc gte4dg?

          Dev.  Equip.-Model
Nomen     Addr  Name     Num  DevMan    EC        Host
--------  ----  -------  ---  --------  --------  -------------------
GTE4DG5     48   DGX_05   67  KE3CG01   KE3CS011  ke3cg01.acc.gsi.de
GTE4DG8     83   DGX_05   67  KE3CG01   KE3CS012  ke3cg01.acc.gsi.de
GTE4DG9     49   DGX_05   67  KE3CG01   KE3CS011  ke3cg01.acc.gsi.de
GTE4DGC     50   DGX_05   67  KE3CG01   KE3CS011  ke3cg01.acc.gsi.de 

Download EQMs

EQMs werden mit ecload geladen. Ecload hat ein kurzes Help, das man mit

  $ ecload -h

erhält.

Datei schicken:

  $ ecload -v ~/workspace/mx/mx-eqms.sr ke3cs082

Ecload schickt die komplette sr-Datei an den GuP.

Vor dem Laden von VME-Produktionssoftware sollte die Software korrekt released sein. Durch den Release-Vorgang wird das .sr File automatisch in die richtige SE-Directory kopiert. Zum SE-Directory kommt man mit cdcpu <SE-Name>.

Ecload ist ein Python-Skript, das das Modul devacc.py benötigt, welches wiederum den Nameservice benutzt. Nutzt man nicht den Alias ecload, sondern ruft das Skript exlizit auf, was man nur in Ausnahmefällen tun sollte, z.B. mit

  $ $utivme/ecload.py -v ...

dann muss man vorher sicherstellen, dass der LD_LIBRARY_PATH auch auf $libasl zeigt.

  $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$libasl

Das braucht man natürlich nur einmal nach dem Einloggen. Hat man's vergessen, dann führt der Aufruf von ecload zu einer entsprechenden (ausführlichen) Fehlermeldung.

Python-Programme zum Lesen einiger GuP-Properties

Siehe dazu auch CSCOFE Tools Overview.

Geräte-Beschreibung (Property DEVDESC) lesen.
Hier bekommt man unter anderem heraus, auf welcher SE ein Gerät läuft.

  asl731$ devdesc -a ktrcg01

            Dev.  Equip. Model
  Nomen     Addr  Name     Num  DevMan    EC        Host
  --------  ----  -------  ---  --------  --------  -------------------
  TR2BB1      17  HFU_13    48  KTRCG01   KTRCS013  ktrcg01.acc.gsi.de
  TR2DP3      33  DPX_03    29  KTRCG01   KTRCS014  ktrcg01.acc.gsi.de
  TR2KY3       6  MD_20     38  KTRCG01   KTRCS011  ktrcg01.acc.gsi.de
  ...

Property-Beschreibung (Property PROPDESC) lesen.

  asl731$ propdesc tr3kx5

                                                       Userface (V08)
  Property   Category   Mode    Medlock   Access    Para type  Data type
  --------   --------   -----   -------   --------  ---------  ---------
  ACTIV      Slave      Read    None      Free      none       BitSet16
  ACTIV      Slave      Write   VrtAcc    Device    none       BitSet16
  CALC       Master     Read    None      Free      none       none
  ...
  CURRENTI   Master     Read    None      Free      none       none
  CURRENTS   Master     Read    None      Free      none       none
  CURRENTS   Master     Write   All       Device    none       none
  ...

Status eines Gerätes, einer SE oder aller Geräte, inklusive SEs und GuP, eines GuPs lesen.

  asl731$ devstatus -a ktrcg01

   KTRCG01: Status = 0xFFFFFFFF
  KTRCS011: Status = 0xFFF3DBFF
  KTRCS012: Status = 0xFFF3DBFF
  KTRCS013: Status = 0xFFF3DBFF
  KTRCS014: Status = 0xFFF3DBFF
    TR2BB1: Status = 0x0002F1FE
    TR2BB2: XSR-E-DEV_OFFLINE, Gerät ist offline
    TR2DP3: Status = 0xFFFFFFFF
    TR2DP4: Status = 0xFFFFFFFF
    ...

Alle asynchronen Requests auf einem GuP tabellarisch oder die Requests eines Gerätes in ausführlicher Form angucken.

  asl724$ reqdesc -a kp1cg01
  getting devices of kp1cg01...
  
                            Async  ---------- Client ----------
  Nomen     Property  Acc      ID  Host                     PID
  --------  --------  ---  ------  --------------------  ------
  KP1CG01   No pending asynchronous requests
  LH1MU1    POWER      -1     136  asl724.acc.gsi.de        609
  LH1MU2    POWER      -1     137  asl724.acc.gsi.de        609
  LH1MU3    POWER      -1     138  asl724.acc.gsi.de        609
  LH1MU4    No pending asynchronous requests
  LH2MU1    No pending asynchronous requests


  asl724$ reqdesc -l lh1mu1

  Long display of pending asynchronous requests of LH1MU1
  -------------------------------------------------------------
  Request 1
    Property
      Name = POWER, Mode = Read, Callmode = Standard
      VrtAcc = -1, Parameter size = 1, Data size = 0
    Setup time = 01.Jan.1970  08:03:27 + 29ms UTC
    Response ID
      Async ID = 168, ExeCnt = 1
      Nomen = LH1MU1, Property = POWER
    Client Access ID
      Host = asl724.acc.gsi.de
      User name = hechler, UID = 609
      Process name = request, PID = 31510, LWP ID = 31510
      Process description = (none)
      Access pattern = 0x34633238
    Exit status = False, thread is running

Alle Konnektierungen auf einem GuP tabellarisch oder die Konnektierungen eines Gerätes in ausführlicher Form angucken.

asl724$ conndesc -ai kp1cg01
getting devices of kp1cg01...

                         - Peri -  - Evnt -   Async  Response      Exec  ---------- Client ----------
Device    Property  Acc      dt/s  Evt  Acc      ID     Count     Count  Host                     PID
--------  --------  ---  --------  ---  ---  ------  --------  --------  --------------------  ------
LH1MU1    STATUS      1      1.00   --   --     200        13        13  asl724.acc.gsi.de       9102
LH1MU2    STATUS      1      1.00   --   --     201        13        13  asl724.acc.gsi.de       9102
LH1MU3    POWER       3        --   55    3     202         7         7  asl724.acc.gsi.de       9102


asl724$ conndesc -l lh1mu1

Long display of connections of LH1MU1
-------------------------------------------------------
Connection 1
  Property
    Name = STATUS, Mode = Read, Callmode = Standard
    VrtAcc = 1, Parameter size = 0, Data size = 1
  Periodical connection
    dt = 1.00s
    Setup time = 30.Jul.2010  09:20:58 + 448ms UTC
    Responses to client = 7, Thread executions = 7
  Response ID
    Async ID = 204, ResponseCnt = 7, ExeCnt = 7
    Device = LH1MU1, Property = STATUS
  Client Access ID
    Host = asl724.acc.gsi.de
    User name = hechler, UID = 609
    Process name = peri, PID = 10191, LWP ID = 10191
    Process description = (none)
    Access pattern = 0x34633238
  Exit status = False, thread is running

VME-Software eines GuPs und seiner SEs lesen.

  asl711$ vme-software ktrcg01

  ----- USRs -----

  Eq-model    No  Version
  --------  ----  -------------
  DMAN_01     76  DMAN 10.09.00
  DPX_03      29  DPX  10.00.00
  EC_20       14  EC   10.08.01
  HFU_13      48  HFU  10.00.00
  MD_20       38  MD   10.09.09

  ----- EQMs -----

  EC        HW    ECM           MIL            EQMs           Variant
  --------  ----  ------------  -------------  -------------  ------------
  KTRCS011  G F4  10.09  May08  CMIL 10.09     MD   10.09.09  Perm. 8bit
  KTRCS012  G F4  10.09  May08  CMIL 10.09     MD   10.09.09  Perm. 24bit
  KTRCS013  G F4  10.09  May08  CMIL 10.09     HFU  10.00.00  HFU-HITRAP
  KTRCS014  G F4  10.09  May08  CMIL 10.09     DPX  10.00.00  DPX normal

Es gibt noch weitere Python-Programme. Einfach mal ausprobieren. Man kann nix kaputt machen, weil es sich bisher nur um Lese-Properties handelt.

PPC-GuP austauschen

TODO!

Tipps für den microIOC

Systemumgebung

Einloggen: Auf dem microIOC funktioniert kein telnet - einloggen per ssh als der bei den PowerPCs gewohnte Benutzer tut es auch.

Der microIOC arbeitet mit einem rein lokalen Filesystem. Directories sind daher nicht über das Filesystem des asl-Clusters zugänglich. Achtung: Aktuell (ab Frühjahr/Sommer 2014) mounted der microIOC auch Teile des Files-Systems des asl-Clusters, siehe next topic.

Die Systemumgebung des microIOC ist eher sparsam ausgestattet. Die Auswahl an vorhandenen utilities ist auf das wesentliche reduziert. Als Editor sind z.B. vi/vim verfügbar.

Stand von Juli/August 2014

Das Eine oder Andere der folgenden Ausführungen scheint sich geändert zu haben. An anderer Stelle sind weiterführende Informationen über den MicroIOC zu finden.zu finden. Einige wichtige Informationen auch an dieser Stelle.

Start des DevMan

Der DevMan wird über ein init-Script gestartet, was beim Booten aufgerufen wird. Das Init-Script scheint auf dem microIOC (auf dem microIOC einloggen, geht weiterhin per ssh) zu liegen unter /opt/nfsinit/<Name des microIOC >/ und heißt z. B. <Nummer>_devacc. (etwa 70_devacc).

Unter /opt/nfsinit/ liegen die Init-Scripte aller microIOCs, jeweils unter dem Namen der microIOCs. Der jeweilige microIOC sucht sich das passende unter seinem Rechnernamen.
Filesystem

Der microIOC mounted Filesysteme, die im RH5-Cluster irgendwo unter /common/usr/export/ zu finden sind. Das wird z.B. für Konfigurationsfiles verwendet.

Beispiel Schrittmotor-Steuerung (Gerätemodell DSM):
  • Auf dem microIOC
    • Datenbasis: /opt/devacc/local/tstci05/tstci05.dbs
    • Konfigurationsfiles: Unter /opt/slits/conf/ (z.B. /opt/slits/conf/pmacProperties.ini)
  • Im asl-Cluster:
    • Datenbasis: /common/usr/export/devacc/local/tstci05/tstci05.dbs
    • Konfigurationsfiles: Unter /common/usr/export/data/tstci05/conf/

Start / Stop des Devman

Der Service heißt auf dem microIOC service-devman und kann wie folgt aufgerufen werden:

  $ service-devman status
  $ service-devman start
  $ service-devman stop
  $ ...

Bei Problemen beim Start des Devman siehe auch Service Devman startet nicht .

Logfiles

Die Logfiles des Devman finden sich in dem gleichen Directory-Baum wie bei den PowerPCs (z.B. /common/log01/logs/kueci01/).

Devman Core Dump vom microIOC debuggen - gilt nur für DSME

Stürzt ein Devman ab, dann sollte er nun einen Core Dump anlegen. Diese Datei liegt auf dem CPU-spezifischen Verzeichnis /opt/acc/cpu und heißt core.<pid>, wobei <pid> die Prozess-ID des abgestürzten Devman ist.

Mit einem GDB kann man sich die Datei näher anschauen. Da auf dem microIOC kein GDB installiert ist, muss man in die Entwicklungsumgebung wechseln.

1. Core dump in die Entwicklungsumgebung kopieren

  $ cd /opt/acc/cpu
  $ scp core.<pid> root@belpc060.acc.gsi.de:/home/herlo/uiocdev-1.1.0/epics/ioc-devman/lib/.

2. In die Entwicklungsumgebung wechseln

  $ ssh root@belpc060.acc.gsi.de

3. Starten der Entwicklungsumgebung

  $ devenv

4. In das lib-Verzeichnis wechseln

  $ cd /epics/ioc-devman/lib

5. Core dump debuggen

  $ gdb devman core.1234
  (gdb) backtrace 

Das Kommando backtrace (bt) beschreibt, welche Funktionen vor dem Absturz aufgerufen wurden. Die letzte Funktion die aufgerufen wurde, hat die Index Nummer #0.

Besonderheiten der allgemeinen Schrittmotor-Steuerung

Die MBox-Steuerung hat kein lokales Bedienfeld. Stattdessen gibt es ein spezielles remote-Bedienprogramm. Dieses benutzt nicht die Kontrollsystem-Schnittstelle, sondern verwendet einen unabhängigen Kommunikationsweg. Dieses Bedienprogramm ist damit auch funktionsfähig, wenn Kontrollsytem-Komponenten nicht verfügbar sind.

Über dieses Bedienprogramm können die Schrittmotoren konfiguriert und auch verfahren werden. Dazu werden die Schrittmotoren auf lokale Bedienung geschaltet. In diesem Zustand werden Schreibzugriffe uber das Kontrollsystem abgewiesen (Meldung %DSM-W-LOCAL, Device is in local control). Der local-Zustand wird im Gerätestatus angezeigt. Es ist vereinbart, dass nach einer gewissen Zeit der Nicht-Bedienung des lokalen Bedienprogrammes der Zugriff automatisch auf remote (d.h. Bedienung über das Kontrollsytem) zurückfällt. Der Verfasser dieser Zeilen hat eigenhändig festgestellt, dass dieser automatische Rückfall auf remote nach einigen Minuten der Nicht-Bedienung tatsächlich erfolgt ist (Zeit wurde nicht gemessen, aber es waren 'wenige' Minuten).

Die Betreuer der Schrittmotoren in der Strahldiagnose-Gruppe sind in das Bedienprogramm eingewiesen.

Besonderheiten des Antriebs des SIS-Septums

Fehlermeldung: DSME_W_INTERLOCK

Im Elektronikraum gibt es einen Schlüsselschalter, der die Schrittmotoren des Septums verriegeln kann (Interlock). Ist der Schlüsselschalter aktiviert kann das Septum nicht verfahren werden. Der Schlüsselschalter ist im gleichen Rack wie der microIOC eingebaut. Einen Schlüssel für diesen Schlüsselschalter wird im HKR in einem Panzerkasten aufbewahrt. Der Schlüssel hat die Nummer 18. Nach dem deaktivieren des Schlüsselschalters kann das Septum wieder verfahren werden.

Java-Applikation zeigt eine vorhandene Verbindung zu dem Gerät an. Das Gerät oder die Applikation verhält sich aber nicht wie gewünscht.

Läuft die Applikation auf dem Notebook der Arbeitsgruppe von Herr Blell, könnte es an Netzwerkproblemen liegen. Das Notebook hat schon mehrfach Probleme mit dem Netzwerk gezeigt. Schließt und startet man die Applikation könnte es dann funktionieren.

Die Bedienungsfelder oder ?-Buttons sind grau hinterlegt

Die Java-Applikation lässt sich nur im Expertenmodus bedienen. Unter dem Menü-Punkt " File " kann man in den Expertenmodus wechseln.

Anmerkung: Das Passwort für die Java-Applikation auf dem Notebook der Arbeitsgruppe von Herrn Blell ist das gleiche Passwort wie für den "local Admin" des Notebboks.

Tipps für die SEs

Init inklusive Neuaufbau der Geräteliste

Seit der ECM-Version 08.64 oder 09.18 wird beim INIT einer SE die Liste der logischen Geräte im DPRAM nicht mehr standardmässig initialisiert. Damit wird verhindert, dass im Falle einer Neuordnung der Liste auf der SE-Seite die deviceDataPtr auf der GuP-Seite falsch werden können (und sei es auch nur für eine kurze Zeit). In den meisten Fällen merken sich die xxxDevices in den privaten Attributen einen Pointer auf die Daten im DPRAM.

Sollte jetzt ausdrücklich eine Intialisierung der Geräteliste auf SE-Seite notwendig sein, dann muss man die INIT-Property mit dem entsprechenden Parameter aufrufen.

Notiz: es wurde mehrfach beobachtet bei SEs, die mehr als 16 Monate ohne restart durchgelaufen sind, dass 'Dinge' passieren, für die es keine plausible Erklärung gibt. Auch da hat sich ein Init der SE als hilfreich erwiesen.

ALERT! Achtung: Nach dem Init der SE ist ein Restart des Devman unbedingt notwendig!

Init mit Hilfe von vmeboot:

$ vmeboot -i uktcs3e2

Init interaktiv unter Python (Wert des Parameters: 32(dez) bzw. 20(hex)):

>>> import devacc
>>> devacc.Device("uktcs3e2").call("init", 32)

...und Restart des Devman:

$ remotegupcmd kp1cg01 "service devman restart"          # GuPs im acc5 cluster
$ ssh root@kp1cg25 "etc/init/boot.d/99_devman restart"   # GuPs im acc6 cluster (could also be 95_devman_restart)

Notiz: der Neuaufbau der Geraeteliste kann auch hilfreich sein, wenn die Sollwerte nur sporadisch angenommen werden. D.h. vmeboot -i <GuP>, reboot <GuP>

SE austauschen

  • Gucken, von welcher Hardware (HW) die SE ist; z.B. KE3CS058 am GuP KE3CG05:
    asl733$ vme-software KE3CG05 
    ...
    ----- EQMs ----- EC HW ECM MIL EQMs Variant ---------- ---- ------------ ------------- ------------- ------------
    ...
    KE3CS058 G F4 10.05 Mar16 CMIL 10.26 TGX 10.00.03 ESR
    F ist eine SEMAX; G ist eine SE2K
  • Passende SE aus dem Schrank im Kabäuschen des HW-Labors holen.
    • SEMAX mit 9-poliger Canonbuchse oder
    • SE2K mit Mini-Sub-D9-Buchse
  • VME-Crate ausschalten, SE tauschen, VME-Crate einschalten
    • Sollwerte der anderen SEs gehen in der Regel nicht verloren, da deren Dualport-RAM gepuffert ist.
    • Trotzdem vor dem Tausch im HKR nachfragen, da alle Geräte, die am VME-Crate angeschlossen sind, nicht mehr gesteuert werden. Das ist wichtig für die gemultiplexten Geräte.
  • SE-Software neu laden; dabei die hier rot markierten Versionen von ECM und EQMs beachten bzw. vergleichen
    asl733$ cdcpu KE3CS058 
    asl733$ ls -l
    total 2812
    -rw-rw-r-- 1 hechler bel 498 Mar 29 2016 2016-03-29.log
    -rw-rw-r-- 1 hechler bel 806 Mar 31 2016 2016-03-31.log
    -rw-rw-r-- 1 hechler bel 152 Apr 4 2016 2016-04-04.log
    -rw-rw-r-- 1 hechler bel 148 Sep 7 2016 2016-09-07.log
    -rw-rw-r-- 1 hechler bel 941078 Mar 31 2016 f-tgx-esr-eqms100003-ecm1005.sr
    -rw-rw-r-- 1 hechler bel 956856 Mar 29 2016 g-tgx-esr-eqms100003-ecm1004.sr
    -rw-rw-r-- 1 hechler bel 957024 Mar 31 2016 g-tgx-esr-eqms100003-ecm1005.sr
    -rw-rw-r-- 1 hechler bel 52 Mar 31 2016 ke3cs058.dat
    asl733$ ecload -v g-tgx-esr-eqms100003-ecm1005.sr ke3cs058
    Read hardware type of ke3cs058 Read EQMs and ECM versions of ke3cs058 Eq. models in file (tgx) and on EC (not) do not match Send anyway? [n]: y
    Software versions of ke3cs058 prior to loading EQMs: not defined! Variant: not defined!
    MIL: CMIL10.26
    ECM: 10.07
    Feb18 Send boot command to ke3cs058 ...wait until EC has booted Download file /common/export/devacc/cpu/ke3cg05/ec8/g-tgx-esr-eqms100003-ecm1005.sr to ke3cs058 Load done, init ke3cs058 ...wait until EC has booted Read EQMs and ECM versions of ke3cs058 Software versions of ke3cs058 after loading EQMs: TGX 10.00.03 Variant: ESR MIL: CMIL10.26 ECM: 10.05 Mar16
  • Geräte tun nicht mehr, was sie sollen
    • zugehörige SE finden:
      • prophelper <device-nomen> &
      • rdevdesc liefert die Nomenklatur der SE (ec-nomen), an der das Geräte angeschlossen ist
    • überprüfen, ob die SE, von der aus die Geräte gesteuert werden, noch events empfängt:
      • prophelper <ec-nomen> &
      • revtbuff liefert die letzten ca 128 events
        • wenn da nur ['00FF'] angezeigt wird, kommen am VME-Rahmen keine events an
          ('00FF' events generiert das Timinginterface im VME-Rahmen selbst, wenn keine events von extern empfangen werden)
        • überprüfen, ob das bei weiteren SEs im selben Rahmen auch der Fall ist
      • mit 'Refresh' checken, ob sich am Inhalt etwas ändert
      • kommen keine events (außer '00FF'), dann muss das Timing-Verteilsystem überprüft werden
    • überprüfen, ob die Gerätesoftware noch getriggert wird:
      • prophelper <ec-nomen> &
      • rec_info zeigt u.a. die eqmQueue mit den Ausführungeszählern
      • mit 'Refresh' checken, ob sich am Inhalt etwas ändert
      • ändert sich nix, dann kommen nicht die richtigen events

IPS

Testprogramm

Es existiert ein einfaches Testprogramm unter Linux.

Aufruf IPS Testprogramm:
  1. Umgebung für AP-SW einstellen:
    . /common/usr/belap/prefs/belap.sh
  2. Programm aufrufen:
    ipstest

  3. Den Angaben des Programms folgen.
    Numerische Eingaben werden im Zweifelsfall dezimal erwartet (insbesondere die Box-Nummer).

Zuordnung IPSBox-Nummer / Konsole

Konsolen mit IPSBOXnn "--" haben kein Potiboard eingebaut.

Möglicherweise aktuellere Zuordnungen finden sich im VMS-Cluster in SIS_MGR:CONSOLRUN.COM.

IPSBOXnn Konsole Beschreibung
01 U3 HKR: UNILAC 3
02 S2 HKR: SIS 2
03 ?  
04 TK HKR: TK
05 U2 HKR: UNILAC 2
06 Y7 SHIP
08 U1 HKR: UNILAC 1
09 ?  
0A FS Fragmentseparator
0B HT Hochtemperaturmessplatz
0C CA Cave A
0D HI HKR: HITRAP
15 HL HLI (LSB 3)
16 UI UNILAC-Injektion
2B T1 Testkonsole Terminalraum
-- BH Betriebshalle
-- CC Cave C
-- E1 HKR: ESR 1
-- E2 HKR: ESR 2
-- EQ Quellenteststand
-- GF Testkonsole
-- HD HADES
-- HO Hosti Quellenstand
-- HQ Hosti-Quellenteststand
-- MF Testkonsole Materialforschung
-- PK Testkonsole
-- S1 HKR: SIS 1
-- S3 HKR: SIS 3
-- SJ Testkonsole
-- VS Testkonsole
  1. Umgebung für AP-SW einstellen:
    . /common/usr/belap/prefs/belap.sh
    (den Punkt zu Beginn nicht vergessen)
  2. Programm aufrufen:
    ipstest

  3. Den weiteren Angaben folgen. Numerische Eingaben werden im Zweifelsfall dezimal erwartet (ausprobiert an der ersten erforderlichen Eingabe, die der Box-Nummer).

Probleme mit der Choppersteuerung

Wenn der Chopper nicht choppt. Siehe Chopper Funktionen und Zusammenhänge

RPG-Geräte werden nicht online

Obwohl die Interfacekarte von der SE erkannt wurde (vmeterm, Menüpunkt D), sind die Geräte auf der SE offline (ecconfig <SE-Name>). Hier hilft nur ein vmeboot -i <SE-Name>, wobei die Option -i notwendig ist.

Danach sicherheitshalber ein Reboot des GuP ausführen: ssh root@<GuP-Name> '/etc/init/boot.d/95_devman restart'.

Therapiebetrieb, SISMEDI und falsche Datenkennung (DID)

Problem: Therapie-Datensätze eines Gerätes wurden nach-programmiert und haben anschließend die falsche Datenkennung.

Beispiel: Die gültige, GSI-weite Maschinenkennung sei 146. Mit dem NODAL-Programm therapy liest man aber für das nach-programmierte Gerät z.B.

----- Therapieinfos lesen -----

...
Kleinste Slave-Datenkennung = 0.1.0
Größte Slave-Datenkennung =   0.1.0
...

Da SISMEDI sich bei der Einzel-Programmierung eines Gerätes die "gültige" Maschinenkennung aus dem Gerät selbst holt, ist diese z.B. 0, wenn das Flash neu initialisiert wurde. Man muss also dafür sorgen, dass entweder der erste oder ein beliebiger Therapie- Datensatz(1) die korrekte Maschinenkennung hat.

Vorgehen (mit NODAL therapy):
  1. Betriebsmodus setzen: Einstellmodus
  2. Datenkennung setzen: z.B. 146.1.0. Sie muss größer als die oben gelesene größte Kennung sein. Und natürlich muss die Maschinenkennung (DID, im Bsp.: 146) die korrekte, GSI-weit eindeutige sein.
  3. Max. EFI-Parameter setzen; ist geräte-abhängig. Für ein Gerät, dass nur von E abhängt: E = 254, F = 0, I = 0. Für andere EFI-Abhängigkeiten entsprechend.
  4. Evtl. einen Sollwert ans Gerät schicken, bei Magneten z.B. CURRENTS = 0A. Es tut aber auch der gerade aktuelle oder der Initwert. Der Sollwert wird dann von SISMEDI eh noch mal überschrieben.
  5. Slavedatensatz DPR -> RAM. Z.B. für ein E-abhängiges Gerät:
    ----- Slavedatensatz DPR -> lokales RAM -----
    
    Energie (0..254)   : 1
    Fokus (0..7)       : 0
    Intensität (0..15) : 0
  6. Datensätze ins Flash schreiben
  7. Nun sollte die Nach-Programmierung mit SISMEDI für alle Datensätze des Gerätes tun.


(1) Was genau SISMEDI liest, um an die Maschinenkennung des Gerätes zu kommen, weiß im Moment niemand so recht. Man könnte annehmen, es liest MEDIINFO, weil es damit an die größte Kennung käme.
Topic revision: r72 - 22 Apr 2020, DominicDay
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 Foswiki? Send feedback