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