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 habe schon gesehen, dass es mehrere Threads zu dem Thema mit meinem Fehler gibt. Allerdings habe ich da keine passende Antwort gefunden bzw. manche Antworten auch schlicht weg nicht verstanden, da ich mehr oder weniger blutiger LabView Anfänger bin.
Also ich beschreibe Vorweg mal mein Messzenario:
1.) Ein Auto ist mit diversen Sensoren verkabelt (9xTemperatur, 3xBeschleunigung, 2xPotentiometer und 4xDehnungsmessstreifen)
2.) Die Daten werden während der Fahrt mit einem NI6210 und NI9237(für die DMS) und einem Laptop verarbeitet.
3.) Das ganze ist keine Spazierfahrt, es treten Kräfte bis 1-2g in ziemlich alle Richtungen auf und es gibt ständig Erschütterungen etc.
4.) Die Daten sollen eigentlich nur ausgelesen werden, in die entsprechenden Einheiten skaliert werden, angezeigt werden und anschließend gespeichert werden.
Da meine Festplatte bei Erschütterungen anscheinend aussteigt werden die Daten auf eine SD Karte gespeichert.
So nun zum Fehler: Dieser ist nicht unbedingt reproduzierbar und tritt eher sporadisch auf. Mal direkt nach dem Start des Speichervorgangs (welcher durch einen Button aktiviert wird) mal dauert es aber auch mehrere Minuten bis es zum Fehler kommt. Manchmal tritt der Fehler auch gar nicht auf und alles läuft wie es soll.
Ich bin dankbar für jegliche Tipps zu meinem VI vor allem in Bezug auf den DaqAssi (ich weiß das, dass nicht die eleganteste art ist, weiß aber auch nicht recht wie man es richtig macht) und natürlich auch zur Problemlösung.
Dazu habe ich schon eine Theorie: Ich vermute, dass das schreiben mit zunehmender Fülle auf der SD Karte immer schwieriger / langsamer wird und es eben so sein kann das der Puffer überläuft, weil die Daten nicht schnell genug geschrieben werden können.
Angehängt habe ich sowohl ein Bild meines VI's, eines des Fehlers und das VI selber. Ich benutze im übrigens Labview2011.
hast du schon mal versucht, das Ganze ohne ExpressVIs/DDT zu programmieren?
Einfach nur die "normalen" DAQmx-Funktionen zu nutzen? Und dann gleich die Skalierungen von DAQmx übernehmen zu lassen?
Du wirst sehen, dass das wesentlich einfacher wird als dein Drahtverhau!
Du brauchst dann nämlich nur noch eine einzige DAQmxRead-Funktion. Und bei entsprechend eingestelltem Sampling wirst du auch keine Messwerte mehr verlieren - was man durch Nutzung eines Producer-Consumer-Schemas noch "erzwingen" könnte...
Genau solche Antworten habe ich befürchtet. Ich habe schon geahnt das diese Lösung eigentlich zu einfach ist für ein stabiles Programm hehe.
Erstmal zur Begriffsklärung was ist mit DDT gemeint? Und was ist das Producer-Consumer-Schema?
Ich habe schon versucht statt der DAQAssi die "normalen" Funktionen zu nehmen aber irgendwie habe ich das nicht richtig geblickt und in den Beispielen sind oft nen riesen Haufen Schleifen und Fehlerbehandlungen und was weiß ich noch alles - was ich auf jedenfall nicht brauche.
GerdW es geht wirklich von zwei Geräten die Daten mit einer ReadFunktion zu lesen?
Könnte mir evtl. mal einer ein Beispiel zu meinem Programm geben also wie genau ich in meinem Fall die "normalen" DAQ Funktionen einsetzte ohne unnötigen Schnick Schnack möglichst schlank. Statt irgendwelchen aufwändigen Skalierungen reicht auf einfach ein Faktor 5*x oder so es geht ja nur darum das ich verstehe wie der Hase eigentlich laufen soll. Hier zuhause habe ich übrigens nur LabVIEW 8.5
(14.07.2012 13:08 )OBI schrieb: Genau solche Antworten habe ich befürchtet. Ich habe schon geahnt das diese Lösung eigentlich zu einfach ist für ein stabiles Programm hehe.
Erstmal zur Begriffsklärung was ist mit DDT gemeint?
DDT = Dynamic Data Type. Ein ziemlich aufgeblähtes Datenformat, das zwecks Express-VIs und DAQ-Assi in LabVIEW eingeführt wurde. Leider so aufgebläht, dass "sinnvolles" Programmieren damit nicht möglich ist.
(14.07.2012 13:08 )OBI schrieb: Und was ist das Producer-Consumer-Schema?
Das ist ein Programmier-Konzept. Die Basis-Struktur kannst du dir in LabVIEW anschauen, unter File->New..., dann unter Frameworks->Design Patterns.
(14.07.2012 13:08 )OBI schrieb: Ich habe schon versucht statt der DAQAssi die "normalen" Funktionen zu nehmen aber irgendwie habe ich das nicht richtig geblickt und in den Beispielen sind oft nen riesen Haufen Schleifen und Fehlerbehandlungen und was weiß ich noch alles - was ich auf jedenfall nicht brauche.
(14.07.2012 13:08 )OBI schrieb: GerdW es geht wirklich von zwei Geräten die Daten mit einer ReadFunktion zu lesen?
Jein, das hängt von den Geräten ab. Je nach Typ kann man sie synchronisieren. Ich schätze, in deinem Fall geht es nicht, du brauchst 2 DAQmx-Read. Aber auch das geht.
(14.07.2012 13:08 )OBI schrieb: Könnte mir evtl. mal einer ein Beispiel zu meinem Programm geben also wie genau ich in meinem Fall die "normalen" DAQ Funktionen einsetzte ohne unnötigen Schnick Schnack möglichst schlank. Statt irgendwelchen aufwändigen Skalierungen reicht auf einfach ein Faktor 5*x oder so es geht ja nur darum das ich verstehe wie der Hase eigentlich laufen soll. Hier zuhause habe ich übrigens nur LabVIEW 8.5
Gruß, OBI
s. oben, NI Example Finder...
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!
Zitat:Fehlerbehandlungen und was weiß ich noch alles - was ich auf jedenfall nicht brauche.
Wenn du das wirklich so siehst, bräuchtest du hier nicht fragen. So aber sagen dir schon 2 Leute, wie es besser geht...
Klickibunti-ExpressVI hat seine Daseinsberechtigung und ist (manchmal) auch sinnvoll - aber ein dauerhafter Betrieb eines VIs erfordert doch etwas mehr als "nur" mal schnell was zu konfigurieren!
Okay ihr habt mir zur Einsicht gebracht. Bis jetzt habe ich immer nur ein bissel mit C, Java und Matlab Programmiert. Da ging es mir immer um schnelle Ergebnisse und Fehlerbehandlung stand ganz am Ende wenn überhaupt.
Aber okay ich versuche mal ein VI richtig aufzubauen mit allem drum und dran.
(14.07.2012 13:35 )jg schrieb:
(14.07.2012 13:08 )OBI schrieb: GerdW es geht wirklich von zwei Geräten die Daten mit einer ReadFunktion zu lesen?
Jein, das hängt von den Geräten ab. Je nach Typ kann man sie synchronisieren. Ich schätze, in deinem Fall geht es nicht, du brauchst 2 DAQmx-Read. Aber auch das geht.
Aber eine Frage hab ich dazu denn doch noch und zwar meine beiden Geräte sind ja ein NI6210 und ein NI9237. Wie bekomme ich die beiden dann synchron kann ich einfach zwei DAQ Stränge aufbauen und die jeweiligen DAQReads in eine Schleife packen? Oder müssen dafür zwei Schleifen herhalten?
Gruß
14.07.2012, 14:20 (Dieser Beitrag wurde zuletzt bearbeitet: 14.07.2012 14:22 von GerdW.)
Zitat:meine beiden Geräte sind ja ein NI6210 und ein NI9237
Das 9237 ist kein Gerät, sondern ein Modul. Und wo steckt es drin?
Zitat:Wie bekomme ich die beiden dann synchron kann ich einfach zwei DAQ Stränge aufbauen und die jeweiligen DAQReads in eine Schleife packen? Oder müssen dafür zwei Schleifen herhalten?
Wie synchron brauchst du sie denn? Bisher bist du ja dank ExpressVI auch ohne Synchronisierung ausgekommen...
Wie schnell willst du die diversen Signal aufnehmen? All das muss man zur Beantwortung deiner Fragen wissen...
Zitat:es gibt ständig Erschütterungen
Man könnte das Laptop ja vor den Erschütterungen schützen. Bisher ist mir noch kein Laptop im Auto/LKW "ausgestiegen", selbst mit 2 USB-Boxen, wackligem RS232-Stecker und nervösem Bediener...
Okay wieder eine Feinheit die ich übersehen hab hehe. Also das 9237 Modul steckt in einen cDAQ9171 USB Chassis.
Naja zum Thema Synchronität habe ich mir noch keine genauen Gedanken gemacht. So synchron wie möglich würde ich mal sagen. Ich habe keine Ahnung was da so möglich ist. Zeit gleich die Daten von beiden Geräten lesen wird ja vermutlich nicht gehen oder?
Es ist eben so, dass ich in meiner Anwendungen schon die Werte der Dehnungsmessstreifen vom 9237 mit den Werten des 6210 vergleichen möchte. Also z.B. war bei einem Fahrmanöver erst eine Beschleunigung an einem Bauteil und stellte sich darauf hin eine Dehnung ein oder wurde die Beschleunigung durch eine Dehnung hervorgerufen oder war beides gleichzeitig?!
Da wir aber eh erst am Anfang unserer Entwicklung stehen muss das ganze jetzt nicht auf Biegen und Brechen auf eine µs synchron sein.
Es muss eben ein gutes Verhältnis zwischen Programmieraufwand und Synchronität sein. Für unsere jetzigen Untersuchungen reicht eine Abtastrate von 2kHz aber im späteren Verlauf wird es auch Fälle geben wo ich gerne auf eine Rate von 50kHz gehen würde.
Zum letzten Punkt mit den Erschütterungen kann ich sagen, dass der Laptop bei mir aufm Schoß liegt und ich die Fahrt direkt überwache. Man kann das ganze zwar etwas polstern aber es muss eben sehr flexibel bleiben. Mit aussteigen des Laptops meine ich auch, dass sich die Festplatte zum eigenen Schutze bei zu hohen Stößen abschaltet und so natürlich jeglicher Schreibvorgang unterbrochen wird. Deshalb sind wir eben zu SD Karten bzw. USB Sticks übergegenagen.
