(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..
