+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: Probleme bei IEC Bus Kommunikation mit Word-Item (/Thread-Probleme-bei-IEC-Bus-Kommunikation-mit-Word-Item)
Probleme bei IEC Bus Kommunikation mit Word-Item - Kasi - 03.12.2010 09:55
Hallo zusammen,
ich habe nach mehrstündiger Problemanalyse keinen Lösungsansatz mehr und wende mich daher (erstmalig) an das allwissende Internet.
Ich bastele gerade an einer Programmierung für einen Messplatz, welcher mittels gpib mit diversen Geräten kommuniziert.
Fast all diese Geräte erwarten String-Befehle als Input und lassen sich problemlos mittels VISA-Routinen ansprechen.
Ein Gerät weicht jedoch ab und erwartet als Befehl 3 Bytes. ich zitiere hier mal aus der "Anleitung" (das Gerät IECBA-01 ist ein IEC-Bus Adapter, der die Befehle dann für eine Magnetsteuerung übersetzt):
Zitat:Um das IECBA-01 zu programmieren, sollten die Daten in Form eines 3-Byte Binärfeldes übertragen werden. Das erste Byte entspricht zur Hälfte dem High-Byte (Bit 0-3), Bit 4 enthält das Vorzeichen, Bit 5 - 7 wird nicht benutzt. Das zweite Byte entspricht dem Low-Byte. Das dritte Byte enthält die Endekennung LF (0AH), die gleichzeitig mit EOI gesendet werden muss.
Darunter ist noch ein Bild mit der entsprechenden Bit-Zuordnung aufgezeichnet, die das oben gesagte bis auf die Endekennung nochmal zusammenfasst:
[attachment=31014]
Das ist das erste mal, dass ich mit einer nicht-String Kommunikation konfrontiert werden, aber ich habe das Original HP Basic Programm zur Verfügung, mit dessen Hilfe ich die Kommunikation bewerkstelligen wollte. Daher zitiere ich erstmal daraus die relevanten Befehle:
Initialisiert wird die Bus-Kommunikation mit folgendem Befehl:
Code:
ASSIGN @Magnet TO 715;EOL CHR$(10) ENDGesprochen wird dann mit dem Gerät auf folgende Art:
Magnetfeld auf 0 fahren:
Code:
OUTPUT @Magnet USING "W";0Code:
OUTPUT @Magnet USING "W";4096Code:
OUTPUT @Magnet USING "W";<X>Meine Interpretation: Kommunikation an Magnetsteuerung mit einem Worditem (-> using "W"), und zwar Werte zwischen 0 und 4095, welche den genutzen Bereich des Word Items (Low-Byte 0-7, High-Byte 0-3) voll ausnutzen. Außerdem noch 4096, welches lediglich bit 4 des High-bytes setzt, um die Polarität zu ändern.
Das Programm funktioniert in HP Basic wunderbar, das Gerät arbeitet als nicht fehlerhaft.
Nun habe ich versucht, dieses Word-Item in Labview einzubauen (Labview 2009 SP1, VISA und 488.2 Treiber auf aktuellem Stand).
Erste Einsicht (die vielleicht falsch ist?): etwas anderes als Strings kann man nicht direkt über GPIB senden.
Zweite Einsicht: Ein Typ-Umwandler muss her. Also habe ich ein 16-Bit numerisches Element (Word) genommen, mittels Typecast in String umgewandelt, <LF> an den String gehängt und in eine unkonfigurierte Visa-Write Routine gegeben.
Dritte Einsicht: Das Gerät reagiert "unerwartet". Leider gibt die Steuerung kein direktes Feedback, man kann nur über den Strom am Magneten ablesen, ob sich überhaupt etwas getan hat, und dann über eine Kalibriertabelle ungefähr rückrechnen, was das Gerät verstanden hat.
Zu meinen durchgeführten Tests: Am Anfang habe ich ihm erstmal eine 0 geschickt. Der Magnet-Strom stand zu diesem Zeitpunkt bereits auf 0, nichts hat sich getan. Daraufhin wollte ich mich langsam hochtasten und habe ihm eine 1 geschickt. Der Magnetstrom sprang dabei auf einen Wert, der in etwa 256 entspricht. Auf eine zwei reagiert er mit einem Strom, der in etwa 512 entspricht.
Binär (high-byte|low-byte) würde das ganze also 00000001|00000000 bzw. 00000010|00000000 bedeuten.
"Aha", dachte ich mir, bringt der als irgendwie High-Byte und Low-Byte durcheinander. Nun habe ich mit High- und Low-Byte Aufschlüsselung die beiden Bytes vertauscht und separat mittels Typecast in Character umgewandelt und zu einem String zusammengefügt. Nach langem rumtesten: der Inhalt des ersten Bytes wird komplett ignoriert, der Inhalt des zweiten Bytes wird wieder wie ein High-Byte behandelt. Zumindest in den ersten drei Bits. Bit 5-7 des zweiten Bytes wurden wie Bit 0-2 des Low-Bytes behandelt, damit konnte ich also Werte von 0 bis 7 einstellen.
An dieser Stelle wurde es mir zu verwirrend und ich habe die Steuerung nochmal neu gestartet. Dann nochmal in "normaler" Byte-Reihenfolge die 1 geschickt. Daraufhin sprang der Strom auf einen Wert, der in etwa 2855 (+- 20) entspricht. Daraufhin habe ich den Befehl wiederholt und er sprang wieder auf 256. Und von da an immer auf 256.
Also dachte ich daran, dass irgendwas mit der Sende-Routine falsch konfiguriert ist, bin weg von Visa hin zu den Standard-GPIB-Kommunikationsroutinen (diese Dinger, die ne String-Zahl als Adresse erwarten), habe den Mode auf 2 gesetzt, was <LF> + EOI entsprechen sollte und habe den LF in meinem Sendestring entfernt. Das hat leider garnichts gebracht, exakt das gleiche Verhalten.
Schlussfolgerung:
GOTT, ICH WEIß NICHT WEITER!
Naja, seien wir konstruktiv: Die Kommunikation läuft schief. Insbesondere an den letzten beiden Befehlen kann ich erkennen, dass irgendetwas verschluckt / inkorrekt abgeschlossen wird, da er zwei identische Befehle direkt nach der Initialisierung unterschiedlich behandelt. Ich weiß nur leider nicht, was schiefläuft.
Kann jemand helfen?
Probleme bei IEC Bus Kommunikation mit Word-Item - jg - 03.12.2010 10:29
Bitte LVF-Regeln lesen und beachten. Screenshots bitte hier im Forum hochladen. Danke.
Gruß, Jens
Probleme bei IEC Bus Kommunikation mit Word-Item - unicorn - 03.12.2010 10:40
So wäre ich auch vorgegangen.
Du solltest noch mal versuchen den IEC mitzulesen und zu sehen, welche Zeichen tatsächlich gesendet werden. Vielleicht ist ja doch noch ein Fehler im TypeCast. Kannst ja auch noch mal Dein VI hochladen.
Muss eventuell von der Magnetsteuerung noch ein Bestätigungswert gelesen werden, bevor der nächste Befehl gesendet wird?
Probleme bei IEC Bus Kommunikation mit Word-Item - Kasi - 03.12.2010 11:03
Hallo unicorn,
danke erstmal für die Bestätigung meiner Ideen
Mein "Programm" ist wirklich nur das beschriebene Vorgehen (das ist nicht das Original, daher ne leere Visa-Konstante):
Version: 9.0.1
[attachment=31016]
Ausgelesen wird bei der Magnetsteuerung laut Anleitung und Originalprogramm nie etwas.
Den IEC kann man über MAX Spy mitlesen, richtig? Werde ich tun, allerdings komme ich erst Dienstag wieder dazu.
Grüße,
Kasi
Probleme bei IEC Bus Kommunikation mit Word-Item - Lucki - 03.12.2010 14:35
Bin in Zeitdruck, nur ganz kurz:
Hier hilft die reine Logik weiter. Das zu übertragende Low-Byte (ich schreibe immer in Hex) liegt im Bereich 0..FF- Es kann also z.B auch das Ende-Zeichen 0A enthalten, und das führt direkt in die Katastrophe, wenn das dann als Steuerzeichen interpretiert wird. Die zu übertragene Information darf also dieses Zeichen nicht enthalten. Wie macht man das? Indem man z.B statt des Bytes FF (als Zeichen nicht darstellbar) die lesbare zweistellige Zeichenkette "FF" sendet, manchnmal sogar (aber eher selten, hier vermute ich nicht) wird die dreistellige Zeichenkette "255" übertragen.
Also: nicht die numerischen Bytes mit Typecast in einstellige, z.T kryptische Strings konvertieren, sondern mit der Funktion Bytes to Hex in normal lesbare zweistellige HEX-Strings.
Probleme bei IEC Bus Kommunikation mit Word-Item - Kasi - 03.12.2010 17:02
Hallo lucki,
auch für diese Info erstmal danke. Das Gegenargument gegen typecast sehe ich voll ein, eine "10" zu übermitteln wäre so unmöglich, da es ständig zu einem <lf> führen würde.
Allerdings verstehe ich dein Lösungsargument nicht. Das Gerät erwartet drei Bytes, und stattdessen schicke ich ihm 5 Bytes (2 Hexzeichen für jeweils low- und high-byte + <lf>) und erwarte dann, dass das Gerät schon weiß, dass ich gerade versuche, mit ihm hex zu sprechen? Ich würde dann eher vermuten, dass er den Anfang der Hex-Nachricht, also beispielsweise "F", als das erste Byte ansieht und das als Highbyte mit Ascii-Code dezimal 70 wertet.
Aber ich werde es auf alle Fälle versuchen.
Grüße,
Kasi
Probleme bei IEC Bus Kommunikation mit Word-Item - Lucki - 04.12.2010 12:05
Ich bin mir der Schwäche meiner Argumentation bewußt. Beim IEC-Bus ist ja alles genau genormt, und deshalb funktioniert der (im Gegensatzt zu den COM-Schnittstellen) eigentlich immer problemlos. Nur eben das Datenformat selbst ist nicht genormt. (oder bei IEEE488.2 doch?)
Die Regel ist allerdings eher die Übertragung als ASCII-Dezimal oder ASCII-Hex und nicht das Senden dar Bytes direkt.
Beim Googeln habe ich nur diesen Hinweis gefunden:
Zitat:All commands and most data use the 7-bit ASCII or ISO code set, in which case the eighth bit, DIO8, is either unused or used for parity.
Was mich aber wundert: Warum benutzt Du die VISA-Funktionen, und warum nicht die GPIB-Funktionen unter Instrumenten-IO/GPIB ? Ich kann mir nicht vorstellen, da bei Dir das EOI beim letzten Byte mit gesendet wird.
Dein Beispiel für Senden einer "1" inklusive Senden von <LF> und EOI würde dann etwa so aussehen:
[attachment=31039]
Das Datenformat ist bei Dir auch nicht eindeutig. Zu vermuten ist:
0..4095 = 0..4095
4096 = Vorzeichenwechsel-Kommando
4097..8191 = -1..-4095
Richtig so?
Probleme bei IEC Bus Kommunikation mit Word-Item - Y-P - 04.12.2010 12:09
Um mit meinen GPIB-Geräten zu kommunizieren verwende ich auch immer VISA. Vielleicht ist es aber in dem Fall echt besser, mal die GPIB-Funktionen zu verwenden.
Gruß Markus
' schrieb:Was mich aber wundert: Warum benutzt Du die VISA-Funktionen, und warum nicht die GPIB-Funktionen unter Instrumenten-IO/GPIB ?
Probleme bei IEC Bus Kommunikation mit Word-Item - Kasi - 04.12.2010 12:56
Zitat:Was mich aber wundert: Warum benutzt Du die VISA-Funktionen, und warum nicht die GPIB-Funktionen unter Instrumenten-IO/GPIB ? Ich kann mir nicht vorstellen, da bei Dir das EOI beim letzten Byte mit gesendet wird.
ich arbeite immer lieber mit Visa Funktionen, da alleine die Adress-Kontrollen wesentlich cleverer sind als die Adress-Strings der Gpib-Kontrollen. Und alles, was ich bisher über Visa weiß, verstehe ich so, dass es letztlich auf die gleichen Routinen zurückgreift, sobald das Gerät als GPIB identifiziert wird. Trotzdem habe ich die Kommunikation wie oben in meinem kleinen Roman bereits erwähnt auch mit dieser reinen GPIB Schreibroutine durchgeführt (also ziemlich genau dein Beispiel, nur dass der Mode auf 2 steht, Mode 1 wäre <cr> + EOI), allerdings mit genau dem gleichen Fehlverhalten.
EOI sollte auf jeden Fall mit der Visa-Funktion mitgesendet werden, wenn ich es nicht explizit in den Message based settings ausstelle, zumindest habe ich die Dokumentation dazu so verstanden
Zitat:Das Datenformat ist bei Dir auch nicht eindeutig. Zu vermuten ist:
0..4095 = 0..4095
4096 = Vorzeichenwechsel-Kommando
4097..8191 = -1..-4095
Richtig so?
Fast. Nur die letzte Zeile würde ich so nicht sehen. Der Vorzeichenwechsel ist hier eine Art NOT - Kommando, welches die Polarität ändert. In der Anleitung wird dann auf explizit davor gewarnt, das Vorzeichen bei bereits angelegtem Strom zu ändern, da sonst die induktive Last während des Feldrichtungswechsels zu hoch wäre. Also sind alle Zahlen > 4096 erstmal gefährlich, da jede Zahl, die das Bit 4 auf 1 setzt zur potentiellen Katastrophe führt. Neben diesem worst case würde ich die Anleitung dann so verstehen, dass er die 3 most significant bits abschneidet und den rest wie gehabt behandelt, also 0 bis 4095 und evtl ein Vorzeichenwechsel.
Danke nochmal für die Lösungsansätze.
Probleme bei IEC Bus Kommunikation mit Word-Item - unicorn - 04.12.2010 22:28
Hast Du zum HP-Basic auch ein Handbuch. Im dem HP-Basic statement "OUTPUT @Magnet USING "W";0" müsste "W" bedeuten, dass eine Interger binär ausgeben wird. Stimmt das?