Offset, bit, etc

A

Aurelien

PILOTE PRIVE
Messages
94
Réactions
0
Points
16
Bonsoir à  vous!

J'ai une question à  soumettre aux experts en la matière...

Voilà , j'arrive depuis peu à  interfacer 2 gauges du cessna A2A, via mobiflight, la vitesse et le RPM.

Cependant, impossible de les avoir fonctionnelles en même temps!

J'ai définit la gauge de vitesse sur l'offset libre 66c0.
Cette gauge est liée à  la Lvar L:AirspeedIndicatedNeedle, qui d'après le log donne des valeurs entre 0 et 200 grosso modo si on fait péter le badin! :)
Dans la liste des Lvar, la valeur a 12 chiffres après la virgule, mais FSUIPC récupère une valeur arrondie à  l'unité. J'ai donc une valeur qui en bin'aire va de 0 a 00010011, soit une place de 8 bit = 1 octet pour exploiter cette variable. (Quon marrête si je dis des bêtises)

Je me suis donc dit que la seconde gauge que j'arrive à  faire fonctionner seule sur l'offset 66c0, je dois la mettre a 66c0+1octet=66c1?

Donc en plus de la vitesse en 66c0, jaffecte le RPM en 66c1, mais...
Malheureusement, pour la gauge RPM, FSUIPC ne reçoit aucune valeur pour celle ci (alors qu'il recoit bien des valeurs entre 0 et 2700env si elle est sur l'offset 66c0...), J'ai testé sur d'autre offset, comme 66c8, 66ff, mais impossible. Ca ne marche que sur 66c0.

Quelqu'un aurait-il une idée à  ce petit souci? Je me demande sil faut pas, à  tout hasard, faire des scripts sur des Lua séparés?!

Merci en tout cas
Aurélien
 
Comment as tu défini ton offset 66c0 (en byte, word, dword, ...) ?
Désolé mais les scripts sous LUA je ne connais pas.
 
HB-EBC a dit:
Comment as tu défini ton offset 66c0 (en byte, word, dword, ...) ?
Désolé mais les scripts sous LUA je ne connais pas.
Cliquez pour agrandir...

je ne suis pas sûr de répondre à  ta question,
mais j'ai défini dans le script .Lua avec "ipc.writeUB" pour Unsigned 8 bit = 1 byte,
et dans mobiflight, offset 66c0, size in bytes = 1.

J'ai progressé dans mon souci, et j'ai trouvé quelque chose dintéressant!...

En fait,

si je met dans le script .Lua l'offset 66c0 pour lIAS, et 66c1 pour le RPM, via mobiflight, je ne recoit des valeurs que pour lIAS.
A tout hasard, j'ai inversé la position des scripts, c'est à  dire que j'ai d'abord écrit le script pour le RPM, toujours en 66c1, puis à  la suite le script pour lIAS, toujours en 66c0. Et boeingo! J'ai des valeurs pour le RPM, mais plus pour lIAS!

J'ai donc fait un second fichier .Lua, avec lIAS en 66c0, déclaré dans FSUIPC. Et ca marche maintenant: j'ai bien les valeurs à  la fois du RPM et de lIAS!

Mais javoue que cela me parait bizarre que je doive en faire un nouveau .Lua;

Pour les offset des switch battery (3340) et alternateur (3344), j'arrive bien a les mettre à  la suite sans que ça pose problème.

Savez vous éventuellement si j'ai oublié quelque chose entre mes 2 scripts RPM et IAS, qui fait que la lecture sarrête au premier?!
Code: 
-- test IAS
while 1 do
IAS = ipc.readLvar("L:AirspeedIndicatedNeedle")
ipc.writeUB(0x66c0, IAS)
ipc.sleep(100)
end


-- test RPM 
while 1 do
RPM = ipc.readLvar("L:Eng1_RPM")
ipc.writeUW(0x66c1, RPM)
ipc.sleep(100)
end

mes scripts sont à  la suite, tel quel, avec end à  la fin de chaque
 
C'est normal Aurelien...
Ton script réagit correctement à  son écriture actuelle.

Là , tu lui as fait deux boucles.
Il reste donc scotché dans la première boucle sans jamais pouvoir passer à  la seconde puisqu'il n'y a pas de mode de sortie.

Nota :
J'ai très bien compris ce que tu voulais faire dans ton petit test, mais je ne te donnerais pas la solution à  celui-ci. :(
Si, je te la donne, tu napprendrais rien...
 
Ptipilot a dit:
C'est normal Aurelien...
Ton script réagit correctement à  son écriture actuelle.

Là , tu lui as fait deux boucles.
Il reste donc scotché dans la première boucle sans jamais pouvoir passer à  la seconde puisqu'il n'y a pas de mode de sortie.

Nota :
J'ai très bien compris ce que tu voulais faire dans ton petit test, mais je ne te donnerais pas la solution à  celui-ci. :(
Si, je te la donne, tu napprendrais rien...
Cliquez pour agrandir...


tu vas rire, mais c'est sous la douche que j'ai trouvé...
Jme repet'ais "while 1 do"... "while 1 do"... et là  BINGO!!!! je me suis rappelé que ca se traduit par "tant que... faire"! Mais biensûr!! résultat, il reste bien bloqué à  la première partie!

J'ai donc édité ce script:
Code: 
-- test RPM IAS 
while 1 do
RPM = ipc.readLvar("L:Eng1_RPM")
IAS = ipc.readLvar("L:AirspeedIndicatedNeedle")
ipc.writeUW(0x66c0, RPM)
ipc.writeUB(0x66c2, IAS)
ipc.sleep(100)
end

:) :) :) youpi! ça marche!!!!

Bon bah, lets go, yen reste un paquet, et bien d'autres problèmes/mystères qui vont surgir!
 
Aurelien a dit:
Quelqu'un aurait-il une idée à ce petit souci? Je me demande sil faut pas, à tout hasard, faire des scripts sur des Lua séparés?!
Cliquez pour agrandir...
Alors là , je vais te répondre directement et te donner la solution!...

Dans ton cas, tu peux tout écrire dans le même script (1 seul fichier...).
Lintérêt dengager plusieurs scripts est au niveau de ton Operating System. En effet, chaque script (fichier) sera lancé dans un thread différent au niveau de ton System. Il y a même des options dAffinit'y mask dans FSUIPC pour gérer cela.

Aurelien a dit:
:) :) :) youpi! ça marche!!!!
Cliquez pour agrandir...
Ha... Lenthousiasme de la jeunesse!... :)

Je vieux con que je suis maintenant, va te dire de ne pas partir dans cette logique algorithmique...
Car même, si elle marche sur un ou deux items (ou même plus...) et quelle te donne satisfaction, elle n'est pas bonne car elle consomme trop de CPU. :(

Trouve autre chose!... O:)
 
Last edited by a moderator:
Lintérêt dengager plusieurs scripts est au niveau de ton Operating System. En effet, chaque script (fichier) sera lancé dans un thread différent au niveau de ton System. Il y a même des options dAffinit'y mask dans FSUIPC pour gérer cela.
Cliquez pour agrandir...


Hum, intéressant. Donc ca serait pas mal de scinder en plusieurs scripts, rangés un peu par thème, ou famille de composants interfacés par exemple.

Cependant, il y a un truc qui me chagrine là  dedans: j'ai remarqué que pour que le script fonctionne, il faut qu'il soit appelé, sinon je ne recois pas de valeur.

Par exemple, avant le script des gauges, j'ai un script pour le switch de la batterie. Quand je lance le simu, si je démarre moteur allumé, que je ne touche pas a la batterie, alors je n'ai aucune valeur sur mes offset 66c0 et 66c2, je nen reçoit qu'une fois le script lancé après avoir actionné la batterie.

Cela voudrait donc dire qu'il faut que je trouve une action différente/script, que je ferai forcément avant mise en route, pour que tous les script soient fonctionnels. Hum,... pas simple. A moins de mettre a chaque debut de script le switch de la batterie, mais jsuis pas sûr que ça se fasse!

Ou alors on peut peut-être simplement mettre un code au debut, qui servirait justement a lancer le script?un peu comme un void setup sous arduino?
 
Bonjour Aurelien,

juste une petite remarque dans ton script, transforme ton
Code: 
ipc.writeUB(0x66c2, IAS)

En
Code: 
ipc.writeUW(0x66c2, IAS)
car si ton IAS dépasse 255 ça ne marchera plus.

offset suivant possible le 0x66C4.
 
HB-EBC a dit:
Bonjour Aurelien,

juste une petite remarque dans ton script, transforme ton
Code: 
ipc.writeUB(0x66c2, IAS)

En
Code: 
ipc.writeUW(0x66c2, IAS)
car si ton IAS dépasse 255 ça ne marchera plus.

offset suivant possible le 0x66C4.
Cliquez pour agrandir...


Merci, mais comme c'est uniquement pour le cessna, je n'ai pas besoin de > 255. J'ai testé pour être sûr, mais sur le cessna A2A (et sûrement sur tout bon cessna :D ) j'ai mis plein gaz, manche en bas, j'arrive difficilement à  200 et puis c'est le crash par overspeed, donc je peux garder cette valeur en 8 bit :)

J'ai poursuivi avec la vitesse verticale, en bloquant le stepper à  <= -2000 et >= 2000, ca fonctionne également!
 
Aurelien a dit:
Hum, intéressant. Donc ca serait pas mal de scinder en plusieurs scripts, rangés un peu par thème, ou famille de composants interfacés par exemple.
Cliquez pour agrandir...
Pour l'instant, ce n'est pas ta priorité...
Je t'ai juste donné la réponse à  ton interrogation, pour plus tard.


Aurelien a dit:
Cependant, il y a un truc qui me chagrine là  dedans: j'ai remarqué que pour que le script fonctionne, il faut qu'il soit appelé, sinon je ne recois pas de valeur.

Par exemple, avant le script des gauges, j'ai un script pour le switch de la batterie. Quand je lance le simu, si je démarre moteur allumé, que je ne touche pas a la batterie, alors je n'ai aucune valeur sur mes offset 66c0 et 66c2, je nen reçoit qu'une fois le script lancé après avoir actionné la batterie.

Cela voudrait donc dire qu'il faut que je trouve une action différente/script, que je ferai forcément avant mise en route, pour que tous les script soient fonctionnels. Hum,... pas simple. A moins de mettre a chaque debut de script le switch de la batterie, mais jsuis pas sûr que ça se fasse!

Ou alors on peut peut-être simplement mettre un code au debut, qui servirait justement a lancer le script?un peu comme un void setup sous arduino?
Cliquez pour agrandir...
Alors, pour te faire gagner du temps et téviter de partir sur des fausses pistes, il y a deux choses dévoqué dans ton texte.
- Premièrement, le lancement et éventuellement le déclenchement de ton script (de tout ou d'une partie...),
- Deuxièmement, le réveil d'un périphérique.

Concernant le deuxième point, laisse tomber car il ne dépends pas de toi. Là , c'est du domaine de la liaison, généralement USB et de sa couche HID.

Pour ton "test", tes deux items sont amplement suffisant pour trouver une écriture plus sioux de ton script LUA.

Un indice pour te faire gagner du temps...
Regarde bien ta boite à  outils de fonction!...
 
Bonjour! :)

Bon javoue que j'ai fouiné un peu dans le fichier de FSUIPC Lua librairie, et javoue également que je pose des questions sur le forum FSUIPC. Et à  ce sujet, Pete Dowson me suggère d'utiliser la fonction event.Lvar() à  la place de ipc.readLvar(), qui permettrait d'avoir un script qui se "lance" seul, sans avoir à  "lappeler" en basculant un switch pour qu'il s'active. Peut être cela dont du fais allusion Alain?
Malheureusement, j'ai bien essayé avec la fonction event.Lvar, en remplacant les ipc.readLvar dans le script mais ca ne fonctionne pas. Je ne sais pas dans quel genre de boucle je dois mettre cet "event.Lvar"
J'ai essayé dans le "while 1 do ... end", ca ne marche pas, j'ai essayé sans rien, idem

Si je comprend bien la doc FSUIPC, il semblerait que ce doit être dans une fonction déclarée, alors j'ai pensé que ce script serait le bon, mais toujours pas. Aucune valeur reçue
Code: 
function(Eng1_RPM, value)
event.Lvar("L:Eng1_RPM", 100, Eng1_RPM)
ipc.writeUW(0x66c0, Eng1_RPM)
end
 
Aurelien a dit:
Bonjour! :)

Bon javoue que j'ai fouiné un peu dans le fichier de FSUIPC Lua librairie, et javoue également que je pose des questions sur le forum FSUIPC. Et à  ce sujet, Pete Dowson me suggère d'utiliser la fonction event.Lvar() à  la place de ipc.readLvar(), qui permettrait d'avoir un script qui se "lance" seul, sans avoir à  "lappeler" en basculant un switch pour qu'il s'active. Peut être cela dont du fais allusion Alain?
Cliquez pour agrandir...
Dommage que tu nes pas trouvé cette solution tout seul, en cherchant et analysant le contenu de ta boite à  outils comme je te l'avais suggéré... :(

Merder et se faire chier font partie de lapprentissage d'un langage informatique. Ce n'est pas en donnant la solution à  quelqu'un qu'on le fait avancer. :)

Là , tu as eu directement la bonne solution qui est de passer par un "Event"...
Mais, tu n'as pas appris grand chose au final!... :p
 
Ptipilot a dit:
Aurelien a dit:
Bonjour! :)

Bon javoue que j'ai fouiné un peu dans le fichier de FSUIPC Lua librairie, et javoue également que je pose des questions sur le forum FSUIPC. Et à ce sujet, Pete Dowson me suggère d'utiliser la fonction event.Lvar() à la place de ipc.readLvar(), qui permettrait d'avoir un script qui se "lance" seul, sans avoir à "lappeler" en basculant un switch pour qu'il s'active. Peut être cela dont du fais allusion Alain?
Cliquez pour agrandir...
Dommage que tu nes pas trouvé cette solution tout seul, en cherchant et analysant le contenu de ta boite à outils comme je te l'avais suggéré... :(

Merder et merdouiller font partie de lapprentissage d'un langage informatique. Ce n'est pas en donnant la solution à quelqu'un qu'on le fait avancer. :)

Là , tu as eu directement la bonne solution qui est de passer par un "Event"...
Mais, tu n'as pas appris grand chose au final!... :p
Cliquez pour agrandir...

Ah bah pour merder et merdouiller, je le fais ne tinquiètes pas :p Et même si j'ai un coup de pouce ici et là , je cherche avant tout à comprendre le pourquoi du comment :)

Hier j'ai passé bien 4 heures à tenter d'interfacer le turn coordinateurnator avec les Lvars, sans succès... Et bien le soir c'étais chose faite à force de chercher ;)

Trouvé! en merdant et merdouillant

Plus besoin de "lancer" le script, les Lvars sont dorénavant "surveillées" :p
 
Last edited by a moderator:
Connectez vous pour répondre ici.
Retour
Haut