Probleme bei IEC Bus Kommunikation mit Word-Item

Freut mich für Dich. Vielleicht sollte Du den "GPIB-USB-HS Adapter" hier mal mit Adresse und Hausnummer benennen, damit andere die den Thread später lesen informiert sind.

Anzeige

Gute Idee. Der Name ist zwar schon recht eindeutig, aber es handelt sich um ein Produkt von National Instruments, der NI GPIB-USB-HS Gpib-Controller für Highspeed USB.
Wenn ich die Werte richtig im Kopf habe, war der einzig identifizierbare Unterschied zur früher verwendeten PCI-Steckkarte der, dass die DataValid Leitung hier etwa 150 ns gesendet wird, während es bei der Karte etwa 170ns waren. Weitere Unterschiede konnten nicht gefunden werden, daher ist es sehr wahrscheinlich, dass dies die Ursache für das Fehlverhalten ist.
Es wird momentan eine künstliche Verzögerung eingebaut. Sollte diese nicht zum Erfolg führen, werde ich das hier auch nochmals festhalten, ansonsten ist das Problem damit gelöst. Es handelt sich bei dem Gerät um einen Eigenbau, insofern ist es sehr wahrscheinlich, dass der Bastler hier evtl. Timing-Standards nur insoweit eingehalten hat, dass es mit dem alten Infertace funktioniert. Aber das sind nur Mutmaßungen. Hauptsache, es kann behoben werden.

Die GPIB Spezifikation sagt ganz eindeutig dass die Daten nur genau so lang aktiv sind wie DataValid aktiv ist. Wenn man dann die Flanke von DataValid benützt um die Daten einzulesen kann das schon mal zu spät sein. Ich glaube dass man im MAX für den entsprechenden Kontroller das Bustiming immer noch verlangsamen kann. Das könnte eventuel helfen aber eine Modifikation des Devices um den IEEE488 Spezifikationen zu entsprechen ist natürlich besser.

Hallo Rolf,

die Hoffnung mit MAX hatte ich an dem Tag, als ich festgestellt habe, dass es ein Timing Problem ist, auch. Das Einzige, was ein bißchen danach klang, das Problem zu lösen, war "Bus Timing". Dort half aber leider keine der Einstellungen. Ich hab dann auch noch sicherheitshalber andere Einstellungen, die irgendwas mit Zeit zu tun hatten, variiert, jedoch ebenso ohne Erfolg. Ohne die Modifikation (im Endeffekt haben Sie wohl nur an einer passenden Stelle einen zusätzlichen Widerstand zur Verzögerung eingebaut, hab mir das aber nicht mehr im Detail erklären lassen) hätte es wohl wirklich nicht allein softwareseitig funktioniert.

' schrieb:Die GPIB Spezifikation sagt ganz eindeutig dass die Daten nur genau so lang aktiv sind wie DataValid aktiv ist. Wenn man dann die Flanke von DataValid benützt um die Daten einzulesen kann das schon mal zu spät sein. Ich glaube dass man im MAX für den entsprechenden Kontroller das Bustiming immer noch verlangsamen kann.

Daß ein GPIP-Empfänger die Ende-Flanke von DAV zum Einlesen verwendet, das geht überhaupt nicht. Denn eben diese Flanke (und damit die Wegnahme der gültigen Daten) kommt vom Sender erst dann, nachdem der langsamste Empfänger über die NDAC-Leitung gemeldet hat, daß er die Daten gelesen hat. (Möglich ist natürlich alles, aber wir reden hier von GPIB).

Die Beginn-Flanke von DAV (und damit gültige Daten) wird übrigens auch nicht aufs Geradewohl gesendet. Voraussetzung ist, daß kein Empfänger den Status NRFD (Not Ready vor Data) hat.

Man muß bei GPIB nichts konfigurieren, ob die Datenübertragung schnell oder ist, bestimmen die angeschlossenen Geräte selbst. (Oder: Wenn die Übertragung zu langsam ist, besteht die Konfiguration darin, den langsamsten Empfänger zu finden und herauszunehmen).

Das Geniale an diesem ganzen Bus ist wesentlich das Geniale das Handshaking. Es werden dazu nicht wie sonst üblich 2 Leitungen, sondern deren 3 verwendnet: DAV (low-aktiv) gehört dem Sender, die beiden anderen den Empfängern (1..mehrere) . Letztere sind Open-Kollektor- Leitungen (ein Signal geht erst auf High, wenn alle High melden, bzw. man hat LOW, wenn einer das meldet)

NRFD (Not ready for Data) Low-Aktiv. Wenn "Not ready für Data", dann darf der Sender nichts senden. Ein Empfänger mit Status "Not ready for Data" reicht aus für den Status NRFD auf der Leitung.

NDAC (Not Data ACcepted) LowAktiv. Erst wenn alle Empfänger die Daten akzeptiert haben, geht die Leitung auf High (=Daten akzeptiert). Danach muß der Sender die gültigen Daten nicht länger halten - aber bis dahin schon.
Es ist noch etwas komplexer, siehe Hier. Dort ist es auch sauberer erklärt.

' schrieb:Daß ein GPIP-Empfänger die Ende-Flanke von DAV zum Einlesen verwendet, das geht überhaupt nicht. Denn eben diese Flanke (und damit die Wegnahme der gültigen Daten) kommt vom Sender erst dann, nachdem der langsamste Empfänger über die NDAC-Leitung gemeldet hat, daß er die Daten gelesen hat. (Möglich ist natürlich alles, aber wir reden hier von GPIB).

Die Beginn-Flanke von DAV (und damit gültige Daten) wird übrigens auch nicht aufs Geradewohl gesendet. Voraussetzung ist, daß kein Empfänger den Status NRFD (Not Ready vor Data) hat.

Genau und der MC68488, um nur ein Beispiel zu nennen, aktiviert NDAC um dann etliche ns danach die Daten erst zu lesen. Das war zu Zeiten der NEC7210 Controller noch kein richtiges Problem, da diese alles in Software abhandelen mussten und der MC68488 noch genug Zeit hatte um die Daten doch noch (zu spät) einzulesen. Dann integrieret NI die ganze Sache in einen Chip (NAT4882) der das alles selber tat und plötzlich war da ein grosses Problem mit diesen Geräten da der Chip unmittelbar nach dem NDAC Signal schon die Daten vom Bus holte und der MC68488 nur noch Mist las. Viele Stanford Research Apparate waren betroffen und der schmutzige Fix war, um das Gerät zu öffnen und in die NDAC Leitung ein RC Verzögerungsglied zu hängen. Wird wohl sowas ähnliches in diesem Fall gewesen sein.

Anzeige

' schrieb:Genau und der MC68488, um nur ein Beispiel zu nennen, aktiviert NDAC um dann etliche ns danach die Daten erst zu lesen.

Dagegen nützt natürlich das perfekteste Handshaking nichts: Wenn die "Job erledigt" - Meldung des Datenempfängers gelogen ist. Daß es solche fehlerhafte Hardware überhaupt gibt, und zwar von namhaften Firmen, ist schon erstaunlich. Die Einrede, daß der Sender die Daten schon noch eine Weile länger halten wird, zählt nicht - es ist ein Verstoß gegen das Protokoll, basta.

' schrieb:Dagegen nützt natürlich das perfekteste Handshaking nichts: Wenn die "Job erledigt" - Meldung des Datenempfängers gelogen ist. Daß es solche fehlerhafte Hardware überhaupt gibt, und zwar von namhaften Firmen, ist schon erstaunlich. Die Einrede, daß der Sender die Daten schon noch eine Weile länger halten wird, zählt nicht - es ist ein Verstoß gegen das Protokoll, basta.

Das ist es, aber hast Du schon mal mit IC Samples arbeiten müssen? Da bekommt man manchmal ein Errata Sheet mit jedem einzelnen Sample mitgeliefert das länger ist dann das eigentliche Datenblatt. Und die Serienproduktion wird oft mit bekannten Fehlern gestartet und wenn die Anzahl der verkauften Chips dann den Prognosen hinterherläuft verzichtet man gern mal auf ein kostbares Redesign, weil die Einkünfte ja eh kaum die Kosten decken! Resultat: Die Bugs im Chip werden sowas wie der Standard. Und in IEEE488 Controllern gab es in der Zeit nicht viel Alternativen: ausser dem NEC7210 der dank der GPIB-PCII Karte von NI, die von allen anderen x-Mal geclont wurde, zum Standard wurde bis NI einen eigenen Controller entwickelte, gab es eigentlich nur noch den MC68488 von Motorola und den 9914 von TI. Der Kontroller von Motorola war mit seinem Bus Interface hauptsächlich für 68K Designs interessant hatte aber einige Probleme (Bugs) und spielte eh nur eine untergeordnete Rolle, der TI Chip war eine Möglichkeit um eine Alternative zum NEC zu haben, hatte aber ein gänzlich anderes Registermodell, und NEC betrachtete den 7210 schon bald als ein nötiges Übel das sie lieber ausrangiert hätten, vielleicht weil sie viel grössere Stückzahlen gewöhnt waren, obwohl der 7210 in der Zeit mit Abstand der meistverwendete GPIB Controller war.

Und auch der NEC und der TI Chip hatten (und haben) einige Bugs die man aber in Software umgehen konnte.