LabVIEWForum.de - Druckmessung über Multiplexer (NI9237 + NI9472)

LabVIEWForum.de

Normale Version: Druckmessung über Multiplexer (NI9237 + NI9472)
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo Liebes Forum!

Ich bin derzeit bei meiner Diplomarbeit und dabei auf ein, für mich nicht lösbares, Problem gestoßen.
Bei der DA handelt es sich um eine mehrkanalige (bis zu 32 Kanäle) Druckmessung in einem microfluidischen System über mindestens 12h. Da ich nur eine NI9237 Datenerfassungskarte zur Verfügung habe, habe ich das ganze über 4 parallele ADG407 8-Kanal Multiplexer gelöst. Nicht ideal, aber finanziell sind keine 7 zusätzliche Messmodule möglich.

Die Programmierung war gedanklich eigentlich kein großes Problem, jedoch traten bei der Ausführung diverse Probleme auf:
Ich versuchte es zuerst über die Erfassung einer endlichen Anzahl von Werten um ein Auslesen alter Messwerte nach dem Umschalten der MUX zu verhindern. Dies funktionierte leider nicht in einer zufriedenstellenden Geschwindigkeit. Ich erreichte bei 100 Samples mit 50kHz abgetastet lediglich rund 1Hz Abtastfrequenz was für meine Anwendung zu gering ist.
Komischerweise zeigte auch ein Test-VI welches nur die Datenerfassung ohne den ganzen Overhead mit MUX-Steuerung etc. enthielt keine bessere Performance.

Als zwischenzeitliche Performance-Lösung bin ich auf kontinuierliche Erfassung umgestiegen. Damit erreiche ich Abtastfrequenzen von ca. 7Hz pro Kanal (ausreichend für mich, jedoch auch gerne höher). Jedoch erhalte ich je nach Einstellung von Abtastrate der Messkarte und Anzahl der Samples früher oder später den Fehler, dass auf Samples zugegriffen wird welche nicht mehr zur Verfügung stehen. Ebenso werden je nach VI-Abtastrate (im Frontpanel eingestellt) und Anzahl der Kanäle die Messwerte in meinem Array um meist 4 Elemente verschoben (Kanal 1-4 an der Position von 5-8 und so weiter, 28-32 auf 1-4). Diese Verschiebungen hängen zusätzlich auch noch von der DAQ Abtastrate sowie der Sample-Anzahl ab. Habe es als Übergangslösung per Fallunterscheidung "gelöst". Damit ich keine Messwerte anderer Sensoren einlese habe ich dann vor der eigentlichen Datenerfassung ein DAQ-Read eingebaut um den Puffer zu leeren.

Alles in allem mehr als eingenartig...

Auch vollständiges Neuprogrammieren (sowohl Sequenzen als auch State-Machine) anstatt der Fehlersuche blieben ohne Erfolg. Ebenso die Fehlersuche im Internet/Forum. Da ich langsam Betriebsblind werde hoffe ich auf Input von Außen.

Anhang:
VI mit endliche Erfassung (keine Fallunterscheidung) sowie die dazugehörigen Sub-VIs im ZIP-File.
VI mit kontinuierlicher Erfassung und Fallunterscheidung direkt als VI.

Verwendete Umgebung/Hardware:
Windows 7 64bit
LabView 2013 SP1 32bit
NI 9237 4-Kanal Brücken-Input Modul
NI 9472 8-Kanal Digital-Output Modul
NI cDaq 9172 Chassis
Analog Devices ADG407 Multiplexer

Vielen Dank und LG
Jürgen
Hallo Jürgen,

einige Dinge, die mir in deinem VI auffallen:
- eine gestapelte Sequenz mittendrin: damit erreicht man nur selten wirklich "schöne" Programme
- du verwendest die Sequenz, um DATAFLOW zu erreichen: warum nicht den ErrorCluster, wie er überall empfohlen wird?
- du fragst beim AI-Task "-1" Samples ab: das ist NIE hilfreich, wenn man irgendwie synchrone Messungen erreichen will…
- du erzeugst eine "Abtastrate" über eine Wartezeit. Abgesehen davon, dass diese Wartezeit nur Integerwerte unterstützt, ist sie auch extrem ungenau, da Windows für einen erheblichen Jitter sorgt. Warum nicht eine Abtastrate über DAQmx einstellen?
- nachdem du die "Abtastrate" per Wartezeit eingestellt hast, wartest du im nächsten Frame erneut 5ms (mitsamt Jitter). Ist das hilfreich?
- Du hast im AI-Task eine Samplerate von 10kHz eingestellt und fummelst am Parameter "Sample pro Kanal" rum. Hast du dir die Hilfe zur Funktion durchgelesen? Dann leerst du den Buffer in der Schleife mittels der Abfrage von "-1" Samples, um dann nur zwei Samples abzufragen. Dann braucht die Schleife wieder "ewig" (x ms und weitere 5ms), bevor wieder Samples gelesen werden. Da kann es schon zu einem BufferOverflow-Fehler kommen!
- Du hast RaceConditions in deinem VI, da du lieber lokale Variablen/ProeprtyNodes statt einfacher Drähte verwendest ("Schaltzyklen", "Kanäle")…

Was ich machen würde:
- Den AI-Task mit hoher Abtastrate (ca. 10fach höher als die Samplerate im DO-Task) in einer parallelen Schleife laufen lassen, die Messdaten in einem Buffer speichern
- den DO-Task parallel dazu schalten lassen und den aktuellen Schaltzustand ebenfalls im Buffer vermerken
- in einer dritten Schleife jeweils die zusammengehörigen Daten aus dem Buffer lesen und auswerten

Anderes Konzept:
Prüfen, ob deine Hardware mit (DAQmx-)Triggern arbeiten kann. Falls ja: über einen Trigger jeweils einen neuen Wert im DO ausgeben und die Messwertaufnahme mit endlicher Anzahl im AI starten. Messwerte lesen, auswerten, neuen Trigger setzen…

Tipps:
- Eine AND-Funktion mit je einem NOT an jedem Eingang und Ausgang ist hochgradig RubeGoldberg, dafür gibt es einmal die CompoundArithmetik und grundlegende boolsche Algebra sollte dir sagen, dass das eine OR-Funktion ergibt ( -(-x AND -y) == x OR y )…
Hallo Gerd,

Danke für die schnelle Antwort!

- gestapelte Sequenz: du hast vollkommen recht, war geplant sobald die Funktion vollständig gegeben ist umzubauen
- Error-Cluster: Habe ich noch nie verwendet um Dataflow zu erzeugen. Muss ich mir Infos holen. Kurz zum testen: Über die Reihenfolge der DAQ-VIs am Error-Cluster die Reihenfolge herstellen?
- AI-Samples -1: War als Notlösung implementiert nachdem die anderen Varianten nicht funktioniert haben. Soll natürlich verschwinden
- Abtastrate: Edit: Hat sich erledigt, manchmal übersieht man das offensichtlichste. (Da stehe ich leider auf dem Schlauch was du mit Einstellen über DAQmx meinst. Wie kann ich da drüber die Abtastrate einstellen?)
- Abtastrate #2: War ein Hinweis von einem NI-Mitarbeiter
- AI-Task: Ich habe an den Samples pro Kanal rumprobiert da ich ansonsten wieder das eigenwillige Probleme mit meinen Messwertverschiebungen hatte. Ok, ich hatte den Fehler nicht als Buffer-Overflow identifiziert.
- RaceConditions: Habe ich nicht bedacht. Ich habe es so übersichtlicher gefunden, wird aber nun auch geändert.


Infos von dir:
- Also die bestehende For-Schleife entfernen und durch zwei parallele Schleifen ersetzen.
- Ich habe also in meiner Case-Struktur 3 Schleifen: AI, DO sowie Daten-auswerten.

Trigger: Sehe ich mir an ob dies möglich ist.

AND-Funktion: So weit hat es an diesem Entstehungsabend nicht mehr gereicht. Soll, da Notlösung, natürlich auch nicht in die finale Version kommen.

LG
Jürgen
Referenz-URLs