Probleme bei IEC Bus Kommunikation mit Word-Item

Ich habe dazu auch ein Handbuch, hab bisher aber immer nur die für mich relevanten Befehle ergoogled.
In diesem Fall war ich mit diesem Foreneintrag (zweiter Beitrag) erstmal zufrieden, der aussagt, dass es sich um ein word handelt. Ich hab jetzt aber gerade ein schlechtes Gewissen bekommen und nochmal die offizielle Dokumentation überflogen, auch dort wird in 1-28 "W" als Word charakterisiert.
Also sollte die Übertragung auf jeden Fall binär stattfinden, ja. Sonst würden die nicht von 2 Byte sprechen.

###

danke nochmal für das schlagwort "binär", zumindest habe ich damit nochmal ne aussage bzgl binärer gpib-übertragung gefunden. Dort wirt zur Funktion Flatten to String geraten. Die wirkt auf den ersten Blick wie die Typecast Funktion, allerdings kann man hier noch die Übertragungsreihenfolge ändern (auch wenn ich die begrifflichkeiten big-endian und little-endian noch nie gehört habe, "native" hört sich aber toll an) Werde ich am Dienstag dann auch versuchen.

Anzeige

So, nach Recherche zum Thema Big- und Litte-Endian ist das Problem - rein theoretisch - gelöst.
Ich habe mit diesen Schlagwörtern sowohl weitere Leidensgenossen als auch den ausführlichen Erklärungsartikel zum Thema gefunden.
Dort wird im letzten Absatz auch deutlich gesagt, dass Labview bewusst den nicht Windows-konformen Big-Endian Standard verwendet, da es im Original aus Mac entwickelt wurde.

Grau ist alle Theorie, gleich stehe ich dem Biest wieder gegenüber und dann werden wir sehen, ob das die (alleinige) Ursache war.

nichts klappt, nichts, nichts NICHTS! Jedenfalls nichts nach meinen Erwartungen.

Also, Little- und Big-Endian bringt zwar Veränderung, aber keine, die von mir erwünscht ist.
Ich habe versucht, mich dem Problem systematisch zu nähern, indem ich durchteste, in welchem Zustand (frisch neugestartet oder bereits ersten Befehl erhalten) wie reagiert, das ganze mit dem Wert "1" und der GPIB-Schreibroutine im Modus 2 (<lf> + EOI)

Ergebnis: (die Zahlen sind immer die ungefähren Interpretationen, welche Zahl das Gerät auf den Word-Befehl "1" verstanden hat (+/-20))

Neustart, ohne Byteswap: 2860
Kein Neustart, ohne Byteswap: 266
Neustart, mit Byteswap: 0
Kein Neustart, mit Byteswap: 0

Der Buffer wurde dabei immer über NI Spy gecheckt und enthielt immer die gleiche Hex-Information, d.h.
00 01 ohne Byteswap
01 00 mit Byteswap

Mit Byteswap ignoriert er dann alle Zahlen bis 255 und springt dann ab 256 auf 256. Dort bleibt er bis 511, ab 512 springt er dann auch auf 512, usw. Er scheint also das erste Byte zu ignorieren.

Ich habe dann auch nochmal die "Visa Interactive Control" genutzt und diverse Bytefolgen versucht, aber das wurde unsystematisch und ich kann keine klare Aussage aus dem Verhalten ziehen. Momentan habe ich auch keine Energie mehr, darüber nachzudenken.

Falls noch jemand eine zündende Idee hat, nur heraus damit.

Idee nicht, aber ab diesem Punkt wird der Einsatz eines Dataloggers / Logic Analysers unumgänglich, damit man sieht was an der Schnittstelle läuft. Zu Empfehlen, für dreistelligen Eurobetrag: Gwinstek GLA1000-Series.

Danke für den Hinweis mit dem Datalogger. Das Gute ist, dass wir eine Elektronik-Werkstatt im Haus haben, die sowas auf Anfrage schon als Eigenbau im Schrank stehen hat. Man muss nur wissen, wonach man fragen muss

Heute wird es nur ein einseitiger Test, da ich nicht an das Gerät komme, aber zumindest kann ich mir schonmal anschauen, was Labview so aus meinen Flatten-to-String versuchen + Mode 2 GPIB Kommunikation bastelt.

Die gute Nachricht: Labview tut, was es soll. Die schlechte: Ich habe immer noch keine Ahnung, wo der Fehler liegt.

Er sendet, am Hex-Beispiel "01 02":

40 (+ATN) /* hier ist mir die Bedeutung leider nicht klar
3F /* Unlisten an alle Geräte
30 /* Adresse des Geräts
01 /* erstes Byte des Words
02 /* zweites Byte des Words
0A (+ EOI) /* LF

Ich werde das morgen nochmal am richtigen Messplatz testen, der einzig relevante Unterschied, der mir jetzt noch einfällt, ist, dass dort mit einem GPIB-USB-HS Adapter gearbeitet wird. Aber der sollte doch hoffentlich nichts fundamentales an der Nachrichtenübermittlung ändern... man wird sehen.

Anzeige

oh Gott, es ist ein Timing Problem... wenn ich die gesendeten Daten langsam mit dem Logger mitschreibe, macht das Gerät was es soll, tue ich das nicht, macht es bei der gleichen Nachricht Unsinn.
Sollte gpib-kommunikation nicht sauber Byte-weise mit "hast du das verstanden"-Abfragen selbst geregelt werden?!
Und das Schlimmste, mir fällt nicht mal ein Work-around für das Problem ein. GPIB bietet meines Wissens nach keine Baudraten-Einstellung, Byte-weise die Nachricht verschicken (Byte 1, Byte 2, 0A + EOI in getrennten Übermittlungen) führt auch zu Unsinn.
Ende der Fahnenstange? Wird das "High-Speed" in GPIB-USB-HS zu meinem Verhängnis?

Ich werde nochmal googlen, aber Hoffnung habe ich keine.

' schrieb:. GPIB bietet meines Wissens nach keine Baudraten-Einstellung, Byte-weise die Nachricht verschicken (Byte 1, Byte 2, 0A + EOI in getrennten Übermittlungen) führt auch zu Unsinn.
Ende der Fahnenstange?

Die Defakto Übermittlung erfolgt ja immer Byteweise - logisch bei einem 8bit Datenbus. Und das nächste Byte wird immer erst gesendet, wenn das langsamste angesprochene Gerät in der Kette sein OK gegeben hat, daß es das Byte empfangen hat. Von daher kann eigenlich nie etwas schief gehen, solange das Handshake auf den dafür vorgesehenen 3 Leitungen funktioniert. Es kann höchstens langsamer sein als einem lieb ist, was aber deswegen nicht zu Fehlern führt.

Mit "Byte-weise verschicken" meinte ich natürlich den kompletten Unlisten- und Geräteadressierungspart für jedes einzelene Byte, anstatt als komplettes Mehr-Byte-Paket. Ich werde das Gerät + GPIB USB Adapter mal unserer E-Werkstatt vorstellen, um besagte Handshake-Leitungen auszumessen, vielleicht setzt der Adapter ja irgendwelche Pegel nicht hoch genug für das Gerät an.

Das Problem wurde von unserer Werkstatt identifiziert, der neue GPIB-USB-HS Adapter reduziert die Data-Valid Übermittlung um 20ns gegenüber dem alten GPIB-Interface. Das hat allen anderen Geräten keine Probleme bereitet, dieses letzte Gerät jedoch war vom Timing her wohl doch etwas an der Grenze angesetzt. Nun versuchen sie das Problem mit Invertern in den Griff zu bekommen, mit Labview hat das Problem jedenfalls nichts mehr zu tun (und dann auch leider nie gehabt, meine Programmierung stimmte von Anfang an). Danke an alle nochmal für die Tipps, die auf jeden Fall die Ursachenfindung des Problems extrem beschleunigt haben.