aircockpit.com

C'est le cas! Il y a un réseau de PC.

Ce que je n'arrive pas à faire et c'est la ma question (je me suis sans doute mal exprimé) c'est :

- Créé une variable (qui n'est pas associée à un offset de base de IOCP) dans une instance de SIOC de type Link IOCP
- Récupérer la valeur de cette variable dans une autre instance de SIOC (sur un PC déporté)

Est ce que vous voyez ce que je veux dire et est ce que vous pouvez m'aider?

Merci,
PJ.

PS : En ce qui concerne la commande GROUP, je ne peux pas l'utiliser car les différents modules SIOC doivent communiquer entre eux sur des variables qui n'existent pas dans la liste d'offset d'IOCP ou FSUIPC et qui sont déclarées à l'intérieur des modules SIOCeux même, d'où ma question.

Ce que tu veux faire est faisable. Voici comment je l'imagine :

Machine 1 : SIOC principal
Machine 2 : SIOC secondaire

Il faut savoir que SIOC est en fait un serveur IOCP caché. Ton sioc principal va contenir toutes tes variables.

tu parametres SIOC 2 pour qu'il se connecte au serveur IOCP de sioc 1. Ainsi tu peux y lire et écrire tes variables

Par contre pourquoi avoir différent sioc sur des ordis différents ?

Le but d'avoir des SIOC sur différentes machines est la recherche de performances. Puis comme les machines n'ont pas toutes le même rôle, les SIOC seront dispatchés en fonction. (impossible de faire tourner toute la logique d'un A320 sur la même machine + affichage (fluidité) + gestion des IO HW...

guda a écrit:Ton sioc principal va contenir toutes tes variables.

Je déclare comme ça ? : Var 0001, name VAR1, Link IOCP, Offset ???? ou juste Var 0001, name VAR1.

guda a écrit:tu parametres SIOC 2 pour qu'il se connecte au serveur IOCP de sioc 1. Ainsi tu peux y lire et écrire tes variables

Le paramétrage c'est OK mais comment je fais pour appeler ma variable du SIOC 1?

Peux tu me faire un exemple de se fonctionnement?

Merci pour tes réponses.

Je suis un peu largué moi aussi. Sur les anciennes versions de IOCP il me semble qu'il y avait un outil pour réassigner les EVENTS aux variables IOCP... ce n'est plus le cas ?

Dans IOCP Offset Explorer on voit qu'il y a des offsets "Iocpserver" 3100 à 3131 que l'on peut peut être utiliser ?

Egalement "User Defined" 3500 à 3507 qui sont libres... ça fait pas beaucoup

Il faut écrire Var 0001, name VAR1, Link IOCP, Offset xxxx si tu mets pas Link IOCP c'est une variable INTERNE, ça ne sortira pas !

sinon comme dit Guda, si tu linkes les SIOC entre eux sans passer par le serveur (ça marche donc ça ?) tu peux utiliser n'importe quel offset puisqu'on ira pas lire la valeur dans FS.

J'ai déjà fait ça il y a longtemps pour contrôler les écrans des PFD/ND/EICAS de PM, installés sur 3 PC différents, par des émulations clavier sur chaque PC. J'avais donc des variables IOCP qui indiquaient à tous les SIOC la configuration écran souhaité à partir du sioc qui avait les commandes (inters rotatifs)

Sachant que SIOC utilise trés peu de CPU/RAM, je ne vois pas l'utilité d'exploser le code sur différente machine pour des raisons de perf. D'autant qu'elles seront reliées en TCP/IP qui peut grever les perfs IOCP.

Pour ma part je cherchais les perf mais aussi a optimiser les échanges entre les PC : le but étant d'avoir les éléments "vitaux" sans lag : affichage principal, PFD/ND et SIOC :
1 PC puissant pour FS+VASFMC (pfd/ND)+SIOC (attention de n'avoir qu'une seule Carte Graphique car Windows se base sur la moins puissante). j'ai ajouté une matrox triple Head ==> 4 écrans sur la bécane
2eme PC : tous les EICAS (3 écrans) qui discutent avec SIOC
3eme PC : IVAO, VASFMC en remote pour les CDU, console instructeur

Niveau réseau, s'assurer d'être en gigabit sur tous les maillons (carte réseau mais aussi Switch - en non hub). D'avoir des câbles petits (non entremêlés) et blindés (CAT6) car les câbles électriques/structures métalliques aux alentours peuvent perturber le flux. S'assurer aussi que niveau PC la couche IPX est désactivée (pour réduire la taille des packets).

Quelle suite logicielle va tu utiliser ?

Nous allons utiliser les EIS que nous développons en C++ et qui devraient contenir un client IOCP.

Le fait de dispatcher les modèles de calculateurs (car c'est bien la l'idée) permet aussi de reproduire ce qui se fait en simulation pro (et pourtant les machines ne sont absolument pas les escargots que nous avons...) (4*4 cœurs et 16G de RAM pour les plus modestes)

Pour l'instant je me demande si je vais rester sur SIOC ou directement partir sur un code C (comme en vrai).
SIOC est bien pour la connection Hardware! donc il sera utilisé de toute façon.

Je teste, si ca passe sur une machine, tant mieux sinon je préfère savoir quelles sont les limitation de cette méthode.

Merci!

Avant j'étais développeur, j'aurais tendance à te dire de tout coder en C.

Sioc est un langage trop simple. Il suffit dans 90% des cas mais au prix d'un code long avec pleins de IF imbriqués, sans manipulation de fichier ni de chaine, sans objets

Par contre, vous allez réinventer la roue car beaucoup d'autres projets ont déjà codé le comportement d'un Airbus...

Non, vraiment aucun n'a codé le comportement réel d'un A320.
Et puis c'est la tout le plaisir de faire un simu, si c'est juste pour voler (en virtuel), ca ne m'interresse pas, c'est tout l'enjeu de commencer quelque chose et de le faire évoluer!

Tu ne pourras pas coder le comportement complet d'un A320. Ne serait-ce que les limites dues à Flight Simulator.
Par contre je te rejoins dans le fait de coder soit-même fait partie des motivations pour faire son cockpit

Bonne chance

guda a écrit:Tu ne pourras pas coder le comportement complet d'un A320. Ne serait-ce que les limites dues à Flight Simulator.

Justement, l'idéal serait de pouvoir utiliser au minimum FS, on a une plateforme au boulot où fs n'est utilisé que pour faire l'affichage du monde extérieur (en l'occurrence c'est flight gear). Certes, c'est pas demain la veille que nous pourrons faire la même chose, mais s'en approcher au maximum serait bien!

C'est le début, on va commencer par simuler DMC's, LGCIU's, BSCU's (la première partie hard construite est le MIP) pour se faire la main après on va élargir les calculateurs simulés pour voir jusqu'où on peut aller.
"Patience et longueur de temps. Font plus que force ni que rage" La Fontaine.

Merci pour les réponses, on va voir ce que l'on peut faire!