Hallo allerseits,
mit LabVIEW 9.0.1 habe ich unter XP ein VI erstellt, das über die serielle Schnittstelle Daten eines MC einliest. Das funktioniert soweit super. Gestern habe ich LabVIEW 9.0.1 und NI-VISA 4.5.1 auf meiner Workstation mit Debian installiert. Das lief auch super. Das VI konnte ich direkt öffnen und statt COM1 ASRL1 auswählen, wenn ich dann starte läuft das Programm wie unter XP (Anhang: error_1). Ändere ich allerdings etwas an der "Verkabelung" dann erscheint folgender Fehler bei VISA Read und VISA Close (Anhang: error_2):
Wire: Class conflict
You have connected a refnum of one type to a refnum of another type and both types are members of some class hierarchy, but there is neither a simple up cast nor type cast between the two classes.
Aber das kann doch gar nicht sein. Es ist eine direkte Verbindung von VISA Init zu Read zu Close. Der Fehler ist auch leicht zu reproduzieren, wenn man in ein leeres VI ein VISA Serial, dann ein VISA Read einfügt und beide verbindet. Beim VISA resource name Kabel erscheint ein Class conflict.
Ich glaube erstmal nicht an ein Treiber-Problem, da das VI bei direkter Übernahme von XP läuft. Mir ist noch aufgefallen, dass ich beim "VISA resurce name Control" die VISA Class nicht auswählen kann. Der Eintrag ist im Drop-Down-Menu ausgegraut (Anhang: error_3).
Speichere ich das VI mit den Fehlern dann ab, dann ist es statt 26kiB nur noch 19kiB groß. Kann das ein Hinweis auf eine fehlende Bibliothek/Ressource sein?
Es wäre schön, wenn mir jemand weiterhelfen könnte bzw. einen Wink in die richtige Richtung geben kann!
Einen schönen Tag,
Cornell
So weit mir bekannt ist, VISA lauft unter Debian nicht.
eq schrieb:So weit mir bekannt ist, VISA lauft unter Debian nicht.
Das ist jetzt eine komische Antwort, da ich ja geschrieben habe, dass es läuft, wenn man an der auf XP erstellten Variante nichts ändert. Die zentrale Frage wäre: Wo kommt der Class conflict her?
Ich verstehe auch nicht warum es unter Debian nicht laufen sollte, Kernel ist Kernel und hat mit dem Rundherum nicht soviel zu tun. Gibt es zu dem Thema etwas tiefergehende Quellen? Oder ältere Beiträge im Forum? Habe in der Suche auf Anhieb nichts gefunden.
Danke
' schrieb:Das ist jetzt eine komische Antwort, da ich ja geschrieben habe, dass es läuft, wenn man an der auf XP erstellten Variante nichts ändert. Die zentrale Frage wäre: Wo kommt der Class conflict her?
Ich verstehe auch nicht warum es unter Debian nicht laufen sollte, Kernel ist Kernel und hat mit dem Rundherum nicht soviel zu tun. Gibt es zu dem Thema etwas tiefergehende Quellen? Oder ältere Beiträge im Forum? Habe in der Suche auf Anhieb nichts gefunden.
Danke
Das hängt stark von Deiner Debian Version zusammen. VISA vor 5.0 installiert unter anderem auch PXI und verschiedene andere Interfaces, die allesamt Gebrauch von Kerneltreibern machen. Aber die lieben Linux Entwickler haben beschlossen dass ein Kerneltreiber der nicht Open-source ist die GPL Bedingungen unter der der Linux Kernel steht, verletzt, und haben deshalb seit Kernel 2.6.28 oder so dass Linken von closed source Kerneltreibern unterbunden. Damit ist VISA < 5.0 nicht mehr auf Linux Systemen neuer als Kernel 2.6.28 installierbar.
Im Moment gibt es eine Beta Version von VISA 5.0 die diese Treiber nicht mehr zwingend erfordert, und im Fall von USB Devices glaub ich teilweise mit Treibern kommt die nicht mehr auf Kerneltreiber angewiesen sind. Damit ist die Installation in neueren Kerneln grundsätzlich wieder möglich aber es ist Beta und es gibt noch einige Probleme auszbügeln um eine problemlose Installation auf allen unterstützten Plattformen zu ermöglichen, und da Debian nicht offiziel unterstützt ist hat man da typischerwiese so oder so noch was extra Handarbeit zu leisten, auch wenn die Installation grundsätzlich meist möglich ist.
Was Dein Problem betrifft nehme ich mal an dass bei Dir VISA zwar irgendwie installiert ist, sonst dürfte das Progam absolut nicht funktionieren, aber eben nicht vollkommen fehlerlos. LabVIEW benötigt unter anderem im Unterverzeichnis "resources" ein Textfile "visarc" dass ihm die Klassenhierarchie der VISA Resourcen beschreibt. Wenn das fehlt (oder durch den LabVIEW Prozess nicht lesbar ist: Berechtigungen!!) kannst Du solche Fehler bekommen. Das VI dass Du auf Windows erstellt hast hat alle nötigen Informationen noch gespeichert um den VISA Treiber zu laden und aufzurufen, aber bei Änderungen am VI hat das eine komplete Neucompilierung zur Folge und jetzt fehlt LabVIEW die Klassenbeschreibung von VISA um das alles korrekt neu zu erstellen.
Vielen Dank Rolf, dass Du auf alle meine angesprochenen Probleme eingegangen bist!!!
Da kennt sich jemand unter der Haube aus. Ich hatte mir schon gedacht, dass es auch an Berechtigungen liegen kann. Das ist ja sonst das Standardproblem unter *NIX. Im Ordner resource gab es genau eine Datei die Andere nicht lesen konnten und das war visarc. Ein schnelles 'chmod 644 visarc' hat das geregelt. Jetzt kann ich die VISA Klasse wählen, der Class conflict ist weg und die Datei ist genauso groß wie unter XP.
Da hat es sich gelohnt sich hier noch schnell anzumelden!
Das Problem mit dem Kernel-Modul war mir unterwegs aufgefallen. Gestern hatte ich zur Probe noch NI-KAL und NI-PAL installiert (keine Ahnung, was die eigentlich machen, der NI-Abkürzungsfimmel ist immer so wenig sagend). Da konnte das NI-KAL-Modul kompiliert werden, aber das NI-PAL-Modul kam schon vorkompiliert und passt dann natürlich nicht zu meinem Kernel.
Nochmals vielen Dank und ein schönes Wochenende,
Cornell
' schrieb:Das Problem mit dem Kernel-Modul war mir unterwegs aufgefallen. Gestern hatte ich zur Probe noch NI-KAL und NI-PAL installiert (keine Ahnung, was die eigentlich machen, der NI-Abkürzungsfimmel ist immer so wenig sagend).
Dies ist ganz meine eigene Interpretation aber ich gehe mal davon aus:
KAL -> Kernel Abstraction Layer (Thread, Process, Mutex, Events, File IO, etc)
PAL -> Platform Abstraction Layer (Hardware Resource Management: Enumeration, DMA, Interrupts, PCI/PXI bus, etc)
Um nicht für jede Platform einen komplet neuen Treiber schreiben zu müssen haben sich halt ein paar NI Entwickler hingesetzt und einige Schnittstellen festgelegt wofür für jede Plattform ein eigener Low Level Treiber entwickelt wurde. Die anderen NI Treiber wie PXI, DAQmx, IMAQmx, VISA etc sprechen dann keine plattformspezifischen Interfaces mehr an sondern gehen immer durch diese NI Standardinterfaces. Macht die Pflege und Weiterentwicklung dieser Treiber wesentlich einfacher, aber da haben die Linux Entwickler halt einen Stock in die Speichen der NI Entwicklung geworfen, gerade als NI den richtigen Dreh unter Linux endlich entdeckt hatte.
Grundsätzlich ist aus Performancegründen die Verlagerung von hardwarenahen Treibern in den Kernel vorzuziehen und das ist auch die einzige vernünftige Methode unter Widnows wenn man wirklich beste Performance haben will. Unter Linux ist das wegen der GPL Einschränkungen etwas schwieriger und da ist es daher auch gebräuchlicher um ziemlich viel dieser Arbeit im Userland zu tun, und nur ganz wenige generische Dinge direkt im Kernel zu realisieren. Durch die andere Architektur des Kernels geht das meist trotzdem ohne allzu drastische Performanceeinbussen.