zwei unterschiedliche Datenraten / Abbruch bei äußerem Ereignis

Hallo,

Datenerfassung mit einer mx Karte aber mit 2 unterschiedlichen Datenraten. Kann ich da einfach 2 timed-Loops mit jeweils einer unabhängigen Datenerfassung (unterschiedliche Kanäle) programmieren (oder falle ich auf die Nase)?

Im Forum habe ich auch gelesen dass die Verwendung einer lokalen Variablen zum Abbruch einer Schleife ein "Programmierfehler" ist - ähhh was sonst wenn ich nicht bestimmen kann wie lange gemessen werden soll und die Abbruchentscheidung ganz wo anders fällt?

Danke

Gottfried

Anzeige

Also paralleles Messen bei analogen Kanälen ist nicht möglich. Alle Kanäle, die du Messen willst, müssen in einem Task stecken. Wie du dann allerdings die unterschiedlichen Datenraten realisierst, weiß ich nicht. Es könnte aber sein, ich ich nächste Woche vor dem gleichen Problem stehe. Es zeichnet sich gerade ab;)Also bin ich ebenfalls sehr an der Lösung interessiert.

Zum Thema Schleifenabbruch: Zu kannst z.B. die Notifier (einfach mal in der Function Palette suchen) verwenden, das funktioniert sehr gut. Oder du nimmst ein VI mit nicht-initialisierten Schieberegistern, um eine globale Variable "zu simulieren". Das findet in meine aktuellen Projekt Anwendung und läuft auch einwandfrei.

Edit: "Programmierfehler" soll wohl nicht heißen, dass es einen logischen Fehler in deinem Programm gibt. Nur verzögerst du deine Schleife enorm duch das ständige Abfragen der Variable bei jedem Durchlauf. Selbstverständlich hängt der Einflus auch immer noch vom Schleifeninhalt ab. Wenn deine Schleife sehr rechenintensiv ist oder sowieso einen Timeout hat, dann ändert wohl die lokale Variable auch nicht mehr viel daran.

' schrieb:Zum Thema Schleifenabbruch: Zu kannst z.B. die Notifier

das ist genial - habe ich noch nicht bedacht

Danke

PS.: wie geht das mit dem "nicht initialiserten Schiebregister"?

' schrieb:das ist genial - habe ich noch nicht bedacht

Danke

PS.: wie geht das mit dem "nicht initialiserten Schiebregister"?

Das macht mich wahnsinnig. Ich weiß genau, dass wir das heute erst hier im Forum hatten, aber ich finde es nicht mehr... Habe das nämlich selbst das erste mal gesehen und gleich alle meine Globals im Projekt damit ersetzt
Wie auch immer, hab es eben selbst nochmal zusammengebaut...


  Global_IoReadStatus.vi (Größe: 8,42 KB / Downloads: 621)
(LV 8.2)

Hallo Mathias

danke - werde ich auch verwenden.

Gottfried

Hallo monoceros84

' schrieb:Alle Kanäle, die du Messen willst, müssen in einem Task stecken.

das verstehe ich inhaltlich nicht - gibt es irgendwo einen Text der das erläutert?

' schrieb:Wie du dann allerdings die unterschiedlichen Datenraten realisierst, weiß ich nicht.

Ich habe Lava & den Support auch bemüht (meine Meinung zum Support ist bestätigt worden :-) einheitliche Meinung: es geht nicht. Und meines Voters Sohn glaubt es immer noch nicht. Ich denke ich kann 2 Triggersignale generieren und damit auf 2 Kanälen unterschiedlich einlesen - die Linie ist aber auf Eis

' schrieb:Es könnte aber sein, ich ich nächste Woche vor dem gleichen Problem stehe. Es zeichnet sich gerade ab;)Also bin ich ebenfalls sehr an der Lösung interessiert.

Ich habe 2 Lösungswege gesammelt:

A.) mit der höheren Rate Alles messen und dann die überfüssigen Bits wieder Downsamplen oder vergessen - gut, aber nicht sehr intelligent

B.) ich verwende die Soundkarte als zweiten Eingang - funktioniert problemlos - das habe ich realisiert

Viele Grüße

Gottfried

Anzeige

' schrieb:Hallo monoceros84
das verstehe ich inhaltlich nicht - gibt es irgendwo einen Text der das erläutert?
Ich habe Lava & den Support auch bemüht (meine Meinung zum Support ist bestätigt worden :-) einheitliche Meinung: es geht nicht. Und meines Voters Sohn glaubt es immer noch nicht. Ich denke ich kann 2 Triggersignale generieren und damit auf 2 Kanälen unterschiedlich einlesen - die Linie ist aber auf Eis

Der Grund ist zweifach.

1) sind die meisten analogen Eingagskarten gemultiplext. D.h. es gibt nur einen AD Konverter und alle Eingänge die Du lesen willst werden nacheinander an diesen AD Konverter gelegt und gemessen. Solange das von einem Task geschieht der immer dieselben Anzahl Kanäle hat, geht das recht gut aber wenn da zwei Task einander ins Gehege zu pfuschen versuchen, bekommst Du unweigerlich Müll, und deshalb kann ein Task keinen AD Konverter benützen der von einem anderen Task schon reserviert/benützt ist.
Warum verwenden die dann nicht einen AD Konverter per Eingang? Ganz einfach, AD Konverter sind so ziemlich das teuerste Teil auf einer DAQ Karte. Karten mit einem AD Konverter per Eingang gibt es zwar aber die bekommst Du echt nicht als Low-Cost Version, nicht mal wenn deren gemessenen Werte bestenfalls als Schätzwerte klassiert werden können, da die billigsten AD Konverter verwendet wurden Du man kaufen kann.

2) Zur Erzeugung des Taktes des AD Konverters und Multipexers sind mindestens zwei Taktgeber nötig. Eine DAQ Karte hat nur eine beschränkte Anzahl von Taktgebern zur Verfügung und die können normalerweise nicht beliebig für alle möglichen Funktionen verwendet werden, da die entsprechende Routing Logik anders sehr komplex (und teuer wird). Und Programmierung davon ist eines der komplexeren Meisterstücke in der DAQ Programmierung. Indem die HArdware zur Takterzeugung einigermassen einfach gehalten wird, kann der DAQ Treiber in den meisten Fällen die Ganze Programmierung davon übernehmen. Wer schon mal versucht hat komplexere Routings von Taktsignalen selber zu programmiern (Synchronisation von analogem Eingang und Ausgang möglichst noch über mehrere Karten hinweg) weiss die automatische Taktprogrammierung von gewöhnlichen DAQmx Tasks sehr zu schätzen.

Zitat:Ich habe 2 Lösungswege gesammelt:

A.) mit der höheren Rate alles messen und dann die überfüssigen Bits wieder Downsamplen oder vergessen - gut, aber nicht sehr intelligent

So tue ich es immer. Ist am einfachsten und funktioniert sehr gut.

Zitat:B.) ich verwende die Soundkarte als zweiten Eingang - funktioniert problemlos - das habe ich realisiert

Der Soundkarteneingang ist alles ausser ein Messeingang. Er ist optimalisiert um so günstig möglich eine erträgliche Soundqualität zu ermöglichen. Als Messeingang ist er aus verschiedenen Gründen nicht geeignet:

1) AC Coupling: Messung von Gleichspannungen ist nicht möglich da Soundkarten normalerweise eine untere Grenzfrequenz von ~20Hz haben.

2) Genauigkeit: Tja diese Karten müssen billig sein. Eine typische Soundkarte kostet weniger als der AD Konverter auf einer einigermassen guten Messkarte. Die entsprechenden Messwerte sind dann auch im Vergleich eher Schätzwerte dann Messwerte. Für eine rein dynamische Messung eines Signals innerhalb des Audiobereiches 20Hz-20kHz könnte es aber manchmal reichen.

Rolf Kalbermatter

Hallo Rolf,

danke für Deine Erläuterung - nun sehe ich einigermassen klarer. Die hohe Taktrate ist von einem Geräusch - deswegen die Lösung mit der Soundkarte.

Rein begrifflich habe ich ein Problem mit "Task" - was in diesem Zusammenhang ist ein Task? Ich bin auch bei einigermassen komplexen Aufganen noch immer ohne ausgekommen.

Danke

Gottfried

Naja, wörtlich übersetzt ist "Task" eine "Aufgabe" - und mehr ist es wohl auch nicht. Ein Task enthält Informationen über Kanäle, Art der Erfassung, Trigger usw. Eben alles, was alle Kanäle betrifft. Wenn du das VI "Task erstellen" nicht explizit einbaust, sondern gleich mit "Kanal erstellen" anfängst, wird trotzdem im Hintergrund ein neuer Task gebildet. Deswegen hast du auch zwei parallele Tasks, wenn du einfach 2x das VI "Kanal erstellen" benutzt. Und das geht nicht

Tip: Erstelle mal im MAX unter Data Neighborhood einen Task und einen virtuellen Kanal. Dabei wirst du den Unterschied schnell feststellen.