Forum: Mikrocontroller und Digitale Elektronik Identifikation am GPIB


von Heiko (Gast)


Lesenswert?

Hallo,

Ich habe folgendes Problem/Frage. Wie identifiziert sich ein Listener am 
GPIB gegenüber dem Controller/Talker.

Mein Verständnis bisher der Controller setzt ATN auf high und 
übermittelt über DIO die Adresse. Hier muss der Listener sich, als 
angesprochener,  identifizieren. Dann geht es mit der 
Datenübertragungsroutine weiter. Bis auf die Identifizierung ist mir 
alles klar.

Also wie macht er das? Setzt er einfach NRFD auf high wenn seine Adresse 
aufgerufen wird und geht es dann gleich mit der Datenübertragung los?

Wäre toll wenn mir da jemand helfen kann.

MfG
Heiko

von Peter D. (peda)


Lesenswert?

Der GPIB ist sehr alt und daher nach heutigem Stand nicht ausgereift.

Sowas geht also nur über einen Timeout. Man adressiert einen Teilnehmer 
und sendet ein Dummy-Datenbyte. Wenn das innerhalb einer bestimmten Zeit 
nicht klappt (kein Handshake), dann wurde keiner adressiert.
Und das probiert man für alle 31 Adressen.


Peter

von Stefan P. (form)


Lesenswert?

Ich hatte das früher mal in Software nachgebildet,  hat sogar 
funktioniert.
Hier mal eine Zeile (aus dem ATN-Interrupt) die die Frage beantworten 
könnte:

// Wenn wir nicht adressiert sind, sofort NDAC hoch
if (status == 0) G_NDAC_up();

von Heiko (Gast)


Lesenswert?

Okay das nehm ich mal so hin. Man schickt also an Adresse "5" das Dummy 
Datenbye jetzt ist dazu aber meine Frage wie "merkt" Adresse 5 das für 
seine Adresse bestimmt ist. Sprich was ist der unterschied bei keiner 
Reaktion von z.b. Adresse 7 und der Reaktion von Adresse 5.

Ich hoffe man versteht was ich meine mir geht es hier um nicht um die 
Controllerseite sondern um den angesprochenen "Listener", welches Signal 
sendet er? Er wird ja nicht ständig seine Adresse durch den Bus schicken 
sondern diese nur Vergleichen wenn abgefragt wird und das was und wie er 
es da bestätigt interessiert mich.

MfG

von Heiko (Gast)


Lesenswert?

Da hab ich wohl zu schnell geantwortet.

@Stefan P.

Also schickt jeder von der Adresse nicht betroffene "Slave" NDAC auf 
High (Binär = 0) ?

MfG

von STK500-Besitzer (Gast)


Lesenswert?

Heiko schrieb:
> Okay das nehm ich mal so hin. Man schickt also an Adresse "5" das Dummy
> Datenbye jetzt ist dazu aber meine Frage wie "merkt" Adresse 5 das für
> seine Adresse bestimmt ist. Sprich was ist der unterschied bei keiner
> Reaktion von z.b. Adresse 7 und der Reaktion von Adresse 5.


Weil nur Adresse 5 auf die Daten reagieren soll?
Dafür sind die Adressen ja da.

Vielleicht ist es nicht ganz klar geworden:
Der Bus wird vom Controller für Adresse 5 belegt.
Es ist eine Punkt-zu-Punkt-Verbindung, der Datentransfer also nur 
zwischen zwei Geräten möglich.
Um zu erkennen, ob ein Gerät mit der Adresse 5 vorhanden ist, schickt 
man an die Adresse einen Befehl (bei modernen Geräten "*IDN?") und 
bekommt dann als Antwort entweder eine Gerätebeschreibung (z.B. "Agilent 
34401A") oder irgendwas anderes oder gar nichts.
Wenn man keine Antwort innerhalb einer gewissen Zeit (Timeout) bekommt, 
ist kein Gerät mit der Adresse 5 auf dem Bus vorhanden.
Das Gerät mit der Adresse 7 interessiert sich kein Stück für die Daten, 
die für Gerät 5 bestimmt sind.

von Heiko (Gast)


Lesenswert?

@STK500-Besitzer

Auch danke für deine Antwort. Wenn das wirklich so ist was macht ein 
Listen-Only Device? Das soll bei mir der Fall sein un dem soll es nicht 
möglich sein irgendwelche Daten über DIO zu senden. Ist es dann so wie 
vorher beschrieben das ein NDAC auf High zur identifikation ausreicht?

MfG

von Stefan P. (form)


Lesenswert?

Das mit "*IDN?" ist früher noch nicht so gewesen.
GPIB-Controller erkennen auch zuverlässig über die NDAC Leitung welche 
Geräte sich während dem Scan (Adressen-Bruteforce) angesprochen fühlen. 
Erst wenn er dies gemerkt hat, sendet er an die aktiven Adressen ein 
"*IDN?" und wartet auf Timeout oder Antwort-String.

von Edward C. (teddy)


Lesenswert?

Talk/Listen ist auch eine "Addresse", Geraete sind bis 30 und 
Talk/Listen 31

Prizipiell:
Every GPIB instrument must have its own unique address on the bus. The 
PNA address (716) consists of two parts:
   1. The Interface select code (typically 7) indicates which GPIB port 
in the system controller is used to communicate with the device.
   2. The primary address (16) is set at the factory. You can change the 
primary address of any device on the bus to any number between 0 and 30.

Fuer Talk/Listen:
Primary addresses, 31 Talk and 31 Listen; secondary addresses, 961 Talk 
and 961 Listen. There can be a maximum of 1 Talker and up to 14 
Listeners at a time on a single bus.

Mehr info:
http://na.tm.agilent.com/pna/help/WebHelp7_5/Programming/Learning_about_GPIB/GP-IB_Fundamentals.htm

von Heiko (Gast)


Lesenswert?

Hallo,

Ich muss das nochmal hoch holen da meine Frage noch nicht ganz geklärt 
ist, also nochmal folgendes.

Welcher Befehl gesendet oder empfangen wird/muss ist mir relativ egal, 
mich interessiert auf welchen Pin des GPIB-Kabels das Device auf die 
Abfrage der Adresse reagiert (und wie). Mir geht es um ein Listen-Only 
Device welches ich in einen bestehenden Bus mit mehreren Messgeräten und 
dem PC als Controller dazu schalten möchte. Wie die Datenkommunikation 
(Hardwarenah) aussieht wird überall erklärt aber nicht wie das mit der 
Adressierung und deren Identifikation aussieht.

Ist es so wie von Stefan P. beschrieben das ein Signal über NDAC 
ausreicht oder muss Ich über DIO die Identifikation senden (was mein 
Listen only Device, ne Spur komplizierter machen würde).

MfG

von Peter D. (peda)


Lesenswert?

GPIB-Controller haben in der Regel keinen direkten Zugriff auf die 
Steuerleitungen. Sie arbeiten über Kommandos und Ereignisse.
Du schickst also das Kommando "sende Byte" und wartest auf den Interrupt 
"Byte gesendet" und der kommt aber nicht, wenn keiner auf der Adresse 
ist.

Also mußt Du noch einen Timeout aufsetzen, wenn der Interrupt nicht 
kommt. Und der setzt dann den Controller zurück, weil der immer noch auf 
das Handshake wartet bis zum St. Nimmerleinstag.


Peter

von Heiko (Gast)


Angehängte Dateien:

Lesenswert?

Peter Dannegger schrieb:
> Sie arbeiten über Kommandos und Ereignisse.

Ja schon aber irgendwas muss diese Kommandos und Ereignisse ja auslösen 
und das interessiert mich. Mir geht es auch nicht um den Controller 
sondern um das Device.

Ich hab in der zwischenzeit das gefunden was mich interessiert. 
Vieleicht hilft es ja auch noch jemand anderem. Laut der Grafik reicht 
es wenn der Listener dem Controller/Talker mit NDAC auf high übermittelt 
das er "angesprochen" wurde um die Datenübertragung in gang zu setzen.

MfG

von Peter D. (peda)


Lesenswert?

Der GPIB-Controller ist quasi eine Blackbox. Die CPU schickt an ihn ein 
Kommando "sende Byte". Daraufhin läuft in ihm eine Statemaschine ab, die 
das Handshake steuert. Bleiben NRFD, NDAC auf 1, d.h. keiner fühlt sich 
angesprochen, bleibt diese Statemaschine einfach hängen und nichts 
weiter passiert.

Es gibt ja diese USB-GPIB-Umsetzer. Wenn man da das Timeout abschaltet, 
hilft nur den USB-Stecker zu ziehen und wieder zu stecken, um die 
Verklemmung zu beenden. Auf der GPIB-Seite kann man da nichts machen.

Ein Timeout ist für GPIB unbedingt notwendig. Es gibt noch andere 
Möglichkeiten, daß er sich verklemmt. So einen vergurkten Bus würde man 
heutzutage nicht mehr zugelassen kriegen.


Peter

von Heiko (Gast)


Lesenswert?

Peter Dannegger schrieb:
> Ein Timeout ist für GPIB unbedingt notwendig. Es gibt noch andere
>
> Möglichkeiten, daß er sich verklemmt. So einen vergurkten Bus würde man
>
> heutzutage nicht mehr zugelassen kriegen.

Das ist mir schon klar, bloß geht es mir gerade nicht darum sondern 
einfach nur um das Device was am Bus hängt und die "sipmlen" 
elektrischen Signale. Der Controller spielt im Moment noch gar keine 
Rolle.

MfG

von Osche R. (Gast)


Lesenswert?

Hier ist das amtliche Dokument zum HPIB-Bus: 
http://www.bitsavers.org/pdf/hp/hpib/TutorialDescrOfHPIB.pdf

Jahre später wurde das Ding von der IEEE "genormt", der Standard heisst 
IEEE-488-1. Findet man auch im Netz, eventuell aber kostenpflichtig.

Nochmal Jahre später hat man versucht, auch den Befehlssatz der 
Busteilnehmer zu normen. Das nannte sich IEEEE-488-2 und beinhaltete 
Kommandos wie "*IDN?". NI hat diesen Befehlssatz auch verwendet, der 
Rest der Welt eher weniger.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.