Project

General

Profile

Bug #356

Mise au point Timegen sur EM

Added by bruno katra over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
24/10/2014
Due date:
05/03/2015
% Done:

100%

Estimated time:
revision:
r0

Description

/!\ Issue copiée de #255 qui était en "planified" donc pas cloturable. #255 détruite depuis.
------------------------
Installation du code TImegen version 0.0.0.1 sur pc-coillot dans répertoire /opt/TIMEGEN
[validation@pc-coillot 2014_10_23]$ ls l /opt/TIMEGEN/
total 3944
drwxrwxr-x 2 validation validation 4096 24 oct. 13:43 0.0.0.1
-rw-rw-r-
1 validation validation 622 24 oct. 13:58 RELOAD_ALL_STAR_DUNDEE.py
rw-rw-r- 1 validation validation 4022648 26 sept. 08:16 RPW-MEB-LFR-NTT-00125-1-0_GSE_System_clock_simulator.odt

Le test a mis en évidence que la commande TC_UPDATE_TIME n'est pas prise en compte.
- Envoi des timecode OK (on utilise minicom -D /dev/ttyUSB3 (ou USB1)

Avec SocEXplorer, envoi de la commande TC_LFR_UPDATE_TIME, l affichage montre que le COARSE TIME n est pas mis à jour.

----------------------------------------------------------------------------
Contexte
LFR_FSW_PATH = /opt/LFR-FSW/2.0.1.1/fsw
Bridge selection = StarDundee
SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520

Carte EM: 1.1.26
Mini LFR : 0.1.25

2015_2_27-12_4_8_packet_log.data (2.73 KB) 2015_2_27-12_4_8_packet_log.data Veronique bouzid, 27/02/2015 12:05 PM

History

#1 Updated by bruno katra over 6 years ago

  • Description updated (diff)
  • Status changed from New to Closed

Updated by paul leroy 3 days ago

Assignee changed from paul leroy to Veronique bouzid

Comment Edit

Si timegen est lancé, il envoie un paquet TC_LFR_UPDATE_TIME à LFR 700 ms après la réception de chaque timecode valide.

1) Tu envoies un paquet TC_LFR_UPDATE_TIME à LFR (spacewire link 1), mais que LFR est synchronisé par timegen, la synchro timegen prend le dessus. Il peut y avoir un aléat bizarre sur une seconde si tu envoies ton paquet avec lfrcontrolplugin au mauvais moment et qu'il écrase celui de timegen.

2) Tu envoies un paquet TC_LFR_UPDATE_TIME à timegen (spacewire link 2), il mets à jour son coarse time local et envoie des paquet TC_LFR_UPDATE_TIME actualisé à LFR: la date est mise à jour.
#2 Updated by Veronique bouzid 7 days ago

File 2015_2_27-12_4_8_packet_log.data added
Assignee changed from Veronique bouzid to paul leroy
% Done changed from 0 to 100

Comment Edit

Voici le nouveau contexte de test opérationnel depuis debut 2015

- Timegen 0.0.0.1
- LFR-FSW 2.0.2.2 (VHDL = 1.1.63)
SocExplorerEngine.getSocExplorer: Version = 0.4.5, Branch = default, Changeset = c4b98d42ee59

Ouverture de Socexplorer
Lancement du script /opt/VALIDATION_R2//LFRControlPluginstartALL.py

On observe sur la fenetre LFRControlPlugin0 Onglet TM statitics
que le coarse time est bien initialisé à zero et s incremente de 1 . Cela correspond à la date de réference (2000/01/01)

Ensuite onglet dashboard
on envoie un TC_LFR_UPDATE_TIME (now) mais cela ne met pas à jour le coarse time.

Par contre si je glisse dans la console python le script (/opt/VALIDATION_R2/setTime.py qui envoie la commande TC_LFR_UPDATE_TIME avec la date du moment (now) cela fonctionne.

Le fichier de log montre que les HK s incremente correctement mmais que le temps envoyée par la cde TC_UPDATE_TIME n a pas été prise en compte.

Ici un extrait du fichier de log (/home/validation/data/2015_2_27-12_13_16_packet_log.data
qui correspond à l'utilisation du script setTime.py montrant la prise en compte de la mise à l heure
2015 2 27 12:13:24:823 TM_LFR_HK time = 0x 19 395
2015 2 27 12:13:25:824 TM_LFR_HK time = 0x 1a 394
2015 2 27 12:13:26:824 TM_LFR_HK time = 0x 1b 394
2015 2 27 12:13:27:823 TM_LFR_HK time = 0x 1c 393
2015 2 27 12:13:28:823 TM_LFR_HK time = 0x 1c831be8 393
2015 2 27 12:13:29:823 TM_LFR_HK time = 0x 1c831be9 392
2015 2 27 12:13:30:823 TM_LFR_HK time = 0x 1c831bea 391
2015 2 27 12:13:31:823 TM_LFR_HK time = 0x 1c831beb 391
2015 2 27 12:13:32:823 TM_LFR_HK time = 0x 1c831bec 390
#1 Updated by paul leroy 29 days ago

Assignee changed from paul leroy to Veronique bouzid

Comment Edit

Rejouer les tests sur FSW >= 2.0.2.1 et VHDL >= x.1.57

Also available in: Atom PDF