Installations pour PyTango (Itango) et Jupyter

Librairies necessaire pour Itango :

libboost-python1.62-dev et libboost1.62-dev

Depuis l'intervention de ce matin, la lecture des redpitaya baie 17 (à travers l'IHM RF_plot.py) ne fonctionne plus

reparé! suite à l'intervention de ce matin (test redpitaya Nb 2 ) tous les DS étaient HS et la configuration aussi .

Peut etre prévoir un parametrage automatique au démarage des DS?

Vincent

Bonjour à tous,

Quelqu'un ou quelques choses à changer les paquets conda dans l'environnement "#!/usr/bin/env /data/shared/miniconda3/envs/tango_py3.8/bin/python" ce qui fait planter les DS. 

par exemple pour le DS TEST/ThomX_PhotoCathode, le paquet scipy.signal ne possède plus la fonction "convolv2d".

Merci de documenter les modifications que vous faites sur les environnements conda.

PS: nous avons mis à jour la version de scipy.

jiji  -19.860943680697755
****************************** motor_position 0 17.5 1
jiji  1256.0427115463383
*****Error set attenuatation value  ***** motor_position 0 17.5 1
Error set attenuatation value  1256.0427115463383
****************************** motor_position 0 20.5 1
jiji  1289.1434442107527
*****Error set attenuatation value  ***** motor_position 0 20.5 1
Error set attenuatation value  1289.1434442107527
****************************** motor_position 0 26.5 1
jiji  1325.874425230028
*****Error set attenuatation value  ***** motor_position 0 26.5 1
Error set attenuatation value  1325.874425230028
****************************** motor_position 0 27.0 1
jiji  1328.060511551206
*****Error set attenuatation value  ***** motor_position 0 27.0 1
Error set attenuatation value  1328.060511551206
****************************** motor_position 0 26.0 1
jiji  1323.633810076457
*****Error set attenuatation value  ***** motor_position 0 26.0 1
Error set attenuatation value  1323.633810076457
****************************** motor_position 0 25.0 1
jiji  1318.9016548632073
*****Error set attenuatation value  ***** motor_position 0 25.0 1
Error set attenuatation value  1318.9016548632073
****************************** motor_position 0 25.0 1
jiji  1318.9016548632073
*****Error set attenuatation value  ***** motor_position 0 25.0 1
Error set attenuatation value  1318.9016548632073
 

Update du script pour sauver les images :

2 camera en test :

• Basler ACA640 - 100gm

• Basler Scout SCA640 - 70gm

Quelques chiffres :

Trigger : internal

50 images demandées

• Basler ACA640 - 100gm : 70Hz testé sans perte d'images

• Basler Scout SCA640 : plus aléatoire

  • fonctionne pas, ou bien pertes de qq images (10 environ ou moins)

  • Image semble doublée, quadriee

CF : lien github de Lima qui reporte ces les problèmes https://github.com/esrf-bliss/Lima/issues/97

Updates concerning the camera :

Tested camera so far

• Scout : 3 cameras 2 working and one NOK
• Ace A640 -100 gm  Working
• Ace A3088-16 gm NOK

Concerning the Scout which is NOK, and the Ace A3088, we enabled sequencer feature : https://docs.baslerweb.com/index.htm#t=en%2Fsequencer_(gige_cameras).htm&rhsearch=sequencer&rhhlterm=sequencer

To do that see : https://github.com/esrf-bliss/Lima/issues/97#issuecomment-482116457

Now : 3 Scouts are working properly

Ace A3088 still has problems :

[2019/04/11 16:42:59.863241] 7fc9377fe700 (/opt/conda/conda-bld/lima-core_1549637374011/work/control/src/CtControl.cpp:791)-Error: Exception(Error): Frame(s) not available yet [thrown]

J'ai fait une interface graphique qui lit SpVa,...,SpVd et T2TrigCount en utilisant TaurusTrend. Pour un meme BPM ces variables se mettent a jour a des fr'equences tr'es diff'erentes....

En attendant que l'archivage archive : 

dans un terminal : 

• inicon # ça met en place l'environment python 
• cd /data/shared/commissioning_scripts/Trend_scripts/
• ./trend.sh TBT_Sum_ALL3.pck # pour avoir le trend sur tbt sum debut / milieu / fin 
• ./trend.sh TBT_X_BPM4.pck # TBT X meme plage que TBT sum 
• ./trend.sh TBT_Y_BPM4.pck
• ./trend.sh TBT_X_BPM5.pck
• ./trend.sh TBT_Y_BPM4.pck
• ./trend.sh RF_RPy_Trend.pck # trend des signaux RF  
• Nous rajouterons ici les autres trends. 
• MRSV : taurustrend  obl/bpm/mrsv.01-ccd.01/fwhm_x obl/bpm/mrsv.01-ccd.01/fwhm_y
   

MATLAB crash file:/data/christelle.bruni/matlab_crash_dump.54207-1:

--------------------------------------------------------------------------------
       Segmentation violation detected at Wed Mar 16 18:01:02 2022 +0100
--------------------------------------------------------------------------------

Configuration:
  Crash Decoding           : Disabled - No sandbox or build area path
  Crash Mode               : continue (default)
  Default Encoding         : UTF-8
  Deployed                 : false
  GNU C Library            : 2.24 stable
  Graphics Driver          : NVIDIA Corporation Quadro P2000/PCIe/SSE2 Version 4.6.0 NVIDIA 390.144
  Java Version             : Java 1.8.0_152-b16 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
  MATLAB Architecture      : glnxa64
  MATLAB Entitlement ID    : 706414
  MATLAB Root              : /home/debian/R2018B
  MATLAB Version           : 9.5.0.944444 (R2018b)
  OpenGL                   : hardware
  Operating System         : Linux 4.9.0-18-amd64 #1 SMP Debian 4.9.303-1 (2022-03-07) x86_64
  Process ID               : 54207
  Processor ID             : x86 Family 6 Model 85 Stepping 4, GenuineIntel
  Session Key              : 6192dcd1-e5ea-488e-a15c-a9ae8442be9f
  Static TLS mitigation    : Enabled: Full
  Window System            : The X.Org Foundation (11902000), display localhost:12.0

Fault Count: 1

Abnormal termination

Register State (from fault):
  RAX = 00000000ffffffff  RBX = 00007f1ce546cc48
  RCX = 00007f1ce4c752b0  RDX = 00000000ffffffff
  RSP = 00007f1e854af300  RBP = 00007f1ce546cd30
  RSI = 0000000000000000  RDI = 0000000000000001

   R8 = 00007f1ce4ff6480   R9 = 00007f1d00d00e00
  R10 = 00007f1f9feda5d8  R11 = 00007f1f9f62c510
  R12 = 00007f1e6ed62058  R13 = 00007f1ce4eb0fa0
  R14 = 0000000000000001  R15 = 00007f1cf4e05bd0

  RIP = 00007f1d0092a24d  EFL = 0000000000010202

   CS = 0033   FS = 0000   GS = 0000

Stack Trace (from fault):
[  0] 0x00007f1d0092a24d      /home/debian/R2018B/bin/glnxa64/libosg.so.130+01008205 _ZN3osg16ArrayDispatchersD1Ev+00000077
[  1] 0x00007f1d00a2d475      /home/debian/R2018B/bin/glnxa64/libosg.so.130+02069621 _ZN3osg5StateD1Ev+00000101
[  2] 0x00007f1d00a2d7c9      /home/debian/R2018B/bin/glnxa64/libosg.so.130+02070473 _ZN3osg5StateD0Ev+00000009
[  3] 0x00007f1d00266898  /home/debian/R2018B/bin/glnxa64/libosgUtil.so.130+01530008 _ZN7osgUtil9SceneView9cullStageERKN3osg7MatrixdES4_PNS_11CullVisitorEPNS_10StateGraphEPNS_11RenderStageEPNS1_8ViewportE+00006504
[  4] 0x00007f1d00260faa  /home/debian/R2018B/bin/glnxa64/libosgUtil.so.130+01507242 _ZN7osgUtil9SceneView4cullEv+00001162
[  5] 0x00007f1d00f5c6a2                      bin/glnxa64/libmwosgserver.so+02401954 _ZN2hg14openscenegraph14OsgSceneServer11cullAndDrawEibdd+00003506
[  6] 0x00007f1e4b534a70                              bin/glnxa64/libuij.so+00449136 _Z23UIJ_call_OpenGLPaintFcnPN11gui_objects12scene_server16SceneServerProxyEibdd+00000048
[  7] 0x00007f1e4804833e                         bin/glnxa64/libnativehg.so+00033598 Java_com_mathworks_hg_peer_GraphicsPeer_doDisplay+00000030
[  8] 0x00007f1efd9304da                                   <unknown-module>+00000000
[  9] 0x00007f1eff3d5f24                                   <unknown-module>+00000000
 

Serait-il possible de demarrer sys/tg_test/1 sur le PC diag?

Merci!

J'ai ajouté dans plateforme IHM un bouton "scan RF phase" qui scan la phase RF section entre 105 et 125 degrees pour trouver le meximum d'energie et la FWHM minimum du faisceau sur TL/SST2.

Pour l'instant il n'y a pas d'interface à part le plot qui s'affiche à la fin mais j'en ajouetrai une prochainement.

Someone (using the operator account) had added two incorrect lines regarding the photocathode laser in the recipe template recipe_LI_TL_RI.txt.

This was creating an error preventing from saving the kickers/septum values.

This has been fixed.

If you make changes to the recipes templates, please test them and log them!!!

1) Présentation de la méthode utilisée pour le linac pour comme point de départ des IHM 

Les IHM sont décrits en listant les variables qui les composent ainsi qu’un schema fonctionnel. (voir sur https://gitlab.in2p3.fr/CCThomX/OrganisationIHM )  

Les IHM qui ont été développés concernent pour le moment le Linac. 

•  On utilisera la même méthode pour les autres IHM : 
  •      Aimants (quasiment finit)
  •      Diagnostiques Linac 
  •      Diagnostiques Anneau 
  •      Moteurs —> pas indispensable, mais ce serait bien d’avoir une vision globale pour voir si un écran est encore sur le faisceau. 

2) Présentation des IHMs concernant le Linac : 

•     Panneau Vide 
  •      Fait en LabView : pour le moment pas besoin de le refaire il est très bien 
  •          —>  Demande : avoir un panneau avec la courbe de vide pour tout l’accélérateur (par exemple en dessous de celle de l’orbite)        
•      Panneau Aimants 
  •          Discussion autour des sous fenêtres modales ou non 
    •              pour certains cas cela sera nécessaire : cyclage des aimants par exemple ou scan en cours pour les diags 
  •          Discussion sur le fait de fermer les sous fenêtres si la fenêtre mère est fermée 
    •              en principe on voudrait que les sous fenêtres ne soient pas fermées 
  •          Discussion sur la possibilité de dupliquer une fenêtre pour l’avoir sur un autre écran par exemple 
    •              oui c’est possible 
  •          possibilités de voir la stabilité d’un aimant au cours du temps 
    •              Nécessite de passer soit par la base de donnée soit de sauver (accumuler) dans un fichier 
    •              methodologie (générale) doit être discuté lors d’une réunion dédiée a la sauvegarde des données  
•      Panneau RF-Canon 
  •          créé à partir de petits modules, très pratique pour faire des panneaux plus compliqués

3) Panneau général / panneau status : 

•     Plusieurs choix sont possibles : 
  •        un panneau général type bandeau permettant d’ouvrir tous les panneaux  
•      Discussion à propos d’un panneau donnant le status de la machine 
  •          feu vert pour tirer ? 
  •          pendant le commissioning les points de fonctionnement seront recherchés. Nous n’aurons pas forcément tout de suite un feu vert pour tirer / injecter.   
•     —> Attente de propositions concretes pour réalisation 

4) Sauvegarde des données : 

  —> reunion dédiée doit être organisée après le 15 février (Nicolas)

5) Participation des membres du DEPACC à participer au codage des interfaces ? 

•   Vision du CC : normalement les interfaces doivent être faits par le CC. Les “utilisateurs” doivent décrire le mieux possible leur besoins, il reste encore des interfaces qui ne sont pas décrits. 
  •     Demande du DEPACC  (Nicolas, Slava) : possibilités de pouvoir modifier les interfaces pas forcément en prod mais avoir la flexibilité de le faire. 
  •      rien n’empêche de renommer une interface python et de la modifier. Il faudrait juste le faire dans un cadre permettant de revenir en arrière et de contrôler ce qu’on fait. 
• —>  une discussion à ce sujet s’impose 

6) Discussion autour de la possibilité de tirer pendant qu’on fait varier un dipole 

•    le faisceau peut se perdre et déclencher les sécurités 
  •         nécessité d’avoir une sécurité qui diminuerait la charge du faisceau ? 
  •      Christelle : Non pas pour le Linac. On le fait déjà sur PHIL et nous n’avons aucun soucis. 
•   —> Il faudrait savoir ce qui est autorisé par l’ASN      

—————> Document contenant les ingrédients et règles intervenant dans la création des IHMs 

Bilan IHM

IHM génériques

Il est important de comprendre qu'on ne pourra pas imposer des règles trop strictes et trop contraindre le style des fenêtres pour les IHM. Les quelques règles que nous devons discuter devront aider à uniformiser les interfaces, dont le style sera déjà bien guidé par la technologie qu'on va adopter

Contraintes

•  définition d'alarmes plutôt que rafraichissement élevé; possibilité simple : alerte/alarme sur seuils d'attributs dépassés
  •  distinguer les champs d'écriture, lecture et relecture
  •  langue : français
  •  pas de lettres majuscules
  •  couleurs vives/saturées pour conditions anormales uniquement
  •  pas d'objets 3D
  •  couleurs des états cohérentes :
  •   http://www.taurus-scada.org/en/latest/users/ui/ui_colors.html
    •        0 : ON
    •        1 : OFF
    •        2 : CLOSE
    •        3 : OPEN
    •        4 : INSERT
    •        5 : EXTRACT
    •        6 : MOVING
    •        7 : STANDBY
    •        8 : FAULT
    •        9 : INIT
    •        10 ! RUNNING
    •        11 : ALARM
    •        12 : DISABLE
    •        13 : UNKNOWN

•  se contraindre à un nombre de vues limité et défini (pour que les utilisateurs s'y retrouvent dans chaque IHM). 4 niveaux cohérents devraient être suffisants pour les IHM de ThomX (plus ce nombre est élevé, plus on s'y perd):
  •      niv. 1 : zone ThomX
  •      niv. 2 : sous-système (LINAC, EL, TL, etc.)
  •      niv. 3 : équipement/contrôleur (CCD, SST, etc.)
  •      niv. 4 : affichage diagnostic, sécurités, diagramme en une ligne

•  Quelques règles générales (à discuter) :  
  •        Le contenu de la fenêtre doit s'adapter à sa taille (agrandissement avec souris)
  •        Affichage heure pour montrer que la fenêtre s'update correctement
  •        Gestion des alertes (valeur seuil dépassée)
    •            utilisation des couleurs Tango pour signaler un dépassement
    •            Couleur des caractères à modifier (pas forcément du fond)
    •            voir s'il est nécessaire d'ouvrir un pop up pour signaler le problème

•  gestion des fenêtres :
  •      toutes les "sous-fenêtres" doivent être fermées lorsqu'on ferme la fenêtre principale
  •      nécessité (ou pas) d'une confirmation de ferméture de fenêtre
    •          si un process tourne (exemple aimant dont on varie de courant, ...)          
    •          le process peut aussi être un programme extérieur type MatLab : il doit être arrêté proprement
  •      indiquer si la fenêtre doit être modale ou pas (empêchant d'agir sur les autres fenêtres tant qu'on ne l'a pas fermée)

Besoins des utilisateurs

•  appel à des logiciels externes (matlab ou exécutable)
•  pour les traitements : pas de méthode existante pour dire quelle image est correcte ou pas
•  courbes temporelles avec bornes min/max visuelles, échelle auto; utiliser archivage (TDB/HDB de préférence) plutôt que enregistrer des données une 2de fois (risque d'incohérence), voir comment calculer min/max/moyenne/écart-type/régression/corrélation/...
  •      en principe tous les outils existent dans Taurus ou plus généralement dans PyThon  
•  Bouton (?) enregistrement :
  •      dans le Logbook
  •      Snapshot
  •      enregistrer à une fréquence donnée sur un temps donné; relève de l'archivage
  •      configuration de référence
    •          se donner des règles concernant la manière de nommer ou commenter les configs
    •          comment et surtout où sauver les configurations ? MML ?
  •      dans un fichier ?

Règles de codage

•  Environnement : Python Taurus (basé sur PyQt4)
  •      Git : https://github.com/taurus-org
  •      Web : http://www.taurus-scada.org/en/latest/
•  Dépôt Gitlab :
  •      Exemples :  https://gitlab.in2p3.fr/CCThomX/exemplesTaurus
  •      Organisation IHM : https://gitlab.in2p3.fr/CCThomX/OrganisationIHM
  •      Organisation : https://gitlab.in2p3.fr/CCThomX/Organisation
  •      Dépot des IHMs : https://gitlab.in2p3.fr/CCThomX/IHM

Restauration effectuée.

Tests en cours.

Les couleurs des alarmes et erreur pour les chillers sont regles dans les atkpanels. Cf copies d'ecrans jointes.

Pour le chiller canon:

atkpanel CALC/ER_HF/RAC.17-API.AI1_AI2 &

Cliquer sur les points de suspension. J'ai mis comme gamme acceptable 31.6-32.4C (cf copie d'ecran).

Pour les clarinettes:

atkpanel ER/HF/RAC.17-API.AI2 &

Gamme acceptable clarinette canon: 10-35

Gamme acceptable clarinette section: 10-31

Temperature eau aimants:

atkpanel  ER/HF/RAC.17-API.AI1 

lignes AI6 et AI7 (pas de limites pour l 'instant)

L'acquistion des redpitaya doient etre parametrée: sinon l'acquisition n'est pas à 10Hz:

les parametres redpitaya 2 et 4 sont sauvegardés par défaut 

les parametres des reditaya 1 et 3 sont à vérifier

dans propriété Event

Waveform_cha et chb    0.01

dans polling

Waveform_cha et chb    50

Nouveaux tests avec la caméra Scout : scA640-70gm

Contexte : 

Update des librairies tango

      ▶  $ conda list | grep -i lima
lima-camera-basler             1.8.0          py27ha8d69ae_0    esrf-bcu
lima-camera-basler-tango  1.8.0                         0       esrf-bcu
lima-core                             1.8.0            py27ha8d69ae_0    esrf-bcu
lima-tango-server               1.8.0                         0    esrf-bcu
On est passé de release candidate à la version 1.8

Test de sauvegarde d'image

Script Tango qui sauve 100 images :

sans erreur on a sauvé 100 images, avec une vitesse > 20 Hz

Fini les soucis d'images divisées en 4

Test de lecture video :

Fonctionne sans erreur ... !!

Propriétés dans Tango :

Frame transmission  delay : 10 us

Inter packet delay : 100 us

Packet size : 2000

 Jumbo frames 
#  ip link show | grep mtu 
# 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
# 2: enxe4b97ad8e69e: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
# 3: wlp59s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
# modify the second one which corresponds to the camera 
# sudo ip link set enxe4b97ad8e69e mtu 9000;
 

Voici les temperatures mise a jour

AI1 avant purge SF6.

Connection fini, bande passante trop faible...
Verfification repoussé a lundi matin sur place