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)

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/

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

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

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

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.

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

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

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.

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

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

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!

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

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

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

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.

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

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

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

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)