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
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
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();
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
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.
@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
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.
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
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
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
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
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
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
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.
Eine eigene Frage?
Dieser Thread ist über 14 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
