GPIB-Treiber: Kompatibilität / Austauschbarkeit

[Aggakhan]

Hallo Leute,

ich findet leider keine explizite Antwort zu meinen Fragen, so habe ich mir gedacht, dass ich vielleicht von Eurer Erfahrung zehren könnte.

Meine Fragen:

1. Kann man generell jedes Gerät mit einem GPIB mit jedem x-beliebigen GPIB-Treiber steuern, oder muss man da aufpassen?

Es gibt ja zum Beispiel die IEEE-488-Norm für die es wieder ganz viele Bezeichnungen gibt:

IEEE Standard 488
IEEE Standard 60488
IEC-625-BUS
Hewlett-Packard Interface Bus
ANSI Standard MC 1.1

Quelle: (Wikipedia)

2. Sind also alle GPIB-Standards identisch oder zumindest insofern kompatibel, dass man Befehle (ohne irgendwelche Tricks) an ein x-beliebiges (z.B. unabhängig vom Hersteller) GPIB-Gerät senden kann?

Vielen Dank für Euren Rat!

Mit freundlichen Grüßen,

Aggakhan

[LiannaWulf]

Meines Wissens nach verwenden die verschiendenen Hersteller auch verschiedene Protokolle.
Die IEEE488 bezieht sich nur auf die Standartisierung der Datenübertragung. Was du damit überträgst, ist immer noch Herstellerabhängig.
Also wirst du vermutlich nicht überall den gleichen Treiber verwenden können.

[TBuktu]

Also der
General Purpose Interface Bus

ist nunmal von HP gewesen und war eben DIE Schnittstelle z.B. zur Steuerung von den Geräten via LabView von National Instruments

Der Treiber ist da eigentlich egal
Es gibt eine hardaremäßige Spec, bzw . Karten mit der Schnittstelle
Wenn ich ein Gerät mit GPIB habe und will mit LabView dises Gerät steuern, dann kaufe ich auch eine Karte von National Instruments und dann spielt das auch zusammen

Die Befehle sind dann wiederum den Specs der jeweiligen Geräte zu entnehmen

Gruss
Tim

[Aggakhan]

@LiannaWulf: Danke für Deine Antwort. Auf diese Idee bin ich noch gar nicht gekommen.

@ll:
So wie ich das jetzt verstehe, hat die Standardisierung der Datenübertragung mehrere Ebenen. Es gibt standardisierte Hardware (wohl in IEEE 488.1), standardisierte Datenübertragungprotokolle und Gerätekommandos (IEEE 488.2). Wobei die "Standardbefehle für programmierbare Geräte" (SCPI) ein Teil von IEEE 488.2 zu sein scheinen:

1987 verabschiedete das IEEE eine Ergänzung, IEEE 488.2 (alias IEEE 60488.2:2004), die den Originalstandard erweitert, nicht ersetzt. Der Originalstandard definierte keine Datenübertragungsprotokolle oder Gerätekommandos. Um den Wildwuchs von Herstellerlösungen einzudämmen, wurde 1990 IEEE 488.2 um die standardisierte Kommandosprache SCPI erweitert. Viele Geräte erfüllen auch heute noch nicht den IEEE488.2-Standard.

(Quelle: http://de.wikipedia.org/wiki/IEC-625-Bus#Geschichte)

3. Kann man also davon ausgehen, dass die IEEE 488.2 sich wenig, nicht oder kompatibel zu älteren Versionen (d.h. alte Geräte trotzdem mit neuem Treiber steuerbar) verändert hat? Also, z.B. nur neue Befehle für die Geräte dazugekommen sind?

So hätte ich es zumindest gemacht.

Vielleicht hat ja doch noch jemand Erfahrung damit?

Vielen Dank!

[TBuktu]

Ist doch alles Nötige gesagt - lies es einfach nochmal

Wenn Du es nicht verstehst, dann nimm Dir ein einfaches Beispiel wie z.B. RS232
Das eine ist die Schnittstelle, das andere sind die Telegramme, die rüberlaufen

Ausserdem habe ich nun selbst mal auf Wiki nachgelesen...und da steht alles drin

Vielleicht machst Du Dir die Mühe auch

http://de.wikipedia.org/wiki/IEC-625-Bus

Gruss
Tim

[aNtiCHrist]

Kann man generell jedes Gerät mit einem GPIB mit jedem x-beliebigen GPIB-Treiber steuern, oder muss man da aufpassen?

Was meinst du mit Treiber? Einen LabVIEW-Treiber? Oder einen Treiber, der dem Betriebssystem und der darauf laufenden Software einen Zugriff auf den Bus ermöglicht. Letzterer Treiber ist natürlich spezifisch für Hardware und Betriebssystem. LabVIEW-Treiber müssen zu dem anzusteuernden Gerät passen.

Sind also alle GPIB-Standards identisch oder zumindest insofern kompatibel, dass man Befehle (ohne irgendwelche Tricks) an ein x-beliebiges (z.B. unabhängig vom Hersteller) GPIB-Gerät senden kann?

Grundsätzlich sollte das möglich sein, wobei man ggf. Einbußen bei Jitter und Datendurchsatz in Kauf nehmen muss. Für viele Zwecke sollte es da aber keine Probleme geben.

Problematischer ist da schon eher die Software. Die muss nämlich mit der softwareseitig bereitgestellten GPIB-Schnittstelle (etwa der gpib32.dll unter Windows) harmonieren. AFAIK stammt dort das API von National Instruments, mit einer Agilent-Karte und einer dazu passenden gpib32.dll hatte ich mal Probleme mit einer Steuerungssoftware, die wohl exotischere Calls genutzt hat, die von der Agilent-DLL nicht genau gleich implementiert wurden. Grundsätzlich funktionierte die Kommunikation, aber bei einigen Funktionen wurden seltsame Fehlermeldungen ausgegeben. Bei meinen eigenen Programmen, die sich bisher auf simple Lese- und Schreibvorgänge beschränkten, habe ich aber unabhängig von dem Controller keine Probleme feststellen können.

[Aggakhan]

@TBuktu: Entschuldige, ich hatte Deinen Beitrag noch nicht gelesen. Ich habe diesen Wikipediaartikel auch schon x-mal gelesen und zitiert.

4. Gehst Du also davon aus, dass die Gerätebefehle (siehe SCPI) kein Bestandteil der IEEE 488.2 sind?

Ich bin nämlich vom Gegenteil ausgegangen (5. Ist Deiner Meinung nach ein Fehler in dem Wikipediaartikel oder verstehe ich da etwas nicht?). Dann wäre es doch nicht egal welchen Treiber man verwendet, weil der Treiber dann geräteabhängig wäre?!

Oder im dem Falle, dass es kein Bestandteil der IEEE 488.2 ist, dann könnte es noch immer ein Bestandteil des Gerätetreibers (ein Stück Software) sein.
6. Oder werden die Treiber für die Schnittstelle und das Gerät immer getrennt?

Ist doch alles Nötige gesagt

Ich bin nicht so sicher, dass schon alles gesagt wurde, weil es scheint ja zwei Meinungen zu geben:

Also wirst du vermutlich nicht überall den gleichen Treiber verwenden können.

Der Treiber ist da eigentlich egal

7. Weil LabView diesen Treiber mitliefert?!

@TBuktu: Entschuldige, dass ich mich so blöd stelle, aber Du könntest auch mal genauer auf meine Fragen antworten. Die Zahlen vor meinen Fragen kannst Du übrigens als Hinweis darauf verwenden, auf welche Frage Du gerade antwortest. Trotzdem vielen Dank. Ich habe es einfach noch nicht richtig verstanden.

[TBuktu]

Nur mal kurz zur Ergänzung zum Post meines Kollegen
HP hat seine Produktpalette mal umbenannt in Agilent
Die Geräte sind phantastisch und - wenn man einmal das Konzept begriffen hat - absolut intuitiv bedienbar
(man kann einen Funktionsgenerator z.B. wirklich so einstellen, dass alles passt in Abhängigkeit, ob man nun ein T-Stück mit Abschlusswiderstand dran hat oder nicht - neues, unbekanntes Gerät ohne Manual!!!)
Niemand hat seinerzeit verstanden, warum man einen etablierten Namen in dieser Branche nun unbedingt ändern muss...aber erstaunlicherwiese hat der Markt das locker mitgemacht und die Geräte haben einfach überzeugt

TE, ich denke mal, dass ich Dir das NICHT bis runter zu indizierten Fragen vorkauen werde

Es ist wirklich alles gesagt - nur merkst Du es offensichtlich nicht
Also bitte alles noch einmal durchgehen und dann gezielt fragen, wo denn nun das Unverständnis liegt

Gruss
Tim

[Aggakhan]

@aNtiCHrist: Vielen Dank! Deine Antwort war bisher die beste.

Was meinst du mit Treiber? Einen LabVIEW-Treiber? Oder einen Treiber, der dem Betriebssystem und der darauf laufenden Software einen Zugriff auf den Bus ermöglicht. Letzterer Treiber ist natürlich spezifisch für Hardware und Betriebssystem.

Ja, ich meine den Treiber, der einer Software (eines bestimmten Betriebssystems) Zugriff auf den Bus ermöglicht. Mit LabView habe ich nichts am Hut.

8. Mit Hardware meinst Du, so wie ich das verstehe nicht die periphere Hardware (das zu steuernde Gerät)?! Dann macht das alles schon mehr Sinn für mich.

Zusätzlich braucht man, dann aber logischerweise noch einen Gerätetreiber.
9. Dieser Gerätetreiber ist also unabhängig von dem GPIB-Treiber (bei Windows: gpib32.dll)? Die SCPI sind also in den Gerätetreibern implementiert und nicht im GPIB-Treiber? <- Das wäre super!

Problematischer ist da schon eher die Software. Die muss nämlich mit der softwareseitig bereitgestellten GPIB-Schnittstelle (etwa der gpib32.dll unter Windows) harmonieren. AFAIK stammt dort das API von National Instruments, mit einer Agilent-Karte und einer dazu passenden gpib32.dll hatte ich mal Probleme mit einer Steuerungssoftware

Interessant! Aber das sollte funktionieren oder in anderen Worten, ist nicht mein Problem. Zumindest bis jetzt.

Ich hoffe ich habe das jetzt alles richtig verstanden!

Vielen Dank nochmal!

@TuBuktu:

HP hat seine Produktpalette mal umbenannt in Agilent

Auch interessant.

HP hat seine Produktpalette mal umbenannt in Agilent
Die Geräte sind phantastisch und - wenn man einmal das Konzept begriffen hat - absolut intuitiv bedienbar

Ist das etwa Schleichwerbung? Ich verwende auch gerne Produkte, die nicht von HP / Agilent sind.

Ich muss mir das Ganze wohl nochmal durch den Kopf gehen lassen. Vielleicht mache ich ja irgendeinen doofen Denkfehler? Den kannst Du mir gerne verraten! Wenn ich keinen Denkfehler mehr machen sollte, dann sag' mir doch bitte Bescheid. Ich muss jetzt aber erstmal 'ne Esspause machen.

[aNtiCHrist]

8. Mit Hardware meinst Du, so wie ich das verstehe nicht die periphere Hardware (das zu steuernde Gerät)?!

Korrekt, ich meine damit den GPIB-Controller, der sich im/am Rechner befindet.

Zusätzlich braucht man, dann aber logischerweise noch einen Gerätetreiber.
9. Dieser Gerätetreiber ist also unabhängig von dem GPIB-Treiber (bei Windows: gpib32.dll)?

Was meinst du mit Gerätetreiber? Gerät im Sinn von Hardwarekomponente im/am Rechner (Stichwort "Gerätemanager") oder ein über GPIB ansprechbares Gerät?

Der Treiber für den GPIB-Controller und die DLL die bilden ein Paar. Eine DLL kann ja nicht direkt auf die Hardware zugreifen, daher ist noch eine SYS-Datei nötig. Die DLL stellt dann aber mehr oder weniger gut ein einheitliches API für die Programme bereit. Bei der von mir erwähnten DLL von Agilent gab es eben offenbar kleinere Probleme. Die DLL von National Instruments konnte ich in dem Rechner aber nicht nutzen, da dort eben kein National-Instruments-GPIB-Controller drinsteckte.

Einen Treiber für ein über GPIB ansprechbares Gerät benötigst du nicht. In LabVIEW wäre er nötig, damit dort die von dem Gerät bereitgestellten Möglichkeiten bekannt sind. Aber allgemein reicht halt der Befehlssatz, der im Handbuch des Geräts aufgeführt sein sollte. Damit kann man dann selbst die Kommunikation mit dem Gerät realisieren.

Die SCPI sind also in den Gerätetreibern implementiert und nicht im GPIB-Treiber?

Da verwechselst du wohl was. SCPI ist nur ein Konzept für eine systematische, hersteller- und geräteübergreifende Befehlssyntax. Bei alten GPIB-Geräten herrschte ziemliches Chaos bei den Befehlen und deren Syntax, weil jeder Hersteller sich da selbst etwas ausdachte. Dadurch kam man bei der Nutzung mehrerer Geräte schnell durcheinander, welches Gerät welche Syntax erwartete/ausgab. Ob ein über GPIB ansprechbares Gerät einen SCPI-konformen Befehlssatz nutzt, hängt nur von der darin genutzten Firmware ab. Über Treiber kann man da nichts beeinflussen. Da müsste man schon die Firmware austauschen.