aircockpit.com

Bonjour Michel,

En effet, je te confirme, pas possible de re-armer l'A/THR, quelque soit la phase de vol ou la position des manettes ...

Donc cela équivaut à un ordre de déconnexion définitif de l'A/THR, comme un appui prolongé ou permanent sur l'un des boutons (CPT ou F/O) des manettes...

Ce matin, d'autres tests, mais nouveau pb, je n'ai plus les petites pinules qui représentent la position des manettes sur l'E'WD, tant avec le TQ soft que le hard ! Bref, je commence à patauger

Voilà autre chose... .
Demande toi tout de même si la complexité et l'hétérogénéité (en soft autant qu'en hard) de ton installation, n'est pas tout simplement en cause, en tant que source de fragilité et d'instabilité...
Les autres utilisateurs de Skalarki et de SIOC / OC ne rencontrent pas ce problème, donc...

Je pense que je vais re-installer complètement FMGS, et coté OC, je vais changer usb expension et master, j'en profiterai pour mettre la seule master restante en position 1 plutôt que 3, ce qui me permettra dans sioc.ini de restreindre la déclaration de l'usb expension.

Peut-être rechercher une simplification de l'ensemble...

Ceci dit, je pense que seul Jean-Luc peut rèpondre à la question de savoir ce qui, dans son soft, pourrait provoquer cette déconnexion (mis à part les causes "normales") ...

Possible en effet, je te le souhaite...
Mais tu as fait les tests avec son soft seul et tout se passe bien... Je crains que Jean Luc ne puisse rien faire si son soft reçoit des ordres extérieurs à son soft, qui se contentera de les appliquer...

Je croise néanmoins les doigts pour qu'il ait une idée et puisse te suggérer une solution.
Pour ce qui me concerne, je ne suis pas en capacité d'aller plus loin.

Bon courage à toi, @++ ,
Michel

Michel,

je ne suis pas en train de penser que le pb réside au sein de FMGS, mais savoir comment est codé FMGS peut permettre d'envisager des causes improbables, des situations qui n'auraient pas de sens dans les systèmes réels et qui perturberaient le fonctionnement normal du soft.

Cela étant, avec la v2 du simu je suis en effet en train de simplifier considérablement tout le hard, j'ai déjà retiré une quantité impressionnante de cartes OC et de torons divers !

Et là, je suis le nez dans le MIP, en train de continuer ... des nouvelles d'ici peu !

Michel

Re,

Que dire d'autre ?


Les dernières actions :
1) Ré-installation de FMGS
2) Remplacement des 2 cartes OC restantes, USB expension et Master, et repositionnement de la Master en première position (elle était antérieurement en 3ème, séquelle du temps où le Simu comportait 3 USB expension et 5 master).
3) Renumérotation en conséquence des I/O concernées, tant dans Sioc-creator que dans mon code SIOC spécifique, et restriction de la déclaration de l'USB expension dans sioc.ini

Re-démarrage sans pb, et disparition du phénomène de désarmement de l'A/THR

Un grand merçi tout particulier à Michel, ainsi qu'à Fabien et Greg, ce forum est vraiment irremplaçable

Quelle explication ?
- Mon hypothèse rejoint la remarque de Fabien : la master positionnée en 3ème position sur l'USB expension conduisait à compter 3 master dans la déclaration de l'USB expension dans sioc.ini ; du coup, les 144 entrées des 2 master absentes étaient actives ; or les pull up/down sur l'USB expension étant vraisemblablement trop fortes, le niveau de ces entrées en l'air fluctuait sans arrêt ; comment ces fluctuations peuvent elle influer le code SIOC ? j'ai vérifié dans mes divers paramétrages/divers codes qu'aucune variable SIOC ne pointait dans cette plage, mais ...
- Ou alors port 3 de l'USB expension un peu naze ? ou Master défaillante ?

Bon, mauvais souvenir, je suis bien soulagé, cette affaire commençait à relever du spiritisme

A+, Michel

Hello Michel

Désolé j'arrive après la bataille...
Ce qui est TRES possible, c'est que l'un de tes boutons ATHR DISCONNECT (les boutons rouges sur les manettes de gaz pour déconnecter l'ATHR) soit envoyaient un "clignotement" ON/OFF au soft, d'où déconnexion (faut que je vois si ça le fait qu'en l'air me rappelle plus comme ça). Ou alors, les boutons n'ont pas les 2 fonctions ON/OFF séparées, et ça coupe complètement l'ATHR (c'est prévu pour une panne d'ATHR qui mettrait TOGA ou IDLE tout le temps...).

A+
Jean Luc

Bien, pourvu que cela dure !

Il ne faut pas oublier que les entrée "en l'air" provoque beaucoup d'échange sur l'USB, alors que L'ensemble SIOC/carte IO est conçu justement pour éviter ces échanges et cela fonctionne pas mal du tout en temps normal.

Tu as pris la bonne décision !

Fabien

En effet, Jean-Luc,

J'ai rapidement pensé à ça, et ai très vite déconnecté physiquement ces boutons ! Mais les entrées sont restées en l'air, et les déclarations sont restées ...

Mais j'aimerais bien savoir à partir de quel instant, en phase take-off, l'action sur ces boutons est prise en compte ?

Mihel

A320 hérétique a écrit:En effet, Jean-Luc,
../..
déconnecté physiquement ces boutons ! Mais les entrées sont restées en l'air, et les déclarations sont restées ...
../..

ça c'est pas cool ...

En effet, en effet

Michel

A320 hérétique a écrit:Mais j'aimerais bien savoir à partir de quel instant, en phase take-off, l'action sur ces boutons est prise en compte ?

L'action est prise en compte immédiatement, mais en regardant dans le code, tu as "trouvé" une condition non prévue…
Tant que tu es au sol, tu peux avoir l'ATHR armé si tu as les manettes en TOGA ou FLX.

A quelque chose malheur est bon !

Bonne fin de soirėe.

Michel