Les modif faites pour ameliorer la rapidite font qu'il faut maintenant au moins 2 minutes pour passer d'un Yag a un autre ........... :-((

Pendant l'arrêt technique j'ai mis à jour le script qui effectue des vérifications quotidiennes (toutes les nuits entre 5h et 7h du matin) sur les cameras SST et leur moteurs (ce qui permet d'anticiper certaines pannes).

J'ai programmé le script pour qu'à la fin des vérifications les caméras soient mise sur la position YAG. Cela me semble faire gagner du temps aux opérateurs puisque lors du démarrage il faut vérifier la forme du faisceau et donc insérer le YAG... Sauf si il est déjà en place...

Suite a un commentaire lors de la reunion technique de ce matin, j'ai fait une verification en salle de controle du temps de reponse des changements de cameras dans l'IHM SST:

Sur client 2 lors du changement de camera le temps de latence est inferieur a 2s.

Sur client1 effectivement, il y a des plantages...  Etude en cours.

Apres quelques modifications, le temps de reponse sur client 1 de l' IHM SST est inferieur a 4 secondes.

Une nouvelle interface allegee pour les cameras SST est en preparation. 

Afin de pouvoir vérifier que plusieurs enregistrement proviennent du même tir j'ai crée une IHM: IHM
_align_trigger.py dans panneaux/Synchro (cf copie d'écran).

Cette IHM affiche pour un certains nombre d'équipements le numéro de déclenchement (trigger ou event ID). Cf copie d'écran.

En cliquant sur "Reset trigger number" on remet à zéro le numéro de déclenchement (pour les équipements où cela est possible).

En cliquant sur "Stop" on suspend la distribution du signal de déclenchement à toute la machine. On cliquant sur "start" on le restore.

En cliquant sur "Save" on suspend la distribution du signal de déclenchement à toute la machine pendant 5 secondes. À l'issue de ces 5 secondes le numéro de déclenchement  de chaque équipement est sauvé dans un fichier hotodaté dans /data/shared/Commissioning_tools/Mesure/today/ (par exemple: trigger_values_00_20_12.txt )  Cela permet de savoir quels étaient les numéros de déclenchement au début d'une prise de données et ensuite de vérifier par différence si les enregistrement en provenance de deux équipements proviennent du même tir ou pas.

Il est possible d'ajouter d'autres équipements selon les besoins.

Les fonctions utilisées dans cet IHM sont dans le git panneaux dans Synchro/freq_tools.py elles sont utilisables de manière autonome de l'IHM.

Bonjour,

après les shifts de la semaine dernière, il semblerait que la calibration de la caméra TL/SST1 soit erronée. Les valeurs diffèrent beaucoup des autres stations diag. Après une calibration rapide on trouve bien une différence :

on trouve v = 28.7um/pixel, h = 28.6 um/pixel

au lieu de v = 54.7 um/pixel, h = 52.8 um/pixel

La station TL/SST2 semble avoir le même problème. Il doit y avoir un bug dans la calibration.

Bonne journée,

Il y effectivement eu une dérive sur certains écrans (best donne la meilleure calibration actuelle - target donne la calibration qui était en mémoire):

('name_sst', 'tl_dg_sst_01')
('best: ', 'pixel_size_matrix: 31.71 0.32 -0.93 29.24')
('target: ', 'pixel_size_matrix: 54.69 -0.02 -0.84 52.81')

('name_sst', 'tl_dg_sst_02')
('best: ', 'pixel_size_matrix: 18.29 1.40 -0.48 20.34')
('target: ', 'pixel_size_matrix: 54.69 -0.02 -0.84 52.81')

('name_sst', 'el_dg_sst_01')
('best: ', 'pixel_size_matrix: 48.78 1.93 -1.48 49.56')
('target: ', 'pixel_size_matrix: 32.58 0.68 -1.07 34.12')

La nouvelle calibration a été appliquée.

Bonjour,

Les calibrations semblent toujours ne pas être correctes. Surtout pour TL/SST02 ou on dirait qu'il y a un facteur 2.

En PJ les calibrations de ce jours et des jours précédents. Il n'y a pas de dérive visible d'un jour à l'autre. Je met les images qui m'ont permet d'en arriver là également.

J'ai ajouter dans PlateformeIHM un outil "lock phase" qui permet de recaler la phase RF canon vs laser.

Pour l'utiliser cliquer sur "Check phase". Il decale la phase de 52 degrees par rapport a la phase actuelle et prends des mesures quelques degrees avant et apres pour voir ou se situe la chute en charge. Une fois la chute en phase trouvee, il retire 52 degrees et suggere une nouvelle phase de fonctionnement.

Cela evite de devoir le faire a la main (en attendant la retroaction sur la phase en cours d'installation).

Ci-joint les images de verification des calibrations actuellement utilisées sur les station écrans.

Le nom de la station est dans le nom de l'image.

Pour chaque image:

* les croix rouges indiquent les centres des mires détectées par l'algorithme de calibration.

* les croix vertes indiquent les centres des mires calculés à partir des contraintes fixées par les croix rouges.

* Les carrés (rouges ou verts) sont calculés à partir de la calibration, en prenant la croix comme référence et la taille réelle de la mire (en mm) convertie en pixels.

On peut voir que ce n'est pas parfait mais cela permet d'avoir une idée de où on en est.

Pour référence voici les valeurs utilisées:

('li/dg/sst.01', 'pixel_size_matrix: 35.59  0.87  0.97 36.86')

('tl/dg/sst.01', 'pixel_size_matrix: 27.29  0.63 -0.55 27.59')

('tl/dg/sst.03', 'pixel_size_matrix: 30.41  0.63 -0.61 29.78')

Pour les deux autres écrans, il y a une difficulté à cause de la taille des images qui est en cours de résolution.

Je travaille à une adaptation du script pour pouvoir verifier la calibration sur d'autres images que celle sur laquelle elle a été calculée. Je posterait quelques images ocrrespondantes en réponse à ce message quand ce sera prêt.

- Certains connecteurs du MRSV etaient deconnectes.

- Alignement de la ligne Cerenkov: nous avons atteint la salle laser. Il manque le dernier miroir de renvoi vers la camera a balayage.

The scope reading the ring fibers is currently ER/DG/RAC.06-OSC.01.  It is on channel 18 of the Diag delay generator. This channel is labelled "spare camera". I has been added it to diag_delays (will be available after the next git pull).

It was set to -49us with a scope horizontal latency of +42.5us. We changed this to set the chanel delay at -9us with a scope latency of 2.5us. So this should be transparent for all.
 

9:20 Fuite d'eau constatee en salle de controle. Ticket 13095 mis.

10:00 Mise en chauffe du modulateur par Maher

10:51 Alignement laser terminé jusqu'à la caméra à balayage

11:14 Modulateur sur Trig (Maher)

Nombreux problemes sur health check.

12:01 Des  tirs manques sur le modulateur. Vu avec Maher. OK pour fonctionner comme cela.

12:19 Pb Health check resolu, seul subsite un probleme de refroidissement de l'eau (Temperature RF section en alarme).

12:35 Apparement le shutter securite laser est ferme. Attente Viktor. Mise en standby.

13:08 Pb shutter laser resolu. Attenuateur laser passé de 410mm a 310mm.

Après-midi: observation du signal dans la ligne de transport.

Le signal est plus visible avec l'écran YAG inséré.

Début d'installation d'une caméra dans la boîte au milieu du couloir pour enregistrer le signal.

17:20 Arrêt

Programme pour la prochaine fois (29 septembre):

- Alignement au laser et observation signal sur camera

- Attention: le 29 septembre il sera nécessaire d'éteindre la lumière dans tout l'iglex (casemate, couloir et igloo).

Des mesures ont ete faites sur la camera a balayage a differentes frequence.

Le probleme a ete identifie (un composant que l'on pensait etre un dephaseur etait en fait un diviseur de frequence).

Apres rectification des branchements la camera fonctionne bien.

Mesures a continuer en faisceau.

Le gain automatique sur les BPMs avait été désactivé. Il a été réactivé pour LI-TL-LE.

ER/CA/RAC.05-WAC.02 était en déclenchement interne avec déclenchement sur ch0 alors qu'il avait été configuré en déclenchement externe jeudi dernier. Je l'ai remis en déclenchement externe et j'ai retiré le déclenchement sur ch0.

Si l 'on ne parvient pas a changer le temps d'exposition des CCD dans l 'ancienne interface, sur PlateformeIHM choisir "SST laucnher" puis dans la colonne controls du SST Laucnher, choisir la SST  

Test de la profondeur memoire des libera.

Il est possible de mettre 'TbtLength' a 200000 a 1Hz sur  'RI-C1/DG/BPM.01-LIB.03'.

Si l'on tente d'ecrire 200001 sur 'TbtLength', il y a une erreur.

Si l'on met 'TbtLength' a plus de 480000 a 10Hz sur les 12 BPMs de l'anneau il y a un timeout.

Si l'on met 'TbtLength' a 200000 a 1Hz sur les 12 BPMs de l'anneau il n'y a pas de timeout.
Si l'on met 'TbtLength' a 200000 a 5Hz sur les 12 BPMs de l'anneau il n'y a pas de timeout.
Si l'on passe a 10Hz avec 'TbtLength' a 200000 crash de 'RI-C1/DG/BPM.01-LIB.03'.

Si l'on met 'TbtLength' a 10000 a 10Hz sur 8 BPMs de l'anneau et 200000 sur  'RI-C1/DG/BPM.01-LIB.03',  'RI-C1/DG/BPM.05-LIB.04', 'RI-C2/DG/BPM.03-LIB.05' il n'y a pas de timeout mais comportement bizarre.

Recomendation: for operation with  'TbtLength'=200000 turns  , one should trigger the diags at 1 Hz, otherwise libera crashes and has to be restarted.

Retard TL/DG/SST.02 passe de 96ms a 6ms.