11:50 Perte trigger. La diode sur le chassis ne clignotait plus.

Difficult'e pour trouver un adaptateur SMA <=> BNC...

Quand j'ai deconnecte le cable du synthe linac pour mesurer son signal, le trigger est reparti.

Solution: extinction puis redemarrage dy synthe linac...

A surveiller: peut-etre qu'il y a une defaillance intermittente sur le synthe linac...

Un filtre est en plae sur le 50Hz (après le transfo ) dans le chassis synchro; le signal est propre.

le chassis est rebranché sur la prise secteur de la baie 8

Vérifier avec faisceau que le timing fonctionne proprement

Le chassis de synchro est alimenté par une ralonge electrique venant de l'établis "de Jean Noel"

les mesures sur le 230V ont montrées que le signal était moins perturbé là bas qu'en baie 8

ceci est une solution temporaire en attendant un filtrage qui rende le chassis synchro moins sensible aux perturbations du 230V

Le generateur DEG 4 a été nettoyé par Vincent à la soufflette (ce n'était pas très sale).

Il a été réinstallé et testé.

Il est en observation pour une semaine avant d'être recablé comme avant.

===

Pour mémoire:

DEG 1 T0 etait sur A11, debranche.

DEG 4 T7 branche sur A11

Trigger box N1 sur DEG 4.

Le DEG4 a été retiré pour nettoyage.

Les constantes de synchronisation 8 (sans DEG 4) ont été rechargées. Toutes les valeurs sont remises à celles du 8 juillet 2025.

Les constantes de synchronisation 9 (avec DEG 4) ont été effacées.

Gen4, voie 1 => Gen1,voie2, RF Gun

Gen4, voie 2 => Gen1,voie3, Laser

Gen4, voie 6 => Gen1,voie4, RedPitaya

Gen4, voie 8 => Gen1,voie5, Salle de controle

Sauve en memoire 9 des DEG1

scope (déclenche sur glitch inversé (inférieur à 50ns) CH1
CH1 trigext DeG4 (pris avec 1 "T" scope sur 1MOhm)
CH2 33MHz RI (in trigbox)
CH3 500MHz RI (in trigbox)

REF bruit
Septum  à 0V de tension Kicker Inj & Ext "on" V nomimal
CH1-N4-CH2_33RI-CH3_500RI-V2.png 
glitch présent sur CH1
Pas de bruit sur les signaux RI

=> si la tension cumulée des kickers (inj et ext) est supérieure à 11KV le glitch apparait :
CH1-N4-CH2_33RI-CH3_500RI-V3.png    (limite de tension pour apparition du glitch)
=>le septum n'a aucun effet sur l'appartition du glitch
=>le cable de tri ext vers DeG3 diag n'a pas d'effet
=> Cable tranverse feedBack 500 et 16 débranché (IGLOO ELR2) pas d'effet

=> DeG2 (ring) déclenché par un géné pulse  (12.5Hz non synchro de la machine) cable trig ext débranché coté Igloo
       cable trig ext débranché coté D1 pas d'effet DeG 3 débranché
      Defaut de comptage de la trigger box (plus de 12.5Hz ) tioujours des gliches

Les glitches venaient des bits de choix de fréquences de l'automate CA. certainement plus visible du au changement de programation de la CPLD (lecture des divisions en temps réél)

une ferrite sur la nappe qui véhicule les bits de choix (automate CA vers Trigger Box) resoud le probleme

TEK00035.png: Bruit sur le câble venant du DEG3 (2 kickers allumés) lorsque celui-ci est débranché de la trigger box.

TEK00036.png: Bruit sur le câble venant du DEG3 (2 kickers allumés) lorsque celui-ci est débranché de la trigger box et débranché du DEG3.

TEK00036.png: Bruit sur le câble N2 lors d'un changement de fréquence (utilisation d'un T).

TEK00044.png: Lorsque l'on avance le kicker d'extraction de 1us, le bruit disparait.

TEK00045.png: Lorsque le déclenchement du kicker d'extraction est trop proche du déclenchement du kicker d'injection, le bruit revient.

Signal N4.

Zoom sur t=+195ns, persistence allumée

TEK00018.png: All EP on.

TEK00019.png: Ext kick only.

TEK00020.png: Inj kick only.

TEK00021.png: Deux kickers allumés

TEK00024.png: Septum only.

Étude de N2: pas de bruit en retour sur N2. TEK00025.png

Installation d'un T sur N3.

TEK00030.png: 2 kickers allumés

TEK00031.png: Zoom

10h15 Arrêt pour accès RP

11h15: Impossible de reproduire le problème (TEK00034.png)! Quelque chose s'est passé pendant l'arrêt...

TEK00033.png: Zoom sur le début de l'impulsion N3...

Test 1: vérification de l'observation de la double pulse sur DEG4: Cf image TEK00011.PNG. Il y a bien une double pulse sur le DEG4.

Test 2: Image de l'impulsion en entrée N4 (venant de la trigger box), mode persistance = 5s. 

Élements pulsés eteint: image TEK00012.PNG

Élements pulsés allumés: image TEK00015.PNG On voit une impulsion à t=195us.

On ne voit rien sur N1,  EP allumés (TEK00016.PNG) ou eteints (TEK00017.PNG).

Une solution pour palier au double pulses sur les voie de DG:

il faut mettre un retard sur une des voies supérieur à 195µs

il faut prendre les voies SDC:

DEG1 voie 1

DEG2 voie 8

DEG3 voie 20

DEG4 voie 8

Captrures d'écran voie 5 DEG1 avec Trig ECT=12,5Hz: double déclenche.

Image 1: pas de double déclenche

Image 2: avec double déclenche

Image 3: avec persistence: montre que la double déclenche ne se produit pas tout le temps.

Gen4, voie 1 => Gen1,voie2, RF Gun

Gen4, voie 2 => Gen1,voie3, Laser

Gen4, voie 6 => Gen1,voie4, RedPitaya

Gen4, voie 8 => Gen1,voie5, Salle de controle

Sauve en memoire 8 des DEG

Les voies du DEG4 ont ete reportees sur le DEG1 qui a ete mis a 12.5Hz. Cela change la frequence de declenchement du klystron.

La PLL du DEG4 a de nouveau delocké.

Le DEG4 a ete baissé de quelques centimetres afin de laisser une circulation d'air entre DEG3 et DEG4. La temp'erature a déjà un peu baissé.

Ce midi 37C, maintenant 35C. Pour comparaison les autres sont a 33C.

Si le probleme se reproduit, prendre une copie d'ecran ou une photo de la face avant.

pB avec le DG 4

(malgré plusieurs reboot du chassis)

pilotage par IHM impossible (par la page propriétaire http://192.168.229.124/  c'est possible)

température DG de 36.6°C ( les autres sont à 32.6°C)

la pll du DG saute (hier soir impossible de le redémarrer)

il faudra peut etre contacter GreenField, et peut etre acheter un spare...

La voie 19 du générateur de retard diags était déjà branchée sur le scope (ch1 - jaune)

Branchement de la voie 8 sur le scope (ch 2 vert).

Kicker d'injection sur ch3 (orange)

septum sur ch4 (violet)

Mode enveloppe pour voir si il y a des coups anormaux.

Image SCR_PA02: machine en standby: on ne voit rien.

Image SCR_PA03: on retire la longue durée d'impulsion sur la voie 8; toujours rien.

Allumage de la machine.

Imgae SCR_PA06: machine en trig, toujours pas de double déclenche.

Vérification sur les ICT: pas de double déclenche sur ICT1.

Conclusion: le problème n'est plus présent.

Les performance de la synchro de ThomX au 16 mai 2025 sont:

Le jitter 500MHz Ring  500MHz Linac est de 8ps Sdev et   95% es événement dans  20ps   100 % dans 80ps (quelquesoit la fréquence de répétion)  (Jitter rapide)

Le jitter entre les voies de synchro Linac et Ring  est contenu dans 100ps (quelquesoit la fréquence de répétion) (jitter rapide)

La varition du temps entre les timing ring (drift timing) (quelquesoit la fréquence de répétion)

sont inférieurs à 3ns entre le modulateur et le linac

sont inférieurs à 1.5ns entre le  modulateur et les diag

sont inférieurs à 200ps entre linac et ring (mesure plus précise avec jitter rapide)

Rappel: pour voir le taux de declenchement manqués taper:

atkpanel  CALC/SY/missed_triggers

Rien dans les logs permettant d'identifier le problème.

J'ai utilisé ring_cavity pour changer la fréquence et le problème s'est résolu.

J'ai modifié la sortie de ./ring_frequency.py --read  pour détecter les désaccords en fréquence...

probleme de saute sunchro (50Hz)

avec le programme ./ring_frequency.py --read  (les fréquence  lues sont validées directement sur les générateurs anneaux)

('ring freq', '+5.0010045000000E+08\n', 500100450.0)
('Commande: ', ':SOURce2:Freq?')
('Commande: ', ':SOURce2:Freq?')
('data', '3.334002E+07\n')
('Commande: ', ':SOURce1:Freq?')
('Commande: ', ':SOURce1:Freq?')
('data', '3.334002E+07\n')
('sub freq', '3.334002E+07\n')
 

les deux fréquence ne sont pas multiples entière entre elles:  500.100450 /15 = 33.34003   ou 33.34005*15= 500.1003

Vincent

Attention au démarrage de l'interface faire 'restore laser and Kicker' pour etre sur que le systeme de synchro est en mode "normal"

Les codes de synchronisations ont ete mis a jour afin de permettre le 50Hz.

L'interface a ete mise à jour et un git pull a ete fait.

Le bit 4 est un reset du CPLD (il n'y a plus de synhcro tant que Bit 4 = 1 et la LED du chassis synchro ne clignote pas) 

Il existe 6 codes possibles

Modulateur  Linac Ring Diag

code 1    50 50 50 12.5
code 2    50 25 25 12.5  
code 3    50 12.5 12.5 12.5
code 4    50  6.25 6.25 6.25
Code 5   50  3.125 3.125 3.125
Code 6    50  1.5625 1.5625 1.5625
 

Baie 9: B14 =>cable 94545 => baie 34 A5

Le 500MHz pour la camera a balayage est injecte sur la voie C9 dans la baie 09, passe par le cable 90542 et arrive sur la voie A4.

Pour l'instant le 500MHz est pris a la place du scope de la baie 9.

Changement de DS effectué en accord avec la salle de contrôle. Problème résolu, cependant les DS ont mis beaucoup de temps à se charger.

$ ls /data/shared/tangoscripts/DeviceServer/Calibrations/DS/SY
create_ds.sh         ds_GeneRetard2_int.py     ds_GeneRetard.py    launch_ds_Freq.sh           loop_create_ds.py
DS_GeneRetard         ds_GeneRetard2.py     fill_GeneRetard.py  launch_ds_gene_retard_loc.sh
DS_GeneRetard2         ds_GeneRetard_float.py  Freq             launch_ds_gene_retard_new.sh
ds_GeneRetard2_float.py  ds_GeneRetard_int.py     Freq.py         launch_ds_gene_retard.sh

On voit qu'il existe deux versions de ds_GeneRetard, l'une entière et l'autre flottante.

head -50 DS_GeneRetard montre la version de DS_GeneRetard dans tangoscript est la bonne (dtype=float).

$ cat launch_ds_gene_retard.sh
#!/bin/bash

PYTHON=/usr/bin/python
DIR=/data/shared/DS_CALC/gene_retard

$PYTHON $DIR/ds_GeneRetard.py DS_GENERETARD &
$PYTHON $DIR/ds_GeneRetard2.py DS_GENERETARD2 &

On voit que le script execute la version dans DS_CALC et non la version dans tangoscript.

Sur client5:

$ ps -aux | grep ds_Gene
operate+ 48899  0.0  0.1 1465728 118380 ?      Sl   Jan09   8:47 /usr/bin/python /data/shared/DS_CALC/gene_retard/ds_GeneRetard.py DS_GENERETARD
operate+ 50690  0.0  0.2 1959808 146012 ?      Sl   Jan09  44:33 /usr/bin/python /data/shared/tangoscripts/DeviceServer/Calibrations/DS/SY/ds_GeneRetard2.py DS_GENERETAR2
nicolas+ 54085  0.0  0.0  12780   952 pts/1    S+   14:02   0:00 grep ds_Gene

On voit que la version de ds_GeneRetard.py qui s'execute est celle de /data/shared/DS_CALC/gene_retard/ et non celle de /data/shared/tangoscripts

Il faudrait l'arrêter et lancer la bonne version.

Sur client5 (à faire):

 kill -9 48899

ps -aux | grep ds_Gene

cd /data/shared/tangoscripts/DeviceServer/Calibrations/DS/SY

ipython /data/shared/tangoscripts/DeviceServer/Calibrations/DS/SY/ds_GeneRetard.py DS_GENERETARD &

Il y a un problème avec le DS  SIM/SY/DEG.sim qui stock des valeurs entières au lieu de valeures décimales.

Le problème peut être caractérisé avec le code ci-dessous:

import PyTango

#We create the proxy
tango_synchro = PyTango.DeviceProxy("SIM/SY/DEG.sim")

#we read and printthe delay array
delay_array=tango_synchro.read_attribute("delay")
print(delay_array)
delay_array_val=delay_array.value

#we check one value and modify it to a non interger value and wrote it
print(delay_array_val[2*25+9])
delay_array_val[2*25+9]=42.5
tango_synchro.write_attribute("delay",delay_array_val)

#and read it again
delay_array_val=tango_synchro.read_attribute("delay").value
print(delay_array_val[2*25+9])


#try again
delay_array_val[2*25+9]=44.5
tango_synchro.write_attribute("delay",delay_array_val)
delay_array_val=tango_synchro.read_attribute("delay").value
print(delay_array_val[2*25+9])

Changement de carte synchro

le MCT2 de la carte en place à bruler

A ds to monitor missed triggers has been added in CALC/SY/missed_triggers

Two buttons have been added to the repetition rate interface (see attached screen shot):

- "diags only": Will inhibit all channels from the ring and linac delay generators

- "restore linac and ring": Will set all channels of the ring and linac delay generators to External triggering.

A git pull has been done.

La synchronisation des signaux  mesure suR le timing 50Hz

500MHz LI 500MHz RI  => 18ps sdev

500MHz LI 50Hz  => 190ps sdev

dossier  panneau\synchro   (cdi)

./ring_frequency.py --help  (voir le mode de fonctionnement)

./ring_frequency.py --freq "value"   (choisi que des fréquences possible pour la div par 15)

./phase_shifter_rigol.py --phase "value"  (attention change les phases de ch1 et ch2)

9:20 Le laser est a -8.20us

Verification du retard de la camera LI/OP/LAS.02 en decalant en temps le laser de 999us.

La camera se declenche bien environs 600us avant le laser.

Tests sous pylon: un retard de 500us avait ete mis manuellement dans la camera il est retire.

Maintenant la camera se declenche 120us avant le laser.

12:17 Decalage en temps de toutes la synchro. Maintenant le 0 est 200us avant la production des electrons.

Cela devrait etre transparent pour les utilisateurs.

Mise a jour du fichier de constantes de synchronisation.

Git pull.
Scan de verification avec le laser a -8.20us et le temps d'exposition de la camera a 100us. On voit bien le laser si le declenechement est entre -190us et -100us

Verification des parametres pylon des autres cameras. A priori il n'y a pas de retard caché.

Il faudra verifier en faisceau que tout va bien.

La limite sur les diags a levee. Ils peuvent passer a 25Hz aussi.

Attention si vous passez pres de la baie 8: certains cables n'aiment pas etre caresse. Si le voyant trigger ne clignote plus, appelez la synchro...

Le synthe du linac a ete remis en place et teste a bas niveau.

Les codes de synchro ont ete mis a jour et testes.

Il est maintannt possible de passer a 25Hz sur le linac et l'anneau. Les diags sont limites a 8,33Hz.

test d'un code CPLD à 25Hz   => cela fonctionne.

le systeme est remis sur le code de REFERENCE à 10Hz

Les codes synchros présent dans l'IHM phase et fréquence sont opérationnel (ancien code max 10Hz)

Les codes de synchronisation gérant les taux de répetition des différentes parties de la machine ont été partiellement changé.

Une difficulté est apparu avec le code permettant de générer du 50Hz.

Pour l'instant l'affichage de l'IHM ne corresponds pas à ce qui est généré, un git pull sera fait quand les problèmes seront résolus.

Des tests sont en cours.

Les largeurs des impulsions de synchronisation de toutes les caméras de ThomX sont passées à 10µs (last value 5µs)

Camera linac TL1 TL2 TL3 EL DG spare et laser PC

Passage de Ctrl Klystron TTL2 de -11,5 a  -12.5

Cela n'a pas l 'effet recherche! Annulation, retour a -9.3us

Suite discussion avec Maher et Mohamed:

Changement du retard "Linac trigger RF Gun (PA) de -9.3 a -8.5us

aujourd'hui 13/05,

le synthé 3GHz de ThomX (R&S SMA) est retiré pour prêt à l'experience sur le White Rabbit.

Un autre synthé le remplace (synthé ThomX R&S SML), les caractéristiques en sortie ont été fixé à celles de l'ancien : 2.99855 GHz, 18dBm

Les signaux ont été vérifié avec Vincent, le 3GHz est le même que précédemment (fréquence et amplitude) et le signal sur la sortie pour le Klystron semble conforme aussi.

Le synthé doit être rendu à la fin de la semaine ou au pire avant la fin du conditionnement.

La synchro a été remise le 09/04/2024, le rapport et en P.J.

La synchro n'est plus en place à l'heure actuelle.

un générateur permet d'avoir des signaux en sortie du DEG1(modulateur) et du DEG4(Linac)  (fréquence 10Hz)

La frequence linac est passée à 2998.55MHz

Pb résolu: il fallait etaindre et redémarrer le synthé (le cable réseau avait été débranché et rebranché pour test ce matin sans que la connexion se refasse)

Le synthetizer de l'anneau ne réponds plus aux commandes à distances.

Une intervention en local semble nécessaire.

Apres le changement de longueur de l'anneau: la freequence 500Ri est de 500.07MHz  => 33Ri = 33.338MHz

Frequence 3GLi=2998.550500MHz

avec ces deux fréquences le systeme de synchronisation est instable :

500li 500ri   ok

500li 41li ok

500ri 33ri ok  (attention le script  ne modifie pas la fréquence sur les 2 channels du géné 33 mais seulement sur CH1 => à corriger pour modifier CH2 en meme temps que CH1)

le 10Hz est synchrone avec les 500 Ri et Li (pas de coup manqué)

le 33Ri saute de "bucket" 500  sur 3 buckets

le systeme fonctionne à 500RI = 500.25MHz

les premiers tests montrent  que lorsque l'on baisse la fréquence anneau de 10KHz, le pB apparait sur le 33Ri

=> possibilité de faire un sript pour changer la fréquence linac pour voir si on n'est pas dans un "trou"?

11h10 À la demande de Kevin, passage temporaire du linac de 2998550500Hz à 2998550000Hz puis retour à 2998550500Hz.

Fréquence anneau inchangée.

Dephasage entre les deux signaux 33MHz en sortie du gene Rigol lors d'un balayage de valeur PhaseShifterPhaseFemtoSeconds dans LI/OP/OPT.02-LAS.01-SPS.01 (figure 1)

Idem avec en plus un balayage en phase de la sortie 1 du Rigol (figure 2).

Script dans /tmp_mnt/data/operateur.thomx/Documents/SCRIPTS/test_scan_phase_CFP_with_laser.py

Suite aux modifications sur le laser photocathode le temps de déclenchement du laser photocathode était trop tard. Il a été changé de -8us à -8.20us.

Une nouvelle recette a été sauvée. Elle a aussi été mise en mémoire 9 des générateurs de retard.

Timing opérationnel

les voies des DG2-DG3 sont éteintes

- keep original text -

démarrage mesure stabilité de "phase" longue durée (100K pts 10Kpts environ 20mn)

freq Ring 500.25MHz

500li*500ri

500ri*10Hz

33ri*500ri

start 15h20

Systeme de synchro 500li*500ri 41li&33ri(1ns) 41li

Les mesures sont effectuées en baie 8 (Oscilloscoope 760zi)  prétrig sur signal 10Hz (C1)  (output DEG4 sdc) puis déclenche sur 500Ri (C2) pour une meilleure stabilité de lecture et de mesure

10K échantillons sur les trend représentent environ 20minutes d'acquisition

=> sur 40 minutes la dérive de la phase relative en le 500li et le 500ri n'excede pas 2ps pic à pic et avec une Sdev inférieur à 5ps  (Courbe F1 et F2)

=> sur 40 minutes la variation de la phase relative entre le signal de déclenche à 10Hz et le 500Ri (F4) est de l'ordre de 200ps pic à pic et une Sdev de l'ordre de 100ps

8H15 démarrage chiller et modulateur

9H30 Ronde pour fermer la casemate

9h36 Trig

f_synth_linac: 2998549980.0045Hz (inchangée)

Mesures coups manqués:

@fring=500.25MHz:  874 coups ok / 1000 tirs

@fring=500.0205MHz: 1000 coups ok / 1000 tirs

f_synth_linac: 2998550000Hz (nominale)

Mesures coups manqués:

@fring=500.25MHz:  912 coups ok / 1000 tirs

@fring=500.0205MHz: 1000 coups ok / 1000 tirs

f_synth_linac: 2998551000Hz (nominale)

@fring=500.25MHz:  1000 coups ok / 1000 tirs

f_synth_linac: 2998550100Hz

@fring=500.25MHz:  695 coups ok / 1000 tirs

@fring=500.25MHz:

f_synth_linac: 2998550100Hz: 72 coups ok / 100 tirs

f_synth_linac: 2998550200Hz: 100 coups ok / 100 tirs

f_synth_linac: 2998550010Hz:  65 coups ok / 100 tirs

f_synth_linac: 2998550020Hz:  fluctue entre 45 et 100 coups ok / 100 tirs

f_synth_linac: 2998550030Hz:  90 coups ok / 100 tirs

f_synth_linac: 2998550040Hz:  93 coups ok / 100 tirs

f_synth_linac: 2998550050Hz:  73 coups ok / 100 tirs

f_synth_linac: 2998550060Hz:  77 coups ok / 100 tirs

f_synth_linac: 2998550070Hz:  90 coups ok / 100 tirs

Ecriture d'un script pour mesures plus systematiques, cf plots. 

Conclusion des mesures: quand il y a des coups manque, un decalage de quelques centaines de Hz sur le 3GHz linac permet de trouver une frequence ou il n'y a plus de coups manques. Un tel decalage est probablement transparent pour tous les autres systemes. Ce resultat est valide pour une frequence anneau au moins entre 499.9905MHz et 500.250MHz. A 500.250MHz le jitter observe etait inferieur a 10ps entre les deux 500MHz sur une duree de 6h (cf entree elog separee).

Frequence anneau remise a 500.250MHz.

Frequence linac mise a 2998.550500 (Nominal + 500Hz).

16h36 arret modulateur

Donnees brutes:

@fring=500.25MHz:

Frequences: [-1000.0, -990.0, -980.0, -970.0, -960.0, -950.0, -940.0, -930.0, -920.0, -910.0, -900.0, -890.0, -880.0, -870.0, -860.0, -850.0, -840.0, -830.0, -820.0, -810.0, -800.0, -790.0, -780.0, -770.0, -760.0, -750.0, -740.0, -730.0, -720.0, -710.0, -700.0, -690.0, -680.0, -670.0, -660.0, -650.0, -640.0, -630.0, -620.0, -610.0, -600.0, -590.0, -580.0, -570.0, -560.0, -550.0, -540.0, -530.0, -520.0, -510.0, -500.0, -490.0, -480.0, -470.0, -460.0, -450.0, -440.0, -430.0, -420.0, -410.0, -400.0, -390.0, -380.0, -370.0, -360.0, -350.0, -340.0, -330.0, -320.0, -310.0, -300.0, -290.0, -280.0, -270.0, -260.0, -250.0, -240.0, -230.0, -220.0, -210.0, -200.0, -190.0, -180.0, -170.0, -160.0, -150.0, -140.0, -130.0, -120.0, -110.0, -100.0, -90.0, -80.0, -70.0, -60.0, -50.0, -40.0, -30.0, -20.0, -10.0, 0.0, 10.0, 20.0, 30.0, 40.0, 50.0, 60.0, 70.0, 80.0, 90.0, 100.0, 110.0, 120.0, 130.0, 140.0, 150.0, 160.0, 170.0, 180.0, 190.0, 200.0, 210.0, 220.0, 230.0, 240.0, 250.0, 260.0, 270.0, 280.0, 290.0, 300.0, 310.0, 320.0, 330.0, 340.0, 350.0, 360.0, 370.0, 380.0, 390.0, 400.0, 410.0, 420.0, 430.0, 440.0, 450.0, 460.0, 470.0, 480.0, 490.0, 500.0, 510.0, 520.0, 530.0, 540.0, 550.0, 560.0, 570.0, 580.0, 590.0, 600.0, 610.0, 620.0, 630.0, 640.0, 650.0, 660.0, 670.0, 680.0, 690.0, 700.0, 710.0, 720.0, 730.0, 740.0, 750.0, 760.0, 770.0, 780.0, 790.0, 800.0, 810.0, 820.0, 830.0, 840.0, 850.0, 860.0, 870.0, 880.0, 890.0, 900.0, 910.0, 920.0, 930.0, 940.0, 950.0, 960.0, 970.0, 980.0, 990.0, 1000.0]

Success rate=[100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 96.0, 99.0, 100.0, 90.0, 88.0, 61.0, 86.0, 95.0, 80.0, 57.0, 87.0, 100.0, 87.0, 79.0, 100.0, 100.0, 80.0, 100.0, 97.0, 100.0, 100.0, 99.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0]
 

@fring=500.0205MHz:

Frequences: [-600.0, -550.0, -500.0, -450.0, -400.0, -350.0, -300.0, -250.0, -200.0, -150.0, -100.0, -50.0, 0.0, 50.0, 100.0, 150.0, 200.0, 250.0, 300.0, 350.0, 400.0, 450.0, 500.0, 550.0, 600.0]

Success rate: [100.0, 100.0, 100.0, 98.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 98.0, 100.0, 100.0, 100.0, 99.0, 100.0, 100.0, 100.0, 100.0, 100.0, 99.0, 100.0, 100.0, 100.0, 100.0]

@fring=500.019MHz:

Frequences:  [-600.0, -550.0, -500.0, -450.0, -400.0, -350.0, -300.0, -250.0, -200.0, -150.0, -100.0, -50.0, 0.0, 50.0, 100.0, 150.0, 200.0, 250.0, 300.0, 350.0, 400.0, 450.0, 500.0, 550.0, 600.0]

Success rate:[100.0, 100.0, 90.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 99.0, 83.0, 78.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0]

@fring=499.9905MHz:

('Frequences', [-600.0, -550.0, -500.0, -450.0, -400.0, -350.0, -300.0, -250.0, -200.0, -150.0, -100.0, -50.0, 0.0, 50.0, 100.0, 150.0, 200.0, 250.0, 300.0, 350.0, 400.0, 450.0, 500.0, 550.0, 600.0])
('success rate', [100.0, 100.0, 100.0, 99.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 92.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0])

@fring=500.100MHz:

('Frequences', [-600.0, -550.0, -500.0, -450.0, -400.0, -350.0, -300.0, -250.0, -200.0, -150.0, -100.0, -50.0, 0.0, 50.0, 100.0, 150.0, 200.0, 250.0, 300.0, 350.0, 400.0, 450.0, 500.0, 550.0, 600.0])
('success rate', [73.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0, 100.0])

Objectif: test du nouveau code CPLD.

- Un montage avait été installé sur le système de synchro entrainement une modulation d'amplitude de certains signaux. Nous l'avons retiré.

Le nouveau code CPLD semble fonctionner. Sdev 6.8ps entre les deux 500Mhz.

=> tests avec modulateur cf autre entrée elog.

distribution du systeme entre baie 8 baie 9 et sous systeme

https://atrium.in2p3.fr/c3aa1ee8-ef12-47c6-b9f0-25641bf71744

Le 500MHz Li entre baie 8 et 9 passe par le cable heliax 90358

baie8-E7  baie 9-D1

sensibilité mélangeur    180° 500MHz   => 100mV  ie pente autour de la valeur moyenne (-30mV) 2mV/degré 500MHz

Test synchro dont changement de frequence.

Le systeme de génération du timing (programme CPLD 33li*33Ri (delay ligne)  33ri*41li  41li)

A 500.02MHz, il y a 16% des coups qui sont manques.

A 500.1MHz il y a 4.6% de coups qui sont manqués

A 500.25 il y a 2.2% des couop qui sont manqués

Aujourd'hui la puissance envoyé par le synthé 500MHz RI était trop faible (-15dbm au niveau de l'ampli RF). Alors que tous l'affichage était correcte (freq: 500.25MHz, puissance 18dbm) 

Nous avons éteins et redémarré le synthé et la puissance nominal est revenu (20dbm au niveau de l'ampli RF). Nous avons réglé la fréquence à la main au niveau de l'afficheur. (au scope l'amplitude du signal à augmenté d'au moins un facteur 2). 

Phénomène à surveiller.

La frequence de l'anneau a ete changee pour voir le comportement a 500.02MHz.

Mesures a continuer vendredi.

L'anneau a ete remis a 500.25MHz et le rigol a 33.35MHz

le cablage de la synchro en baie 9 a été 'mis au propre" conformément au schéma ci joint

Dans l'état, le jitter entre les 2 500Li et Ri mesuré en baie 8 est de 7 ps Sdev et 22ps FW10% (sur 1mn)

la mesure est aussi faite en baie 9 à travers un mélangeur (Wac3-ch3) (l'étalonnage amplitude /temps en sortie de mélangeur n'est pas réalisé)

une dérive existe toujours, (non quantifiée et très variable au cours du temps)

Pickup cavite RF puissance incidente <=> Panneau 91501 A1 <=> Baie 9, E2 <=> Baie 5, WAC3, voie 4

WAC3:

Ch1 debranche

Ch3 = Melange pickup cavite RF, 500MHz RI

Ch4 = 500MHz pick up cavite RF

Sur ER/CA/RAC.05-ELR.01-WAC.01:

Ch3 = 33MHz CFP

Ch4 = Trigger Gen 2 Ch7

La mesure du jitter en les 500Li et Ri est de 7ps Sdev (22ps FW10%)

(les mesures anormalement hautes du début de semaine étaient dues à une érreur de parametrage de la mesure, seuil  dT@level en relatif )

Mesure du dephasage par les dephaseurs, cf images jointes.

Dans la config actuelle le dephaseur 33MHz n'influe pas sur la valeur du mixage des deux 500MHz.

===

Mesure sur le déphaseur 33MHz étrange

Sur le déphaseur 500MHz on a bien quelque chose de cohérent mais c'est le bazar pour remonter à la charge

j'ai éssayé de comparer la dérive en temps (mesurée en temps sur l'oscillo baie 8) et la dérive en tension en sortie du mélangeur (baie 9) pour avoir une rélation temps tension quand le mélangeur est autour de "0"

mais la dérive est faible sur 10mn (trop stable ) et je n'arrive pas à mesurer de correspondance..

===

Fin de journee: Probleme sur le mixeur 500MHz. Tres gros jitter. Probablement un cable endommage.

18:25 Quelques connecteurs resseres... Le bruit a diminue... On semble etre revenu a des valeurs raisonnables.

Signal declencment camera streak: gene 4, canal 9

Routage Streak camera:

Baie 8 <=> Baie 34

E4, A1, A2, A3 <=> B3(N), A1, A2, A3

A1/A1: Declenchement streak camera gene 4, channel 9

E4/B3: 125MHz

A3/A3: 16MHz

A2/A2: Declenchement laser PC gene 4, channel 2

Routage Laser:

Baie 8 <=> Baie 34

E1, E2 (N)  <=> B1, B2(N)

E1/B1: 500MHz Li

Value initiales phase shifters: 500MHz et 33MHz: 7.830V(AO6) et 0V (AO7)

Signal 33MHzRI  remis sur generateur.

Dephaseur 500MHz mis avant la mesue du 500MHz RI sur le wavecatcher.

Creation de CALC/SY/Synchro_Status pour les donnees de jitter et IHM_status_synchro
 

Le programme CPLD a été modifié puis remis à (33x33 ==> 33x41 ==> 41MHz avec ligne à retard externe) aujourd'hui

Un ampli a été ajouté sur la voie du 33MHz puis enlevé

Ajout d'un pickup sur le 500MHz envoyé à la cavité CFP

Les signaux synchro sont sur ER/CA/RAC.05-ELR.01-WAC.03

Ch7: 500MHz Linac

Ch6: 500MHz Anneau

Ch5: Melange des deux 500MHz + pass bas 15MHz

Ch4: Trigger Gen 2 Ch7

Ch3: 33MHz

Ch1: Electrons (une des électrodes de RI-C1/BPM.03 remonté via le câble BPM spare 46037 jusqu'au panneau 90526 en baie 5 sur la voie A6. Signal difficile a interpreter.

Ch0 et Ch2: Utilises pour autre chose.

Le declenchement du WAC3 etait sur -6.05us Il a ete change.

Signaux deplaces sur WAC3

Voie 2: Mélange des 500MHz + Passe-bas 15MHz

- Remis programe CPLD 13 septembre 2023: 33x33 clck 33x41 clck41; delai externe (ligne à retard)

- Suspicion de problème sur un câble SMA transportant le 41MHz.

- Changement de frequence du synthe linac: passage à 2998.54998MHz (sur le synthe mettre 2998549980.0045Hz).

- Nouvelle fréquence de comparaison F_linac/6/15= 33.317222MHz (33Li)

- Nouvelle fréquence laser photocathode F_linac/6/12= 41.646 527 5MHz (41Li)

-Image jitter17oct--00001.jpg: 41li = Oscillateur laser Photocathode; mesure jitter.

-Image jitter17oct--00003.jpg: 41li = Generateur tektro; mesure jitter.

- jitter17oct--00005.jpg: Jitter sur le 50Hz; Nombre de coups à +/-500us 9734/10000.

Image jitter17oct--00007.jpg: 41li = Oscillateur laser Photocathode; mesure jitter. Longue durée.

===

Bilan:

Le système est fonctionnel. Le jitter observé entre les deux 500MHz est inférieur à 10ps sdev à court terme. Une petite dérive lente entre les deux 500MHz a été observée (moins de 1ps/minute).

Le 41MHz linac est pris sur le signal photocathode.

Acquisition en cours sur 192.168.229.21

Voie 1: Trig

Voie 2: 33MHz CFP (simulé)

Voie 3: 500MHz Ri

Voie 4: 500 MHz Li

Routage 500MHz Li: Baie 8 B1 <=> Baie 38 A6 <=> Baie 38 A3 <=> Baie 9 C5

* En baie 9: Signal géné 33MHz divisé en 2 et envoie vers scope et baie 8. Le signal provenant de la CFP et le déphaseur ne sont plus utilisés.

* En baie 8: Entrées du mélangeur 8MHz x 8MHz remplacées par 33,xMHz CFP (simulé par un géné) et 41MHz Laser * 4/5 = 33,317222MHz. Ci après noté 33x33.

===

Frequence synthe Linac changée!!!! pour division entiere 2998.53 = 33.317 * 90

Obsrvation de sautes sur le 33MHz CFP. Cf Vidéo https://photos.app.goo.gl/a1MDU9EUsJt8mx5G9

===

Changement du programme CPLD. Nouveau programme: 26/9/2023, une seule bascule D=33x33, Clk=41MHz.

On observe que le 33MHzCFP saute sur 5 positions possibles.

Les 500MHz bougent l'un par rapport à l'autre, 2 phases possibles.

FW10% = 54ps entre les deux 500MHz. sdev: 12ps

Utilisation du 33MHzli comme clk dans le cpld.

C'est stable!

sdev=18ps, FW10%=76ps

===

Freq synthe linac remise a 2998.55MHz.

Freq Gene remise à 33.3172222MHz

==

ci joint une capture d'écran des jitters:

C1(jaune) 500MHz ring C3(bleu) 33ring

C4(vert) 500MHz Linac  C2(rouge) 41 Linac

Jitter entre les 500MHz 18ps sDev (76 FW10%)

Signal de l'une des électrodes de RI-C1/BPM.03 remonté via le câble BPM spare 46037 jusqu'au panneau 90526 en baie 5. Probablement sur la voie A6 (à vérifier), puis envoyer par cordon BNC sur le scope en baie 9.

Routage possible pour le 500MHz Linac: Baie 8 voie B2 <=> Baie 38 voie A7

Version CPLD: 8x8:33x41=>41(reset sur 2 front de 41)

Bruit mesuré entre les deux 500MHz: 42ps sdev / 170ps fw10%.

Le déphaseur 33MHz a été installé. Il est piloté par ER/CA/RAC.05-API.AO1/AO7

Nom proposé:

ER/SY/RAC.09-DEP.01

lui même composé de deux déphaseurs:

ER/SY/RAC.09-DEP.01-DEP.01

ER/SY/RAC.09-DEP.01-DEP.02

La phase RF anneau par rapport à la synchro est maintenant contrôlé par ER/CA/RAC.05-API.AO1/AO6 et ER/CA/RAC.05-API.AO1/AO7 qui donnent chacun un déphasage de 210 degres en allamnt de 0 à 10V.

Un DS sera ajouté prochainement.

Le probleme de bruit semble regle. Dephaseur reinstalle.

Le problème de bruit persiste. Le déphaseur a été retiré jusqu'à jeudi.

Le déphaseur piloté à été remis dans la chaîne allant de la source RF anneau à la cavité.

Pour l'instant il n'est pas alimenté.

Des mesures de bruit et des tests de pilotage auront lieu jeudi.

L'insertion des déphaseurs 500MHz a causé du bruit sur le signal envoyé à la cavité RF. Cf copies d'eçran ci-joint avec les déphaseurs alimentés et non alimentés.

Hypothèse à tester: bruit en provenance de l'alimentation 10V.

Le bouton "phase scan off" a ete ajoute sur l'IHM phase.py (faire un git pull pour recuperer la nuvelle version)

Branchement temporaire

Canal 4 du DEG2 => E2 panneau de brassage synchro => cable 90382 => port A2 panneau FBT

Un bouton pour connaitre l'etat des synthetisers de la synchro a ete ajoute dans la partie synchro de PlateformeIHM.

Le generateur DEG-3 [diag] etait partiellement plante (plus de reponses a certaines commandes).

Il a ete redemaree et reponds a nouveau normalement.

Alignement laser :

position iris :
- X: 5.985 mm
- Y : 3.552 mm

Phase Qmax : 362°

Charge phase avec iris @3mm

IHM des reglages des retards des éléments.

data/Shared/Interfaces/panneaux/Synchro/

ipython ep_delays.py

attention ne pas changer les largeurs des signaux

L'ajout du 16MHz anneau est nécessaire pour la synchro.

La modif est effectuée dans le chassis TriggerBox (baie 8) => sur la carte CPLD l'entrée IN2 (initialement mélange 3GHz linac - 125MHz ring) devient le 16MHz ring

la connection entre la baie 9 et la baie 8utilise le cable 90359 Baie9-D2 Baie-E8 (anciennement 10MHz

Résultats:

mesure effectuée entre le 125MHz anneau et une voie de timing du DG1

sur 1mn le jitter entre les signaux RF (500MHz ring 3GHz anneau et leurs sous-multiples) est de l'ordre de 110ps Sdev 

sur 40mn la largeur à 1% est inférieure à 600ps et la dérive de la valeur moyenne est de l'ordre de 300ps

l'ensemble des données est contenu dans un jitter inférieur à 1ns

*RST
SOUR:POW:POW?
-30
SOUR:POW:POW?  
-30
FREQ:CW?
1000000000
FREQ:CW 2998550000
SOUR:POW:POW 18
SOUR:POW:POW?
18
FREQ:MODE?
CW
OUTP?
0
OUTP ON
OUTP?
1
 

Exemple:

FREQ:CW?
2998550000
 

SOUR:POW:POW?
18

L 'ecran du synthe linac ne fonctionne plus.

Il est possible de se connecter au synthe linac par telnet avec la commande suivante:

$ telnet synthe-b8 5025

Ensuite envoyer les commandes du manuel chapitre 7 page pdf 389.

Sensibilité en Phase du systeme de mesure temps réel de la phase relative entre l'oscillateur laser PC et le 500MHz

 1 °3GHz/mV  la précision de la mesure est de 1.5 °3GHz _eff

Schéma de la mesure :

en attaché

A travers le déphaseur intégré dans l’oscillateur on fait varier la valeur de la phase (en pas 0 à 17000)

La valeur de la tension est mesurée à l’oscilloscope (impédance 1MOhms) (data en attaché)

Un fit est réalisé (matlab) pour obtenir la pente : 364mV/rad. A 500MHz la sensibilité en temps est de 318ps/rad.

On a donc une sensibilité (autours du zéro en sortie du mélangeur) de 0.87ps/mV

Soit à 3GHz une sensibilité de l’ordre de 1  °3GHz/mV  la précision de la mesure est de 1.5 °3GHz _eff

Aujourd'hui, François et moi avons mis à jour le firmware de la CPLD du systeme de génération des voies de déclenchement. Les "coups manqués" ont disparu, 3 pendant pendant 6 H de fonctionnement (environ 1 tous les 10s avant)

Recette du 01-02-2022 rechargé et sauvé sous le nom : 20220201_reference.xml

Correction d'un bug de lecture de recette dans le script => git push nécésaire pour pouvoir recharger une recette !

Impossible d'accéder au DS des miroirs M4 et M5 du laser.

Impossible d'aligner le laser sans les miroirs.

DS AcqAttr mannager démarrer correctement.

Générateur de retard Diag : Voies T6, T7, T8 (WAC) mise en SSE

-> Tir sigle shot sur le géné nécéssaire au début

Sinon cela fonctionne.

Retour en config normal.

Le trigger de la voie 14 du generateur 3 (diags) qui correspond a une redpitya etait sur SSE (tir unique). Il a ete remis sur EXT (mode normal avec declenchement externe).

MAUVAIS REPERTOIR !!!

Pour lancher les 2 DS il faut faire :

cd /data/shared/tangoscripts/DeviceServer/DS_CALC/Synchro/
./launch_ds_gene_retard_loc.sh

AM

Pour redémarrer le DS Sim.SY/DEG.sim :
/data/shared/DS_CALC/launch_ds_gene_retard.sh &

(Comment démarrer Sim.SY/DEG2.sim ?)

Tous les DEG avaient été remis à zéro... Peut-être qu'une interface synchro était ouverte au moment où le DS a été rechargé?

J'ai remis la config 6.

J'ai vérifié les largeurs de:

GENERATOR_2_CHANNEL_1: 'Ring pulsed injection' => 320ns
GENERATOR_2_CHANNEL_2: 'Ring pulsed extraction' => 320ns
GENERATOR_2_CHANNEL_3: 'Ring pulsed septum' => 5000ns

Declenchement OK

La synchro a ete redemaree avec les reglages de la memoire 6.

Bonjour,

En prévisions de la coupure électrique, la synchro côté linac a été éteinte. La synchro côté anneau était déjà éteinte quand je suis arrivé.

Les réglages actuels des retards sont sauvés dans la mémoire 6.

Le code de cron_synchro.py a été modifié de manière à prendre la valeur OVERALL_DELAY dans synchro_constants et à la retirer de la valeur lue dans le DEG lorsque celle-ci est écrite dans Tango. Inversement cette valeur est ajouté à la valeur TANGO lorsqu'elle est écrite dans le DEG.

Une bibliothèque synchro_tools.py a été écrite afin de permettre des balayages en temps.

La carte synchro CPLD du chassis synchro a les sorties DEG 2 3 4 qui se décale par rapport à la sortie DEG1 (50 Hz) avec un taux de répétition aléatoire. Le Décalage temporel est constant (5ms) entre les front montant DEG1 et DEG 2 3 4.

voir la prise d'écran ci dessous: partie haute acquisition (jaune deg1 rouge deg 2 bleu deg3 vert deg4) la partie basse est le zoom de la partie haute (surbrillance)

NNous avons un pB qsur le DEG1 en salle de controle:

bien que ce soit la fréquence la plus élevée, il manque parfois des "coups" par rapport aux fréquences les plus basses Linac Diag...

cela explique les "tirs" ratés que l'on a parfois (pas de signal modulateur => pas de pulse HT

je ne sais pas à quel point cela peux faire disfonctionner le modulateur qui doit etre à 50Hz

le conditionnemt est en cours je ne peux pas investiguer plus

Suite a un oublis de sauvegarde de la configuration décalé de 100µs, et un redémarrage du ds sim, il a fallu refaire les décalage de retard.

Nicolas trouvant que 100µs était trop, j'ai cherché le minimum de retard possible pour avoir un signal sur la caméra linac.

Après quelque test, j'ai décallé les retard de 40µs et ça focnctionne pour la caméra linac et la caméra laser.

sauvé dans : 20211028_1105_deplacement_trigger_linac_a_40_micro_s.xml

Impossible de passer à un trigg diag à plus de 1 HZ

Décalage de tous les délais de 100us effectué par Alexandre M.

Cela permet de trigger les caméras avec les ~ 70us d'avance. Caméras linac et photoCathode, réglées à 0 dans l'IHM des retard.

La fréquence des signaux de déclenches du DG3 (diag ) est conforme à celle de l'IHM en salle de controle:

Une des voies (ch16) avait un retard supérieur à la période du 5Hz interdisant un fonctionnement correcte du générateur de retard.

Peut etre faudrait il limiter les retards et les largeurs (en soft) pour ne plus avoir ce genre de probleme

Vincent

Suite des investigation avec François W ce matin:

Les codes "fréquence" sont bien transmis jusqu'à la CPLD de la carte synchro du chassis Synchro (Baie8), les fréquences programmées dans l'IHM sont bien mesurées en sortie de la carte synchro (signaux qui servent à déclencher les DGs en externe)

Nous avons testé le DG3 (baie 9) => avec un générateur d'impulsion qui donne la fréquence externe (Fext)

une voie de sortie est regardée au scope (CH20 EXT mode Width 5ms amplitude 5V)

pour toutes Fext> 1Hz Freq CH20 = 1Hz  !!!!!!! pour Fext < 1Hz Freq CH20 = F ext

Pour le DG2

avec un générateur d'impulsion qui donne la fréquence externe (Fext)

une voie de sortie est regardée au scope (CH7 EXT mode Width 5ms amplitude 5V)

pour toutes  Fext   Freq CH7 = Fext   (dans la limite de la largeur de l'impulsion de CH7)

je n'ai pas d'explication pour cette limitation sur le DG3

pB de taux de répétition des signaux de déclenche:

Dans l'IHM le taux de répétition est de 5Hz pour les diags (code décimal 12 )

La relecture de l'automate est conforme au tableau des fréquences (lien code fréquence:https://atrium.in2p3.fr/5da11240-159f-4d7f-ae2e-ba87cd5ed733)

Attention Bit de poid fort Bit 4 et TRUE = 0 et False =1

la mesure du taux de répétition est de 1Hz

=> nous avons donc un pB

Il faudrait vérifier que le tableau des fréquences est bien celui dans le firmware de la CPLD de la carte synchro et que la sortie physique de l'automate soit conforme aux données de l'ATK panel

Alexandre et Vincent

La synchro est en route (le synthé 3GHz) avait été arreté et redémarré mais avec des valeur par défaut

A signaler un "bug" de fonctionnement de l'interface de gestion des retards:

quand on décoche "la coche" actif d'une voie cela arrete le signal sur cette voie

Quand on re cocche actif rien ne se passe.

=> après avoir regardé à travers la page oueb 

quand on décoche on passe bien en mode inibit sur la voie  => OK

quand on recoche on passe en mode "SSE" => donc pas de signal si il n'est pas provoqué par le software!

Suite a une erreur de manipulation la config des generateurs de retard a ete effacee a 16h12. J'ai recharge celle de 16h.

La fréquence de déclenchement des diagnostics a été passée à 5Hz à la demande de Jean-Claude.

J'ai mis en place en cron qui sauve automatiquement la config des générateurs de retard toutes les heures dans la mémoire 3. Si cela fonctionne je ferais aussi des sauvegardes quotidiennes et hebdomadaires via cron...

Si il faut restaurer les générateurs de retard:

-  cat /data/shared/SY_config/gene_memory.log

pour repérer la mémoire où la sauvegarde qui nous intéresse se trouve...

Ensuite dans panneaux/Synchro/

 ./gene_memory.py recall x

où x est la valeur de la sauvegarde à rappeler.

The timing interface has been updated to provide a wheel editor for the variables. A git pull is necessary to get the interface.

La ligne 157 du code delay_family.py avait été commentée dans le cadre des tests de déploiement de TaurusWheelEdit.

Le scope en salle de contrôle été déréglée et les coordinateurs indiquaient que la synchro ne fonctionnait pas. Après vérification, tout allait bien.

j'ai rechargee la config par defaut des generateurs de retard (config 9)

J'ai mis le générateur de retard 3 en mode SSE.

Pour info dans la mémoire des générateurs de retard il y a:

- En position 9 la config par défaut (à définir)

- En position 8 la config avec le générateur 3 en EXT

- En position 7 la config avec le générateur 3 en SSE

Comme cela il est possible de recharger la config en ssh ligne de commande:

cd ~/git/panneaux/Synchro

./gene_memory.py recall 7

Bonjour,

J'ai mis les bonnes adresses IP sur les generateurs de retard et tout teste. Cela fonctionne.

Par contre le DS n'est pas demarre donc l'IHM ne fonctionne toujours pas.

Nicolas

Les réglages des générateurs de retard ont été sauvés dans le canal 1 et 9 de chaque générateur.

Les réglages des générateurs de retard ont été sauvés dans le canal 1 de chaque générateur.

La recette XML des valeurs de synchronisation a été mise à jour dans https://atrium.in2p3.fr/nuxeo/nxdoc/default/dc821b72-899c-42cc-9896-8d327d9670ff/view_documents

Pour provoquer un declenchement force du DEG3 il faut regler les canaux a declencher sur SSE

et ensuite envoyer la commande

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

C'est equivalent a l'appui de Run/Stop sur l'interfqce web: http://192.168.229.25/

Des mesures préliminaires montrent un jitter entre la sortie DEG1-1 et la sortie DEG-4-8 de l'ordre de 25ps Sdev (sur 1K events)

Test du 7 01 2020 pour la connexion au EloG synchro