LUA Scripting sur V2.1.x

Kilrah a écrit:Il est possible de créer un ficher sur la carte SD et d'écrire/relire ce qu'on veut dedans depuis lua.

Je ne connaissais pas, je vais aussi explorer ce domaine.

@Dev.fred : Je vais re-tenter les GV dans ce cas
Sinon, pour la formule, selon ta réponse, elle n'est pas possible à définir dans un doc Excel si je ne me trompe (?)

Avant de faire un petit outil sous MVC++, j'ai regardé la fonction de décalage de mon excel qui est en version 2007 et je ne l'ai pas.

Par contre elle existe sous Excel 2016, Excel 2013, Excel Online, Excel 2016 for Mac, Excel for Mac 2011.
https://support.office.com/fr-ca/article/BITDECALG-BITDECALG-fonction-c55bb27e-cacd-4c7c-b258-d80861a03c9c

Maintenant, j'ai fini mon ciment ce matin, je peux ajouter le gps dans l'outil, je trouve ça fun  

Les coordonnées sont à entrer en degrés décimaux, attention à utiliser une virgule dans les valeurs décimales et la télémétrie affiche en DM:

Wow, ça, c'est du boulot !
Merci.

Qui aurait pu être fait directement dans le simu de télémétrie

Il ne manquait plus que la date et l'heure pour avoir toute la famille des capteurs à données multiples  

Kilrah a écrit:Qui aurait pu être fait directement dans le simu de télémétrie

Je ne sais faire que des soins palliatifs .

Tu me trouverais casse-c... Si je te disais que tu approcherais la perfection si tu pouvais ajouter encore 4 à 6 cellules de plus de batteries pour couvrir 95% des besoins du modelisme ?

Oui ? Bon, je sors.

Blague à part, je te tire ma révérence pour cet utilitaire qui vient combler ce manque dans companion !
Bravo.

Heisenberg a écrit:...
Jusque là tout va bien, j'ai créé ma variable "positiongaz" mais comment la conserver pour une lecture après vol ? (hormis logs).
...

La 2.1 offre quelques possibilités d'accès aux fichiers sur la SD :
- io.open(filename, options)
- io.seek(file, position)
- io.read(file)
- io.write(file, value)
- io.close(file)

Je ne peux pas t'en dire plus, je n'ai pas testé.

Ce topic et d'autres infos glanées ici et outre Atlantique m'a permit de réaliser un très joli écran de télémétrie en version bêta, pas encore totalement terminé, pas encore optimisé, et avec des jauges verticales, des aides aux réglages de modèle, des interactions etc... le tout en respectant une certaine organisation du script comme suggérée par Sacre100. Sans vous, je n'y serais pas arrivé, et je suis encore médiocre.

Pour garder une valeur affichée à l'écran, c'était tout simple, il suffisait de déclarer la locale variable avant la boucle et ensuite de jouer avec dans la boucle.
Erreur de débutant, tout mon script était dans la boucle, les variables étaient re-déclarées à chaque passage et il ne m'était pas possible de faire des moyennes, garder des maxima/minima etc... J'en apprend un peu plus chaque jour et ce n'est pas très compliqué, ça se rapproche un peu du Perl. Vos réponses sur la conservation d'une valeur m'a été instructive car ça va me permettre de faire des moyennes sur plusieurs vols, sur un pack de batterie qui va dans plusieurs zincs etc...

A présent, je recherche à faire une jauge de fuel basée sur le restant en mAh.
- Une variable fixe à 3000 pour un accu de 3000.
- Une variable proportionnelle de 100 à 0% selon ce qui a été pompé dans l'accu.

Je pensais y-être arrivé mais mon calcul est faux.
Au début, j'ai pensé simplement à ça :


... mais c'est bcp trop simple.

Je ne vois qu'une possibilité : C'est de sampler Curr et incrémenter une variable à chaque fois, ou me servir d'un timer pour ensuite recalculer.

J'ai donc encore 3 questions :

1) Suis-je passé à côté de qqch de plus simple déjà natif dans OpenTX pour le calcul de la jauge fuel ?

2) Comment savoir combien de fois est exécuté un Lua en 1 seconde ?

3) Comment savoir quelle quantité de ressources en mémoire et processeur que prend un Lua ? (Le mien fait + de 600 lignes et à l'air bien lourd car les annonces vocales sont saccadées)

1) Oui, faut utiliser la formule "consommation", pas "totalisation".
2) - 3) Page statistiques/debug

Heisenberg a écrit:... Pour garder une valeur affichée à l'écran, c'était tout simple, il suffisait de déclarer la locale variable avant la boucle et ensuite de jouer avec dans la boucle.
Erreur de débutant, tout mon script était dans la boucle, les variables étaient re-déclarées à chaque passage et il ne m'était pas possible de faire des moyennes, garder des maxima/minima etc...

Juste pour préciser :
- les variables "local xxx ..." déclarées dans une fonction sont disponible uniquement dans la fonction et sont réinitialisées à chaque appel de la fonction.
- les variables "local xxx ..." déclarées en dehors des fonctions sont disponibles dans tout le script et sont crées au chargement du script.
- les variables "xxx ..." (celles qui ne sont pas déclarées "local", utilisées aussi bien à l'intérieur qu'à l'extérieur d'une fonction) sont disponibles dans tous les scripts chargés dans l'environnement LUA et sont crées au chargement du premier script qui les utilise.

Ce qu'il faut savoir, c'est que les model (mixer) script, function script et telemetry script sont chargés dans le même environnement LUA. Lorsqu'un one-time script (dont font partie les wizard), les model, function et telemetry script sont déchargés, l'environnement LUA est recrée et seul le one-time script est chargé dans cet environnement. L'opération inverse est effectuée lorsque le one-time script est terminé. C'est important de le savoir car cela permet de partager des variables globales (et donc échanger des données) entre les model, function et telemtry script, mais il n'est pas possible d'échanger des données entre ces script et un one-time script.

Autre chose qu'il faut savoir, c'est que si tu déclares une fonction qui fait usage d'une variable qui n'est pas encore déclarée "local", la fonction va toujours accéder à une variable globale. Puis si tu déclares "local" une variable avec le même nom dans ton script et que tu écris ensuite une fonction qui accède à cette variable, même si elle portent le même nom, ce sont deux variables différentes autrement dit, pour la fonction écrite avant la déclaration, elle va accéder à la variable globale et pour celles écrite après la déclaration, elle va accéder à la variable locale. Ceci s'explique par le fait que LUA "compile" le script au moment du chargement et résout l'accès aux variable à ce moment là, pas lors de l'exécution.

Exemple de code pour illustrer cela :

Code:

local function f1 ()
  return (v)          -- v n'est pas encore déclarée alors retourne la variable globale
end
v = 1                 -- initialise v globale avec 1

local v               -- déclaration locale de v
local function f2 ()
  return (v)          -- v est déclarée local alors retourne la variable locale
end
v = 2                 -- initialise v locale avec 2

print("f1 : ", f1())  -- Appel de f1() -> donne 1 (variable globale)
print("f2 : ", f2())  -- Appel de f2() -> donne 2 (variable locale)


Ce script va donner dans la console :

Code:

f1 : 1
f2 : 2


J'en parle parce que cela m'est arrivé et que j'ai mis beaucoup, beaucoup de temps à comprendre où était le problème.

Salut à tous,
Question simple : comment récupérer pour un script la tension des batteries du Tx ? ça marchait pour 2.0.17 avec "tx-voltage", mais en 2.1.3, pas moyen.
J'ai écrit un joli script spécial planeur electrique qui reprend les différentes tension, les niveaux Rx et le vario pour 2.0.x, mais il me manque ça pour finir la conversion.
C'est un peu relou ce manque de doc, officielle ou pas, sur le scriptage en 2.1.x
Au secours !
Merci d'avance,
Jimbo

J'ai eu pas mal de soucis de script en 2.1.3, et la conclusion empirique a laquelle je suis arrivé, c'est que souvent, les capteurs avec 'unité' ("v", "mah",...) posent des soucis. Essaye de créer un capteur calculé qui reprend la valeur mais sans unité (mais je n'ai pas testé spécifiquement pour tx batt).

G

Essaie : getValue("BtRx")

Merci de vos conseils,
BtRx, c'est la tension de l'accu de réception, ce que je cherche à retrouver, c'est l'accu d'émission. A la détection des capteurs, je n'ai rien qui ressemble à Batt ou TxBatt ou qqchose du genre.
A+
Jimbo

Oui, je viens de voir ca. un test a faire :

Utiliser cette fonction : 

Code:

local function getTelemetryId(name)
   field = getFieldInfo(name)
   if field then
     return field.id
   else
     return -1
   end
end

l'appeler comme ca : 

local mytxbatt= getValue(getTelemetryId("tx-voltage"))

Si on as -1 c'est que ce label n'est plus valide,ça donnera déjà une piste

G

A voir les sources de la 2.1.3, "tx-voltage" devrait être toujours disponible (ligne 1924 de myeeprom.h) néanmoins, dans les écrans de télémétrie, pour obtenir cette valeur, il faut utiliser "Batt", est-ce nom nom qu'il faut utiliser, je n'ai pas approndi la chose.

Un chose est sûr, "tx-voltage", "clock", "timer1", "timer2" et "timer3" n'apparaissent pas dans les capteurs trouvés mais ils devraient être en principe disponibles dans LUA.

Le petit bout de script suivant fonctionne sous Companion mais bug sur ma radio (écran blanc).
J'ai fait une erreur quelque-part ou est-ce un réel bug ?

local function run(event)
lcd.lock()
lcd.clear()
 local batt_cels = getValue("Cels")
 lcd.drawNumber (100, 25, batt_cels, XXLSIZE + LEFT)
end
return { run = run }

Pareil pour ça, essayé au cas où...

local function run(event)
lcd.lock()
lcd.clear()
 local batt_cels = getValue("Cels")
local test = (batt_cels* 3)
lcd.drawNumber (100, 25, test, XXLSIZE + LEFT)
end
return { run = run }

Impossible de récupérer la valeur Cels, si j'utilise VFAS à la place, le script ne pose aucun problème.

Utilise la fonction que j'ai donné 2 postes plus haut, ça te permet déjà de vérifier la validé des noms.

Sinon j'ai eu aussi un soucis qui semblait affecter le flvss et pas vfas, et comme dit plus haut, j'ai crée un second capteur qui reprend la valeur de cels (j'ai fait un calculé , add,  et juste cels comme source), mais sans l'unité et la ça refonctionne. A tester

G

Gandalf a écrit:.../...j'ai crée un second capteur qui reprend la valeur de cels (j'ai fait un calculé , add,  et juste cels comme source), mais sans l'unité et la ça refonctionne. A testerG

Et ça marche très bien comme ça ! Merci pour l'astuce.
Les valeurs de Cels manipulés par la radio sont toutes dispo comme Cmin, Cmax etc...
Par contre, le script Lua ne peut pas utiliser directement Cels directement, c'est curieux.

Le fautif est le capteur défectueux ou OpenTX ?

Sauf erreur quand tu getValue("Cels") ça te retourne un tableau avec les tensions de chaque élément, pas le total.

Kilrah a écrit:Sauf erreur quand tu getValue("Cels") ça te retourne un tableau avec les tensions de chaque élément, pas le total.

Vu comme ça, c'est logique, mais un peu illogique que la radio ou qu'un Lua dans companion seulement puisse l'afficher comme un total, ça induit en erreur.

C'est juste souvient-toi, on en avait déjà parlé de getValue("Cels") : https://frskytaranis.forumactif.org/t2666p30-lua-scripting-sur-v2-1-x#31254

Pourquoi ça marche sur le simulateur et pas sur la radio, je n'ai pas d'explication et cela me surprend, peut-être un problème de casting, je ne sais pas.

En tout cas, en cas de problème comme ça, ne pas hésiter à regarder le type de la valeur retournée par getValue(...) :
- "nil" indiquerait plutôt une valeur inexistante
- "table" indique que getValue retourne plusieurs valeurs dans une table (cas "Cells" et "GPS" et ... je ne sais pas s'il y en a d'autre)
- "number", une valeur utilisable dans drawNumber
- "number", "string" ou "boolean" (je ne sais pas si le cas existe), une valeur utilisable dans drawText
- "function", "thread" ou "userdata", ça ne devrait pas ne produire en principe.

Sacre100 a écrit:C'est juste souvient-toi, on en avait déjà parlé de getValue("Cels") : https://frskytaranis.forumactif.org/t2666p30-lua-scripting-sur-v2-1-x#31254

Je me souviens bien, mais je n'ai pas fait le rapprochement, j'avais compris une lecture de table mais n'avais pas compris que ça renvoyait en forme de table à l'appel de Cels.

Sacre100 a écrit:Pourquoi ça marche sur le simulateur et pas sur la radio, je n'ai pas d'explication et cela me surprend, peut-être un problème de casting, je ne sais pas.

Il m'a fallu un moment pour trouver l'erreur, le script marchant très bien sur Companion, je n'ai pas été cherché sur ce domaine.

Sacre100 a écrit:En tout cas, en cas de problème comme ça, ne pas hésiter à regarder le type de la valeur retournée par getValue(...) :.../...

Pour connaître ce type, c'est avec les quelques lignes postées par Gandalf ?
Je n'ai pas encore essayé car ne suis pas à la maison pour le moment, sinon, quelle est la formule magique pour connaître le "type" ?