Verification de la transmission sur les BPMs.

Après appel avec Nicolas, nous avons redémarré, ça a résolu le probleme.

Les DS du libéra 2 sont HS. Des modifications ont été apporté qui font planté l'init des DS.

Redémarrage effectué.

Les liberas, red-pitaya (diags), wavecatcher et cameras ont été eteints en prévision de la coupure électrique de demain.

Le WAC1 est reparé...

Peut-être que le problème venait des valeurs de synchronisation chargées précédemment.

Afin de résoudre le problème de double déclenche des wavecatcher on augmente la longueur de l'impulsion.

Test avec seulement le kicker d'injection allumé (septum en FAULT).

Avant modification on voit une double impulsion toutes les ~5 secondes.

Après modification on voit que c'est la longueur de l'impulsion qui varie...

Est-ce que le bruit créé par le kicker réinitialise un compteur pour certaines voie du générateur de retard?

=> Cela devrait résoudre le problène mais à vérifier.

Test à faire: 

- regarder si le problème change selon que la porte arrière de la baie synchro est ouverte ou fermée (si c'est de la CEM on devrait avoir un effet)

Laser aligned on MRSV.
 

Beam position observed on the MRSV when changing RI-C1/STR.06-H01 (3 images) and then RI-C1/STR.06-V01 (3 images).

We can see that the beam moves horizontally with the steerer. It is not so clear in the vertical plane.

A GUI to measure the transmission through the BPMs has been developped. It is in the git panneaux at Diags/BPM (a git pull is needed to have access to it).

To lauch it type:

ipython IHM_BPM_ratio.py

You get a window with the interface like in the attached image.

For the measurements to be meaningfull you need to click on "set fixed gain". It will set all the BPms on teh same fixed gain.

Once you are done, it is preferable to revert the BPMs to auto gain by clicking on "set auto gain".

Note: The charge on TL/BPM.03 is higher than on TL/BPM.02 see separate elog entry about this.

A preliminary alignment of the MRSV has been done this morning.

There were difficulties with the camera, that have been adressed but only at slow rate.

To be tried on Friday.

J'ai regarde le probleme des camera basler ACE avec Pylon.

Il semeblerait que la camera ait une latence de 650us.

Je n'ai pas trouve de reglage permetant de resoudre le probleme.

La résolution de LI/DG/SST.01 a été ajustée. L'accès à la station est rendue difficile par les modifications faites à la station.

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

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.

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  

Le cable de controle de la LED de EL/DG/SST.03 est le 36041. Il a été branché sur le switch controlé sortie 3.

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.

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

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.

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).

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.
 

- 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.

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.

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).

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.

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,

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,

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.

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. 

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.

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...

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

Une nouvelle calibration a été appliquée aux stations écrans.

Quelques mofications ont été appliquées à l'IHM_SST pour améliorer sa rapidité.

Les câbles vers LI/DG/SST.01 et  EL/DG/SST.01 sont connectés aux câbles 36027 et 36030 pour l'éclairage.

Le signal de déclenchement du MRSV est connecté au câble 36040.

Verification de la longueur de deplacement en fonction de la vitesse des moteurs:

Vitesse = 3:

Vitesse =2:

La vitesse recomandée est 2, au delà certains moteurs pas à pas manquent trop de pas.

Le code de mesure de taille faisceau ecrit par Laura a ete ajoute a plateForm IHM sous le nom "Beam size".

Le retard de déclenchement du WAC.03 a été ajusté pour que l'impulsion sur la coupelle de Faraday soit bien incluse dans la fenêtre d'acquisition.

La constante de calibration de la charge sera à régler... Une valeur temporaire a été mise.

EL/DG/FC.01-WAC.03 est mal réglé en temps, la charge renvoyé ne donne pas la bonne valeur (cf image ci-joint).

J'ai tenté d'appeler la salle de contrôle pour faire le réglage en direct mais il n'y avait perosnne (alors que la page de status annonce qu'il y a du faisceau).

Les diagnostics ont été rallumés.

Les diagnostics ont ete eteint afin d'economiser de l'electricite pendant la pause hivernale.

L'affichage du gain et de l'intensité sur l'interface SST a été mise à jour.

La calibration des ecrans a ete calculee et entree dans l'interface SST.

Config:

Gene 500MHz -> Splitter 8 voies -> 4 voies BPM + 4 charges

Etude sur RI-C1/DG/BPM.01

100mV -21dB = pas de saturation (limite)

RI-C1/DG/BPM.01 est sur raf3 de libera3-b5

Pour voir les coefficients:

libera-ireg dump boards.raf3.conditioning.coefficients

Les 4 voies montrent des différences.

Pour activer le switching

libera-ireg boards.raf3.conditioning.switching=true

Les 4 voies convergent.

Pour démarrer l'apprentissage (cf p32 du manuel libera):

libera-ireg boards.raf3.conditioning.tuning.dsc.coefficients.adjust=true

Pour utiliser le coefficients appris:

libera-ireg boards.raf3.conditioning.tuning.dsc.coefficients.type=adjusted

Activation de l'ajustement automatique du gain:

libera-ireg boards.raf3.conditioning.tuning.agc.enabled=true

Attenuation progressive du signal...

Gain cofficients: cat /var/opt/libera/cfg/gain3.conf

16:45 Fin des mesures

Etude de l'alignement de BPMs

16:17 rep rate 50/10/10/10

Identification et correction d'un bug sur l'interface de tir unique.

Dans Taurus le T2TrigCount ne se refaichit pas a la meme cadence pour tous les BPM alors que dans jive il se refraicit a la meme cadence. => a comprendre.

Etude de l 'alignement des declenchement des BPM

14:07

Rep rate initial: 50/10/10/10

- Nouvel eclairage installe sur TL/DG/SST.01 et TL/DG SST.01 (reste LI/DG/SST.01 et  EL/DG/SST.01 a faire)

- Cable reseau installe vers EL/DG/SST.01 et TL/DG/SST.03. Les cables sont trop cours pour les autres stations => acheter des 1 cable 20m et 3 cables 30m.

- Cables coax installes vers TL/DG/SST.02. Les cables sont trop cours pour les autres stations => acheter 3 cables 30m.

- Adresse Mac camera MRSV 00:30:53:22:EE:71 / adresse IP: 192.168.229.44 (ccdmrsv1) (adresse IP mise a jour en conformite avec la note Atrium)

- EL/DG/SST.01 reinstallee et testee. Alignement et mesure de resolution a faire.

An update has been done on the script launched by the scan charge phase IHM.

Now if the first scan is 0-360 degrees, it launches a second scan on the area where the max charge has been found during the first scan.

At the end of the second scan the phase is set to max charge -50.

The plots indicate the max charge value computed and max charge - 50 degree (max energy).

Un git pull a ete fait.

Intervention du 26/10:

Le retard pour les cameras ACE a été ajusté dans l'interface IHM_SST maintenant il ne devrait plus y avoir de problème pour voir le faisceau en déclenchement externe.

Une mesure plus fine (et un réglage plus fin des retards) sera fait vendredi.

La raison pour laquelle il faut déclencher la caméra à +6ms du passage du faisceau n'est pas clair et devra être étudiée...

Les réglages d'atténuation des BPM effectués le 6/10 avaient été effacés! Je les ai remis.

We  went to the casemate to check visually the BPM ri-c2/dg/bpm.04-lib.05 after Friday's shift. We found the the ChD was NOT CONNECTED.

It is not clear why since last time all the connections were checked !!!

We connected the cable and will check it with the beam.

Camera du MRSV non fonctionnelle... À tester...

Le MRSV a ete installee (a tester).

Utilisation de l'alimentation de EL/DG/SST

Les cables ont ete mis a cote de ceux qui traversent deja l 'anneau: au sol n'importe comment.

Deux cables d'alimentation supplementaires branches 36041 et 36044.

Le reseau est pris sur TL/DG/SST.02 via un routeur.

EL/DG/SST est temporairemment indisponible (connexion utilisee pour le MRSV)

La camera TL/DG/SST.02 a un comportement bizarre.

Parametre de declenchement:

Retard= 156950, exp =0.02

Des boutons de contrôle d'intensité ont été ajoutés sur les caméras SST.

Pour l'instant c'est approximatif mais devrait aider en cas de saturation.

Cela sera affiné plus tard.

rotation de 180° des caméra TL/DG/SST.01, 02, 03 et EL/DG/SST.01
Toutes les caméra sont orienté avec le convention de ThomX : x positif côté MUR

ATTENTION a la convention sur ThomX : si z est le sens de propagation des électrons et y vers le haut, le trièdre x,y,z est INDIRECT !!!

Le centrage de la caméra de la ligne d'extraction est a refaire.

La calibration des écrans est a refaire (mais les valeurs actuelle ne doivent pas être très loin de la vérité)

Calibration des fentes TL/DG/SRH.01

Ecart contacteurs: 45mm

Course: 4750

=> 106pas/mm

Le zero a ete defini a +1mm du contacteur bas (extrait)

La position par defaut des fentes a été mise à 23.5 au lieu de 19 ce qui devrait résoudre le problème.

Faire un git pull pour avoir cette valeur dans l'IHM fente.

Mesures de taille de faisceau faites avec le DS developpe par Laura.

Il a ete verifie qu'en decalant TL/DG/SST.01 de 100us la saturation disparait.

Une etude plus detaillee sera faite et des boutons adaptes seront installes sur l'interface SST.

Verification de l'obstruction du faisceau par les fentes.

Le mors cote mur obstrue legerement le faisceau.

Acces requis pour voir si on peut reculer le contacteur de limite sans mettre le materiel en danger.

18h30

Acces casemate

RI-C1/BPM.02 cable D etait mal visse + passe pres du faisecau direct

=> cables A et D mis pres du faisceau direct

=> cable A rebranche

RI-C1/BPM.01 cable B devisse

RI-C1/BPM.01 cable A, B et D pres de la ligne deviee

Access a Casemate:

BPM2

A (blanc aoutour de bypass) B (debranche) C(vissse,pas touche) D(debranche)

Suite a un probleme de fonctionnement des WAC, nous avons permutter les cables reseau des WAC2 et WAC3.

Cela permutte le probleme.

Pour l'instant nous laissons les cables permuttes. WAC2 est fonctionnel, WAC3 ne l'est plus.

Fait :
- Allumage des caméras après la coupure estival
- Échange des caméra TL/DG/SST.02 et EL/DG/SST.01 pour avoir une caméra qui trig au niveau des fentes
- Verification de la rotation sur TL/DG/SST.01
- Allignement, reglage zoom/focus, verification position moteur des écrans pour les caméras : TL/DG/SST.01, TL/DG/SST.02, TL/DG/SST.03, EL/DG/SST.01 (OK pour LI/DG/SST.01)
- inversion caméra spare/caméra EL/DG/SST.01 + nouveau zoom
- Calibration des caméra faite a ma main :

• Création d'un code permetant d'obtenir la convetion pixel micrometre a partir de la mesure en pixel du plus grand group/element (2,1) des cibles.
  Le code est : $HOME_IHM/Diags/interface_SST/conversion_px_um_target_usaf1951.py

- Code de calibration (usaf_detector_py2.py) fonctionnel sur le compte opérateur mais ne done pas de très bon résultats d'ou la calibration a la main. Le code permet néanmoins de prendre des images de toutes les target et les sauve dans "/data/shared/status/SST_calibration" sous un nom générique "data_heure_stationName_calibration_image.png
Pour l'utiliser suvre les étape suivante :

• Allumer les LED des caméra ACE (TL/DG/SST.02-ccd.01 et EL/DG/SST.01-ccd.01) :
  • arreter les serveurs des caméra depuis astor ou l'IHM_astor_serteur
  • ce connecter au caméra conserner avec pylon (sur le pc TangoDiag)
  • aller dans le menu ccdsst2-tl -> I/O control et cliqué sur la case "user output line 1" (permet d'allumer les LED)
  • deconnecter les caméra de pylon (pylon peux rester ouvert et sera réutilisé plus tard) et relancer les serveurs des caméras
  • dans le doute mieux vaut relancer l'IHM_SST avant d'appuyer sur le bouton "Image calibration"
  • attendre que le bouton "image calibration" redvienne de la même couleurs que les autres puis recommencer au premier point pour éteindre les caméra en décocahnt la case coché plus tot

A faire :
- Scotcher le focus de EL/DG/SST.01 pour eviter qu'il ne bouge ?
- retouner de 180deg toute les caméras sauf le linac pour être dans la même convension que les BPM.
Convension :

• x positif vers l'exterieur de la machine,
• y positif vers le haut
• z selon l'axe faisceau
• Attention : cette convension implique un trièdre INDIRECTE !

Verification cablage BPM

Selon Jive :

 Verification calibration BPM (cf https://atrium.in2p3.fr/0c2065cc-824a-4d70-ba26-8f1770cc54fa).
Les mesures ont était faites en associant les serial number (SN) des tiroires des Libéra au BPM cablé dessus. Depuis 2 modifications de cablage ont était executé, une inversion des Libéra 2 et 3 et une inversion des tiroires en haut a droite et en bas a gauche.
L'impact sur les SN est résumé ci dessous.

A FAIRE : Revoir les le fichier de calibration des BPM ($HOME_IHM/Diags/BPM/ThomX_BPM_calibration.csv)

Les moteur des station SST passe en "alarm" par moment pendant quelque second.

Il s'agit d'une alarme de temperature. Il faudra guetter pour s'assurer qu'il n'y a pas de probleme de surchauffe et il fauraut eteindre les moteurs de temps en temps.

Première image d'un potentiel rayonnement cherenkov sur la station TL/DG/SST.01 pris au téléphone portable dans le couloir de l'igloo.

Travail en cours sur la caméra TL/DG/SST.01 => rotation de 180° de la caméra

Laura a amélioré son analyse du bruit sur les BPMs (LI+TL), voir fichier joint.

Le bruit RMS sur la mesure de position dans le linac est inférieur à 200um.

Le bruit RMS sur la mesure de position dans le TL/DG/BPM.01 est inférieur à 50um.

Si votre analyse est fortement dépendante des barres d'erreurs je vous encourage à prendre des données statistiques pour faire une analyse de bruit dans la configuration machine de votre choix.

Analyse du bruit sur les mesures de position effectuée par Laura Pedraza sur les données du 21/06/2022.

Conclusion:  le bruit sur les mesures de position avec LI/DG/BPM.01 est inférieur à 150um.

Le bruit sur les mesures *relatives* de position avec les écrans semble inférieur (attention à ne pas oublier d'appliquer la calibration).

comparaisons des valeurs des BPMs (TL/DG/BPM.01-LIB.02/SpX et SpY) aux valeurs sur écran TL/SST01. 

Voici des valeurs numériques que j'ai notées :
lors d'une variation de I_steerer allant de -12 A
à + 12 A
- déplacement (à peu près horizontal) du faisceau mesuré
avec les BPM : 3,75 mm,
- déplacement (à peu près horizontal) du faisceau mesuré
sur l'écran : 13,5 mm.
Rapport des deux déplacements : 3,6.
Distance des BPM au steerer : 1,2 m
Distance de l'écran au steerer : 2,9 m
Rapport des deux distances : 2,42.
Le rapport des déplacements est donc 50 % plus élevé qu'attendu
à partir des distances.
A priori, ce désaccord pourrait provenir soit d'une erreur de calibration
des BPM ou des déplacements sur l'écran, soit d'un effet de lentille
divergente que le triplet de quads introduirait pour une source
localisée au centre du steerer.
Petite vérification : l'énergie du faisceau était de ~50 MeV (ou de 68 MeV?)
La longueur équivalente du steerer est 70 mm, et le champ dans le steerer
est de 40 gauss, soit 40e-4 T. On en déduit que le rayon de courbure
du faisceau dans le steerer est de 42 m, et donc que la déviation due
au steerer est de ± 1,67 mrad, soit 3,33 mrad en tout (lorsqu'on passe
de -12 A à +12 A). À une telle déviation correspond un déplacement
de 4 mm dans les BPM et de 9,7 mm sur l'écran. Ces nombres sont à
vérifier!
 

Sinon pour info des énergies ont été mesurées via les BPMs et l'écran en bout de linac en bougeant le steerer apres section (tl/ps/str.01-h.01).

resultats dans :

• pour les BPMs : /data/shared/Commissioning_tools/Mesure/20220414/Energie_BPMs/  --> 68 MeV
• /data/shared/Commissioning_tools/Mesure/20220414/Esteerer_section/  *IDXR*      --> 50.5 MeV

Verification de la calibration des BPM :

Les valeurs de l'ATKPannel sont coforme a celle du fichier de configuration ($HOME_IHM/Diags/BPM/ThomX_BPM_calibration.csv)

Préparation de la présentation du RIF : https://indico.ijclab.in2p3.fr/event/8142/timetable/#20220407.detailed

Charge faisceau : 30 pC

Images prise :

• Signaux ADC des BPM
• Image TL/DG/SST.01 (focalisé grace au quad) :
  • cible de calibration
  • Image OTR (exposition : 10s) avec faisceau
  • Image OTR (exposition : 10s) sans faisceau
  • => substraction images OTR pour mettre l'enphase sur le faisceau
  • Image YAG (exposition : 1ms)

Fin des tests. er/ca/rac.05-elr.01-wac.01 est de retour sur sa config habituelle.

Observation:

Toujours s'assurer que EnableDynamicCharge est sur False

Attention, tests de config pour comprendre le bruit sur er/ca/rac.05-elr.01-wac.01

La config en place n'est pas la config habituelle.

Analyse des mesures de charge du jour:

Charge_plot_25: données prises en faisceau: Convergence vers une std de 10pC, même sur TL/DG/ICT.02 où il ne devrait pas y avior de faisceau.

Charge_plot_26: données prises de nuit (sans faisceau): bruit similaire (le décalage positif des zéros vient de la soustraction du courant d'obscurité).

Il y a quelque chose à comprendre sur le bruit des mesures de charge!

Mesures de charges:

16h41 moyenne sur 50 tirs

16h57 moyenne sur 1000 tirs

17h03 moyenne sur 1000 tirs

17h11 moyenne sur 1000 tirs

17h16 moyenne sur 10 tirs

Rotation de 180° de la caméra li/dg/sst.01 + zoom remis sur tl/dg/sst.01

-> Focal refait sur les caméra + position ecran revu

Nouvelle calibration caméra :

x = M(x,H) * H + M(x,V) * V
y = M(y,H) * H + M(y,V) * V

Calubration trouvable sur l'interface SST.

/!\ C'est l'inteface qui fait fois !!! PAS CE POST !!!

Jean-Claude a redémarré meanStd_charge2.

L'affichage de la charge moyenée semble correcte sur les trois équipements.

C'est fait et l'interface a été testée.

Une demande de redémarrage de meanStd_charge2 a aussi été faite pour l'affichage des charges dans la TL.

L'IHM Charge a été mis à jour mais je n'ai pas le mot de passe pour faire un git pull.

Bonjour, 

nous faisons quelques mesures de transport après section. La mesure de position des BPMs n'est pas consistante avec les variations des steerers. Pouvez-vous vérifier le cablage du BPM TL/DG/BPM.01-LIB.02. 

Pour le premier du Linac, le vertical donne une valeur négative pour un déplacement en haut de l'écran, ce qui n'est pas consistant avec la convention. 

L'oscilloscope est maintenant pilotable à travers le réseau ThomX:

parametrage oscillocope

nom : oscillo8

carte réseau "connecteur du haut" Intel  (R) 82579LM  (IPV4 en DHCP)

MAC 00:19:0f:11:81:32

IP ThomX 192.168.229.47

utilisation du portable wl-delerue2  avec le software Wavestudio (Lecroy)

connection Ethernet 1 (IPV4 192.168.229.152 Subnetmask 255.255.255.0 )    (dans Network & internet Network connections)

 Wavestudio

adresse Scope : 192.168.229.47

Les chassis libera ont ete eteint en prevision des tests electriaues de la semaine prochaine.

Prise de donné pour étudier le fluctuation du faisceau avec les BPM.

Les lignes contenant au moins 1 zero correspondent a des pertes faisceau.

ATTENTION : DONNÉES NON ALLIGNÉ !!!!

Retard initial WAC.02 : -6.39 µs

Dernière valeur utilisé : -6.28 µs

Retour à la valeur initiale

Changement de cablage :

Fait, modification transparente pour les mesure.

Test de la mesure de charge sur les FaradayCups

Le filtre passe bas 21MHz est installé après 2m de cable RG58 derrière la FC avant le cable lmr200 90300 qui va en baie 5

Bonjour,

Le DS "bpm" des caméra retourne des valeurs en pixels.

L'interface SST quand a elle peut retourner des valeurs en pixel ou en mm selon si une calibration à était faite il n'y a pas trop longtemps.
Pour faire les calibrations il existe le bouton "Image calibration" qui insert toutes les cibles, allume les LED, prend une image de calibration, resort les écrans du faisceau, calcule la calibration et permet de l'appliquer au mesure affiché sur l'interface. Attention toute cette procédure prend un peu de temps (autour de la minute), tant que le bouton n'est pas revenu a la couleur de base cela signifie qu'il travaille, si jamais au bout de 10min il n'est toujours pas revenu, il y a un bug, merci de me le faire remonter et de relancer une nouvelle interface.

Il est possible que la calibration ne puisse pas aller jusqu'au bout puisque le script python de traitement d'image nécésite un package python (opencv-python pour python 2) qui au dernière nouvelle n'est pas installé sur le compte opérateur (a verifier).
Si vous avez un problème envoyé moi un mail et je verrais ça a distance.

Bonjour,

les valeurs des dimensions des camera données dans le DS bpm sont t-elles calibrés donc en m ou mm, ou um ou bien pixels?

Si c'est en pixels, on sont stockées les valeurs de calib ?

Merci d'avance !

Christelle

La conection du BPM Li/DG/BPM.01 doit être refaite.

Une double permutation (une au niveau du BPM et l'autre entre le patchpanel et le Libera) permet actuelement d'avoir un fonctionnement normal du BPM, mais il serait préférable de normaliser les configurations de cablage.

La modification nécésite la clé dynamometrique.

Hi,

please, find attached the sketch, where the directions are shown. In any case, it should also be cross-checked with other systems (e.g. screens).

Iryna

Bonjour, on aurait besoin de savoir par rapport à l'axe faisceau comment sont référencés positif/négatif ?

Par exemple une valeur positive en x signifie que le faisceau va vers l'anneau, ou vers le mur ?

Merci d'avance,

Christelle

Signal ICT linac : 

2022-01-14_ictLI-new_delay.png
 

Avant modification du delay de la WAC 2 : -6.39 µs
ICT TL1 :

2022-01-14_ictTL-old_delay.png
FC TL:

2022-01-14_FC-old_delay.png
Après modification du delay de la WAC 2 : -6.24 µs

ICT TL1 :

2022-01-14_ictTL-new_delay.png
FC TL :

2022-01-14_FC-new_delay.png

We are investigating the charge difference between LI/ICT.01 and FC.01.

There are big oscillations on FC.01.

We have changed the timing of the WAC.02 to -6.24us (initial value: -6.39) to have the full signal in the WAC.

J'ai redemarre:

- Les Liberas 1 et 2

- Le chassis des cameras

- Le chassis des RPY

J'ai verifie le declenchement et la lecture de:

- LI/SST.01

- TL/SST.01

- LI/DG/BPM01-LIB-01

- TL/DG/BPM01-LIB-02 (un init manuel dans Jive a ete necessaire pour ce libera)

J'ai éteint les deux chassis restant...

En prevision de la coupure électrique général prévus le 18 Décembre 2021 de 9h30 à 13h30 j'ai éteint les Libéra servant a mesurer les BPM de l'anneau (3,4 et 5).
Le Libéra 1 servant pour le BPM du linac et le 2 pour celui en sortie de section ils sont toujours allumé mais devrons être éteint au plus tard le vendredi 17 décembre.

Je viens de corriger cela (je n'ai pas la possibilité de tester cette fonction puisque cela actionne l'obturateur).

Je vous appelle dès que possible.

L'IHM ne marche plus du tout. 

l'erreur est :

Measure dark current
Traceback (most recent call last):
  File "/data/shared/Interfaces/panneaux//Diags/BPM/IHM_charge.py", line 309, in click_on_measure_dark_button
    shutter_state=get_shutter_state()
NameError: global name 'get_shutter_state' is not defined
 

Je viens de modifier l'IHM_charge pour ajouter un boutton qui affiche l'état de l'obturateur et j'ai ajouté  une case à cocher qui permet de choisir si il faut conserver son état ou non quand on fait une mesure de courant d'obscurité.

Faites un vote en salle de contrôle si vous voulez pour choisir si vous cochez la case ou pas mais mettez vous d'accord...

Faire un git pull.

J'ai appelé la salle de contrôle à 11h26, expliqué le fonctionnement et Hayg m'a dit que c'était bon.

l'obrurateur doit rester dans l'etat ou il est est. Et donc ne pas etre ouvert par l'interface s'il etait ferme avant ---> a modifier

Le mode de fonctionnent de l'interface a été modifié comme convenu en réunion.

Le nouveau bouton "Set dark current" effectue séquentiellement les actions suivantes:

- fermeture de l'obturateur, attente 5s et vérification

- réinitialisation des moyennes de courant

- attente 50s

- affectation des moyennes à la valeur du courant d'obscurité

- ouverture de l'obturateur, attente 5s et vérification

- réinitialisation des moyennes de courant

le git push de l'ihm charge a ete faite

LE SHUTTER S'OUVRE TOUT SEUL PAR L'INTERFACE. iIL DOIT ETRE OUVERT UNIQUE,ENT PAR L'UTILISATEUR ET NON PAR L'INTERFACE ---> a mofifier

Nouvelle calibration de la caméra TL/DG/SST.01-CCD.01 :

Horizontale : 31 µm/pixel

Verticale : 46 µm/pixel

Working on LI/SST.1:

We looked at the YAG:Ce signal as function of time.

From the Bassler camera manual, the scout scA640 have a latency of 33.80us and a minimum exposure time of 24us.

We scanned the camera delay to see the YAG signal to see the fast decay and the slow decay.

We attempted to see the OTR signal but the charge was too low. A scan of charge vs the phase gave a maximum charge of 12pC.

On a constaté que si on déplace le faisceau de gauche a droite dans le tube du linac, il se déplacait en y dans le BPM.

En débranchant un cable on a toujours du faisceau sur les 4 voies => le module BPM linac n'est pas celui qu'on pensait.

BPM Linac : Serial number 14

BPM EL : Serial number 6

ThomX_BPM_calibration.csv Mise à jour.

Le cablage sur le BPM du linac est le suivant :

Problème inversion x-y réglé. Inversion sens x possible.

Je viens de vérifier le cablage des BPM. Je considère que les cable sont bien branché lorsque les cable sont branché comme suit:

Pour le linac, la ligne de transfert et la ligne d'extraction tout est OK.

Pour l'anneau :

Modification des étiquettes sur les Libara pour qu'elle correspondent au bon BPM dans jive. Mise a jour de ThomX_BPM_calibration.csv (dans git Diag/BPM).

Vérification du cablage des patchpannel.  Configuration patchpannel  90508 à 90511 :
BPM A - BPM C
BPM B - BPM D

Placement des modules dans le Libera :
BPM A - BPM B
BPM C - BPM D

Les BPM haut-droit (B au dessus) et bas-gauche (C haut dessus) sont inversé entre le patchpannel et le Libera.

Solution possible :
- Recabler les patchpannel -> compliqué d'accès
- mettre de "long" cable entre croisé pour ces 8 modules (xa voies). Est ce qu'on a assez de cable ? (il en faut 32)
- Renommer BPM B en BPM C et vice-versa.
Je viens d'en parler avec phillipe Gauron et il ne sait pas comment faire, mais après verification dans la doc il est possible qu'on ai juste a échanger la propriété "LiberaBoard" entre les DS concerné dans jive. A verifier avec Nicolas Hubert !
(LiberaBoard peut valoir raf3, raf4, raf5 ou raf6 pour les moddules des BPM)

25/10/2021

As soon as we had the beam, we found very quickly the signal. Please, see the screen shots attached.

More probably the horizontal and vertical directions are swapped.  The calibration and offsets should be checked.

Le BPM LI/DG/BPM.01-LIB.01 a une erreur de cablage. Les axes x et y sont inversé.
Echange des câbles sur le BPM compliqué (les connectiques sur le BPM semble fragile et on ne voulais pas les casser avec Slava)

La configuration actuel pour ce BPM est :

- Blanc : en haut
- Rouge : a droite (côté laser PC)
- Jaune : en bas
- Bleu : a gauche (côté Anneau)
(Code couleur vérifié au niveau du Patchpannel)
- Position : orthogonal :
=> x = kx*(Va-Vc)/(Va+Vc)
=> y = ky*(Vb-Vd)/(Vb+Vd)

Donc si on veux suivre la convention MadX (x (y) positif vers la droite (le haut) si on regarde vers la section), il faut :
- Rouge : Voie A
- Blanc : Voie B
- Bleu : Voie C
- Jaune : Voie D

La modification faite correspond a une rotation d'angle -Pi
=> Modification des offsets :

Fichier ThomX_BPM_calibration.csv modifié.

 12/10/2021

Due to the problem of finding the signal with the first BPM LI/DG/BPM.01-LIB.01, it was decided to try to read out the signal with the scope.

The two screenshota attached show the BPM signals with and without the beam read by scope connected to the alectrods A and B in the rack 5.

We clearly saw that there was a signal coming from the beam.

13/10/2021

Due to the problem of finding the signal with the first BPM in the linac  LI/DG/BPM.01-LIB.01, it was decided to do the tests with the signal generator (500 MHz sine wave cw, ~100 mV).Eventually, we found that the cables (or tango names in the control room) of that BPM in the linac LI/DG/BPM.01-LIB.01 and the BPM in the EL EL/DG/BPM.01-LIB.01 were swapped.

We change the cabling the tha rack between these two BPMs, now in the control room, the tango names correspond to the nomenclature for ER/DG/RAC.05-LIB-01. What about the calibration constants in this case? To be discussed !!!!

Once the cabling was fixed, we saw well the sin signal on the libera (see the screenshot attached).

We also check the ER/DG/RAC.05-LIB-02 with the generator since there there is one TL BPM TL/DG/BPM.01-LIB.02 we will need as well for this phase of the commissioning. We found also that two BPM modules are swapped with respect to tango names used in the control room. Here it is the summary:

- in the rack5  (sticker TL/01, serial number S/N 11) corresponds well to TL/DG/BPM.01-LIB.02 in the control room =>>>> OK 

- in the rack5  (sticker TL/02, serial number S/N 4) corresponds to TL/DG/BPM.01-LIB.03 in the control room  =>>>> to be corrected  !!!!!!!

- in the rack5  (sticker TL/03, serial number S/N 18) corresponds to TL/DG/BPM.01-LIB.02 in the control room  =>>>> to be corrected  !!!!!!!

- in the rack5  (sticker TL/04, serial number S/N 16) corresponds well to TL/DG/BPM.01-LIB.04 in the control room =>>>> OK 

Now, we are ready to restart again with the beam (we are waiting when there will be a beam at ThomX). 

=>  need to play with the trigger delay but hopefully we will see the signal on the libera this time.

The similar tests with the generator should be done for the rest of the liberas (ER/DG/RAC.05-LIB-03, ER/DG/RAC.05-LIB-04, ER/DG/RAC.05-LIB-05) in order to eliminate such problem in the future for rest of the BPMs.

Recommendation from N. Hubert: look at the TbT signals as well during the commissioning.

Câblages des BPM sur les Libéra non encore connecté en utilisant la clé dynanométrique.
Verification du câblage des Wavecatcher.

État actuel :
- BPM tous câblé correctement
- WC tous câblé correctement

Sur le devant du libéra 5 la LED E rouge est allumé.

Il me semble que le problème a déjà était rencountré et qu'il est aquitable par connection ssh sur le Libéra et utilisation d'une commande specifique

XXXX

Nicolas:

La solution est que quelqu'un avec le mot de passe tape: libera-bmc --sel --clear

J'ai fait la demande dans le ticket 12984.

- Coef (sans unites) est censé être le coefficient de conversion de la charge. Veux-tu que je retire son affichage? Est-ce que tu as demandé à Hayg des modifications sur le calcul de la charge? Il n'est pas normal que le coef ne s'affiche plus.
- Aucun valeur n'est mise à zéro au moment du lancement de l'IHM et je ne suis pas favorable à le faire car si une personne lance l'IHM sur un deuxième terminal (ou si l'IHM plante), alors tout sera remis à zéro.
- Quel facteur de conversion pour passer de Dark (nV*s) à la valeur en pC?
- J'ai crée la colonne pour le Sdev, mais le DS de calcul ne renvoi pas la sdev... à mettre en ticket.
- Pilotage de la profondeur moyenne: c'est compliqué, à mettre en ticket.

Vérification du fonctionnement de l'IHM_charge.py avec les variables d'étalonnage

Les 5 voies de mesures fonctionnent correctement.

Remarques sur l'IHM:

Une colone "Coef (sans unité)" est affichée sans données => peux t'on l'a retirer?

Par défaut au lancement de l'IHM la valeur Dak(nV*s) est renseigné pour la ligne LI/DG/ICT.01  => peut elle etre à mise à "0" par défaut comme les autres lignes?

Peut 'on ajouter un colonne " Sdev" en pC après la colonne Calc (pC)  calculée avec la meme routine que RAW(nV*s)   => Calc(pC)

La colonne Dark (nV*s) peut elle etre exprimée en pC?

Peut'on rajouter un parametre dans l'IHM pour piloter la profondeur du moyennage  effectué dans le DS mean_std?

Le nom de la colonne Calc(pC) peut il etre changé en Q_Beam(pC)

Test reglage de la largeur de la fenetre d'acquisition.

les parametres sont

FMP_RefCellForCharge  => début de la fenetre (numero du sample)

FMP_ChargeLength => largeur de la fenetre (nombre entier = nB samples/16  ie 100ns = 20 à 3.2GS/s)

pour changer les valeurs: (dans le DS wavecatcher)

1- stop acquisition

2- choisir les valeurs des parametres

3- set firmwave measurement parameters

4- get firmware measurement parameters (pour vérifier les valeurs)

5- start acquisition

mesure

Pour une fenetre de 100ns le bruit de charge des wavecatchers (quelque soit la voie) est de 0.03nVs  Sdev => 0.6pC

pour la fenetre entiere (1000 samples) le bruit de charge des wavecatchers (quelque soit la voie) est de 0.08nVs  Sdev => 1.6pC

Remarque

dans le DS ER/CA/RAC0.5-ELR.01-WAC.02

la valeur AcqTime est a 1.94e+227   !!!! dans les autres DS WAC1 et 3 la valeur est 0.

au bout de 2 minutes de fonctionnement le DS charge ne rafraichi plus les valeurs "RAW" et EventID de charge

d'abord affecte le wavecatcher 2 puis le 1 et 3

Sur WAC1:

Polling

ch0: 10=> 50

ch0_charge: 20 => 50

test IHM diag mesure charge:

Géné pulse trigger en externe (DEG3-CH15) sur les 3 Wavecatchers   (50mV 50ns)

[LI-DG-ICT01 WAC1-CH0]

[TL-DG-FC01  WAC2-CH0]

[EL-DG-FC01   WAC3-CH0]

les 3 DS Wavecatcher fonctionnent 

IHMcharge 2021-07-12 10-39-31.png 

=> colonne RAW seule la ligne  EL/DG/FC/01 se rafraichie. (à 5Hz)

=> les cases coef ligne 1 et 4 grisées (pB DS calc)

sur le DS de reboot

=> adressage calc/ict/charge_li-ict.01_wac.01-ch0  ==== charge/ict.01

=> adressage calc/ict/charge_tl-ict.01_wac.02-ch3 ====charge/ict.01

Les DS calc ne sont pas rebbootables... voir attachment2.

les DSmean std non plus

Test IHM ICT

Injection d'un pulse 100mV-100ns en entrée des voies des wavcatchers.

Trigger sur la voie d'injection avec un retard de 100ns (pour simplification pas de réglage de timing)

le wavecatcher 2 ne fonctionne pas correctement :(voir fichier joint)

pour l'IHM de charge:

aucun affichage des valeurs "RAW" 

les valeur moyenne et std sont calculées et affichées

pas de calcul de la charge en pC

les boutons reset average et set dark current fonctionnent

La vérification du fonctionnement des moteurs ci-dessous ainsi que des butés associées ont été faites récemment. Aucun problème à déplorer.

Station SST :
- LI/DG/SST.01-MOT.01
- TL/DG/SST.01-MOT.01
- TL/DG/SST.02-MOT.01
- TL/DG/SST.03-MOT.01
- EL/DG/SST.01-MOT.01

Fente :
- TL/DG/SRH.01-MoG.01-MOT.01
- TL/DG/SRH.01-MoG.02-MOT.01

Cf présentation ci-joint.

Conclusions:

L'échange entre le Libéra 2 et 3 est terminé.
Chacun est de nouveau controlable avec Jive, ainsi tout les Libéra sont fonctionnels.

Dans l'ordre de haut en bas dans la baie 5 nous avont les Libéra : 3 4 5 2 1
Les étiquètes on toutes était modifié aussi pour être les bonnes.

Lorsque j'ai rallumé le Libéra 3, il a fallu que j'ouvre toute les interfaces BPM sur jive pour faire un "Init" car ils étaient tous en alarme (main pas pour le Libéra 2).

Tous les Libéra ont était rééteint apès les tests.

Methode pour changer un attribut dans MeanStd  et redémarrer le ds :

Sur jive :
dans  MeanStd/test/MeanStd/'tmp/DG/MeanStd'/paramètre, modifier "ManagedAttributeList" pour avoir les valeurs voulues.

Sur Astor :
"Kill" le serveur "MeanStd" dans 'Salle de controle'/client2/'Not Controlled' (ATTENTION, les ds Not controlled ne sont pas affiché par défault, il faut double cliquer sur Not Controlled)

Sur un terminal depuis le pc client2 tapper la commande :
/data/shared/MeanStd/MeanStd test &

Sur jive :
Ouvrir l'ATKPanel : MeanStd/test/MeanStd/'tmp/DG/MeanStd'
Lancer une commande start.

La caméra TL/DG/SST.02-CCD-01 semble ne pas pouvoir se déclencher sur signal externe. Pour l'instant elle reste en déclenchement interne.

Nous la changerons avant le démarrage de la ligne de transfert.

Une intervention aura lieu sur les baies de l'IGLEX cet après-midi.
J'ai donc arrêté les liberas.

Nicolas

Les étiquettes des libéra 2 et 3 ont été interchanger de façon a avoir les bonne informations inscrite dessus.

Ainsi nous avons en partant du haut de la baie 5 :
Libéra 3 : 2/3 Ri-C1 (BPM 1 à 4)
Libéra 4 : 1/3 Ri-C1 (BPM 5 à 6) + 1/3 Ri-C1 (BPM 1 à 2)
Libéra 5 : 2/3 Ri-C2 (BPM 3 à 6)
Libéra 2 : TL (BPM 1 à 4)
Libéra 1 : EL + Li

Il reste a verrifier la connection au réseau du Libéra 3 et a faire les branchements des sorties des BPM sur les Libéra 2 et 3.

Le libera 2 est revenu de maintenance.

Il a était mis à la place du Libéra 3 puis qu'il ont été echangé (attention les etiquettes sur ces 2 Libéra n'ont pas encore été échangées).

Le cc doit encore modifier l'addresse IP et le nom de l'ex Libéra 2 afin qu'il soit utilisable depuis jive.

Le libera 2 a été renvoyé en maintenance. Il est donc indisponible jusqu'à son retour.

Modification interface IHM_SST pour permetre de sauver des images lorsque l'on ouvre l'interface avec le panneau interfaces. A tester.

Les éclairages LED :
- li/dg/sst.01-ccd.01 : Installé, tester, fonctionnelle
- tl/dg/sst.01-ccd.01 : Installé, tester, fonctionnelle
- tl/dg/sst.02-ccd.01 : Installé, tester, fonctionnelle
- tl/dg/sst.03-ccd.01 : Installé, tester, fonctionnelle
- el/dg/sst.01-ccd.01 : Installé, NON tester, LED fonctionnelle (Impossible de contrôler les LED depuis le cc car c'est (avec la spare) une caméra ACE et non Scout)

2 LED en plus : 1 jeu fonctionnelle mais pas installable sur ThomX (au sous sol du bât 208), 1 en réparation chez Thomas Chabaud

La caméra "spare" est au sous sol du bat 208.

Ouverture interface IHM_SST avec le panneau_interface OK, allume correctement les serveurs des 5 caméras installé sur ThomX (li/dg/sst.01-ccd.01, tl/dg/sst.01-ccd.01, tl/dg/sst.02-ccd.01, tl/dg/sst.03-ccd.01, el/dg/sst.01-ccd.01)
Caméra "spare" non testé car pas sur ThomX (au sous sol du 208 pour faire les tests sur les objectifs).

Interface IHM_SST ouvert avec le panneau_interface ne permet pas de saugarder des images.
Interface IHM_SST ouvert en ligne de commande si. (A voir avec Hayg)

Les éclairages LED :
- li/dg/sst.01-ccd.01 : OK
- tl/dg/sst.01-ccd.01 : OK
- tl/dg/sst.02-ccd.01 : Pas de Led d'installée, fonctionnait avant le confinement
- tl/dg/sst.03-ccd.01 : OK
- el/dg/sst.01-ccd.01 : Impossible de contrôler les LED car c'est (avec la spare) une caméra ACE et non Scout
- spare                      : Il existe un système d’éclairage en rab mais il n'est pas montable sur les montures des caméras mais qui est utilisable sur le banc de test des caméras

Un script pour connaitre le T2TrigCount d'un libera

panneaux/Diags/BPM/get_BPM_trigcount.py
 

La commande a mettre dans le DsDiagManager pour un declenchement externe est

wget --no-cache -S --post-data 'elem=Run&val=true&end' "http://192.168.229.25/main.php"

Camera El/DG/SST.01-ccd.01 ajouté à ça place.

Pour tester les LED, le jeux de LED de la camera Tl/DG/SST.01-ccd.02 a était déplacé et installé avec cette nouvelle caméra.

Device servers have been updated for the camera(s) as following : 

DS_list=['LI/DG/SST.01-CCD','TL/DG/SST.01-CCD','TL/DG/SST.02-CCD','TL/DG/SST.03-CCD','EL/DG/SST.01-CCD','CR/DG/SST.00-CCD','LI/OP/LAS']
DS_Ext=['.01','.01','.01','.01','.01','.01','.02'] 
Camera=['ccdsst1-li','ccdsst1-tl','ccdsst2-tl','ccdsst3-tl','ccdsst1-el','ccdsst1-spare','ccd2-laser']

They need to be restated and checked again.

https://atrium.in2p3.fr/c8fc130b-c7e5-4200-ba00-95e5f6921828

--> Use user_output_line1 to swich it ON/OFF

On 09/01/2020 I have restarted all the Libera in order to make it accesible in the CR. Meanwhile, the DS of the Libera 2 remained to be in the unknown state. It is green in astor, however, in Jive it says that the DS is in the unknown state. All the atribute fields are filled with crosses.

The GLPI ticket has been openned to fix this issue. 

Les caméras de ThomX ont été rallumées hier soir.

Alexandre a remarqué que:

- Il ne devrait pas y avoir de caméra ccdsst2-li mais ccdsst1-el

- l'adresse MAC assignéee à ccdsst1-el est incorrecte

Nous avons voulu tester l'allumage des LEDs sur LI/DG/SST.01-CCD01 cependant il était impossible de redémarrer le serveur dans Astor.

Nous avons testé les caméras ACE:

* ccdsst2-li l’adresse MAC est correcte par rapport à  https://atrium.in2p3.fr/c8fc130b-c7e5-4200-ba00-95e5f6921828 mais elle n’apparait pas dans Astor...

* Dans  https://atrium.in2p3.fr/c8fc130b-c7e5-4200-ba00-95e5f6921828  il n'y a pas d'adresse pour ccdsst1-spare.
Cela devrait être: 00:30:53:2D:2A:CB

 

All cameras have been shutdown for the holiday season.

TL/SST.03-CCD and TL/SST.02-CCD have been started.

TL/SST.03-CCD is in the correct configuration (but without light)

TL/SST.02-CCD is next to the SST station, not in the correct configuation.

The lens has been installed on the CCD at TL/SST03