Project

General

Profile

Actions

Task #624

closed

Long test with SBM1 and SBM2 FSW 3.0.0.22

Added by Veronique bouzid about 8 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/02/2016
Due date:
% Done:

90%

Estimated time:
revision:
r0

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

Related to Task #620: 3.0.0.22ClosedVeronique bouzid12/02/2016

Actions
Related to Support #626: Lost TM_LFR_HK in 3.0.0.22 Closedbruno katra13/02/2016

Actions
Related to Support #627: Commutation immediateClosedVeronique bouzid14/02/2016

Actions
Related to Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20Closedpaul leroy11/02/2016

Actions
Actions #1

Updated by Veronique bouzid about 8 years ago

Actions #2

Updated by Veronique bouzid about 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

Actions #3

Updated by Veronique bouzid about 8 years ago

Actions #4

Updated by Veronique bouzid about 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.

Actions #5

Updated by Veronique bouzid about 8 years ago

Actions #6

Updated by Veronique bouzid about 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.

Actions #7

Updated by thomas chust about 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 ?

Actions #8

Updated by thomas chust about 8 years ago

En fait il est tout petit : 40 Mo au lieu de 1.2 Go avec le FSW 3.0.020 (#618)

Actions #9

Updated by Veronique bouzid about 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 obtenus
rw-rw-r-. 1 validation validation 40455311 17 févr. 05:46 2016_02_16_17_26_11_packet_log.data
rw-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.

Actions #11

Updated by bruno katra about 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.

Actions #12

Updated by thomas chust about 8 years ago

  • Assignee changed from thomas chust to paul leroy
  • Priority changed from Urgent to Normal
Par rapport à la 3.0.0.20 (#618):
  1. 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 ...
  2. 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).
  3. 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 ...)
  4. 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 ...)
  5. CWF2: idem OK (la continuité temporelle est nominale)
  6. CWF1: idem OK (continuité temporelle est nominale)
Actions #13

Updated by thomas chust about 8 years ago

  • Related to Task #618: Long test with SBM1 and SBM2 FSW 3.0.0.20 added
Actions #14

Updated by paul leroy almost 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

Actions #15

Updated by bruno katra almost 5 years ago

  • Status changed from Feedback to Closed

Fait pour 3.2.0.24

Actions

Also available in: Atom PDF