Falsche Werte durch paralleles Einlesen digitaler und analoger Werte

So, nachdem ich hier schon einiges an netter Hilfe bekommen habe - nochmasl vielen Dank dafür! - wende ich mich wieder einmal an euch. Und zwar geht es immer noch um das selbe Tool wie letztes Mal, das zur universellen Messung von Analog- und Digitaleingängen mit dem USB-6009 dienen soll. Mein aktuelles Problem ist: Trotz Producer-Consumer-Schema "laggt" das Tool ab und zu bei der Anzeige, und noch viel eher wenn ich die Daten in eine Datei speichere (ich kann zwar gut damit leben, aber vielleicht liegt das ja mal wieder an einem groben Schnitzer meinerseits).

Außerdem fehlen bei der Anzeige auf einmal einige Werte im analogen Verlauf (siehe Bild im Anhang), und die digitalen (die bei der Aufnahme angezeigt wurden) fehlen ganz. In der Datei sind auch nicht so viele digitale Werte wie analoge - hier klaffen einige Lücken.

Wenn ich nur digitale Werte aufnehme, werden diese auch nicht angezeigt, aber "immerhin" sind alle Werte in der Datei vorhanden. Hoffentlich kann mir jemand von euch helfen und erklären, was ich falsch mache.

Schon einmal vielen Dank im Voraus & verzweifelte Grüße,

Alex

PS: anzeige.png ist der Teil des Tools, der alles anzeigt, messung.png zum Messen (wie die Namen auch erklären); tool.png ist ein Screenshot von der Anzeige, in der Lücken beim analogen Verlauf klaffen und die digitalen Werte ganz fehlen, und das SubVi ist zuständig für die Umwandlung des digitalen Signalverlaufs in analoge Werte, damit beides in einem Diagramm angezeigt werden kann.

PPS: Angehängtes VI ist jetzt für die 11er Version geeignet. Tut mir Leid, hatte nicht daran gedacht das so zu speichern.

Hatten wir schon mal:

(14.08.2013 16:11 )jg schrieb:  
LabVIEW 2013 ist noch nicht mal 2 Wochen auf dem Markt. Das haben hier die allerwenigsten Leute installiert.
Wäre gut, wenn du deine VIs für eine frühere Version speichert (File->Save for previous version), so kannst du mehr Hilfe erwarten.

Gruß, Jens

Hallo daxel,

1. noch mal der Hinweis: wenn du dein VI in einer älteren Version anhängst, können wesentlich mehr Leute darauf zugreifen...
2. Du gibst in der Lese/Producer-Schleife immer noch nicht vor, wieviele Samples pro Task gelesen werden sollen. Die Kontexthilfe ist da sehr eindeutig: "Bei der fortlaufenden Erfassung von Samples, liest das VI bei der Einstellung dieses Eingangs auf -1 alle Samples aus, die sich gerade im Puffer befinden." Obwohl eigentlich mit dem gleichen Taktsignal gearbeitet wird, ist nicht sichergestellt, dass ständig die exakt gleiche Anzahl Samples in beiden Task-Buffern vorrätig ist - auch wenn du das glauben magst...
3. Zuviele geknickte Drähte behindern den DATAFLOW: einfach mal aufräumen!
4. Falscher Einsatz von InsertIntoArray, wo es auch ein BuildArray tun würde...
5. Keine Fehlerauswertung in der Producerschleife...

Ich speicher's mal runter.

  WaveformDig2Ana.vi (Größe: 58,13 KB / Downloads: 232)


Gruß Markus

Erstmal sorry, habe leider nicht daran gedacht, das kompatibel zu speichern. Habe es aber jetzt als 11er-kompatibel hochgeladen. Danke an Markus, der schneller war als ich.

(20.08.2013 07:57 )GerdW schrieb:  2. Du gibst in der Lese/Producer-Schleife immer noch nicht vor, wieviele Samples pro Task gelesen werden sollen. Die Kontexthilfe ist da sehr eindeutig: "Bei der fortlaufenden Erfassung von Samples, liest das VI bei der Einstellung dieses Eingangs auf -1 alle Samples aus, die sich gerade im Puffer befinden." Obwohl eigentlich mit dem gleichen Taktsignal gearbeitet wird, ist nicht sichergestellt, dass ständig die exakt gleiche Anzahl Samples in beiden Task-Buffern vorrätig ist - auch wenn du das glauben magst...

Achso, ich dachte es reicht das vorher im Sampletakt einzustellen, da habe ich ja einfach mal als Wert 1000 drangehängt. Was wäre denn ein sinnvoller Wert, und sollte ich den dann sowohl an den Sampletakt vor der Producerschleife als auch an das Lesen innerhalb der Schleife hängen?
Und muss ich noch irgendwas ändern, damit es keine Probleme gibt, wenn ich beide Tasks gleichzeitig lese?

(20.08.2013 07:57 )GerdW schrieb:  3. Zuviele geknickte Drähte behindern den DATAFLOW: einfach mal aufräumen!

Es sah zwischenzeitlich schon schlimmer aus, ich arbeite aber noch daran

(20.08.2013 07:57 )GerdW schrieb:  4. Falscher Einsatz von InsertIntoArray, wo es auch ein BuildArray tun würde...

Ändere ich jetzt gleich mal. Ich meine zwar, ich hatte letztes mal einen Fehler dabei, weil ein 2d-Array rauskam, aber dann melde ich mich nochmal

(20.08.2013 07:57 )GerdW schrieb:  5. Keine Fehlerauswertung in der Producerschleife...

Da muss ich mir noch eine sinnvolle Fehlerbehandlung überlegen. Bisher diese ja nur für die Entwicklung.

PS: Habe mal das ganze Projekt als 11er-kompatibel angehängt. Passwort für die zip ist labviewforum.

Edit: So, habe jetzt bei den Samples pro Kanal einfach mal 10 eingestellt, das klappt schon wesentlich besser. In meiner Messdatei habe ich nirgendwo mehr leere Stellen. Nur hat er jetzt ein Problem bei der Anzeige der Digitalwerte - bei der Messung werden in größeren Abständen einzelne Punkte der Werte angezeigt, bei der Anzeige gerade nur ein einziger Wert, obwohl in der Datei durchgehend der Wert 0 für das Signal eingetragen ist.

Eine USB-6009 kann Digital-Kanäle nicht mit Hardware-Taktung erfassen.
Betreib mal Debugging an der Stelle der Datenerfassung der D-INs, da müsste schon eine Fehler auftauchen.

Gruß, Jens

Anzeige

Hallo daxel,

Zitat:Ich meine zwar, ich hatte letztes mal einen Fehler dabei, weil ein 2d-Array rauskam

Wann immer man in LabVIEW etwas konfigurieren will, sollte man einen Rechtsklick ausprobieren: hier wäre ein Häkchen bei "Eingänge verknüpfen" zu setzen. Kontexthilfe lesen schadet auch nie...

Ansonsten gilt ja wohl Punkt 5, wie man Jens' Antwort entnehmen kann...

@Gerd: Oh ja, so geht das! Die Kontexthilfe habe ich auch dauernd offen, aber das hab ich irgendwie übersehen

Habe jetzt einfach mal an alle Stellen, wo denn ein Fehler auftreten könnte, einen einfachen Fehlerbehandler gehängt. Damit sollte ich nichts mehr übersehen..

@Jens: Stimmt, dann kommt folgender Fehler:

Code:

Mögliche Ursachen:
Gewünschter Wert wird für diese Eigenschaft nicht unterstützt. Der Eigenschaftswert ist ggf. ungültig, da er mit einer anderen Eigenschaft in Konflikt steht.
Eigenschaft: SampleTimingArt
Angeforderter Wert: Sample-Takt
Mögliche Auswahl: Auf Anforderung
Task-Name: DigitaleErfassungTask

Ich werde da allerdings nicht ganz schlau draus Der Fehler liegt dann an der von mir gewählten Instanz des Timing-VIs (Sample-Takt); allerdings gibt es hier keine Auswahlmöglichkeit "Auf Anforderung", wie der Fehler suggeriert/ich es verstehe. Was für eine Möglichkeit hätte ich denn dann, die Werte zu lesen, und lässt sich dann überhaupt eine einstellbare Abtastrate für die Digitalwerte realisieren?

Muss ich dann vielleicht die Instanz "Implizit" zur Einstellung wählen?

EDIT: Bei der Einstellung "Implizit" kommt die selbe Fehlermeldung. Oder muss ich hier ganz auf das SampleTiming verzichten?

Hallo daxel,

Zitat:Oder muss ich hier ganz auf das SampleTiming verzichten?

Ja. Und auf Einzelwertabfrage umstellen...

Okay, dafür muss ich dann ja nur die Instanz vom Lese-VI verändern, auf NKanäle 1Sample. Das habe ich jetzt beim analogen und digitalen gemacht, und die Anzeige klappt bei beidem wunderbar und flüssig. Nur die Consumerschleife scheint nicht ganz hinterher zu kommen, wenn ich Dateien schreibe, dann läuft die Anzeige nämlich nur unglaublich langsam weiter und es werden kaum Datensätze geschrieben. Ist natürlich verständlich, wenn ich immer einzelne Datensätze in die Datei schreibe; kann ich die in ein 2D-Array zusammenfassen und dann hinterher alles auf einmal in die Datei schreiben? Das probier ich einfach mal aus..

EDIT: Wie genau könnte ich dann ein 2D-Array aus Signalverlauf zu "Messwerte in Datei schreiben" übergeben, das ja eigentlich DDT verlangt?