LabVIEWForum.de

Hallo,

Ich habe folgendes Problem:
Ich möchte einen Frequenzgenerator ansteuern (Hameg HM8131-2).
Dies passiert über RS-232. Das Gerät unterstützt Software-Handshake (Xon/Xoff). Wenn ich jedoch die Befehle über VISA direkt hintereinander an das Gerät schicke, bekomme ich einen Fehler, obwohl ich bei Labview bei der Initialisierung den Handshake an geschaltet habe (Die Einstellungen am Gerät stimmen auch mit denen, die ich in LabVIEW gemacht habe überein).

Wenn ich nach jedem Befehl ein Delay von 50 ms einbaue, funktioniert alles einwandfrei, aber ich frage mich, ob das eigntlich nicht auch so gehen müsste und labview sich darum kümmern sollte, wenn der Handshake aktiv ist?

Ich habe versucht, direkt die Buchstaben einzeln auf die Schnittstelle zu schreiben, um herauszufinden, ob ich irgendwelche Steuerzeichen zurück bekomme.
(Die Ergebnisse habe ich in ein Hex-String Array geschrieben).
Die Einstellungen wurden alle am Gerät vorgenommen, aber im Array steht nichts.
Heißt das dann, dass ich garkeine Steuerzeichen bekomme, also eigentlich auch garkein Handshake aktiv ist?
(Anbei eine Grafik von meinem Test-VI.

Vielen Dank für Eure Hilfe im Voraus,
Viele Grüße

(01.07.2011 17:38 )Just Me schrieb: [ -> ]Wenn ich nach jedem Befehl ein Delay von 50 ms einbaue, funktioniert alles einwandfrei, aber ich frage mich, ob das eigntlich nicht auch so gehen müsste und labview sich darum kümmern sollte, wenn der Handshake aktiv ist?

Du liegst hier ganz falsch. Das Handshake ist nicht dazu da, das Frage-Antwortspiel der Kommando/Antwortsequenzen zu synchronisieren, sondern einzig dazu, den Überlauf der beidseitigen Empfangspuffer zu verhindern. Der Empfangspuffer auf Labview-Seite könnte z.B 4 kByte groß sein. Wenn die Gegenstelle sendet, Labview aber längere Zeit am Empfang verhindert ist, dann sendet Labview bei drohendem Empfangspuffer-Überlauf mit Xoff eine höfliche Bitte an die Gegenstelle, vorerst nicht weiter zu senden.
Ich führe das jetzt nicht weiter aus, nur so viel: bei Deinen paar Bytes kommt Xon/Xoff nie zum Einsatz, Wahrscheinlich wird ohne die Xon/Xoff Konfiguration alles genau so funktionieren.
Bei Dir liegt dieser Fehler vor: Du synchronisierst überaupt nicht, sondern willst Null µs nach Senden eines Kommandos sofort wissen, wie viele Bytes angekommen sind (das sind 0 oder höchstesn 1 Byte) und liest das aus, ohne das Ende der Nachricht abzuwarten.
Es kommt aber darauf an, erst zu lesen, wenn die vollständige Nachricht im Empfangspuffer ist.
Und in einem hast Du Recht: 50ms warten funktioniert zwar, es ist aber nicht die feine Art.
Sondern so: In der Regel endet eine Nachricht mit einem Endezeichen (z.B CR).
In der Konfiguration ist standardmäßig Endterm mit x0A aktiviert.
Alles was Du ändern muß ist: An den Input "Anzahl bytes zu lesen" einen hohen Wert anzuschließen. Also z.B 100 bytes, wenn Du maximal 50 erwartest. Das Read VI wartet nicht bis zu dieser Anzahl, sondern wartet und liest die ganze Nachricht aus, sowie ein CR eintrifft. Das nenne ich ideales Syncronisieren, im Gegensatz zum Einfügen von Wait.
Zu Deiner Entlastung aber sei gesagt: mit der überflüssigen, fehlerhaften Verwendung der Funktion Bytes im Puffer fangen sie hier im Forum fast alle an..

Hallo,

zunächst einmal vielen vielen Dank für Deine Antwort!

Das kleine VI, welches ich gepostet habe, war auch nur zum Test um herauszufinden, ob ich beim Schreiben auf die Schnittstelle irgendwas zurück bekomme.
Ich habe das jetzt ausprobiert, was Du gesagt hast.
Nachdem ich die String-Termination richtig eingestellt hab, hat das auch funktionert

Jetzt habe ich aber immernoch folgendes Probelm:
Wenn ich die VISA-Session initialisiere und dann Befehle schreibe, muß ich immer ein Delay nach dem jeweiligen Befehl einbauen (ich habe jetzt einfach einmal ein Delay von 50 ms gewählt).
Wenn ich das mache funktioniert das auch einwandfrei.
Aber müsste sich nicht LabVIEW selbst darum kümmern, dass das mit der Synchronisation hinhaut?
Oder muß ich jetzt nach jedem Befehl einfach eine Wartezeit einbauen?

Anbei das VI, wie es jetzt funktioniert.

Vielen Dank für Deine Mühe,
Liebe Grüße

---

P.S.: Was ich noch vergessen habe:

Wenn ich das Delay nicht einbaue, bekomme ich von LabVIEW den folgenden Fehler:

Error -1073807339 occurred at VISA Read in HM8131-2-Test-Read-2.vi

---

Possible reason(s):

VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.

(04.07.2011 11:32 )Just Me schrieb: [ -> ]Wenn ich das mache funktioniert das auch einwandfrei.
Aber müsste sich nicht LabVIEW selbst darum kümmern, dass das mit der Synchronisation hinhaut?

Das kommt darauf an. Aber auch ich habe ein gesunde Allergie gegen Waits im Allgemeinen und bei seriellen Schnittstellen im Besonderen, und würde auch nicht eher Ruhe geben, bis die weg sind.
Den Fehler kann ich mir nicht erklären: Die Waits stehen vor den Write-Befehlen, es wird aber ein Fehler beim Lesen gemeldet, wo kein Wait davor steht.
Timeout wird in der Visa-Config mit eingestellt und beträgt standardmäßig 10sec. Daß diese Zeit überschritten wurde, kann ich mit nicht vorstellen. Kannst ja probehalber mal einen anderen Wert anschließen.
Normalerweise quittiert ein Gerät mit "OK" oder so, wenn ein Kommando gesendet wurde, aber keine Daten als Antwort erwartet werden. Erst danach sollte ein weiteres Kommando gegeben werden. Schau mal nach, vielleicht solltest Du nach dem ersten Schreibbefehl gegebenenfalls das "OK" lesen, anstatt die Wartezeit einzubauen.

Ich hatte neulich ein ähnliches Problem. Ich habe auch wunderbar gemessen, und auch Werte erhalten. In unregelmäßigen Abständen erhielt ich aber eine Meldung mir "...timeout..."

Bei mir stellte sich raus, dass einfach die Synchronisation zwischen PC und Messhardware nicht immer gegeben war. Im Prinzip half dabei nur, den entsprechenden Datenblock nicht zu nutzen und die Komunikation beim nächsten Versuch synchron wieder aufzubauen.

Grüße,

Takuro

Hallo zusammen,

habe jetzt nach jeder interaktion mit dem Gerät eine Wartezeit von 50 ms eingebaut, dann läuft alles einwandfrei...
Ist zwar furchtbar unsauber und es ärgert mich, dass ich keine bessere Alternative finde, aber das lasse ich jetzt erstmal so.

Wenn mir einer eine bessere Lösung für dieses Problem sagen könnte, wäre ich sehr dankbar.

Viele Grüße