Stabilität von Mix/Model scripte ?

[strgaltdel]

Hallo zusammen,


ich möchte meine Wölbklappen per Modell/Mix script ansteuern.
Via Kipptaster werden zuvor definierte Positionen angefahren.

Hat jemand Modell/ Mix scripte schon länger im Einsatz und kann etwas über die tatsächliche Stabilität unter Realbedingungen sagen ?
Imho unterliegen Mix-scripte in dieser Hinsicht den gleichen Kriterien wie die Telemetriescripte.
Bis dato habe ich leider nur eine Woche intensiver Nutzung am Hang hinter mir, meistens liefen zwei tele-scripte parallel, da gabs nie Probleme.



Per Definition laufen Mix scripte halt nicht mit allzu hoher Priorität, treten Resourcenprobleme auf gibt es einen Zwangs-Halt und keinen Restart:

- Exceeding the script execution runtime limit will result in the script being forcefully stopped and disabled

- script is stopped and disabled if it misbehaves (too long runtime, error in code, low memory)

- mix scripts are run with less priority than built-in mixes. Their execution period is around 30ms and is not guaranteed!


Danke & Gruß

Udo

 

[helle]

Hy,
scripte schön und recht,

aber damit doch keine flugkritischen Aktionen damit steuern/auslösen!

Sind gut für Anzeigen, Umrechnungen, Darstellnngen, Warnungen usw.


Inputs, Mischer, Servos, log Schalter lösen doch deine Wölbklappensteuerung

 

[strgaltdel]

Hi Helle,

Danke für die Antwort,
am Anfang hatte ich ja auch so gedacht.

Ich betrachte der Einfachheit jetzt nur das Ausfahren der Klappen:
Stelle Dir vor, ich möchte durch Ziehen des Kipptasters "SH" jeweils eine neue Wölbklappenposi anfahren, 4 Posis sollen möglich sein.
Würde z.B. im Inputbereich auf eine Definition hinauslaufen, wo ein "Geber" vier Zeilen mit entsprechendem offset hat.
Eine jeweilige Zeile würde durch einen logischen Schalter "scharfgeschaltet" werden.


Die logischen Schalter könnten in etwa so aussehen:
L8..L10 sind verkettet und bauen eine Art "Binaerzähler" auf.



L1..L3 fragen die drei "Bits" ab und schalten aufeinanderfolgend die jeweils gewünschte Posi "scharf".
Initial sind alle Schalter auf "0", erst ab dem ersten "SH-pull" wird 3x hochgezählt:



Das eigentliche Problem ist jedoch, dass man ab einer bestimmten Posi/einem bestimmten "Bitmuster", trotz Betätigung von "SH" nicht mehr weiterzählen darf, da die Maxstellung der Klappe bereits erreicht ist.
Da gehört dann zum minderwertigsten Bit eine einschränkende Bedingung hinzu

Meine Versuche dort eine Bedingung zu Verknüpfung liefen immer wieder auf Rekursionen hinaus, wodurch die Schalter "Eigenleben" produzierten.


Ich fand es daraufhin einfacher das zu scripten & einfach immer nur eine Inputzeile im Offset anzupassen.


Gruß
Udo

 

[r41065]

Hallo Udo

Solch einen Zähler habe ich mit Hilfe der Spezialfunktionen Realisiert:

z.B. SF3 Adjust GV3 Increment 1.

Als Schaltbedingung für SF3 dann relativ einfach mit SH unten UND GV3 < "4"

L1: a=x GV3 = 1
L2: a=x GV3 =2
L3: a=x GV3 =3
...


Ralf

Du musst nur aufpassen dass GV3 dann für alle benutzten Flugphasen gleich definiert ist.

 

[r41065]

Screenshots dazu

 

[strgaltdel]

Hi Ralf,

vielen Dank für die Anregung !
Ist auf jeden Fall die plausibelste Lösung & man käme ohne script aus
Muss in mich gehen & mal abwägen, ob ich nicht lieber auf eine GV verzichte und den Mischerwert "hardcodiere".

(alle GVs bereits belegt ))-:






Gruß
Udo

 

[r41065]

(alle GVs bereits belegt ))-:

Gruß
Udo

Logische Schalter und GV hab ich immer zu wenig , bin auch mal gespannt auf OpenTx 2.2
( sollen dann ja 64 log.Schalter werden ) und ob die Idee mit den Globalen log.Schaltern umgesetzt wird

Ralf

 

[strgaltdel]

Hi Ralf,


habe gestern Abend beide Varianten ausprobiert.
Im Ergebnis macht es (fast) keinen Unterschied ob das skript läuft oder das "Konglomerat" an SFs & Logischen Schaltern genutzt wird, beides reagiert gleich schnell.

Werde Betriebssicherheit vor Eleganz setzen, will heißen Deinen Vorschlag nutzen, Danke nochmals.

Das skript hat zwar den deutlichen Vorteil weder LSe noch SFs belegen zu müssen: einfach ein Eintrag unter den scriptzuweisungen und gut ist.
Dafür aber immer im Hinterkopf, ob nicht ein Engpass zum Hänger führt.
Evtl bin ich ja mal später dafür offen, wenn mehr Erfahrungswerte vorliegen.

Das einzige was bleibt, ist, das ich immer kurz ein skript "anlaufen" lasse um die zugehörige GV auf den Initialwert 0 zu setzen.
Ansonsten würde der Sender den Wert vom Aussschaltzustand "anfahren".

Hier nochmals die komplette Umsetzung:

1)
"Schaltfunktionen" zum Hoch/Runterzählen inkl. Grenzwerte definieren



2)
damit SF definieren, die die GV anpassen



3)
die möglichen Zustände auf einzelne LS legen



4)
Input mit den einzelnen Schaltzuständen anlegen



5)
Ich habe im Nachgang noch eine Kurve mit den Einzelwerten zwecks Anpassung des jeweiligen Klappenausschlags drübergelegt

(Koord. 90% & 100% sind Reserve, falls ich mich für mehr Klappenposis entscheide)

6)
Sounds beim Umschalten definieren



Bei so etwas gehen halt, wie du ja geschrieben hast, eine Menge LS'e / SF's & auch eine GV "flöten".

Zu der Anzahl von GVs & LSe unter 2.2:
Im "nightly" Opentx 2.2 sind die 64 Logischen Schalter ja schon länger enthalten, GVs konnte ich überhaupt noch nicht entdecken.
Anfragen nach mehr GVs wurden im Github allerdings vor etliche Zeit mal abgewiesen, Begründung war, meine ich aus der Erinnerung, "Ressourcenengpässe".



Grüße
Udo

 

[r41065]

Hi Ralf,
...
Das einzige was bleibt, ist, das ich immer kurz ein skript "anlaufen" lasse um die zugehörige GV auf den Initialwert 0 zu setzen.
Ansonsten würde der Sender den Wert vom Aussschaltzustand "anfahren".
...
Udo

Hallo Udo

Für die "Initialisierung" frage ich immer den Modelltimer ( die laufen bei mir aufwärts, kein Countdown) ab z.b. T1 < 3s.
"Verschwendet" aber schon wieder log.Schalter und Spezialfunktion...( Adjust GV9 Wert 0)
kann man auch allgemein Halten z.B. mit Flugphase Start oder Abfrage Gas Aus...

zu 4) und 5)
Ich definiere die Input Verarbeitung an der Stelle anders:
z.B. Quelle Max Gewichtung -12% wenn L17 aktiv
Quelle Max Gewichtung -32% wenn L19 aktiv

damit dann für den Ausgangskanal
Quelle I20 Gewichtung 100% und du kannst das Servo langsam runter und schnell hoch laufen lassen

Damit hast du für jede Position nur eine Zeile und kannst problemlos Positionen einfügen und editieren.

Ralf

 

[strgaltdel]

Hi Ralf,

evtl habe ich mich nicht exakt genug ausgedrückt,
ich glaube wir liegen da in der Verarbeitung sehr nahe beieinander.

- eine Input Zeile pro Position habe ich ja auch
- die Kurve lege ich im Ausgangskanal fest, funktioniert fast so, wie Du den Wert halt in der Inputzeile angibst:


Geschwindigkeit kann da dort eingestellt werden.

Motivation:
1.
Die Gewichtung (den Ausschlag) stelle ich nur in der Kurve, nicht als "hardkodierten" Wert einer Mischerzeile ein.
So kann ich sehr schnell zwischen den unterschiedlichen Ausschlägen wechseln.
Geht imho einfacher, als von Mischerzeile zu Mischerzeile zu springen.

2. Wenn ich bei eingeschaltetem Modell in die Kurveneinstellung gehe und Werte nachjustiere, sehe ich in "Echtzeit" wie sich die Flapstellung anpasst, die Kurve muss nicht extra abgespeichert werden um die Änderung wirksam zu machen. Ich dreh einfach an der Einstellung bis es optisch optisch passt.
Habs ehrlich noch nicht ausprobiert, hatte im Hinterkopf dass ich eine % Änderung in einer Mischerzeile am Sender erst sichern muss, um die Änderung zu aktivieren.
Somit würde ich mehr Anläufe benötigen um die richtige Stellung zu treffen (trial & error)...
Mag sein, dass ich mich da irre & es funzt auch in Echtzeit in der Mischerzeile, evtl ja eine persönliche Vorliebe aufgrund Altlasten in meinem Hirn....

Gruß
Udo

 

[r41065]

...
evtl ja eine persönliche Vorliebe aufgrund Altlasten in meinem Hirn....

Gruß
Udo

kann ich nachvollziehen:
Ich benutze z.B. nie die Differenzierung sondern arbeite an der Stelle mit einer 3Punkt-Kurve.
Dadurch kann ich den Knickpunkt z.B. auf -25/-25 verschieben um im Nulldurchgang noch die normale Knüppelbewegung auszunutzen.

Ralf