[Lua] Ein Sonnen-Live-OSD als Add-on für Twilight

[erfi00]

Info: Die neueste Version24 vom 22./23.02. läuft bei mir nicht. Habe beide Dateien probiert (sinter, msl). Die ältere Version vom 18.02. läuft...

[msl]

Es ist nett, dass du die neuen Versionen testest. Danke dafür. Aber ohne konkrete Fehlerangabe ist deine Bewertung völlig nutzlos.

Gruß msl

[erfi00]

Sorry! Nach dem Starten werden unten links 3 Zeilen eingeblendet. Oben "GESTARTET" , ganz unten "Twilight Live". In der mittleren Zeile steht auch "GESTARTET" und flackert schnell. Sonst passiert nichts. Abbrechen mit Auslöser funktioniert.

[msl]

Laut deiner Beschreibung läuft das Skript. Es wird keine Fehlermeldung ausgegeben. Es fehlt lediglich die eigentliche grafische Anzeige. Das kann schon mal passieren, wenn irgendeine Kamerakomponente die Anzeige überschreibt. Falls das so sein sollte, kann man die Anzeige einfach durch Drücken von hoch oder runter die Anzeige zurückholen.

Ich habe gerade noch einmal die aktuelle Version heruntergeladen und getestet. Bei mir funktioniert alles tadellos.

tw_l-osd.lua: http://trac.assembla.com/chdkde/browser ... _l-osd.lua (Download ganz unten auf dieser Seite)
v0.8.113 live osd 023

Gruß msl

[erfi00]

Hab's nochmal heruntergeladen und probiert. Alte Version läuft, neue nicht, bzw. wie Du schreibst ohne grafische Anzeige. Hoch- und Runterdrücken am Rädchen bringt auch nicht den gewünschten Erfolg.

[msl]

Schade. Dann scheint das Problem doch tiefgründiger zu sein. Möglicherweise gibt auch Speicherprobleme.

Für Testzwecke habe ich eine Skriptversion erstellt, die von jeglichem Ballast befreit ist und dadurch 25% weniger Platz beansprucht. Funktionell ist sie identisch mit der aktuellen 'normalen' Version.

Gruß msl

[erfi00]

Läuft! Danke!
Scheint vielleicht ein Speicherproblem zu sein...

[Sinter]

Hallo zusammen,

vielen Dank für die weiteren Tests. Es ist spannend, wie sich nun Erkenntnisse über Grenzbereiche von CHDK zeigen.

Bei Jens hat offenbar einzig die Erweiterung des Skripts um die Hilfe-Anzeige das Speicherproblem verursacht. Interessanterweise ist mit dieser Hilfe-Anzeige eigentlich kaum mehr Variablen-Handling hinzugekommen, sondern fast ausschließlich Codelänge.
Genau dieser Sachverhalt könnte uns die Prüf-Gelegenheit geben, ob es vielleicht möglich ist, mittels dofile() einzig nur die einfachen draw-Anweisungen der Hilfe-Anzeige in einen separaten File für dofile() auszulagern, und ob das dann bei Jens die Speicherprobleme umgehen würde. Bei der Hilfe-Anzeige müssen keine Variablen übergeben werden (sofern wir es versuchsweise erst mal ohne 16:9-Ergänzung probieren), es sind keine Sleeps vorhanden, sondern einzig eine ganz einfache Abfolge von draw-Befehlen. Falls das klappt, dann könnte es ein erster Ansatz sein, um erste wichtige Erkenntnisse zur Umgehung von Speicherproblemen mittels dofile() zu gewinnen. Für 16:9 wäre denkbar, einen separaten Hilfe-File ebenfalls ohne Variablen, sondern mit konkreten Werten zu hinterlegen, falls wir bei dofile() auf Variablenübergaben erst mal verzichten müssen.


Die Azimutformel hatte ich nochmals für die Südhalbkugel getestet. Für Wellington ergab sich dabei zur Mittagszeit sogar eine falsche Wanderrichtung der Sonne in Richtung Osten. Insofern scheint unser aktuell bekanntes Gleichungssystem wohl ausschließlich für die Nordhalbkugel geeignet, während für die Südhalbkugel noch (bislang unbekannte) Anpassungen notwendig sind. Sollte ein Mitleser hinreichende astronomische Kenntnisse besitzen, um Hinweise auf ein (auch) für die Südhalbkugel gültiges Gleichungssystem geben zu können, solche Hinweise zu möglicherweise geeigneten Gleichungssystemen sind stets willkommen.


Die verschiedenen Versionsnummern waren mir ebenfalls aufgefallen. Ich hatte für mich selbst bislang meine eigenen Versionsnummern fortgeschrieben, bzw. falls meine noch niedriger als die hinterlegte war, meine Versionsnummer an die hinterlegte angepasst. Nachdem die hinterlegten Nummern stets streng um 1 hochgezählt werden, werde auch ich mich umstellen und meine interne Zählung mit dem hinterlegten System kompatibel angleichen.

Viele Grüße,
Sinter

[Sinter]

Hallo zusammen,

anbei eine neue Version des Sun-Live-OSD. Beim Optimieren der Gültigkeit des Gleichungssystems zur weltweiten Berechnung des Azimut ist ganz nebenbei ein neues Feature abgefallen:

NEU:
- Optimierung der Azimut-Berechnung. (Gültigkeit der Werte erweitert)
- Stundenweises „Blättern“ mittels des ZOOM-Hebels innerhalb des aktuellen Tages.

Man kann nun in einer Art „Tages-Simulation“ (bspw. von morgens beginnend) stundenweise voranschalten, oder auch zurückblättern.


EDIT: Alte Skriptversion entfernt. Die neueste Version findet sich in den laufenden Beiträgen weiter unten.

Viele Grüße,
Sinter

[erfi00]

Hallo sinter,
habe die neue Version vom 04.03.2013 getestet. Sie läuft bei mir wieder nur ohne grafische Anzeige. Die neue Datei hat auch 10KB mehr im Gegensatz zur tw_pur.lua.
Gruß Jens

[Werner_O]

Hallo Jens,

Danke für diesen weiteren Test von Dir inkl. Ergebnis.

Es scheint sich aber abzuzeichnen, daß anscheinend eine zu große Skript-Datei-Größe bei einigen Kameras mit relativ wenig Arbeitsspeicher zu diesem Fehlverhaltem führt bzw. ein Skript dann evtl. erst gar nicht starten kann.

Es laufen allerdings bereits erste Tests zu diesem Skript in einer von msl bzgl. Dateigröße wesentlich minimierten Datei-Version mit meiner Diva SX20, welche ja bekanntermaßen nur sehr wenig Arbeitsspeicher hat und diesbezüglich deshalb besonders störanfällig ist.
Die ersten Ergebnisse sind dabei durchaus vielversprechend, aber ich selber muß (und werde) noch deutlich mehr Tests durchführen (etwa Geodaten-Import und/oder exzessive Kalendernutzung), um die Speicher-Grenzen genauer ausloten zu können.

Soviel zum Stand der Dinge -
es gilt sich also noch etwas zu gedulden, bis zukünftige Optimierungen (und daran wird hier im Forum momentan definitiv gearbeitet) Besserung bringen.

Liebe Grüße
Werner_O

[erfi00]

Hallo Werner,
ja, dieses Script stößt an die Grenzen einiger Kameras. Darum auch gleich die Info an sinter.
Das Script mit 53 KB lief, das mit 57KB nicht. Bei mir läuft zur Zeit die "entmüllte" Version von msl mit 47KB. Läuft die bei Dir auch ohne Probleme oder müsste das Script noch kleiner sein?
Die Idee des Scripts ist jedenfalls prima, ich hab's Freunden gezeigt, die fanden das auch beeindruckend. Als ich ihnen dann noch das CHDK-Bewegungsscript vorführte, waren sie ganz aus dem Häuschen...
Gruß aus Berlin
Jens

[Werner_O]

Hallo Jens,

an meiner Diva SX20 läuft bisher nur eine extrem eingeschrumpfte Test-Version von diesem Skript von msl mit einer Dateigröße kleiner als 35 kB. Diese spezielle Test-Version ist dabei hier im Forum nicht frei zugänglich.

Heute abend habe ich schonmal die Kalenderfunktion genauer getestet mit interessanten Ergebnissen, und in Kürze werde ich noch auch den Geodaten-Import auf Herz und Nieren überprüfen.
Es gibt also noch viel zu tun - packen wir es an!

Liebe Grüße
Werner_O

[Sinter]

Hallo zusammen,

vielen Dank für eure Tests und euer wertvolles Feedback.

Es ist in der Tat äußerst spannend, wie sich mittels dieses Skripts nebenbei auch die Grenzen der Kameras genauer aufzeigen. Die SX20 besitzt in der Regel den engsten Flaschenhals. Die SX230HS hingegen stößt erst später an ihre Grenzen, während einige andere Kameras deutlich mehr Spielraum besitzen.

Möglicherweise reicht es für die SX20 (und damit hoffentlich auch für alle anderen Kameras) aus, den Skriptcode um die Kommentare und die strukturierenden Leerzeichen zu beschneiden, so dass die Überlegung, das eigentliche Skript als "Quellcode" für eine eingeschrumpfte Skriptvariante (im Sinne einer reiner EXE-Skript-Variante) zu nutzen, hoffentlich zum Ziel führt. Denn für ein einzig der Ausführung dienendes Skript sind Kommentare und strukturierende Leerzeichen im Code nicht notwendig. Auch Variablen brauchen dann in ihrem Variablennamen nicht mehr ihre Bedeutung widerspiegeln, sondern man kann ursprüglich längeren Variablennamen einen willkürlichen möglichst kurzen Variablennamen geben.

Da mit solchen Maßnahmen aber die Orientierung innerhalb des Skriptcodes weitgehend verloren geht, werden funktionelle Optimierungen oder weitere Features dennoch zunächst in das "große Quellskript" eingepflegt und müssen dann hinterher erst wieder in die eingedampfte EXE-Version übersetzt werden.
Msl hat inzwischen an einer solchen in der Codelänge eingekürzten EXE-Variante gearbeitet (Danke!), und die eingedampfte Version läuft bereits unter günstigen Umständen auf der SX20. Mal sehen, ob das auch unter erschwerten Bedingungen noch läuft, wenn mehr Geodaten im Spiel sind. Ein Skript, welches auf der SX20 läuft, wird vermutlich auf der SX230HS locker laufen. Die SX20 stellt hier aktuell die größte Herausforderung dar.


Anbei nun nochmals eine neue (große) Version, welche eine kleine Schwachstelle, die in einer seltenen Konstellation auftreten kann, beseitigt.

EDIT: Alte Skriptversion entfernt. Die neueste Version findet sich in den laufenden Beiträgen weiter unten.

Vielen Dank und viele Grüße,
Sinter

[rudi]

Hallo zusammen,

eine einfache Lösung für das Speicherplatzproblem sind die zwei "Starter"-Skripte im Anhang. Um Twilight auszufüren, wird das Skript twilig_x.lua geladen und gestartet. Dieses ruft twilight.lua dann auf. Es ist in der Bedienung kein Unterschied bemerkbar.
Nach dem gleichen Prinzip arbeitet auch tw_l-osd.lua.

Bei der SX260 wird bei Twilight 48kB und bei Twilight Live 109kB weniger Speicher verbraucht (lt. MemInfo im Skript).

Hintergrund: Das mit "Lade Skript..." geladene Skript belegt dauerhaft entsprechend der Skriptgröße Platz im Haupspeicher. Dazu kommt dann noch der für die Abarbeitung erforderliche Zwischenkode.
Speichplatz wird nun dadurch gespart, dass das Skript, welches mit "Lade Skript..." geladen wird klein ist. Dieses Skript ruft jetzt das eigendlich Skript auf und führt es aus. Dabei wird auch der Zwischenkode im Speicher abgelegt, aber nicht der Skriptkode selbst.

Vorteil: Der Skriptkode des aufgerufenen Skriptes kann ausreiched dokumentiert werden und die Länge der Variablen und Funktionsbezeichnungen besitzt keinen Einfluss auf die Größe des Zwischenkodes.

Nachteil: Die Skriptparameter des aufgerufenen Skriptes können beim Laden nicht mehr verarbeitet werden. Deswegen wurden diese in das "Starter"-Skript kopiert und dann an das auszuführende Skript mit übergeben.

Gruß rudi