INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Doppelnutzungen physikalischer Kanäle - Kollisionsvermeidung



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

11.04.2024, 10:52 (Dieser Beitrag wurde zuletzt bearbeitet: 11.04.2024 10:53 von Kiesch.)
Beitrag #1

Kiesch Offline
LVF-Stammgast
***


Beiträge: 414
Registriert seit: Mar 2009

2019, 2018, 2016
2009
DE

04519
Deutschland
Doppelnutzungen physikalischer Kanäle - Kollisionsvermeidung
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-Verfu...e-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

Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
23.04.2024, 12:35
Beitrag #2

Kiesch Offline
LVF-Stammgast
***


Beiträge: 414
Registriert seit: Mar 2009

2019, 2018, 2016
2009
DE

04519
Deutschland
RE: Doppelnutzungen physikalischer Kanäle - Kollisionsvermeidung
Ist immer gut wenn man seinen code auch später noch überblickt Blink
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...

Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
Wink DAQmx, physikalischer Kanal "Kraft (Brücke)" Paul S. 2 4.159 06.03.2021 00:06
Letzter Beitrag: Paul S.
  Effiziente Datenerfassung und -auswertung mehrerer physikalischer Kanäle rohneluk 6 8.514 24.11.2011 14:19
Letzter Beitrag: rohneluk
  Kein physikalischer Kanal beim BNC-2120 mit pci-6034E Rellik 10 11.186 21.05.2007 15:39
Letzter Beitrag: Achim
  Task, physikalische Kanäle, virtuelle Kanäle Biks 2 10.774 29.01.2006 18:23
Letzter Beitrag: Biks

Gehe zu: