Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich versuche gerade in LabVIEW eine Langzeitmessung umzusetzen. Leider bricht das Programm zwischen einer und 4 Stunden ab. Außerdem bekomme ich keinen Zeitstempel in das Excel-File übertragen.
Es kommt keine Fehlermeldung oder ähnliches. Das Programm läuft einfach weiter aber reagiert nicht mehr. Bei den "Sondeninformationen" aktualisiert sich kein Wert mehr.
Hat jemand eine Idee oder hatte schonmal ein ähnliches Problem? Ich bin über jeglichen Hinweis dankbar .
Weiter unten sind noch Informationen zur verwendeten Hardware und die detaillierte Messaufgabe.
In Windows sind Standby, Hintergrundaktualisierungen usw. deaktiviert.
Mit besten Grüßen
MaHa
Messaufgabe:
Es soll über einen Zeitraum von mehreren Monaten kontinuierlich (Intervall: 1s) und zeitgleich Messwerte von 6 Messuhren und einer Kraftmessdose erfasst und in mehreren Excel Files gespeichert werden. Da ein externer Temperaturlogger verwendet wird soll neben der absoluten Messzeit auch noch die relative Zeit in DD:MM:JJ HH:MM erfasst werden.
Zitat:Leider bricht das Programm zwischen einer und 4 Stunden ab.
Warum setzt du einen Timeout von 72 Stunden???
Warum setzt du den Timeout in jeder Iteration erneut?
Warum schließt du die COM-Ports in jeder Iteration? (Und lässt sie von LabVIEW jedesmal erneut wieder öffnen, ohne das irgendwo mal selbst zu machen???)
Warum schreibst du gleich zweimal in Excel-Dateien? Warum (zweifach) mit dem ExpressVI, welches SEHR ineffizient arbeitet?
Warum schreibst du nicht einfach in eine CSV-Datei? Wo du selbst die VOLLE Kontrolle hast, wo welcher Wert wie formatiert landen soll???
Warum legst du den DAQmx-Task in jeder Iteration erneut an und schließt ihn dann wieder?
Wenn du einen Dauerversuch machen willst, dann sollte dein VI auch dafür ausgelegt sein! Und ExpressVIs haben dann darin auch nichts zu suchen…
Hast du dir mal irgendein BeispielVI zum Thema DAQmx angeschaut?
Mal eine ganz allgemeine Kritik neben der ganzen berechtigten Kritik von GerdW:
Langzeitdaten in einer Excel-Datei zu speichern, das gehört verboten. Das Dateiformat (ZipFile vieler XML-Dateien) ist viel zu langsam, um sinnvoll mit einer großen Datenmenge umzugehen.
Die Aufgabe lässt sich auf jeden Fall mit LabVIEW lösen - solche Langzeitläufer habe ich schon x-fach umgesetzt, aber natürlich nicht mit Excel als Datengrab.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
wie ist denn die Fehlermeldung. Denn die Fehler gibst Du ja aus...was gut ist.
Ich weiß es nicht genau, aber Du willst alle 100ms AI-Daten holen, gibst der Schleife aber noch nen eigenen Wait vor von 125ms. Das erledigt meines Wissens dann der Timer Deiner Hardware, den Du mit Sample-Takt eingestellt hast. Lass mal das Wait weg. Du konfigurierst den Takt mit 1kHz und holst dann immer nur einen Wert ab. Was soll dann AI eigentlich genau machen...jede Sekunde 1 Wert lesen? Dann hole bei einer Koniguration von 1kHz auch immer 1000 Messwerte ab und Du hast Dein 1s-Intervall.
Dann packe auf jeden Fall Task erzeugen, Kanal erzeugen und Task schließen außerhalb der der Schleife, denn sonst wird alle 125ms Task erzeugt, geschlossen usw...so erzeugst Du 1x beim Start den Task und beim Beenden wird der 1x geschlossen.
Aber so wie Dein Programm aussieht, habe ich auch mal angefangen...
Danke erstmal für die hilfreiche Kritik und die Hinweise, ihr habt mir sehr weitergeholfen :-).
Im Anhang ist nun das verbesserte VI, dieses läuft zumindest mal über 16h und kommt ohne Express VI's aus . Falls euch noch was auffällt oder ihr wisst wie es noch, (einfach) zu verbessern ist lasst es mich gerne wissen.
Das einzige Problem ist noch das automatische speichern der Messwerte in neue Dateien. Durch die Case Struktur erzeugt das VI in einstellbaren Intervallen (Timer) einen neuen Dateipfad in dem gewünschten Format. Aber wie kann ich diesen mit dem Eingang von "Dateipfad" (Werte in Tabelle schreiben) verbinden? Habe schon alles mögliche versucht, mit Schieberegister oder lokalen Variablen werden die Daten nur in den letzten erzeugten Dateipfad bei Abbruch der while-Schleife gespeichert (leuchtet ein, Datenfluss.....). Habe es auch schon mit einer zweiten while-Schleife versucht, leider auch ohne Erfolg (Schleifendurchlauf beginnt erst bei Abbruch der ersten Schleife).
Hat jemand einen Tipp?
Beste Grüße
MaHa
12.05.2019, 18:03 (Dieser Beitrag wurde zuletzt bearbeitet: 12.05.2019 18:04 von GerdW.)
Zitat:Falls euch noch was auffällt oder ihr wisst wie es noch, (einfach) zu verbessern ist lasst es mich gerne wissen.
- An etlichen Controls/Indicators fehlen die Label/Beschriftungen! Wenn du in einer textbasierten Programmiersprache arbeitest, löscht du doch auch keine Variablennamen weg, oder?
- Du benutzt BytesAtPort: das ist zu 99.9% falsch. Vor allem, wenn man wie du ein TermChar für die VISA-Abfragen aktiviert hat!
In der Case-Struktur
- gibt es eine Wartezeit: wieso/weshalb/warum?
- erzeugst du einen Dateipfad aus Strings: warum keine echten Pfad-Operationen/-Konstanten?
- addierst du immer eine 1 zu einer 0: wieso/weshalb/warum?
Außendrum:
- wozu die Select-Funktion nach der Case-Struktur? Einfach im Case durchverdrahten!
- wieso arbeitest du in der Schleife überall mit Strings, die du dann nach der Schleife erstmal alle zu DBL-Zahlen umwandelst - nur um sie dann mittels WriteDelimitedFile wieder zu Strings umzuwandeln!? Warum baust du dir dann nicht einfach ein 2D-Array of Strings? (Viel weniger Aufwand…)
- Liefern deine COM-Ports wirklich Zahlen mit einem Komma als Dezimaltrennzeichen???
- Du hast eine Samplerate von 1000S/s eingestellt, fragst aber nur ein Sample pro Sekunde ab - das sollte eigentlich sehr schnell einen Fehler melden!
- Deine ErrorCluster werden nicht in Schieberegistern gehalten…
Ein paar Änderungen habe ich mal umgesetzt:
Zitat:Aber wie kann ich diesen mit dem Eingang von "Dateipfad" (Werte in Tabelle schreiben) verbinden?
Mit einem Draht!
(Und wie oben schon gesagt: einen echten Pfad erzeugen und keinen String, der eine pfad-ähnliche Angabe enthält…)
Zitat: An etlichen Controls/Indicators fehlen die Label/Beschriftungen! Wenn du in einer textbasierten Programmiersprache arbeitest, löscht du doch auch keine Variablennamen weg, oder?
Klar, hab ich nicht drangedacht.
Zitat:Du benutzt BytesAtPort: das ist zu 99.9% falsch. Vor allem, wenn man wie du ein TermChar für die VISA-Abfragen aktiviert hat!
"Bytes at Port: Gibt die Anzahl an Byte aus, die aktuell an dem von dieser Session verwendeten Port verfügbar sind."
Was ist daran falsch/oder schlecht? Beim Termchar geht es um die Abschlusszeichen, diese liegen doch ebenfalls als Bits am Port an.
Verwende jetzt 18 Bytes, darunter werden die Messwerte nicht vollständig dargestellt. Und es sollte kein Timeout error kommen.
Zitat:wozu die Select-Funktion nach der Case-Struktur? Einfach im Case durchverdrahten!
Ja
Zitat:wieso arbeitest du in der Schleife überall mit Strings, die du dann nach der Schleife erstmal alle zu DBL-Zahlen umwandelst - nur um sie dann mittels WriteDelimitedFile wieder zu Strings umzuwandeln!? Warum baust du dir dann nicht einfach ein 2D-Array of Strings? (Viel weniger Aufwand…)
Hatte ich zuerst so, Problem ist das es mir die Daten "kunterbunt" in dem .csv-file anordnet wenn ich dieses mit Excel öffne (und mit dem Texteditor),Anhang "String_CSV". Das Array welches zum "Write to Spreadsheet" geht sieht noch richtig aus (Array auf Frontpanel). Habe schon alles mögliche mit Trennzeichen, Formatierung usw. versucht ohne Erfolg. In dem aktuellen VI muss ich den Datensstringarray ebenfalls wieder in Zahlen formatieren um eine gut formatierte Tabelle zu erhalten.
Zitat: Liefern deine COM-Ports wirklich Zahlen mit einem Komma als Dezimaltrennzeichen???
Ja.
Zitat:- Du hast eine Samplerate von 1000S/s eingestellt, fragst aber nur ein Sample pro Sekunde ab - das sollte eigentlich sehr schnell einen Fehler melden!
Legt die "Rate" des DAQmx Timing nicht nur die Buffer Größe fest?
Zitat:- Deine ErrorCluster werden nicht in Schieberegistern gehalten…
Ist wohl klüger.
Zitat:Mit einem Draht!
(Und wie oben schon gesagt: einen echten Pfad erzeugen und keinen String, der eine pfad-ähnliche Angabe enthält…)
Das ist klar allerdings, ändert sich der Wert nur wenn die While-Schleife unterbrochen wird.
Mit der Case-Struktur will ich eigentlich nur einen Dateipfad erzeugen um diesen dann (später) einmal am Tag an das "Werte in Datei schreiben" weiterzugeben, um die erfassten Messwerte einmal täglich in einer separaten Datei abspeichern zu können. Ich bekomme es aber wegen des Datenflussprinzips von LabVIEW nicht hin. Denn wenn ich den Timer auf einen Tag einstelle kann man die While Schleife erst beenden wenn dieser Tag auch vorbei ist....
Hat mir jemand einen Ansatz/Tipp? Tappe völlig im dunkeln bei der Vielzahl von Optionen welche LabVIEW bietet.
Zum Thema "Bytes on Board":
Das funktioniert bei Dir so: Das Visa Read soll etwas auslesen, was die Antwort auf den vorangegangenen Schreibbefehl sein soll. Das funktioniert aber nicht, denn Visa Write funktioniert ganz anders als Du das hier voraussetzt. Visa Write schreibt nur mit Affengeschwindigkeit in vielleicht weniger als 1 µs die Daten in den Schreibpuffer. Es wartet nicht, bis die Daten von der Gegenstelle empfangen sind, und schon gar nicht bis eine Antwort erfolgt ist. Wenn Du also sofort nach dem Schreibbefehle die Bytes on Bord (im Empfangspuffer) abfragst, ist das Ergebnis 0 Byte. Wenn aber trotzdem Bytes gezählt werden, dann sind das immer die Bytes der vorangegangenen Iteration.
Wenn der empfangene String eine Zeilenende-Kennung hat, dann nutze das. Das einzige Problem ist, daß der Programmcode dafür dann so einfach ist, daß Labview sich offensichtlich schämt, etwas so Einfaches als Programmbeispiel zu zeigen. Deshalb wird von Anfängern in der seriellen Komunikation oftmals alles Mögliche probiert, nur das nicht.
danke an Ludwig, dass er diesen Thread wieder hoch geholt hat - ging in meinem Urlaub verloren…
Zitat:Legt die "Rate" des DAQmx Timing nicht nur die Buffer Größe fest?
Warum heißt der Anschluss wohl "Rate" und nicht etwa "Buffergröße"???
Der legt die Samplerate fest!
Du solltest unbedingt DAQmx und den ganzen VISA-Kram in separate Schleifen legen. Momentan bestimmt die Antwortzeit des langsamsten Gerätes n deinen COM-Ports die Iterationszeit deiner Schleife - und die ist wahrscheinlich deutlich langsamer als die 1ms, die dein DAQmxRead eigentlich erwartet!
Dazu dann noch die Wartezeit von 1s in der Schleife, die dein Schleifentiming dann vollends ruiniert…
Zitat:Klar, hab ich nicht drangedacht.
Da sind immer noch etliche nicht sichtbar.
Und warum musst du in die lokale Variable eines Control schreiben ("stop")???
Zitat:Das ist klar allerdings, ändert sich der Wert nur wenn die While-Schleife unterbrochen wird.
???
Ein Wert auf dem FP ändert sich immer dann, wenn man einen neuen Wert hineinschreibt. Das klappt deutlich besser, wenn man eine Schleife nicht unterbricht…
.
. Falls euch noch was auffällt oder ihr wisst wie es noch, (einfach) zu verbessern ist lasst es mich gerne wissen.
