LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

fsw >= 1.0.0.5
La fonction de commutation de mode à une date fixée est implémentée conformément à la SSS:
=> un mode erroné = TM_LFR_TC_EXE_INCONSISTENT
=> une transition non autorisée = TM_LFR_TC_EXE_NOT_EXECUTABLE
=> une date inférieure ou égale au temps courant = TM_LFR_TC_EXE_INCONSISTENT
=> une date valant 0 = transition immédiate
=> une date postérieure de plus de 3 secondes à la date courante = TM_LFR_TC_EXE_INCONSISTENT
=> toute autre date entraîne la transition à la date demandée

Ce point est tjs d'actualité avec la version Soft: 1.0.0.6 (variante sur carte finale).
PRECISION: Je ne parle que des TM_LFR_HK.

En rejouant le test SVS-0034, j'ai pu observé qu'effectivement ce point n'etait tjs pas résolu.
J ai donc ecrit un test plus simple qui demande
- une commutation de mode t+1s
- une commutation de mode t+2s
- une commutation de mode t+3s

Pour vérifier le dysfonctionnement, voir le fichier 2014_05_16-12_48_12-Detail.txt (en PJ)

Ici la trace t+2s, on voit bien que le bloc de HK montre deja la communication de mode avant la date demandée.

12:47:48.978489, TM_LFR_HK,TIME=0x800000043a18, HK_LFR_MODE: SBM2 = 4

12:47:49.776147, TC_LFR_ENTER_MODE (CP_LFR_MODE=0),
CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000060000,

12:47:49.796455, TM_LFR_TC_EXE_SUCCESS,TIME=0x800000050bc0

12:47:49.978485, TM_LFR_HK,TIME=0x800000053a19, HK_LFR_MODE: STANDBY = 0
HK_LFR_LAST_EXE_TC_TIME=0x800000050bc0 ( correspond à TM_LFR_TC_EXE_SUCCESS)

La commutation de mode a été effective dans la foulée.

Contexte:
LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f

Carte mini-LFR: LFR-172200 dev V1.0; No série 5
Vhdl: 0.0.16
Soft: 1.0.0.6 (variante sur carte finale)

Brique Star-Dundee S/N XX.
Script utilisé
SVS-0034/just_tm_hk.py

Le fonctionnement précis du changement de mode est le suivant:
Si la TC est correcte
1) on arrête le mode en cours immédiatement
2) on redémarre les tâches temps réel avec les paramètres du nouveau mode
3) on configure le hardware pour qu'il démarre l'acquisition à la date fixée
4) à la fin de ces étapes, LFR est officiellement dans le mode, ce que reflètent les HK. C'est l'acquisition proprement dite qui commencera à CP_LFR_ENTER_MODE_TIME. On considère que LFR a changé de mode à la fin de la préparation complète du-dit mode.

C'est quelquechose dont j'avais parlé avec Gérald et ça nous paraissait la façon la plus appropriée de procéder. Il faudrait peut-être mettre à jour la SRS pour préciser le fonctionnement.

Pour finit, le juge pour une commutation réussie est la datation des données scientifiques, notamment les waveforms, qui doit être liée à CP_LFR_ENTER_MODE_TIME. C'est un des points à vérifier.

SRS mise à jour avec les informations de Paul sur la façon de valider un changement de mode (REQ-LFR-SRS-5509_Ed1 dans SRS 1.6+).