+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenerfassung (DAQ) (/Forum-Datenerfassung-DAQ)
+---- Thema: Doppelnutzungen physikalischer Kanäle - Kollisionsvermeidung (/Thread-Doppelnutzungen-physikalischer-Kanaele-Kollisionsvermeidung)
Doppelnutzungen physikalischer Kanäle - Kollisionsvermeidung - Kiesch - 11.04.2024 10:52
Liebe LVF Nutzer,
kurz eine Vorbemerkung:
Ich habe mir eine Wrapper Klasse geschrieben mit der ich aktuell nur NI USB 600X ansteuere und die über ein INI file Konfigurieren lasse. Um Zeit zu sparen und das INI file gleich nutzerfreundlich ohne weitere Interaktion mit Werten zu befüllen habe ich das derzeit so aufgesetzt, dass alle verfügbaren Kanäle (AI, AO, DIO) vorinitialisiert werden. Soweit so gut und funktioniert an sich super. Das Problem ist, dass ein Kollege einen Counter nutzen will und der nutzt natürlich immer den Hardwareausgang der auch von einem DIO genutzt wird.
Gefunden habe ich dazu einen alten Thread der eigentlich nur den Teil beschreibt den ich schon gelöst habe (vorhandene Kanäle auslesen) und den ich nicht unbedingt wiederbeleben wollen würde für meine Frage:
https://www.labviewforum.de/Thread-Verfuegbare-physikalische-Kanaele-anzeigen
Also, was ist konkret mein Problem:
Lese ich die physikalischen Kanäle am vorliegenden Device über eine Property aus, kriege ich alle Kanäle gelesen (auch die Counter Kanäle) - soweit so gut. Problematisch sollte es in dem Moment werden, wenn ich einfach alle diese Kanäle versuche (als Tasks) zu intialisieren bzw. zu starten, da ich dann die CTR Kanäle gleichzeitig als DI oder DO sowie als CTR starten würde. Ich erwarte dabei einen Hardwarekonflikt, mindestens jedoch unerwartetes Verhalten zu kriegen (aktuell leider gerade kein NI USB 600X zur Hand zum testen; es erscheint aber offensichtlich, das ich den Kanal nicht gleichzeitig als CTR und DI nutzen kann - falls doch würde ich nochmal Rückinfo geben).
Den Konflikt kann ich vermeiden wenn ich eine Auswahl integriere bei der der Nutzer gefragt wird was er mit dem Kanal machen möchte (wenn noch nicht im INI file Initialisierungsinfos hinterlegt sind). Dazu wäre es aber schön identifizieren zu können, welche Kanäle überhaupt betroffen sind (da von 13 Kanälen nur 2 auch als Counter nutzbar sind). Kriege ich da irgendwie eine Referenz die mir eindeutig den Hardwareausgang (am per Serienummer identifizierten Device) identifiziert? Die "physikalischen Kanäle" erscheinen mir dafür nicht nutzbar, da der gleiche Hardwareausgang als counter mit einem anderen "physikalischen Kanal" angesprochen wird als als Digitaler IO. Ich kann also nicht einfach Namen vergleichen. Und natürlich kann ich für die 600Xer auch einfach fest hinterlegen welche Kanäle bei denen in Doppelnutzung sind. Das erscheint mir aber als etwas unnötige Limitierung des Anwendungsbereichs, da ich dann für jegliche neu eingesetzte NI Hardware auch entsprechend Werte im Program hinterlegen müsste. Das Program soll am Ende beim nutzer als executable ausrollbar sein, die Hardware soll dabei weitgehend frei austauschbar sein (im INI file können Hardwareausgänge auf FP Controls und Indicators gemappt werden). Gerade deswegen würde ich eine Beschränkung auf bestimmte Hardware gerne umgehen.
Habt ihr dazu Ideen?
Mir fällt aktuell eigentlich nur eine gute Idee ein:
Wenn ich Counter auf der Hardware finde, kriegt der Nutzer ein Popup dazu welchem DIO der entspricht und ob der als CTR oder DIO eingesetzt werden soll. Die Eingaben kann ich mir dann ins INI ausspeichern.
Es wäre trotzdem schön wenn jemand eine Idee hat ob ich das auch auf Labview Ebene bereits abfangen kann welcher DIO welchem CTR entspricht da die eingabe durch den Nutzer im Zweifel schief geht.
Danke schonmal für eure Hilfe.
Gruß Kiesch
RE: Doppelnutzungen physikalischer Kanäle - Kollisionsvermeidung - Kiesch - 23.04.2024 12:35
Ist immer gut wenn man seinen code auch später noch überblickt
Der aktuelle Code initialisiert doch nur Kanäle die im INI file bereits namentlich angelegt sind. Ergo kann der Nutzer übers INI file bestimmen was initialisiert wird und selbst dafür sorgen Doppelnutzungen des selben physikalischen Kanals zu vermeiden.
Die Fragestellung wäre jetzt damit nur noch für das Fehlermanagement im Program relevant (da das ein Fehler wäre von dem ich erwarten würde, dass ich den irgendwie ohne großen Aufwand im Initialisationsprozess abfangen können sollte - irgendwo muss es doch was geben mit dem ich vergleichen kann ob ich grade unter zwei verschiedenen Namen auf die gleiche physikalische Resource zugreife). Oder geht einfach nur Stumpf der Parrallelzugriff? Bei DI und Counter würde ich das ja noch glauben, aber DO und Counter (?). Oder DI und Pulsgenerator...