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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.