Project

General

Profile

Actions

Bug #863

closed

Produits SCIENCE : périodes des ACQUISITION_TIME et TIME non nominaux avec TIMEGEN

Added by bruno katra about 7 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Urgent
Category:
R3+
Target version:
-
Start date:
28/12/2016
Due date:
% Done:

10%

Estimated time:
revision:
r0

Description

Les produits BP arrivent à la cadence attendue mais avec des champs ACQUISITION_TIME qui n'ont pas la bonne période seulement lorsqu'on utilise TIMEGEN.
Exemple:
2016 12 28 12:33:59:717 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d6c ffeb
2016 12 28 12:34:19:797 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d7a ffcf
2016 12 28 12:34:39:771 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d88 ffb4
2016 12 28 12:34:59:771 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d96 ff9a
2016 12 28 12:35:19:782 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66da4 ff81

Les BP2 sont bien arrivés toutes les 20s mais leur ACQUISITION_TIME est espacé de 14s

Idem BP1:
2016 12 28 12:33:43:773 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d60 ffff
2016 12 28 12:33:47:711 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d63 fffb
2016 12 28 12:33:51:711 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d66 fff5
2016 12 28 12:33:55:774 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d69 fff0

Les BP1 ont bien arrivés toutes les 4s mais leur ACQUISITION_TIME est espacé de 3s

Idem pour les ASM : 3s au lieu de 4s
Idem pour les SWF : 15s au lieu de 22s

NB : les mêmes tests SANS TIMEGEN ne montrent pas le problème.
NB2 : Le bug n'était pas présent en R3 + ancien VHDL (nous avons revérifié les résultats des tests de charge effectués en oct 2015)
NB2 : il est probable que TOUS les produits soient impactés.

Contexte du test
---------------------
FSW 3.1.0.4
VHDL 1.1.91
EM1 avec TIMEGEN

Actions

Also available in: Atom PDF