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:
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) END
Meine Interpretation: @Magnet ist der Kommunikations-Handler für das spätere Programm, 715 spaltet sich auf in 7 (-> IEC-Bus) und 15 (->Adresse), mit Semikolon wird noch etwas angehängt, nämlich Linefeed und EOI.
Gesprochen wird dann mit dem Gerät auf folgende Art:
Magnetfeld auf 0 fahren:
Code:
OUTPUT @Magnet USING "W";0
Polarität ändern:
Code:
OUTPUT @Magnet USING "W";4096
Magnetfeld auf einen bestimmten Wert ("<X>" ist hier ein Platzhalter für Werte zwischen 0 und 4096) fahren:
Code:
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
