Task #624
closedLong test with SBM1 and SBM2 FSW 3.0.0.22
90%
Description
Description
le script joué est joint il se nomme test_modes_SBMx_12h.py
1 Les parametres utilisés sont ceux par défaut du normal mode.
2- 10mn de NORMAL
3- 6h et 10s de SBM1
4- 6h et 10s de SBM2
5- 10mn de NORMAL
Ajout 10s sur SBM pour recevoir la derniere ASM.
Contexte du test
---------------------
FSW 3.0.0.22
VHDL 1.1.89
EM AVEC Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee
Files
Related issues
Updated by Veronique bouzid over 8 years ago
- Related to Task #620: 3.0.0.22 added
Updated by Veronique bouzid over 8 years ago
- Description updated (diff)
Le test n'etait pas bon. On a recupéré que des HK.
J'ai gardé les fiichiers 2016_02_12_16_55_23*) (ils se trouvent sur pc-faust9 dans le répertoire /home/validation/data/R3/3.0.0.22/TESTCHARGE/TEST-ECHOUE.
J'ai resetté avec le bouton LFR puis glissé
- le script LFRControlPlugin_startAll+setTime.py
- le script test_mode_SBMx_12h.py
Updated by Veronique bouzid over 8 years ago
- Related to Support #626: Lost TM_LFR_HK in 3.0.0.22 added
Updated by Veronique bouzid over 8 years ago
les fichiers de tests (2016_02_13_11_48_53_packet_l*) sont sur pc-faust9 dans le répertoire /home/validation/R3/3.0.0.22/TESTCHARGE/sbm1+sbm2.
Updated by Veronique bouzid over 8 years ago
- Related to Support #627: Commutation immediate added
Updated by Veronique bouzid over 8 years ago
- Assignee set to thomas chust
- Priority changed from Normal to Urgent
les fichiers de test (2016_02_13_11_48_53_packet_l*) sont sur pc-instru weekly erase / Thomas/run-2016-02-13_3.0.0.22-1.1.89.
Updated by thomas chust over 8 years ago
- Assignee changed from thomas chust to Veronique bouzid
Véro, il est bizarre ton fichier. Decommuté il ne donne aucune donnée ?
Updated by thomas chust over 8 years ago
En fait il est tout petit : 40 Mo au lieu de 1.2 Go avec le FSW 3.0.020 (#618)
Updated by Veronique bouzid over 8 years ago
- Assignee changed from Veronique bouzid to thomas chust
Cette fois c'est la bonne.
Log de Socexplorer
Entered in NORMAL with defaults during 10mn
Entered in SBM1 with defaults during 6h et 10s
Entered in SBM2 with defaults during 6h et 10s
Entered in NORMAL with defaults during 10mn
Entered in STDBY
Voici la taille des fichiers obtenusrw-rw-r-. 1 validation validation 40455311 17 févr. 05:46 2016_02_16_17_26_11_packet_log.datarw-rw-r-. 1 validation validation 1223316598 17 févr. 05:46 2016_02_16_17_26_11_packet_record.data
les données sont copiées sur pc-instru Weeklly erased/Thomas/run-2016-02-16-3.0.0.22-1.1.89.
Les données sont également rangéessur pc-faust9 dans /home/validation/data/R3/3.0.0.22/TESTCHARGE/sbm1+sbm2.
Updated by thomas chust over 8 years ago
- File plot_delta_SWF_F0_test.png plot_delta_SWF_F0_test.png added
- File plot_delta_SWF_F1_test.png plot_delta_SWF_F1_test.png added
- File plot_delta_SWF_F2_test.png plot_delta_SWF_F2_test.png added
- File tests_time_asm_VHDL-1.1.89_FSW-3.0.0.22_2016_02_16_test tests_time_asm_VHDL-1.1.89_FSW-3.0.0.22_2016_02_16_test added
- File tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.22_2016_02_16_test tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.22_2016_02_16_test added
- File tests_time_swf_VHDL-1.1.89_FSW-3.0.0.22_2016_02_16_test tests_time_swf_VHDL-1.1.89_FSW-3.0.0.22_2016_02_16_test added
Voir fichiers joints. OK. Commentaires éventuels plus tard. Plouf ...
Updated by bruno katra over 8 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 90
En effet, le comportement des SWF a l'air plus stable qu'en 3.0.0.20
+ lancement du periodicity.py : analyse montre qu'il n'y a plus le saut 169s.
Updated by thomas chust over 8 years ago
- Assignee changed from thomas chust to paul leroy
- Priority changed from Urgent to Normal
- SWF: la modif de Paul semble avoir changer des choses car le type d'oscillation est de nature différente ce qui est surprennant en première analyse car on ne s'attendait pas à actionner des corrections négatives (ce qui a été corrigé dans l'algo); cela renvoie peut-être à mon incompréhension toujours actuelle de ce que fait l'algo pour de vrai; cependant le résultat est correct : les dérives semblent maitrisées; pour ma part à suivre ...
- ASM: avec une transition décalée de 10 s après l'arrivé des (6ièmes) ASM il n'y a plus le problème observé suite à la transition SBM1 vers SBM2 ; les 7ièmes ASM (et non les 6èmes comme j'ai pu l'écrire par erreur [corrigé depuis dans le texte...]) sont bien là au temps attendu; en fin presque: 1s après (les 7ièmes arrivent 3611s après les 6ièmes).
- ASM bis: comme avant: les premiers ASM arrivent 1h10 après le passage en NM lorsqu'il y a eu une transition en SBM1 10 mn après le début du NM: le passage en SBM1 a remis à 0 le timer pour la génération des ASM toutes les 3600s. Même remarque pour le passage à SBM2 (10s de plus ...)
- CWF3: cette fois ci OK (nominale, pas de problème avec le le temps du 2ième buffer; on ne comprends toujours pas ce qui a pu se passer avec la 3.0.0.20; peut-être à suivre ...)
- CWF2: idem OK (la continuité temporelle est nominale)
- CWF1: idem OK (continuité temporelle est nominale)
Updated by thomas chust over 8 years ago
- Related to Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20 added
Updated by paul leroy over 8 years ago
- Status changed from In Progress to Feedback
- Assignee changed from paul leroy to thomas chust
Lors des transitions suivantes, la génération des ASMs est redémarrée (effet collatéral de la nouvelle stratégie de changement de mode):
NORM => SBM1
NORM => SBM2
SBM1 => NORMAL
SBM1 => SBM2
SBM2 => NORMAL
SBM2 => SBM1