Signalverlaufsdiagramm in Datei speichern

Hallo, ich habe folgendes Problem: Ich schreibe Daten in ein Diagramm, funktioniert tadellos. Zu einem Zeitpunkt X soll der Bediener diese Daten (den Verlauf) speichern können, zB. um ihn später auch wieder laden zu können. Dazu habe ich die Funktion "Write Waveforms to File.vi" genommen, welche auch Fehlerfrei durchläuft. Die Daten übergebe ich durch eine Lokalevariable des Signalverlaufdiagrammes, welche aber LEER ist ... warum ? Auf dem GUI ist das Ding "voll".

LV 2011 DE, Consumer-Prod Loop, mit Button getriggert, LokaleVariable>>WritetoFile

Gruss Simatix

Hallo Simatix,

gleich ein paar Gedanken:

Zitat:Die Daten übergebe ich durch eine Lokalevariable

Wenn du keine Daten erhälst, könnte das an einer RaceCondition liegen. Auf deinem Bild kann man da leider nichts weiter zu erkennen. (Es ist immer besser, das komplette VI einzustellen!)

Zitat:welche aber LEER ist

Ist sie wirklich komplett leer? Dann s.o. "Racecondition". Wenn nur ein einzelner Datenpunkt enthalten ist, s.u.!

Zitat:Ich schreibe Daten in ein Diagramm ... diese Daten (den Verlauf) speichern

Ein Diagramm (aka Chart) nimmt nur Einzelwerte entgegen und puffert die Daten intern selbst. Wenn du jetzt eine lokale Variable verwendest, um die Daten wieer abzufragen (was schon grob gegen den DATAFLOW verstößt!), bekommst du nur den letzten Datenpunkt zurück. Bei einem Chart müsstest du die History-Property abfrageen, um die komplette "Ansicht" zu erhalten.

Ich würde immer für eine eigenen Datenpufferung plädieren, wenn man diese Daten sowohl anzeigen als auch speichern will. Mag etwas mehr Aufwand (am Anfang) sein, bietet aber durchaus weitere Optionen und Freiheiten...

(29.10.2012 08:58 )GerdW schrieb:  Wenn du jetzt eine lokale Variable verwendest, um die Daten wieer abzufragen (was schon grob gegen den DATAFLOW verstößt!)

das ist richtig, aber ich kann auch nicht alles mit wires übergeben, das geht einfach von der übersichtlichkeit und vom platz her nicht. Eine Racekondition ? Ich will von einem Chart, welches nicht bearbeitet wird, die Daten speichern.

(29.10.2012 08:58 )GerdW schrieb:  Ich würde immer für eine eigenen Datenpufferung plädieren, wenn man diese Daten sowohl anzeigen als auch speichern will. Mag etwas mehr Aufwand (am Anfang) sein, bietet aber durchaus weitere Optionen und Freiheiten...

Das klingt gut, nur wohin mit den Daten ? Ein Schieberegister o.ä. nutzt nichts, weils es in der Falschen Schleife meine VIs sitzt. Könnte sie in die FGV schreiben..... Werde das mal versuchen.

Gruss Philip

Hallo Simatix,

Zitat:Eine Racekondition ? Ich will von einem Chart, welches nicht bearbeitet wird, die Daten speichern.

Die Racecondition war eine Vermutung aufgrund des Mini-Bildes oben und deiner Fehlerbeschreibung.
Da ich dein VI aufgrund fehlender SubVIs (und wahrscheinlich auch fehlender Hardware) nicht laufen lassen kann, bleibt die Vermutung bestehen.

Zitat:aber ich kann auch nicht alles mit wires übergeben,

Jetzt, wo man dein VI sieht, kann man das bejahen. Aber nur mit lokalen Variablen zu arbeiten, macht dein VI weder "schöner" noch fehlerfreier!
Schon mal das Konzept der FGVs (Funktionale Globale Variablen) bedacht? Dann kannst du das Laden/Speichern deiner Messdaten auch gleich mit in die FGV packen: ein Datenspeicher, einmal debuggen, nur eine Fehlerquelle...

Ich persönlich bin auch kein Freund von frei herumliegenden Terminals der Controls. Insbesondere Buttons sollten auf dem UI als "Latched" benutzt werden - und dann auch (durch aktives Auslesen) zurückgesetzt werden. Stattdessen "Bis zum Loslassen schalten" kann ungeahnte Fehlerbeschreibungen nach sich ziehen...

Edit:
Wenn du schon aufräumst, dann entferne auch die diversen RubeGoldbergs! Mit den boolschen Operationen bist du nicht wirklich sattelfest, oder? (z.B. Vergleich eines Bools mit TRUE, Ausgabe von TRUE/FALSE aus einer Case-Struktur, Schleifenendebedingung kann man an Error-Cluster direkt anschließen, etc.)

Die eigentliche Antwort auf die Frage hat Gert doch am Schluß gegeben, vielleicht ist das untergegangen: Egenschaftsknoten "History" verwenden. Mach das doch erst mal. Damit hast Du alle Daten - soweit sie innerhalb der begrenzenten History Länge noch vorhanden sind - und kannst sie abspeichern. Bei allem anderen würde ich erst mal nicht hinhören.

Hallo Lucki, hallo Gerd,

bei der Suche bin ich bei eurer Konversation gelandet.

Ich möchte die aktuellen Diagrammdaten eines Unterprogramms ins Hauptprogramm übertragen.
Ein Signalverlaufsdiagramm als globale Variable zu speichern funktioniert aufgrund obiger Erklärung scheinbar nicht.

Einen Eigenschaftsknoten auf das Signalverlaufsdiagramm zu setzen und die Daten auszulesen gelingt mir aber auch nicht.
Könnt ihr bitte den letzten Kommentar mit einem Beispiel erklären?

Danke und Grüße

Majuler

Anzeige

Hallo Majuler,

bei einem Chart kann man die "History" der Daten per PropertyNode auslesen.

Wenn das bei dir nicht funktioniert: VI anhängen…

Das VI ist in der 2015-Version geschrieben.

(10.11.2016 16:25 )Majuler schrieb:  Hallo Lucki, hallo Gerd,

bei der Suche bin ich bei eurer Konversation gelandet.

Ich möchte die aktuellen Diagrammdaten eines Unterprogramms ins Hauptprogramm übertragen.
Ein Signalverlaufsdiagramm als globale Variable zu speichern funktioniert aufgrund obiger Erklärung scheinbar nicht.

Bloss weil du es in deinem Thread nicht hinbekommen hast, heißt das nicht, dass es nicht doch geht. Wenn der Datentyp stimmt...

(10.11.2016 16:25 )Majuler schrieb:  Einen Eigenschaftsknoten auf das Signalverlaufsdiagramm zu setzen und die Daten auszulesen gelingt mir aber auch nicht.
Könnt ihr bitte den letzten Kommentar mit einem Beispiel erklären?

Danke und Grüße

Majuler

Hallo Majuler,

Zitat:Einen Eigenschaftsknoten auf das Signalverlaufsdiagramm zu setzen und die Daten auszulesen gelingt mir aber auch nicht.

In deinem VI werden nirgends Daten AUS dem Chart gelesen…
Und wenn du einfach mal die Kontexthilfe aufmachst, wird dir sogar angezeigt,welche Datentypen hier erwartet bzw. verwendet werden!

Wir reden hier über LabVIEW-Grundlagen: die Links in meiner Signatur kennst du doch, oder?