Hi Gerd,
Zitat:- wenn du kontinuierlich lesen willst, musst du nur ganz ganz selten wirklich die Buffergröße über "Samples to read" am DAQmxCreateChannel festlegen. Das macht DAQmx schon selbst ganz gut.
hab ich versucht, allerdings läuft mein VI dann nicht. Mit Buffer gehts. Sollte ja keine großen Nachteile bringen wen ich den Buffer vorgebe ?
Zitat:- wenn du Daten lesen willst, dann hat es sich bewährt, feste Blockgrößen abzufragen - und nicht wie du "aufwendige" QR-Rechnungen in Statemachines durchzuführen. Einfach Blöcke mit 40k Samples abfragen und gut ist!
jup, gemacht.
Zitat:- Diese Blöcke dann in einer Producer-Consumer-Struktur an eine zweite Schleife zur Berechnung weiterrreichen.
- Notfalls Queue-Größe überwachen und (falls deine Rechnung nicht hinterherkommt) überzählige Blöcke verwerfen…
Producer-Consumer sagt mir nur im Zusammenhang mit Message Queue was. Ich hab die Berechnung jetzt in ne andere Schleife gepackt. Ist es das was du meintest? Funktioniert auf jedenfall jetzt noch besser wenn ich das so mache.
Zitat:Du kannst alternativ auch dein Drucksignal zwischen den Pulsen interpolieren. Ist erheblich weniger Rechenaufwand und funktioniert auch mit jedem Drehgeber!
Wir verwenden an unserem Prüfstand einen Geber mit 360Pulsen/Umdr. Meine Software interpoliert von diesen 1°KW auf <0.1°KW…
Jap ist sicherlich auch eine gute Lösung. Das Problem dabei ist aber, wenn beispielsweise das Druckmaximum zwischen 2 Flanken liegt dann wird da einfach drüber interpoliert und ich bekomme keine Aussage darüber wie Hoch das wirklich Druckmaximum ist. Wenn ich den Druckverlauf zeitbasiert messe bekomme ich ein sehr genaues Abbild und nehme dafür nur eine gewisse unschärfe im Drehzahl- bzw Winkelverlauf zwischen 2 Flanken hin. Habs versucht mal kurz in nem Bild zu visualisieren. Rote Kurve ist der interpolierte Verlauf.
Sorry ich nehms zurück. So funkionier das VI nich mit der zweiten While-Schleife. Meinst du das hier mit Producer-Consumer ?
http://www.ni.com/white-paper/3023/en/ Ich seh den Zusammenhang nicht ganz.
Hallo jrraid,
Zitat:Meinst du das hier mit Producer-Consumer ?
Ja.
Zitat:Ich seh den Zusammenhang nicht ganz.
Ein ProducerConsumerPattern trennt zwei ansonsten starr gekoppelte Routinen, indem ein Puffer zwischen ihnen eingebaut wird - die Queue. Beide Routinen können dadurch so schnell wie möglich laufen, ohne sich gegenseitig auszubremsen.
Über die Queue bekommt man auch eine Kontrolle über die Fälle, wenn der Consumer anfängt, hinterher zu hinken. Man kann dann in das Queuemanagement eingreifen und selbst überzählige Datenpakete weglöschen. Oder auch einen zweiten Consumer zur Entlastung starten. Oder...
Ganz allgemein:
Du hast vor, eine recht rechenintensive Routine mit schon anspruchsvoller Messwerterfassung (3 AI-Kanäle á 1MS/s plus ebenso schnelle DI-Kanäle) zu koppeln. Dazu gehört auch ein entsprechend vorbereitetes Software-Konstrukt - das man nicht mal eben aus dem Handgelenk schüttelt. Da sollte man sich vorher überlegen, was man braucht, wie man es aufbaut und wie man leistungsfähige Software schreibt. Das ist in LabVIEW nicht anders als in anderen Programmiersprachen!
Hey Gerd,
das mit dem Queue werd ich auf jeden Fall mal versuchen, denn momentan ist mein Problem, dass ich zu schnell Daten generiere, als dass ich sie auch verarbeiten könnte. Mir läuft mein Buffer immer voll.
Zitat:Man kann dann in das Queuemanagement eingreifen und selbst überzählige Datenpakete weglöschen
Das will ich auf jeden Fall vermeiden. Es sollen keine Messdaten gelöscht werden und zwar aus dem Grund, dass man eventuelles Klopfen verpasst.
Zitat:Du hast vor, eine recht rechenintensive Routine mit schon anspruchsvoller Messwerterfassung (3 AI-Kanäle á 1MS/s plus ebenso schnelle DI-Kanäle) zu koppeln. Dazu gehört auch ein entsprechend vorbereitetes Software-Konstrukt - das man nicht mal eben aus dem Handgelenk schüttelt. Da sollte man sich vorher überlegen, was man braucht, wie man es aufbaut und wie man leistungsfähige Software schreibt. Das ist in LabVIEW nicht anders als in anderen Programmiersprachen!
Auch da geb ich dir mehr als Recht. Das dumme ist nur, ich bekomme von der Uni ne Aufgabenstellung und die muss ich innerhalb von 6 Monaten umgesetzt haben und dann noch eine 100Seitige Arbeit darüber schreiben. Labview Kurse und so bekommt man naürlich nicht
, deshalb ist so ein Forum hier für mich Gold wert. Danke nochmal für deine Hilfe
Hab das Ganze jetzt mit nem Queue programmiert. Problem ist jetzt, dass meine Queue voll läuft. Hab ich jetzt nicht einfach nur den Teufel mit dem Belzebub ausgetrieben ? Anstatt dass mein Buffer voll läuft tut das halt jetzt der Queue. Es bleibt das Problem, dass die Berechnung in der For Schleife zu langsam ist ? Mir bleibt jetzt also nur übrig mir eine schnellere Rechenoperation für die Schleife zu überlegen oder?
Hallo jrraid,
Zitat: Problem ist jetzt, dass meine Queue voll läuft. Hab ich jetzt nicht einfach nur den Teufel mit dem Belzebub ausgetrieben ?
Jein.
Du kannst z.B. nun einfach die Daten in der Queue auf die Festplatte wegspeichern (was ja relativ schnell geht) und nur jeden 10. Datenblock für die Anzeige durchrechnen lassen. Hinterher nimmt man die gepsiecherten Daten und analysiert sie vollständig - aber eben nicht mehr in "Echtzeit"…
Du kannst auch die Rechenroutine verbessern und schauen, ob du den Algorithmus deutlich schneller bekommst.
Du kannst auch mehrere Rechenroutinen parallel arbeiten lassen - wenn du einen MultiCore-Rechner nutzt.
Oder du kannst überlegen, ob es nicht einfacher ist, für diese Messung einfach einen Drehgeber mit 3600Pulsen/Umdr vorzuschreiben…
Zitat:Du kannst auch die Rechenroutine verbessern und schauen, ob du den Algorithmus deutlich schneller bekommst.
Daran arbeite ich gerade. Leider auch ohne wirkliches Wissen. Kannst du mir sagen obs dazu nen Whitepaper oder so was von NI gibt? Hab nichts gefunden.
Zitat:Oder du kannst überlegen, ob es nicht einfacher ist, für diese Messung einfach einen Drehgeber mit 3600Pulsen/Umdr vorzuschreiben…
Ist leider Vorgabe der Aufgabenstellung, dass das ganze unabhängig vom Inkrementalgeber funktionieren muss.