LabVIEWForum.de
SubVI-Daten auslesen - Druckversion

+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: SubVI-Daten auslesen (/Thread-SubVI-Daten-auslesen--20827)

Seiten: 1 2 3


DAQ Fehler "Reservierte Ressource" - PreVIEW - 23.06.2016 08:58

Hallo werte LabVIEW Freunde Wink

Ich muss diesen Thread mal wieder ins leben rufen.

Zu nächst mal muss ich sagen das ich noch nicht so Lange / so Viel mit LabVIEW gearbeitet habe.
Zum Problem:

Ich bin dabei mit einem NI 6003 einen Drehgeber über die Analogeingänge aus zu werden. Später möchte ich die Signale mit einem weiteren Sensorsignal gemeinsam auswerten.

Dazu habe ich eine MainVI die 2 SubVI´s aufruft. In diesen SubVI´s werden die Daten des Drehgebers ( Kanal A und B) erfasst und an die MainVI über Queues weiter gegeben. Dort soll dann eine Vierfachauswertung der Signale geschehen.

Mit einer SubVI funktioniert das ganz gut. Jedoch nicht mit dem Zweiten SubVI ( Kopie der ersten SubVI)

Ich hab mich dann na euren Beispiel orientiert und einen gemeinsamen DAQTask in der MainVI erstellt. Jedoch bekomme ich jetzt statt der Fehlermeldung "Resource resserviert" andere Fehler - siehe Anhang

Schaut mal Bitte drüber, vllt seht ihr auf Anhieb was ich für "Murx" dabriziert habe ^^
Wie bekomme ich das weg? oder wie muss ich das Umgestalten damit das sicher funktioniert?
Ich hoffe mir kann Jemand weiter helfen.

Besten dank im Voraus Wink

MfG

Edit GerdW:
Beitrag verschoben, da zu diesem Thema gehörend.
@Preview: Bitte nicht wahllos alte Threads wiederbeleben. Bitte die Diskussion nicht über mehrere Threads streuen, sondern an einem Platz zusammenhalten!



RE: SubVI-Daten auslesen - Trinitatis - 23.06.2016 09:57

(23.06.2016 07:36 )Lucki schrieb:  Aber: die Daten von mehrere Queues in einer einzigen Hautpschleife zu empfangen geht fast überhaupt nicht. Höchstens dann, wenn alle Raten streng synchronisiert sind.

Die Frage ist, um was für Daten es sich handelt. Ich habe das schonmal auf eine Art gemacht, in der ich in einer Verarbeitungsschleife 4 Queues ausgelesen oder besser gesagt geleert habe und die Ergebnisse jeder Queue zu einem Messwert zusammengemittelt habe. Man könnte auch die Queues leeren und jeweils den letzten Wert verwenden. Aber das hängt natürlich von den Daten ab bzw. davon, ob es nötig ist, exakt die Einträge zu verarbeiten, die von einem Zeitpunkt herrühren. Beide Varianten hätten den Vorteil, dass keine Queue durch Asynchronitäten volllaufen kann.


Gruß, Marko


RE: SubVI-Daten auslesen - PreVIEW - 23.06.2016 10:13

Noch einmal allgemein. Ich möchte ein Drehgeber Signal (Kanal A; Kanal B; Referenzmarke) über Analoge Eingänge eines NI 6003 einlesen. Dazu habe ich eine SubVI die mir werte des Kanales liest und die Flanken auswertet - und in die MainVI übergibt wo dann die Kanäle zusammen verrechnet werden sollen (4Fach-Auswertung) Anschließend möchte ich noch ein weiteres Sensor Signal mit verrechnen. Also sollte alles Synchron laufen.
Lucki:

Die SubVI´s sollen Parallel zur MainVI laufen. Rufe sie also vor der der Mainloop auf.
Hab jetzt aber einfach die SubVI noch einmal Kopiert - umbenannt und rufe einfach 2 SubVI´s auf da ich einen 2. Phys.Channel lese. Oder gibt es eine Möglichkeit auch die Channeladresse in einer 2. Instanz zu ändern? Da ich die Variante mit den Instanzen eigentlich bevorzuge da ich sie für die elegantere Lösung halte.

Die Variante mit dem Cluster - Queues klingt sehr interessant nur wie kann ich die Herkunft in das Cluster schreiben? Also wie bekomme ich die Herkunft heraus?

Trinitatis:
Hab die Kommunikation über Queues realisiert ( mit zwei SubVI´s - siehe oben) - Jedoch wie stelle ich sicher das diese Synchron laufen? Die Werte sollten schon synchron sein.

Besten Dank für eure Ideen und hinweise!

Ich habe die VI´s mal angehangen. - Funktioniert halt nicht ^^ - Encoder_Auswertung.vi ist die Main

MfG


RE: SubVI-Daten auslesen - Trinitatis - 23.06.2016 10:22

Du kannst jeder Instanz deines Sub-VIs am Eingang einen Index (Kanal-Ix) übergeben. Damit kann dann auch jede Instanz ihre eigene Queue mit dem Index im Namen öffnen bzw. anfordern. Wenn du das synchrone Reinschreiben sicherstellen kannst, dann kannst du in deiner Hauptschleife aus allen Queues je 1 Element auslesen.
Insofern geschieht die Auswertung genauso synchron, wie das Reinschreiben der Daten in die Queues.


Gruß, Marko


RE: SubVI-Daten auslesen - GerdW - 23.06.2016 10:35

Hallo,

Zitat:Ich habe die VI´s mal angehangen. - Funktioniert halt nicht ^^ - Encoder_Auswertung.vi ist die Main
Was genau funktioniert nicht?

- Wenn du bei einer USB6003 Analog-Inputs verwendest, dann solltest du diese in einem Task zusammenfassen. Diese preiswerte Box verwendet einen Multiplexer und kann überhaupt keine zwei Task für zwei AIs verarbeiten…
- Die Auswertung von 4 Queues, die aus unterschiedlichen (asynchronen) Quellen kommen, ist sicherlich nicht so einfach durch parallele Abfrage erledigt…
- im SubVI: warum wird "Count direction" so oft als lokale Variable verwendet? Warum hier kein Draht und ein Schieberegister???
- deine Signalauswertung sieht schon reichlich kompliziert aus, das geht ganz sicher auch einfacher: für eine High/Low-Erkennung sollte ein (mittleres) Limit ausreichen; es gibt die Funktion PtByPt-BooleanCrossing; Case-Strukturen, die nur True/False ausgeben, kann man durch ein Select und eine passende boolsche Operation ersetzen; …


RE: SubVI-Daten auslesen - PreVIEW - 23.06.2016 13:07

@Trinitatis:
Danke für deine Unterstützung ^^
Zitat:Du kannst jeder Instanz deines Sub-VIs am Eingang einen Index (Kanal-Ix) übergeben. Damit kann dann auch jede Instanz ihre eigene Queue mit dem Index im Namen öffnen bzw. anfordern.
Also ich übergebe den SubVI`s jeweils einen Index ( in meinem fall einen String - A/B) und verknüpfe diese mit den jeweiligen Queuenamen. Siehe Bilder im Anhang
Weiß leider nicht Ob es Funktioniert da ich den Fehler vom Einlesen habe "Ressourcen Reserviert "
Zitat:Wenn du das synchrone Reinschreiben sicherstellen kannst, dann kannst du in deiner Hauptschleife aus allen Queues je 1 Element auslesen.
Wie kann ich dass denn sicherstellen? Über einen Trigger an den ich iwie den Prozessortakt übergebe? hab so etwas leider noch nie gemacht.

@GredW:
Erstmal bitte ich um Entschuldigung wegen den zweiten Thread - hatte das Thema gelesen und dachte das passt vllt besser. Danke fürs verschieben und danke für die Unterstützung!

Zitat:Was genau funktioniert nicht?

- Wenn du bei einer USB6003 Analog-Inputs verwendest, dann solltest du diese in einem Task zusammenfassen. Diese preiswerte Box verwendet einen Multiplexer und kann überhaupt keine zwei Task für zwei AIs verarbeiten…
Genau das Funktioniert nicht - eben weil ich versuche mehrere Tasks zu öffnen - ich weiß aber nicht wie ich dass richtig mache. geht das überhaupt wenn ich in 2 SubVI´s versuche die jeweiligen Kanäle zu lesen?

Und wenn ich des Richtig sehe ist das Synchrone einlesen mit dem MUX eig. gar nicht möglich?

Kannst du mir ein Beispiel nennen in dem ich erkennen kann wie man die Signale richtig zu einem Task zusammen fügt?
Zitat:- Die Auswertung von 4 Queues, die aus unterschiedlichen (asynchronen) Quellen kommen, ist sicherlich nicht so einfach durch parallele Abfrage erledigt…
Wie geht es besser? Ist es sinnvoll das SubVI so zu erweitern das ich beide Kanäle in diesem SubVI einlese und und dann in einem ClusterQueue an die Main übergebe?
Zitat:- im SubVI: warum wird "Count direction" so oft als lokale Variable verwendet? Warum hier kein Draht und ein Schieberegister???
Wollte damit ein wenig Übersicht schaffen - hab es aber jetzt verdrahtet so wie du sagtest
Zitat:- deine Signalauswertung sieht schon reichlich kompliziert aus, das geht ganz sicher auch einfacher: für eine High/Low-Erkennung sollte ein (mittleres) Limit ausreichen; es gibt die Funktion PtByPt-BooleanCrossing; Case-Strukturen, die nur True/False ausgeben, kann man durch ein Select und eine passende boolsche Operation ersetzen; …

Ich möchte ja den Flankenwechsel fest stellen das ist mit einer einfachen High-Low Erkennung nicht getan? aber ich schau mir dann mal dein genanntes VI an - mein Code ist schon ziemlich unübersichtlich Big Grin


RE: SubVI-Daten auslesen - GerdW - 23.06.2016 13:42

Hallo Preview,

Zitat:eben weil ich versuche mehrere Tasks zu öffnen - ich weiß aber nicht wie ich dass richtig mache. geht das überhaupt wenn ich in 2 SubVI´s versuche die jeweiligen Kanäle zu lesen?
Nein, das wird nicht gehen.
Warum musst du überhaupt zwei subVIs verwenden, wenn du sowieso nur ein Hardwaregerät zur Verfügung hast?

Genereller Hinweis:
(Mehrere) subVIs sind sinnvoll, wenn du unterschiedliche Signaltypen (AI, AO, DI, DO) einzeln handhaben willst. Gleichartige Signale sollten in einem subVI erledigt werden - insbesondere, wenn die Hardware nur einen Task pro Signaltyp erlaubt!

Zitat:Kannst du mir ein Beispiel nennen in dem ich erkennen kann wie man die Signale richtig zu einem Task zusammen fügt?
Beispielfinder -> DAQmx -> Einlesen mehrerer Spannungssignale…

Zitat:Ist es sinnvoll das SubVI so zu erweitern das ich beide Kanäle in diesem SubVI einlese und und dann in einem ClusterQueue an die Main übergebe?
Ich würde in einem VI alle Spannunsgsignale einlesen, diese gleich aufbereiten/analysieren und in die Queue dann nur noch das Ergebnis der Analyse schreiben (in deinem Fall die aktuellen Counter-Stände)…

Zitat:Wollte damit ein wenig Übersicht schaffen
Durch den vermehrten Einsatz von lokalen Variablen verliert man nur die Übersicht, da man nun nicht mehr sagen kann, wo und wann der Wert verwendet wird.
Außerdem mehren sich die "Race conditions"!

Zitat:Ich möchte ja den Flankenwechsel fest stellen das ist mit einer einfachen High-Low Erkennung nicht getan?
Doch, eine einfache High/Low-Erkennung reicht völlig aus.
Du dagegen machst eine (meiner Meinung nach überflüssige) parallele Erkennung von High-Zustand und Low-Zustand. Warum? Entweder das Signal ist auf High- ODER Low-Pegel, da reicht doch ein einziger Vergleich vollkommen aus!?


RE: SubVI-Daten auslesen - PreVIEW - 23.06.2016 13:58

Hallo GerdW,

Zitat:Warum musst du überhaupt zwei subVIs verwenden, wenn du sowieso nur ein Hardwaregerät zur Verfügung hast?
Ich dacht eben ein SubVI für den jeweiligen Eingang - wusste es eben nicht besser
Danke für deinen Hinweis - wieder einen Schritt näher an einer ordentlichen Struktur! ^^
Zitat:Ich würde in einem VI alle Spannunsgsignale einlesen, diese gleich aufbereiten/analysieren und in die Queue dann nur noch das Ergebnis der Analyse schreiben (in deinem Fall die aktuellen Counter-Stände)…

So werde ich es auch machen, Jetzt wo ich weiß das ich da nur einen Task mit der Hardware bekomme ..

Vielen Dank für die Unterstützung ich melde mich erneut wenn ich (hoffentlich) Erfolg zu verkünden habe oder ( was wahrscheinlicher ist Big Grin ) ich auf weitere Probleme stoße. ^^

Beste Grüße


RE: SubVI-Daten auslesen - PreVIEW - 24.06.2016 12:59

So das sieht doch gleich viel besser aus.
Vielen Dank nochmal für eure Hilfe!

Kann man da noch was verbessern? - siehe Anhang?

edit:

hab mal die max. Samplerate probiert ( 33k bei 3 Kanälen ) dann bekomm ich die Meldung dass die Software nicht schnell genug für die Hardware ist. Wie kann ich denn "schneller" programmieren ? Big Grin


RE: SubVI-Daten auslesen - GerdW - 24.06.2016 13:33

Hallo Preview,

Zitat:Wie kann ich denn "schneller" programmieren ?
Durch Verzicht auf unsinnige Dinge…
- wenn du Einzelsamples abfragst, brauchst du keine Waveforms abfragen - da würde ein einfaches 1D-Array ausreichen!
- Verzicht auf DDT-Drähte!!! Statt SplitSignal dann ein einfaches IndexArray nehmen…
- Den HighLow-Vergleich könnte man auch gleich auf dem Array von Samples durchführen: Stichwort "Polymorphismus"…
- CoercionDots vermeiden! Warum werden deine Counter als I16 angelegt? Da ist doch schon bei 32767 Schluss…

Und ganz wichtig:
Niemals Einzelwertabfrage bei Samplerate größer als ~50-100Hz. Immer blockweise Daten lesen, z.B. 3300 Samples bei 33kHz Samplerate!
Dein Rechner bzw. DAQmx wird immer zu langsam sein, um mal eben 33k Samples einzeln weiterzureichen: Hier steckt ein erhebliche Treiber-Overhead drin…