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
Décalage de tous les délais de 40us effectué par Alexandre M.
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)
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
Test du 7 01 2020 pour la connexion au EloG synchro
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.
Les réglages des générateurs de retard ont été sauvés dans le canal 1 et 9 de chaque générateur.
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
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
j'ai rechargee la config par defaut des generateurs de retard (config 9)
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!