LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Fonction remplacée par:

SpwPlugin0.StarDundeeSendOneTimecode( value )

où value est une valeur de timecode valide. Attention, il faut envoyer une série de timecodes valides pour qu'ils soient pris en compte par LFR et donc reflèté dans les TM_LFR_HK. Par exemple:
SpwPlugin0.StarDundeeSendOneTimecode( 21 )
SpwPlugin0.StarDundeeSendOneTimecode( 22 )
SpwPlugin0.StarDundeeSendOneTimecode( 23 )

La fonction a été testée à l'aide du script
/opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0011/starting_time_step1.py.

On envoie une TC_LFR_UPDATE_TIME et on attend 0.3s avant d'envoi 10 timecode valides (increment de 1).
for i in range(10):
SpwPlugin0.StarDundeeSendOneTimecode (i)

12:31:20.196781, TM_LFR_HK,TIME=0x80000009319f, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0
12:31:20.901267, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x000000000000
12:31:21.196706, TM_LFR_HK, TIME=0x8000000a319f, HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0
12:31:22.19677, TM_LFR_HK, TIME=0x00000007fb34, HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_DPU_SPW_TICK_OUT_CNT=8, HK_LFR_DPU_SPW_LAST_TIMC=9

Il me semble que le temps obtenu sur la derniere HK n'est pas correct, cela devrait etre proche de 1s ou 2s et non 7s.

Les logs du test se trouvent dans /home/validation/data/R3/3.0.0.3/SVS-0011/step1

Contexte du test
----------------
FSW 3.0.0.3
VHDL 1.1.83
EM1 sans timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

Il faudrait espacer tes timecodes (de 1 seconde par exemple), sinon l'horloge locale s'incrémente seule à chaque réception. Relire éventuellement la doc de Jean-Christophe pour comprendre le mécanisme d'incrémentation de l'horloge locale.

Il semble que je n'utilisais pas correctement la fonction SpwPlugin0.StarDundeeSendOneTimecode.

j'ai modifié mon script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0011/starting_time_step1.py pour n'envoyer que le nbre de time-code nécessaires
(2 time code valid sent from 1 to 2) après l'envoi de TC_LFR_UPDATE_TIME

09:51:19.227994, TM_LFR_HK, TIME=0x8000000831b8
09:51:20.228145, TM_LFR_HK, TIME=0x8000000931b8
09:51:20.936575, TC_LFR_UPDATE_TIME (CP_RPW_TIME=0x000000000000)
09:51:21.227792, TM_LFR_HK, TIME=0x8000000a31b8
09:51:22.228006, TM_LFR_HK, TIME=*0x00000001fc89*
09:51:23.22774, TM_LFR_HK, TIME=0x00000002fc89
09:51:24.227764, TM_LFR_HK, TIME=0x00000003fc89

ensuite j'attends la desynchronisation

09:52:22.227882, TM_LFR_HK, TIME=0x0000003dfc89
09:52:23.227892, TM_LFR_HK, TIME=0x8000003efc89
09:52:24.227891, TM_LFR_HK, TIME=0x8000003ffc89

et je renvoie une TC_LFR_UPDATE_TIME avec CP_RPW_TIME=0x1d0a30570000
09:52:32.22785, TM_LFR_HK, TIME=0x80000047fc89
09:52:32.242853, TC_LFR_UPDATE_TIME
09:52:33.227786, TM_LFR_HK, TIME=0x1d0a3057aed2
09:52:34.227858, TM_LFR_HK, TIME=0x1d0a3058aed2

les fichiers de log (2015_06_26-09_52_38*) sont dans /home/validation/data/R3/3.0.0.7/SVS-0011

Contexte du test
----------------
FSW 3.0.0.7
VHDL 1.1.83 (_c car chgt de contrainte sur timing)
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee