LabVIEWForum.de

Hallo,
neues Problem = Neues Thema.
Ich versuche aktuell eine bestehende Funktion ordentlicher zu programmieren. Vorher wurden hier etliche Filmsequenzen genutzt und jetzt geht es auf einen Blick.
Dabei ist ein Problem aufgetreten, welches ich aktuell nicht zu lösen vermag.

Ich kann alle gewünschten Daten in eine Textdatei schreiben und sie tauchen dort auf. Selbst die Boolschen Schalter funktionieren.
Das Laden der Datei macht jedoch Probleme.

Alles was in einer For Loop ist geht nicht.
Fehlerbild während der Fehlersuche:
Die Schleife läuft zum ersten Mal durch und kreiert an der richtigen Stelle den Text der dort hin gehört.
Die Schleife läuft zum zweiten Mal durch und kreiert an der richtigen Stelle den richtigen Text leider wird dabei der vorherige Text gelöscht.
Und das geht mit allen Schleifendurchgängen gleich. Egal was ich probiert habe.
[attachment=62723]

Bei meinem Kollegen funktioniert es, selbst wenn ich zwei Schleifen hintereinander setze in seinem Programm.

Gibt es da eine Einstellung auf die ich achten muss?
Ich habe jedenfalls keine gefunden.

Vielen Dank.

(11.04.2024 12:36 )Minako schrieb: [ -> ]... an der richtigen Stelle den richtigen Text leider wird dabei der vorherige Text gelöscht.

Einfach zur Erinnerung: Bilder kann man nicht debuggen..

Was soll denn passieren?
erste Vermutung, diese "Beschriftung messkan..." rausziehen aus der For-Schleife, du überschreibst bei jedem durchlauf den Inhalt..

Mfg Timo

Noch eine Vermutung: du willst eigentlich Auto-Indexing an deinem Array-Tunnel anschalten, das jeweilige Clusterelement beschreiben und wieder zu einem Array zusammenfügen. Das Ergebnis kann dann an die Value-Property. Dann kannst du auch gleich ein SubVI aus den For-Schleifen machen.

Hallo zusammen,

noch ein paar Punkte:
- Schieberegister in den Schleifen nutzen - oder AutoIndizierung…
- warum 4 Schleifen, um 4 Werte in einem Cluster zu beschreiben??? EINE Schleife, die alle 4 Keys aus der INI-Datei liest und in den Cluster einträgt!!!
- die PropertyNode gehört EINDEUTIG hinter die Schleife und nicht hinein! Warum willst du pro Schleife 12mal das ArrayOfCluster aktualisieren, und dass auch noch schneller als der User gucken kann??? (PropertyNodes sind relativ langsam und du schreibst gerade 48mal auf diese PropertyNode, wo ein einziger Aufruf ausreichen würde…)
- Passiert sonst noch was in der äußeren Schleife? Ich sehe keine Abhängigkeit vom Schleifeniterator, also wozu dort eine FOR-Loop?

Guten Tag an Alle,
mit einem Bild scheint sich das wirklich schwer beschreiben zu lassen, was mein Problem ist und was die Funktion machen soll.
Ich bin jedenfalls jetzt komplett verwirrt.

Ich habe in der Zwischenzeit versucht diese Funktion im Einzelnen zu programmieren und zum Laufen zu kriegen.
Dafür habe ich ein neues VI erstellt und alles rausgelöscht, was ich für diese Funktion nicht brauche.
Es hat funktioniert. Ohne autoindexing und ohne Value aus der Schleife raus nehmen. (Hatte ich beides mal eingestellt und es half nicht)
Die Schleife fügt nach jedem Durchlauf an einer anderen Position etwas ein.
Im Anschluss habe ich erst im Hauptprogramm wieder gesucht und nichts gefunden. Danach bin ich in das neue VI und habe Stück für Stück alles hinzugefügt bis der Fehler aufgetreten ist.
Das war bei der äußeren For-loop der Fall.
(@GerdW: Diese äußere For-Loop soll der Abfrage dienen, ob vor dem Laden der Einstellungen das Gerät ausgewählt wurde oder nicht. Ist das nicht der Fall, soll die Durchführung des Ladens abgebrochen werden. Bisher ist mir nichts besseres eingefallen...)

Ich habe dann die For-Loop wieder entfernt und das Programm noch mal ausprobiert (Hätte ja gehen müssen). Leider ging es nicht. Also auf Ur-Zustand zurück. Es geht immer noch nicht.
Stehe also wieder am Anfang mit einer abgespeckten Variante.
Diese stelle ich gern zur Verfügung. [attachment=62724]

Bin gespannt, ob sie bei euch läuft.
Wenn sie direkt läuft muss ich das mal mit ner Case struktur und ner For loop ergänzen und noch mal rein laden. das war der Punkt an dem es bei mir schief ging.
Neustart von Labview oder neu Laden des Programms hat nichts gebracht.
Selbst wenn das hilft, wüsste ich gern, wie ich das verhindern kann, dass sich die Programm da so aufhängen... (Sauber programmieren vermute ich malwird hier eine Hauptaussage sein. Mit der lässt sich leider zu vieles beantworten ohne das es mir direkt hilft )

@GerdW Ich dachte mir schon, dass das dicke verbesserungswürdig ist. Leider sehe ich drei Stellen pro Schleife, die unterschiedlich sind. und da habe ich mich noch nicht mit beschäftigt, wie das gehen soll.

Vielen Dank schon mal. Ich stehe gerne Rede und Antwort für das Chaos, dass ich da erstelle

(12.04.2024 10:06 )Minako schrieb: [ -> ]Die Schleife fügt nach jedem Durchlauf an einer anderen Position etwas ein.

Nein, tut die Schleife nicht.
[attachment=62726]
'Array' ist die Varriante wie sie in deinem VI ist, 'Array 2' ist eine Möglichkeit (keine gute!) das zu erzielen was du willst.

Zur Erklärung, der Eingang an einer (For-)Schleife (gefüllters Kästchen) ist bei jedem Durchlauf der gleiche Wert, in deinem Beispiel der Wert aus der Konstante die du links reingibst.
Du ließt den Ini Key, schreibst den in dein Array und im nächsten Durchlauf lädst du wieder die Konstante, einen andere ini key und ÜBERSCHREIBST den Inhalt in deinem Array.

mfg Timo

Hallo Minako,

Zitat:@GerdW Ich dachte mir schon, dass das dicke verbesserungswürdig ist. Leider sehe ich drei Stellen pro Schleife, die unterschiedlich sind. und da habe ich mich noch nicht mit beschäftigt, wie das gehen soll.

Schau mal hier:
[attachment=62727]
Das sollte bei dir funktionieren: alle Keys (pro Kanal) laden, das Cluster-Array per Autoindizierung aufbauen.
Das IndexArray vor der Loop dient nur dazu, einen Beispiel-Cluster zu erstellen, der in der Schleife modifiziert ("mit Daten befüllt") wird.

Hinweis: Cluster sollten immer typ-defniert sein!

Zitat:@GerdW: Diese äußere For-Loop soll der Abfrage dienen, ob vor dem Laden der Einstellungen das Gerät ausgewählt wurde oder nicht. Ist das nicht der Fall, soll die Durchführung des Ladens abgebrochen werden. Bisher ist mir nichts besseres eingefallen...)

Wenn ich also in einem Programm eine Entscheidung auswerten/ausführen will, dann nehme ich eine Loop?
Wozu nochmal gibt es Case-Strukturen!?

Im Event "Einstellungen speichern" gehst du ebenso umständlich vor…
Statt 4 einzelner Schleifen würde ich wie hier gezeigt nur eine verwenden und alle 4 Keys pro Cluster gemeinsam speichern.
Außerdem würde ich die INI-Keys anders organisieren, nämlich über den Kanal-Index sortiert:
mit "xx" die Nummer des Kanals…
Vorteil: nur noch eine Section pro Kanal statt wie bei dir eine Section pro Cluster-Element…

Zitat:(Sauber programmieren vermute ich malwird hier eine Hauptaussage sein. Mit der lässt sich leider zu vieles beantworten ohne das es mir direkt hilft)

"Sauber programmieren":
- hilft uns, deinen Code zu verstehen
- hilft dir, deinen Code zu verstehen
- hilft uns allen, Fehler schneller zu erfassen

Mahlzeit,

@TpunktN: Nach mehrmaligem lesen hab ich deinen letzen Satz doch verstanden. Es ist im Prinzip schon richtig was ich gesehen habe nur falsch von mir interpretiert...
Danke für den Hintergrund was dort passiert. Leider verschwinden die Werte auch mit deiner Variante.
Das hatte ich nach einem Tipp von Vorschlägen vorher mal ausprobiert gehabt.

@GerdW: Hier merke ich mal, dass es nicht unbedingt sinnvoll ist einen Code einfach zu übernehmen. Vielleicht hätte ich mir mal selbst gedanke machen sollen. Dachte nicht, dass das so einfach geht.

Zitat:Wenn ich also in einem Programm eine Entscheidung auswerten/ausführen will, dann nehme ich eine Loop?
Wozu nochmal gibt es Case-Strukturen!?

Ich habs endlich raus mit dem zitieren xD
Ich weiß das es diese gibt und kann noch nicht gut damit umgehen...
Bei zwei Fällen ist das überhaupt kein Problem aber ich brauche drei, welche ich steuern kann.
Ablauf:
Der Button "Laden" wird gedrückt -> Abfrage 1: Wird Gerät 1 genutzt und ist ausgewählt? Wenn ja dann ok drücken, wenn nein dann abbrechen-> wenn ok gedrückt wird soll Abfrage 2 starten: DAQ970 aktiv (ja oder nein)
Wenn nach Abfrage 1 ein "nein" kommt mussdie Bearbeitung des Events gestoppt/abgebrochen werden.

Ich stelle mir jetzt zwei Case-Struckturen vor. Aber ist das auch ordentlich?

Vielen Dank schon mal. der Rest funktioniert gerade. füge es jetzt noch in alles andere ein und schaue dann noch mal.

Hallo Minako,

Zitat:Bei zwei Fällen ist das überhaupt kein Problem aber ich brauche drei, welche ich steuern kann.
Ablauf:
Der Button "Laden" wird gedrückt -> Abfrage 1: Wird Gerät 1 genutzt und ist ausgewählt? Wenn ja dann ok drücken, wenn nein dann abbrechen-> wenn ok gedrückt wird soll Abfrage 2 starten: DAQ970 aktiv (ja oder nein)
Wenn nach Abfrage 1 ein "nein" kommt mussdie Bearbeitung des Events gestoppt/abgebrochen werden.

Ich stelle mir jetzt zwei Case-Struckturen vor. Aber ist das auch ordentlich?

So vielleicht:
[attachment=62728]
Das würde funktionieren, ist aber nur "bedingt ordentlich"…

Wie sieht es aus, wenn sich noch eine Bedingung dazu ergibt? Gesamten Code auseinanderziehen, noch irgendwo eine Case-Struktur hineinpacken… (unübersichtlich, schlecht skalierbar)

Bessere Option:
Schau dir an, wie Statemachines aufgebaut sind und ablaufen.
Du hast hier klar 3 States:
Das sind 3 States einer Statemachine und nach jedem State entscheidet man, welches der nächste ausgeführte State werden soll.
Du kannst also nach State1 weitermachen mit State2 oder eben "abbrechen", d.h. in einen 4. State "quit" wechseln…

LabVIEW bringt übrigens eine große Sammlung an BeispielVIs/-Projekten mit, da sind auch Beispiele für Statemachines dabei!

Hi,

vielen lieben Dank.
Habs hinbekommen.
Hier nur ein kleiner Screenshot:
[attachment=62732]

Mit ein bisschen probieren hat es sogar funktioniert.