11.12.2010, 16:07
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
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.
|
|
|
11.12.2010, 18:23
|
Kasi
LVF-Stammgast
Beiträge: 342
Registriert seit: Dec 2010
6 - 2009
2005
DE_EN
79194
Deutschland
|
Probleme bei IEC Bus Kommunikation mit Word-Item
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.
If you're havin' serial communication problems I feel bad for you, son, I got 99 problems but a baud ain't one! (except if using USB2serial converters, then I experience serialous problems)
|
|
|
14.12.2010, 07:17
|
Kasi
LVF-Stammgast
Beiträge: 342
Registriert seit: Dec 2010
6 - 2009
2005
DE_EN
79194
Deutschland
|
Probleme bei IEC Bus Kommunikation mit Word-Item
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.
If you're havin' serial communication problems I feel bad for you, son, I got 99 problems but a baud ain't one! (except if using USB2serial converters, then I experience serialous problems)
|
|
|
14.12.2010, 19:56
(Dieser Beitrag wurde zuletzt bearbeitet: 15.12.2010 09:00 von Lucki.)
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
Probleme bei IEC Bus Kommunikation mit Word-Item
' 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.
|
|
|
15.12.2010, 09:14
|
|
|
15.12.2010, 10:34
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
Probleme bei IEC Bus Kommunikation mit Word-Item
' 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.
|
|
|
17.12.2010, 09:28
(Dieser Beitrag wurde zuletzt bearbeitet: 17.12.2010 09:30 von rolfk.)
|
rolfk
LVF-Guru
Beiträge: 2.305
Registriert seit: Jun 2007
alle seit 6.0
1992
EN
2901GG
Niederlande
|
Probleme bei IEC Bus Kommunikation mit Word-Item
' 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.
|
|
|
| |