LO-200 SIOC Serveur, Les exports de LO 2.0 vers SIOC

[KaTZe]

@Vippen,

En fait sous FC1.12 on utilisait les 200 premiers.
Mais là avec la multiplication des exports il faudrait probablement réserver les 500 premiers offset.

Je vais voir si je décale les offsets calculés pour pouvoir garder les offset groupés par type d'info.

@Gilles, je vais voir pour LOVP ... mais là on manque cruellement d'info. sur le format des exports ... j'arriverai peut être à récupérer le module dans le serveur de LeCreole.

Je vais essayer de pondre qqchose pour le WE prochain.

Miaou

[VIPPEN]

katze quels sont les fichier que tu as modifie pour faire fonctionner l'export lua vers le sioc???

[DArt]

PS @Dart : Tu as déjà réfléchi à une structure pour tes exports vers LoPlug ?
Qu'est ce que tu me conseilles (le top serait un module SIOC pour Loplug

Oui nous avons déjà une structure avancée pour LoPlug, en fait, contrairement à losioc qui envoit toutes les données à chaque trame, nous avons un système de programmation du lua. Le client (le module lockon de LoPlug) paramètre le lua pour chaque valeur qu'il veut selon une période différente (ex: altitude toutes les 200ms et le fuel toutes les 5 secondes). Cela évite trop de traitement dans le lua et allège LockOn de ce poids. C'est complexe mais marche très bien. Pour le sioc, je suis pas contre, au contraire, reste à savoir si c'est faisable. Je sais que Tolteque a déjà regardé, mais l'interface avec SIOC est pas le plus facile d'accès, à revoir...

[KaTZe]

En fait Losioc, n'envoie une donnée que si elle a changé (comparaison avec une valeur archive) et envoie que si elle est différente.

D'autre part, il me semble que la fréquence d'envoi n'est pas à chaque frame mais actuellement réglé sur 0.05s.

Je pensais non pas utiliser l'export lors du "LuaExportAfterNextFrame()" mais utiliser "LuaExportActivityNextEvent(t)" pour effectivement espacer les exports (Le KaTZ-Pit fonctionne en 200ms).

Ce que je ne comprend pas c'est pourquoi LeCreole au lieu d'utiliser l'export direct vers SIOC, avait créé un serveur TCP (dans loisioc-serveur) , pouvant accueillir plusieurs clients. Ca complique beaucoup le code.
Dans un premier temps, je compte séparer :
- Les paramêtres de config de la connection SIOC
- Une table de correspondance (valeur LO / offset SIOC)
- Le serveur d'export en temps que tel.

Pour l'envoi vers SIOC, c'est finalement pas trop compliqué :
Par exemple pour envoyer la valeur temps sur l'offset 10

CODE

local t = LoGetModelTime()
socket.try(c:send(string.format("Arn.Resp:%s=%.0f:\n",10,t)))

Mais si tu as une doc sur votre structure, çà pourrait m'intéresser.
Je vous tiendrai au courant des progrès

Miaou

Ce message a été modifié par KaTZe - 29 Mar 2010, 20:01.

[gillesdrone]

Ce que je ne comprend pas c'est pourquoi LeCreole au lieu d'utiliser l'export direct vers SIOC, avait créé un serveur TCP (dans loisioc-serveur) , pouvant accueillir plusieurs clients. Ca complique beaucoup le code.
Dans un premier temps, je compte séparer :
- Les paramêtres de config de la connection SIOC
- Une table de correspondance (valeur LO / offset SIOC)
- Le serveur d'export en temps que tel.

Pour l'envoi vers SIOC, c'est finalement pas trop compliqué :
Par exemple pour envoyer la valeur temps sur l'offset 10

CODE

local t = LoGetModelTime()
socket.try(c:send(string.format("Arn.Resp:%s=%.0f:\n",10,t)))

Mais si tu as une doc sur votre structure, çà pourrait m'intéresser.
Je vous tiendrai au courant des progrès

Miaou

Lecreole avait créé losiocserveur, pour pouvoir envoyer les données a plusieurs clients , même s'ils ont les même adresses de port , du moins c'est pourquoi je l'utilise car LOVP ne peut être changer de port et impossibilité a l'époque d'utiliser SIOC et LOVP en même temps

deuxio, il permettait aussi un gain en Fps car , c'est le serveur qui envoyait les données au client et non LOFC ( je veux dire directement )

[KaTZe]

En lisant le code, je comprend l'objectif du multiclient, cependant en principe il aurait du gérer les connection/deconnection à chaud, hors si on allume SIOC après le début de mission il ne fonctionne pas, et même pire (avant la dernière modif que j'avais faite) il freezait LO, alors que çà ne devait pas être le cas. Bref, y'a un truc qui ne fonctionnait pas exactement comme prévu.

Pour ce qui est de la charge de LockOn, on l'augmente avec les requètes d'export de donnée (LO vers LOSIOC).
La transmission (LOSIOC>SIOC) via serveur TCP, si elle permettaait la gestion multiclient, ne changeait rien quand à l'envoie les données à SIOC.

Comme mentionné par Dart, l'approche intelligente va consister à faire des requètes de donnée à LockOn avec des fréquences adaptées (pas la peine de lui demander un status armement sur un pylone à chaque frame), par contre des données comme le cap, le vario vont nécéssiter une fréquence de rafraichissement plus élevée.

Donc je vais essayer la structure suivante :

LO>> LOSIOC_Serveur : fréquence adapté aux données
- en utilisant LuaExportActivityNextEvent(t)
- en utilisant les tables de coroutine

LOSIOC_Serveur >> SIOC :
- tri des données : uniquement celles ayant changées depuis le rafraichissement n-1
- transmission (éventuellement via serveur TCP multiclient si j'arrive à m'en sortir).

Dans un premier temps, je vais réutiliser la même structure SIOC que celle de LeCreole (même Offset), pour vous permettre rapidement de faire re-fonctionner vos Pits sous LO200
Par la suite, il faudra changer la table des offset pour faire de la place aux nouveaux.
Ca sera aussi l'occasion de combiner LOSIOC_serveur avec le système LoPlug de Dart et Tolteque.

Miaou

Ce message a été modifié par KaTZe - 30 Mar 2010, 17:08.

[KaTZe]

Finalement, je vais séparer le LOSIOC serveur en deux programmes distincts.

- Un module d'extraction des données de LockOn (avec fréquence adaptée au données) vers une table
- Un serveur d'export vers SIOC (qui prend les données dans la table, les traites, expédie les nouvelles vers SIOC à fréquence constante).

D'où deux petites questions à Dart-Toltèque :

Q1> Avec Loplug, créez vous un module d'extraction qui va populer une table, sur laquelle vient se brancher les modules spécifiques ?

Q2> Si oui avez vous déjà créé cette table (données, arguments ?)

Merci
Miaou

[DArt]

D'où deux petites questions à Dart-Toltèque :

Q1> Avec Loplug, créez vous un module d'extraction qui va populer une table, sur laquelle vient se brancher les modules spécifiques ?

Q2> Si oui avez vous déjà créé cette table (données, arguments ?)

En fait on a ce schéma:

CODE

Lockon <--> LUA <-------> LockOn module------|
                                                                     |---- LoPlug Router
                                        TS module         ----|
                                 Cockpit module         ----|

Chaque module est connecté à LoPlug routeur. Chacun possède sa propre base de données selon ce qu'il a besoin. Par exemple, le cockpit a une base de données qui contient toutes les valeurs à affichée (liste des canaux TS, valeurs LUA...). Cette base de données est géré par le framework qui se charge d'aller demander les valeurs aux modules correspondant (liste des canaux au TS, les valeurs lua au module LO).

Donc en fait, cette base de donnée est du code Python objet et contient des objets complexes permettant de gérer des structures complexes comme des images, des payloads, des valeurs... Donc on va bien plus loin que le LUA. En fait, LoPlug n'est pas LO dépendant, LO n'est qu'une source de données comme une autre. En fait, on peut insérer un module FSX, Call Of Duty ou sudoku si on veut...

Pour le SIOC, il faudrait prévoir un module qui se connecte sur le bus LoPlug. Si on peut attaquer le SIOC avec une socket, je pense qu'on peut faire un module pas compliqué qui connecte LoPlug et le SIOC. Cela permettrait aussi de récupérer des données autres que Lockon dans les cockpits (gestion TS par exemple...).

Faut voir la faisabilité, mais ça peut être sympa et pratique avec l'arrivée de la L16 ensuite ^^

[KaTZe]

Pour le SIOC, il faudrait prévoir un module qui se connecte sur le bus LoPlug. Si on peut attaquer le SIOC avec une socket, je pense qu'on peut faire un module pas compliqué qui connecte LoPlug et le SIOC. Cela permettrait aussi de récupérer des données autres que Lockon dans les cockpits (gestion TS par exemple...).

Faut voir la faisabilité, mais ça peut être sympa et pratique avec l'arrivée de la L16 ensuite ^^

En effet çà me parait la solution la plus élégante plutôt que de développer un export spécifique pour SIOC.

En fait SIOC fonctionne en socket (via FSUIPC pour FSX) ou n'importe quel client IOCP via un réseau TCP/IP.
Dans le cas du serveur losioc Lecreole l'interfaçait en créant un serveur TCP (pour pouvoir connecter plusieurs appli sur LO), mais ce week end j'ai pu l'interfacer grace au LuaSocket (socket.try(c:send(string.format("Arn.Resp:%s=%.0f:\n",10,t))) , en envoyant simplement le numéro de l'offset de SIOC (ici le 10) et la valeur (t).

L'avantage de SIOC étant qu'il est supporté par la communauté des piteurs de FSX, et de la boite qui vend du hardware pour pit. Il est donc bien documenté et continue d'être développé (contrairement à GaugeComposer, ou LOVP)

Voici la présentation du système SIOC .ppt présentation

Si tu veux je peux regarder comment l'interfacer en Python ?
Ou commencer par un serveur TCP en lua

En effet comme tu le mentionnes, si l'on peut récupérer dans SIOC des data du bus Loplug comme TS, çà permettrait de faire ce que j'ai fait pour le changement de fréquence TS, mais directement, et non via une émulation des commandes clavier.

En tout cas je suis partant pour vous filer un coup de main sur ce module (dans la mesure de mes modestes compétences)

Miaou

Ce message a été modifié par KaTZe - 30 Mar 2010, 20:26.

[Lecreole]

Salut à tous

Ce que je ne comprend pas c'est pourquoi LeCreole au lieu d'utiliser l'export direct vers SIOC, avait créé un serveur TCP (dans loisioc-serveur) , pouvant accueillir plusieurs clients. Ca complique beaucoup le code.

Pour la simple raison que si l'on ne posséde pas de pit et de IoCard on pouvait connecter GaugeComposer ou autres clients utilisant le protocole IOCP directement à lockon sans avoir recours à d'autres logiciels.
Le module SIOC à été ajouter sur demande des piteurs, c'est pourquoi elle est activable ou pas dans le fichier.

En lisant le code, je comprend l'objectif du multiclient, cependant en principe il aurait du gérer les connection/deconnection à chaud, hors si on allume SIOC après le début de mission il ne fonctionne pas, et même pire (avant la dernière modif que j'avais faite) il freezait LO,

SIOC, n'est pas un client de Loiocpserveur, car SIOC est un serveur d'ou des ports différents, c'est pour cela qu'il ne connecte pas aprés que Loiocpserveur soit lancé, c'est Loiocpserveur qui se connecte à sioc, mais pour ne pas compliqué le code je l'ajoute dans la liste des clients.

voila, bonne continuation à vous tous.

Lecreole.