Abbruchbedingung while-Schleife führt zu Fehler

Okay, also ich habe jetzt beide Sample-Anzahl-Eingänge belegt und zwar mit demselben Bedien-Element, ich hoffe das geht.

Ich habe jetzt meine Abbruchbedingung vom Anfang wieder eingebaut, ich möchte ja die Prüfzeit selber bestimmen, wie lange es läuft. Ich habe nochmal ein paar Sonden platziert, weil ich wissen wollte, was da genau passiert und wo welche Werte zum Abbruch führen. Auch die Highlight-Funktion habe ich eingeschalten, damit es ein bisschen langsamer abläuft (ich bin ja nicht so von der schnellen Sorte xD). Allerdings kommt (nur mit der Highlight-Funktion) dann eine Fehlermeldung, und zwar Fehler 200279 (gibt es eigentlich etwas, wo alle Fehler aufgelistet sind, dass man die nochmal nachgucken kann?) - ist das wegen dem Higlighten?

Was mich auch interessiert, ist der Timer-Wert - der legt ja bei 10594779 los, warum das?

Liebe Grüße,

Franzie

Anzeige

Hallo Franzie,

Zitat:gibt es eigentlich etwas, wo alle Fehler aufgelistet sind, dass man die nochmal nachgucken kann?)

Das hatte ich doch oben schon geschrieben: Rechtsklick -> "Fehler beschreiben…"

Zitat:ist das wegen dem Higlighten?

Ja.

Zitat:Was mich auch interessiert, ist der Timer-Wert - der legt ja bei 10594779 los, warum das?

LabVIEW-Hilfe zur Funktion lesen, da wird das erklärt…
(Der "Millisekunden-Timer" fängt zu zählen an, sobald das OS startet.)

Ah, also der Timer-Startwert kommt daher ab PC-Start wird einfach die Zeit gezählt --> http://www.labviewforum.de/Thread-Absolu...Timer-Wert

Interessant ist auch der Gedanke mit dem Überlauf, ich befürchte an dieser Stelle werde ich noch Probleme bekommen. (2^32)-1 ms sind 49,7 Tage - bei meiner Messung der Lebensdauer brauche ich aber 156 Tage. Casus knaxus

Immerhin: Danke Gerd, ich hab das Gefühl es funktioniert jetzt alles, in 60 Sekunden schreibt es mir genau einen Wert in meine Datei *hurra* Eine letzte Änderung habe ich auch noch vorgenommen und zwar habe ich zum Beschriften der Tabelle einen 2D-Array erstellt und an den richtigen Eingang von "in Tabellenkalkulationsdatei schreiben" gehängt. Jetzt sieht es in der Datei halbwegs formatiert aus Im Anhang nochmal das aktuellste VI. Ich danke euch schon mal für eure Hilfe, wie auch die letzten zwei Tage habt ihr mich heute ein gutes Stück vorwärts gebracht und ich weiß es sehr zu schätzen, dass ihr eure Zeit für so was opfert.

@Gerd: ich schätze mal, die ganzen hab ich verdient Ich wünsch euch einen schönen Nachmittag und bis morgen hoffentlich!

Liebe Grüße,

Franzie

Zum Millisekunden Timer: für Langzeitversuche nimmt man den auch nicht zur Bestimmung der Laufzeit, dafür gibt es Datum und Uhrzeit des PC.

Und gönn dir morgen (= WE ) eine Pause.

Gruß, Jens

Hallo Franzie,

Zitat:ich befürchte an dieser Stelle werde ich noch Probleme bekommen.

Es gibt ja noch mehr Funktionen in der Zeit-Palette, da sind auch welche dabei, die dieses Problem nicht haben…

Außerdem: Wenn du DAQmxRead richtig konfigurierst, brauchst du das FromDDT danach nicht mehr…

Zitat:bis morgen hoffentlich

Morgen ist Wochenende…

Hallo zusammen!
Eigentlich wollte ich mich heute nochmal mit den DAQmx-Tasks beschäftigen aber ich komme gerade gar nicht dazu - Wochenende hält mich ja nicht davon ab, trotzdem was zu lernen Tut mir leid, das war heute wohl nix!

Liebe Grüße,
Franzie

Anzeige

Guten Morgen allerseits!

Nochmal wegen der Überlauf- und Timer-Geschichte: ich habe einen Foren-Beitrag gefunden, in dem behauptet wird, das Express-VI "Verstrichene Zeit" wäre in Ordnung? Hier zur Erinnerung der Link: http://www.labviewforum.de/showthread.php?tid=2910

Grüße,

Franzie

Hallo Franzie,

ja, das könntest du benutzen.
Aber warum nicht einfach dein "Timerwert (ms)" gegen das schon explizit erwähnte "Datum/Zeit in Sekunden" austauschen?

...

Bei meinem "in Textdatei schreiben" erstellt es ja ein Dokument in das in einer Spalte meine Messwerte eingetragen werden. Jetzt ist es aber bei LabVIEW doch so, dass Arrays prinzipiell den ersten Index als Zeile und den zweiten als Spalte sehen. In meine Messwertdatei wird alles in eine Spalte geschrieben, das ist ja auch so gewollt, aber wieso geht das ohne dass ich den Array transponieren muss?

Ich zerbreche mir gerade auch den Kopf darüber, wie ich das, was ich jetzt für den 11. Kanal gemacht habe, für die anderen 10 Kanäle hinbekommen soll. Ich könnte das natürlich kopieren und verzehnfachen, aber dadurch wird das Programm ziemlich unübersichtlich... Für die ersten 10 Kanäle sollen ja auch Mittelwerte gemessen werden mit denselben Bedingungen, ich habe schon mal eine Textdatei angelegt und die Spalten beschriftet, weitergekommen bin ich aber noch nicht wirklich.

Hallo Franzie,

Zitat:Ich zerbreche mir gerade auch den Kopf darüber, wie ich das, was ich jetzt für den 11. Kanal gemacht habe, für die anderen 10 Kanäle hinbekommen soll.

Aha.

Zitat:Ich könnte das natürlich kopieren und verzehnfachen, aber dadurch wird das Programm ziemlich unübersichtlich.

Richtig. Deshalb nimmt man eine andere Lösung:

1) Die einfach pragmatische Lösung lautet: frage per DAQmxRead genau die Anzahl Samples ab, die du mitteln willst. Dann einfach einen Mittelwert pro Kanal berechnen und Speichern. Nachteil: Die Messwertanzeige aktualisiert sich eben auch nur jede Minute einmal.

2) Die (für den User) angenehmere Lösung hast du jetzt für Kanal 11 vorliegen: geringere Sampleanzahl abfragen und darstellen und dafür die für den Mittelwert nötige Sampleanzahl in einem Array sammeln. Nur musst du das eben für 2D-Arrays erweitern: Dein DAQmxRead liefert die Daten im 2D-Array und das musst du passend an die bestehenden Daten anhängen. Probiere das einfach mal mit einem kleinen TestVI aus, um ein Gefühl für den Umgang mit 2D-Arrays zu bekommen!

Bei Lösung 1 und 2 hast du dann nur eine kleine Schleife, die für jeden Kanal (=Zeile) den Mittelwert/min/Max berechnet…
Und nein: es ist nicht sinnvoll, innerhalb eines VIs Daten per Datei schreiben/lesen weiterzureichen!