fischertechnik community forum

Hallo allerseits,
Ich versuche eine Liste (cmd_lst; global) in eine Datei (file1) zu schreiben.
Das Schreiben wird über das event button_clicked "save_file" ausgelöst.
Normalerweise wird die Liste im Hauptprogramm definiert. Wenn ich "save_file" auslöse, wird die Datei dann aber NICHT geschrieben: siehe screenshot 2.
Hier kommt das Programm bis zur Auflistung der Liste cmd_lst (immerhin gefüllt!) und bleibt stehen (keine weiteren, definierten buttons lassen sich auslösen); siehe auch gelb markierte Stellen.


Wenn ich die Liste innerhalb des codes für button_clicked definiere, funktioniert das Programm wie erwartet; screenshot 1.

Wie bekomme ich die globale cmd_lst in die Datei!?

Frohe Weihnachten
Martin

Hallo Martin,

ich bin mir nicht sicher, ob ich Dich richtig verstehe. Falls wir also aneinander vorbei reden, entschuldige dies bitte.
Mein Kenntnistand:

Es gibt zwei verschiedene Dateiarten:
1. Die die über das Symbol links oben (Seite mit +) erstellt werden. Diese landen im Arbeitsverzeichnis unter data
Sie werden über den oberen Block: "Datei .< mit Modus x öffnen angesprochen.
2. Auf anderem Wege erzeugte Dateien irgendwo auf dem Controller. Diese werden mit dem darunter stehenden Block "Datei path mit Modus x öffnen" geöffnet. Der path kann auch ausserhalb des Arbeitsverzeichnisses liegen.



Das Verzeichnis heißt nicht - wie standardmäßig data - sondern data2

Du verwendest wohl Variante 1, probier doch bitte mal Variante 2 aus. Und melde Dich bitte, egal, ob es klappt oder nicht.
Ach so: Ich nutze sicherheitshalber vor dem Schliessen immer den Block "Änderungen in Datei xxx übernehmen."
Falls es nicht klappt wäre es schön, wenn Du mir per PN eine Mail mit einem Testprogramm schicken würdest, das ich ohne große Bauerei auf dem Controller laufen lassen kann.

Für morgen wünsche ich Dir viele bunte Päckchen.

danke,
werde ich ausprobieren.
aber es bleibt die Frage, warum funktioniert mein code eimal. und das andere Mal nicht?
...auch viele Päckchen

Hallo Martin,

Dass der Code manchmal funktioniert und dann wieder nicht, kenne ich auch.

Bei mir war es bisher immer so: Wenn die Anweisungen aus einer Funktion heraus aufgerufen werden funktioniert es nicht, werden die Anweisungen direkt aus dem Hauptprogramm aufgerufen funktioniert es. Sehr ärgerlich bei Ereignisprozeduren (Druck auf Schaltfläche). Z.B. Tonausgabe. Ich setze daher in der Ereignisprozedur eine Variable, Diese wird im Hauptprogramm abgefragt und bewirkt die gewünschte Aktion, z.B. Ausgabe eines Tons.
Vermutlich liegt das daran, dass die Funktionen ja quasi parallel zum Hauptprogramm aufgerufen werden aber nur einen kurzen Zeitraum für die Ausführung bekommen. Wenn ihr Start lange dauert kommen sie überhaupt nicht zur Ausführung. Ich weiß allerdings nicht, ob das so stimmt. Und schon gar nicht, wie das zu lösen ist (abgesehen von meinem Schalter. bzw. dem Semaphor, denn das ist es ja).

Viele Grüße

Horst

Hallo...
So ins Blaue geraten.
Hmm, das mit dem temporären könnte sein.
Versuch doch mal eine kleine Warte einzubauen, die nach dem Befehl kommt.
Halt so, dass das System Zeit hat, die noch auszuführen.
Kann aber auch sein, dass es vom System wegoptimert wird, da ja danach nichts mehr kommt..
Mit freundlichen Grüßen
Holger

Herzlichen Dank an Holger und Günther für die Vorschläge.

Ich habe jetzt (glaube ich...ich muss noch einiges überprüfen) die LÖSUNG ... ist peinlich einfach:

Während eine Liste die Mischung aus STR und INT akzeptiert, ist das offensichtlich bei einer Datei nicht der Fall. Leider gab es im "embedded Fall" (file save im code "button pressed") KEINE diesbezügl. Fehlermeldung. Erst als ich den code ins Hauptprogramm ausgelagert habe (analog zu "Button clicked ..die Dritte" ) gab es den entscheidenden Hinweis, der mich auf die Lösung brachte. Weihnachtliche Grüße Martin

P.S.: Blöd finde ich, dass ich die angelegte Datei weder direkt auf dem Controller noch über den PC Web Browser (user "ft") finde. Die Datei ist irgendwo im Nirwana. Es soll noch einen User "ftgui" geben, aber für den habe ich nicht das Passwort...vielleicht darf/kann der die Datei sehen. Löschen kann ich die Datei auch nicht. Ft hatte vorgeschlagen, die Rechte über CHMOD 777 zu erweitern...aber ich habe nicht die Rechte diesen Befehl abzusetzen... Ich kann die Datei nur auf 0kB setzen. Irgendwann ist mein Controller dicht mit Dateileichen.

Hallo Martin,

ich habe das Programm aus Deinem letzten Post abgetippt. Bei mir läuft es astrein ohne Fehler. Die Datei "file1" finde ich weder direkt auf dem Controller noch über die WLan-Adresse im Browser.
Aber: Ich benutze als ftp-Programm Winscp. wenn ich mich dort anmelde,
sehe ich die Datei:
Und kann mir auch den Inhalt anzeigen lassen.

Löschen kann ich sie allerdings nicht.

Ich halte dieses Verhalten für einen Bug und werde ihn dem Service melden. Wenn Du (und vielleicht auch weitere Forumsmitglieder) dies in einer konzertierten Aktion machen, hilft das vielleicht. Eine einfache Lösung wäre wahrscheinlich, wenn Fischertechnik das Passwort des Benutzers ftgui veröffentlicht. Ich kenne mich allerdings nicht unter Unix aus.

Ansonsten würde ich Dir raten, per WinSCP (oder einem anderen ftp-Programm) auf dem Controller ein Verzeichnis anzulegen und das dann im Öffne-Block anzugeben.

Noch ein kleiner Hinweis: Da die Variable save_file ja bereits vom Typ Boolean ist, ist die Abfrage "If save_file = true" ja doppelt gemoppelt. Es würde reichen "if Save_file". Dient aber nur der Schönheit bzw. beweist, dass Du Durchblick hast.

Viele Grüße

Horst

Hallo Horst,
danke für Deine Rückmeldungen und Anregungen.
Der Reihe nach (ich nummeriere, dann kann besser Bezug auf einzelne Aspekte genommen werden):
1) Auch bei mir läuft (jetzt) das Programm astrein. Das Problem war:
1a) Die Datenstruktur "Liste" akzeptiert gleichzeitig sowohl "STR" als auch "INT" Einträge.
1b) Eine Datei offensichtlich nur entweder "STR" oder "INT"
1c) Nach Umwandlung der "INTs" in "STRs" läuft das Programm.
1d) Ärgerlich ist, dass dieser Fehler nicht angezeigt wird, wenn der code (embedded) in button clicked läuft, sondern nur, wenn man die Ausführung in das Hauptprogramm verlegt.
1e) Konsequenz für mich: Vorsicht bei komplexen code (Schleifen, i/O etc.) direkt im überwachten Ereignis; Ausführung besser ins Hauptprogramm auslagern.

2)Anzeige der Datei.
2a) Ich bin ja beruhigt, dass auch du diese weder auf dem controller noch im browser findest.
2b) Das mit Winscp werde ich ausprobieren.
2c) Was schaltet das Passwort für ftgui frei?
2c) Beim Passwort ist mir aufgefallen, dass es länger als das übliche, mir bekannte Passwort !? Hast du dich anders eingeloggt?

3) Löschen sollte m.E. seitens ft implementiert werden. ft schreibt diesbezügl.:

"Zum Löschen der Datendatei:
- Wenn Sie die Datei im Projekt speichern, so können Sie das Projekt am Controller löschen und dann wird die Datendatei ebenfalls gelöscht.
- Falls Sie die Datei auf dem Controller nicht im Projektpfad speichern, so können Sie die Datei mit Python-Code löschen. Derzeit existiert nur der Weg über Python-Befehle zum Löschen der Dateien außerhalb des Projektes.
Dies scheint ein Bug zu sein. Ich habe dazu ein Ticket erstellt, damit es vom Entwickler der App untersucht werden k

3a) Das Löschen über py-code ist mit nicht gelungen.

4) Konzertierte Aktion
4a) Halte ich für eine gute Idee. Vielleicht sollte sich diese nicht auf einzelne Bugs/Probleme beziehen sondern auf die Forderung endlich einmal eine vollständige (und ) korrekte Dokumentation vorzulegen.
4b) Dann kann man immer noch spezifische Fälle hinterherschieben, die ft vielleicht zur Einsicht bringt, eine gescheite Doko zu erstellen, als dauernd die hotline, und das teilw. mehrfach und unkoordiniert , in Beschlag zu nehmen.
4c) Das die software offenbar mit heißer Nadel gestrickt wurde zeigt auch folgendes Beispiel:
Der Befehl "if ...compressor.is_on()" ergibt die Fehlermeldung:
"TXT4Compressor object has no attribute 'get_value'".
ft schreibt dazu:
"Dieser Bug wird bei der nächsten ROBO Pro Coding Version korrigiert. Es ist als Ticket erfasst, leider wird hier an dieser Stelle auch eine Änderung der TXT 4.0 Firmware in der txtapi benötigt."
Das läßt mich auch an einer gescheiten Qualitätskontrolle zweifeln.

5) Ja," if save_file = true" ist doppelt gemoppelt. Aber selbst ft benutzt das (haben die das Handbuch nicht richtig gelesen? )

Fazit:
1)Software schlecht (eigentlich gar nicht ) seitens ft dokumentiert
2)Vorsicht beim event-monitoring. Das scheint auch nicht immer wie erwartet zu funktionieren.
3) Qualitätskontrolle: Ausbaufähig.

mfg
Martin

P.S.: Steuern die mit diesem Controller / Software ihre teuren Industriemodelle??