INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Probleme bei IEC Bus Kommunikation mit Word-Item



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

11.12.2010, 16:07
Beitrag #21

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
11.12.2010, 18:23
Beitrag #22

Kasi Offline
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)
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
13.12.2010, 22:32
Beitrag #23

rolfk Offline
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
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.

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
14.12.2010, 07:17
Beitrag #24

Kasi Offline
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)
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
14.12.2010, 19:56 (Dieser Beitrag wurde zuletzt bearbeitet: 15.12.2010 09:00 von Lucki.)
Beitrag #25

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.12.2010, 09:14
Beitrag #26

rolfk Offline
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: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.

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
15.12.2010, 10:34
Beitrag #27

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
17.12.2010, 09:28 (Dieser Beitrag wurde zuletzt bearbeitet: 17.12.2010 09:30 von rolfk.)
Beitrag #28

rolfk Offline
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.

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Probleme bei Kommunikation mit Beschleunigungsmodul über AMBER 8350 Funkmodule BollerJan 24 15.237 10.03.2014 18:16
Letzter Beitrag: jg
  Probleme bei der Kommunikation mit Faulhaber Motoren Allyoucaneat 2 7.173 12.09.2011 12:29
Letzter Beitrag: Allyoucaneat

Gehe zu: