Zeitproblem des RTS-Signals der RS232

Hallo,

ich will mittels des RTS-Signals der RS232 an einem Treiber-Schaltkreis zwischen Senden und empfangen umschalten, weil für beides nur eine Leitung verwendet wird.
Dazu schalte ich es im VI ein, sende meine Daten (4 Byte bei 9600 Baud) und sofort danach weise ich RTS wieder Low zu ("unasserted" beim VISA-Eigenschaftsknoten). Es sollte eigentlich ohne Zeitverzögerung gehen. Dann lese ich in einer Wiederholungsschleife die Antwart ein.

Hardware seitig ist alles in Ordnung. Das Signal wird eingeschaltet, die Datenbits werden unverzüglich ausgegeben.

Das Problem ist jetzt, daß die Antwort der Gegenstelle etwa 10 ms nach dem letzten Bit der Anfrage gesendet wird, das RTS-Signal aber für 110 bis 120 ms auf High bleibt und ich quasi die Antwort verschlafe, denn wenn die Lese-Schleife aktiv wird, ist die Antwort schon lange durch.

Hat jemand von Euch eine Idee woher diese Zeitverzögerung kommen kann?

(Einstellungen:
9600 Baud, Timeout 0, 8 Datenbits, keine Parität, 1 Stopbit, keine Flußsteuerung)

Gruß Andreas

Was meinst du mit nur einer Leitung, wieviele Verbindungen hast du ? Pin's
Geht es denn nicht ohne das setzten von RTS ? (Wird das nicht autom. gesetzt durch das lesen, bez. auf 0 nach dem Senden)
RTS auf 0, sagt ja der Gegenstelle, dass sie Daten senden kann.
Wenn du weisst wieviele Byte zurückkommen verwende doch das "Anz. Byte an Ser.Port", die sollten im Buffer sein.
Kennst du Portmon von Sysinternals (jetzt Microsoft) ? Damit kannst du die Timing und Daten anschauen.
Bei einem kurzen Test bei mir, geht das setzen in >1ms.

Hoffe es hilft

Hallo RoLe,

das ganze ist ein Schnittstellenumsetzer.

Mit 1 Leitung meine ich 1 Leitung, die abwechselnd für Sende- und Empfangsbetrieb benutzt wird, also halbduplex. Und mit dem RTS-Signal der RS232 will ich an dem Treiberschaltkreis zwischen Senden und Empfangen umschalten, damit die Daten von der RS232 gesendet werden können und die Antwortdaten an die RS232 kommen.

RTS schalte ich "manuell", weil ich von meiner Gegenstelle keine CTS bekomme. Deswegen kann ich kein Hardware-Handshake machen.

Anzahl der Bytes im Puffer bringt mir momentan nichts, weil ich aufgrund des beschriebenen Fehlers an der RS232 keine Antwort bekomme. Der Treiber geht nicht in den Tristate (weil RTS nicht abgeschaltet wird) und die Gegenstelle schafft es nicht, sich gegen den Treiber durchzusetzen.
Als Hilfsmittel habe ich ein Zweikanal-Oszi. Dort sehe ich, daß eine Antwort gesendet wird, die bewirkt aber keine signifikante Pegeländerung, so daß der Empfänger-Teil des Treiberschaltkreises (der ja ohnehin wegen des noch aktiven RTS deaktiviert ist) nichts mitbekommt.

Nun zu den neuen Erkenntnissen:

Das ganze ist scheinbar abhängig von Rechner und viel wahrscheinlicher abhängig davon, ob das ganze in der Entwicklungsumgebung oder als Applikation ausgeführt wird.

-auf meinem Ziel-PC habe ich es auf den zwei Rechnereigenen Schnittstelllen und auf einer NI 16-fach-seriellen Karte ausprobiert, überall das gleiche. (Hier allerdings ausgeführt nach Laden des Sub-VIs aus einer anderen .exe über Menü-Leiste -> Datei -> öffnen)
-auf meinem Entwicklungs-PC kann ich das Sub-VI (unter LV8.5) separat ausführen und - siehe da - das krasse Gegenteil: RTS wird wieder auf Low gezogen, noch während das erste der 4 Bytes gesendet wird. VISA Write schickt den String also nur in den Sendepuffer der RS232 und schaltet RTS um, noch bevor alles gesendet ist. -> Abhilfe: Parallel zum VISA-Write starte ich eine Sequenz, die 5ms wartet (für das Senden der 4Byte werden ca. 4 ms benötigt) und dann, unabhängig von der Abarbeitungszeit von Write, RTS wieder zurücksetzt. Funktionert in der Entwicklungs-Umgebung wunderbar, aber auf dem Ziel-PC gibt's keine Veränderung.
- nun habe ich eine exe aus dem einzelnen Sub-VI gemacht und lasse diese probehalber auf dem Ziel-PC laufen und es läuft !

Wie kann das sein? Es scheint also so, als ob VISA-Write unterschiedlich lange zur Ausführung braucht. Einmal extrem kurz, so daß der nächste Befehl ausgeführt wird, bevor die Daten alle gesendet sind und einmal extrem lang, so daß der anschließende Befehl viel zu spät kommt.

habe noch mal die derzeitge Änderung als Bild angehängt

Gruß Andreas

Hallo,

es funktioniert doch

Problem Nr1: Bei der Ausführung auf dem Ziel-PC über Aufruf von Datei-> Öffnen keine Änderung des Verhaltens
Mein Fehler. Das SubVI wurde auch in der Aufrufenden Exe verwendet (die unverändert geblieben ist), und damit immer nur aus dem Speicher geladen und nicht aus der aktualiserten Bibliothek (wie ich es wollte). Also habe ich auch die Applikation neu kompiliert und damit ging dann auch die gestern beschriebene Lösung mit der zum VISA-Write-VI parallelen Sequenz und den 5ms Wartezeit.

Außerdem habe ich festgestellt, daß auch an meinem Entwicklungs-PC und in der exe, in der ich nur das Sub-VI kompiliert habe, der allererste Aufruf den gleichen Fehler hat. Alle nachfolgenden sind in Ordnung. Das hat mich auf die Idee gebracht, warum die Ausführung der VISA-Write-Funktion so unterschiedlich lange dauert:

In der SubVI-exe und in der Entwicklungsumgebung wird nur beim ersten Aufruf die Schnittstelle geöffnet und bleibt offen, weil ich sie nicht explizit schließe. Wenn ich das SubVI auf dem Zielrechner aus einer anderen Exe heraus öffne und als separates VI starte, schließt die Runtime-Engine vermutlich automatisch die Schnittstelle nach der Abarbeitung, so daß sie bei jedem Aufruf erneut geöffnet werden muß und damit wieder so lange braucht.

Wieder was gelernt.

Gruß Andreas