Liebe Forumsmitglieder
Ich suche nun seit geraumer Zeit nach einer Lösung zu meinem Problem, doch leider ohne Erfolg.
Zu meinem Vorhaben
1. ich lese Werte von 10 Kraftsensoren mit dem Device NI-USB 6212 ein.
2. Bevor ich mit dem eigentlichen Task starte, würde ich gerne in Echtzeitgraphen überprüfen, ob alle Sensoren richtig funktionieren.
3. Ich hätte gerne einen Startknopf, der dann die eigentliche Datenerfassung mit anschliessender Speicherung startet.
4. Mit drücken des Startknopfes soll gleichzeitig eine externe LED, die über einen digitalen Ausgang an der NI-USB 6212 angeschlossen ist, aufleuchten (dies brauche ich, da die neben der Kraftmessung auch eine Bewegungsanalyse mit Videos aufgezeichnet wird).
5. Durch einen Stop-Knopf soll die Messung und das leuchten der LED beendet werden.
Ich habe das Programm, das ich bis anhin programmiert habe, angefügt.
Ich wäre um jeden Tipp dankbar, wie ich mein Vorhab realisieren kann und bedanke mich schon einmal für eure Hilfe.
Gruß, Nusser
Hallo Nusser,
Zitat:Ich wäre um jeden Tipp dankbar, wie ich mein Vorhab realisieren kann
- Auto-Cleanup…
- gleichmäßige Fontgrößen im BD erhöhen die Übersicht…
- statt SignalSplitten einfach mal IndexArray nutzen…
- statt des riesigen ConcatString ein übersichtliches FormatIntoString (und alle Stringkonstanten dann schon im Formatstring enthalten!)…
Punkt 2-5 gehört in eine Statemachine. LabVIEW kommt mit einem entsprechenden Beispiel-Projekt…
Hi GerdW
Vielen Dank für die nützlichen Tipps.
Ich versuche diese umzusetzen.
Gruß
Servus
Dem Rat von GerdW folgend habe ich meine erste Statemachine erstellt. Der Ausdruck gebastelt würde es zwar wohl eher treffen. Ich bin hierbei nach Beispielen vorgegangen, die im Netzt zu finden sind.
Kurz zur Erklärung der Statemaschine:
1. Schritt: Erstellen des Haeder
2. Schritt: Kontrolle der Signale (Hier nutze ich eine Ereignisstruktur)
3. Schritt: Erfassung und Speicherung der Signale (Hier nutze ich eine Ereignisstruktur)
4. Schritt: Ende des Messprogrammes
Leider funktioniert bis jetzt nur der 1. und 4 Schritt einwandfrei. Bei den anderen habe ich folgende Probleme:
Schritt 2:
Die Signale im Graphen werden nicht kontinuierlich dargestellt, sondern nur sprunghaft. Ich denke, die Ursache liegt in den vielen Schleifen. Wenn nämlich nur eine While-Schleife verwendet wird, werden die Signale im Graphen kontinuierlich dargestellt.
=> Wie kann ich dieses Problem beheben?
=> Gäbe es eine bessere Möglichkeit, als mit Ereignisstrukturen zu arbeiten?
Schritt 3:
Gleiches Problem wie Schritt 2. Ferner braucht das Programm ziemlich lange, bis es auf die Stop - Kommandos reagiert. Woher kommt das?
Desweiteren kommt manchmal die Meldung, dass Daten nicht mehr zuf Verfügung stehen und überschrieben werden.
=> Wäre es besser, wenn man die Daten zunächst alles sammeln würde und zum Schluss erst übergeben? Wenn ja, wie sieht so etwas programmtechnisch aus?
Ich hoffe, dass hier jemand einen konstruktiven Rat weiß und möchte euch bitten auf sarkastische und ironische Kommentare zu verzichten. Ich bin ein LabView - Neuling und brauche das Programm lediglich für die Datenerfassung der Versuche meiner Diss und danach hoffentlich nicht so bald wieder....
Ich bedanke mich schon einmal im Voraus für Eure Hifle.
LG, Nusser
Hallo Nusser,
endlich mal wieder ein VI von dir!
Ich habe gleich mal noch am Header rum-editiert. Schau dir den Formatstring auch mal im "\-Code"-Anzeigemodus an!
Zitat:Die Signale im Graphen werden nicht kontinuierlich dargestellt, sondern nur sprunghaft. Ich denke, die Ursache liegt in den vielen Schleifen.
Falsch gedenkt.
Das Problem ist, dass du dauernd die DAQmx-Task erstellst und wieder löschst! Sowas macht man nicht in einer Schleife…
Schau dir die DAQmx-BeispielVIs an: die zeigen, wie es richtig geht…
Zitat:Gäbe es eine bessere Möglichkeit, als mit Ereignisstrukturen zu arbeiten?
Noch besser? Die Eventstruktur ist schon die beste Möglichkeit, auf User-Events zu reagieren.
Leider aber nicht so, wie du das programmiert hast! Länger laufende Schleifen (wie deine DAQmx-Loops) gehören nicht in eine Event-Struktur hinein…
Da du sowieso schon Wartezeiten in deinen Schleifen hast (aufgrund der DAQmxRead-Zugriffe) würde ich dir hier einfaches Polling der Buttons empfehlen - wie in den DAQmx-BeispielVIs auch sehr häufig gezeigt wird.
Zitat:Ferner braucht das Programm ziemlich lange, bis es auf die Stop - Kommandos reagiert. Woher kommt das?
THINK DATAFLOW!
Ein Stop-Event kann erst bearbeitet werden, wenn das andere Event fertig ist…
Zitat:möchte euch bitten auf sarkastische und ironische Kommentare zu verzichten.
Ich habe mir Mühe gegeben!
Hallo GerdW
"endlich mal wieder ein VI von dir!"
Nett von mir gell, und dann glei eines, mit so vielen Sachen zu verbessern.....
Vielen Dank für die schnelle Rückmeldung und den verbesserten Haeder.
Hast Du vielleicht gleich ein Beispiel zur Hand, wie man diese Polling der Buttons richtig macht?
LG, Nusser
Hallo nusser,
im Case "Datenaufnahme und -speicherung" im "Start Datenerfassung"-Event liegt eine While-Loop.
Diese Loop wird durch den Stop6-Button beendet. Dieser Button wird durch Polling (d.h. wiederholtes Abfragen) ausgewertet…
Das bedeutet:
Dein Stop6-Event ist eigentlich Blödsinn, da der Button ja schon während der Messung und damit im Start-Event ausgewertet wird.
Ich würde dir sowas in der Art (ganz ohne Eventstruktur) empfehlen:
[
attachment=48512]
Die erste Schleife wartet nur auf den Start-Button, danach geht es mit der Messschleife weiter…
Hi Gerd
Merci für den Hinweis.
Dann mach ich mich ans Werk
=> die nächste Frage kommt bestimmt bald
Hi Gerd
Hab versucht, deinen Vorschlag umzusetzten (siehe Anhang).
Also entweder ich habe dich wieder einmal falsch verstanden oder es ist noch nicht die richtige Lösung zu meinem Problem.
Die eine Schleife startet zwar nur auf den Befel " Start" was ja schon einmal gut ist, aber auf dem Graph erscheinen die Daten trotzdem nicht sofort. Das Problem, dass die Fehlermeldung kommt, dass Daten nicht mehr zu verfügung stehn, etc kommt immer noch
.
Hallo Nusser,
THINK DATAFLOW!
Du startest den DAQmx-Task schon bevor du den Start-Button drückst. Das ist wohl eher ungünstig…