RS232 lesen und schreiben eventgesteuert

Hallo Forengemeide,

habe noch nicht viel Erfahrung mit LabView. Momentan versuche ich schon seit einer Woche mit dem Arduino über die serielle Schnittstelle zu kommunizieren.

Zum Programm:
Die Daten auf der Schnittstelle sollen Buchstabenweise eingelesen werden bis zu einem NL.
Sobald auf Senden gedrückt wird soll die Eingabe gesendet werden. Das Lesen funktioniert einwandfrei aber bei Senden haperts.
Anscheinend kommen die Daten manchmal nicht richtig beim Controller an.

Kann mir vielleicht jemand sagen worans liegt? Oder wie mans einfacher umsetzen kann?

MfG Andreas

Anzeige

Hallo Andreas,

beim Senden hast du den DATAFLOW nicht beachtet, die zeitliche Abfolge von Senden und Button auswerten ist nicht gegeben.

Beim Empfangen kannst du NL als TermChar nutzen, dann brauchst du keine Einzelzeichen lesen, sondern den kompletten String mit einmal...

Danke für die Antwort.
Hm ok ich weiß nur nicht wie ichs anders machen soll. Ist es denn überhaupt möglich in getrennten while Schleifen zu lesen und zu schreiben?
Ja das mit TermChar werd ich gleich mal ausprobieren.

(11.10.2013 21:51 )theandreas schrieb:  Ist es denn überhaupt möglich in getrennten while Schleifen zu lesen und zu schreiben?

Hallo Andreas,

also wenn das nicht ginge, wären LabView-Programme oft deutlich hakeliger
Du musst dich in beiden Schleifen auf dieselbe (geöffnete) Schnittstelle beziehen, was du ja schon tust. Dein Problem ist lediglich, dass du in die Schleife gehst, sendest und dann darauf wartest, dass einer den Knopf Senden drückt.

Die Sendefunktion gehört in das Knopfereignis hinein!

Gruß, Marko

(11.10.2013 22:54 )Trinitatis schrieb:  Die Sendefunktion gehört in das Knopfereignis hinein!

Erledigt!

Schreiben funktioniert eventgesteuert einwandfrei.
Solange ich den Eingang polle lauft alles ohne Fehler.


Versuche ich aber das Einlesen auch eventgesteuert hagelts Errormeldungen:
VISA Open in RS232 Read event write event.
Was bedeutet das?

Tasache ist, dass das eventgesteuerte Read hier völlig überflüssig ist. Mittels TermChar- Aktivierung (Default!) kann man auch so erreichen, dass Read "eventgesteuert" funktioniert.
Das Event, auf das Read wartet, ist das Zeilenendezeichen. Wenn das kommt, wird der Lesepuffer von Read gelesen - vorher nicht. Allerdings wird read auch ausgeführt, wenn die angeschlossene Zahl von Bytes im Puffer erreicht ist. Damit das nicht geschieht, ist ein genügend große Zahl von Bytes anzugeben (Größer als die zu erwartende Antwort).
Der Wartemodus von Read wird auch bei Timeout beendet. Bei Deiner Konstruktion mit zwei Schleifen muss der Timout-Fehler abgefangen werden (Unten im Beispiel wir der Einfachheit halber jeder Fehler abgefangen). Timeout ist bei Deiner Konzeption mit zwei Schleifen sogar erforderlich und sollte nicht zu groß gewählt werden, damit der Stop-Taster regelmäßig gepollt wird.
Deine Konzeption mit zwei unabhängigen Schleifen hat den Vorteil, dass Du auch Meldungen empfängst, die vom Controller autark, ohne vorangegangenes Kommando, gesendet wurden. Solche Meldungen wird es aber vielleicht eher nicht geben.
   

Herzlichen Dank jetzt ist mir einiges klarer geworden. Ich hab schon das ganze Internet durchsucht, aber nirgends was aufschlussreiches gefunden. Hast du evtl einen Link oder kennst ein Buch, in dem das genauer beschrieben ist?

(12.10.2013 13:24 )Lucki schrieb:  Deine Konzeption mit zwei unabhängigen Schleifen hat den Vorteil, dass Du auch Meldungen empfängst, die vom Controller autark, ohne vorangegangenes Kommando, gesendet wurden. Solche Meldungen wird es aber vielleicht eher nicht geben.

Doch genau das brauche ich. Auf dem Board befindet sich ein Taster, sobald der gedrückt wird, schickt mein Controller ne Meldung.

Eine Frage hätte ich noch: Ich hab jetzt die ganze Zeit die Funktion "Bytes at Port" verwendet. In den zwei Büchern, die ich da hab
wirds auch so gemacht, aber nicht erläutert warum. Wann brauch ich denn die eigentlich?

(12.10.2013 14:28 )theandreas schrieb:  Ich hab jetzt die ganze Zeit die Funktion "Bytes at Port" verwendet. In den zwei Büchern, die ich da hab
wirds auch so gemacht, aber nicht erläutert warum. Wann brauch ich denn die eigentlich?

Hallo Andreas,

die Bytes, die du empfängst werden im Normalfall erstmal in einem Puffer abgelegt, damit du sie nicht adhoc weglesen musst. Die Funktion "Bytes at Port" gibt dir genau diese Anzahl der im Puffer liegenden bytes zurück. So könntest du also nachsehen, wieviel Bytes schon da sind, ohne sie lesen zu müssen.


Gruß, Marko

Zusatzinformation zur Antwort von Marko:
Die Funktion "Bytes on Board" wird sehr oft von Anfängern (- die nicht wissen, dass die Steuerung über Zeilendezeichen die sehr viel bessere Methode ist -) in Verbindung mit der Read-Funktion verwendet,
Steuerung mit Zeilenendezeichen:
Kommando senden, dann sofort lesen. Read wartet, bis das Zeilendezeichen im Puffer ist und liest die gesamte empfangene Nachricht.
Steuerung mit Bytes on Board:
Kommando senden. Dann Wait-Funktion aktivieren. Die Wartezeit muß so groß gewählt werden (inklusive Sicherheitsreserve), dass nach Ablauf der Zeit sich die gesamte Nachricht im Puffer befinden sollte.
Jetzt kann man aber nicht einfach lesen, denn man muß zum Lesen die Anzahl der Bytes kennen. Sind es zu wenig, dann wird nicht die gesamte Nachricht gelesen, sind es zu viele, wartet Read bis zum Timeout auf die noch fehlenden Zeichen und gibt dann eine Fehlermeldung statt des Strings aus.
Mann muß also vor dem Read noch "Bytes on Board" lesen, um dann mit Read genau die Anzahl von Bytes zu lesen, die im Puffer sind.

Zitat:Herzlichen Dank jetzt ist mir einiges klarer geworden

Schön, nur ist es so, dass man, wenn man ein Beispiel macht, die Hardware nicht zur Verfügung hat und deshalb immer im Dunkeln tappt. Deshalb wäre ein klare Rückmeldung, ob es so funktioniert hat, interessant gewesen. Oder kann man obigen Satz in diesem Sinne interpretieren?

(13.10.2013 12:29 )Lucki schrieb:  Schön, nur ist es so, dass man, wenn man ein Beispiel macht, die Hardware nicht zur Verfügung hat und deshalb immer im Dunkeln tappt. Deshalb wäre ein klare Rückmeldung, ob es so funktioniert hat, interessant gewesen. Oder kann man obigen Satz in diesem Sinne interpretieren?

Oh sorry . Dein Programm funktioniert natürlich super. Autarke Meldungen werden korrekt empfangen, Befehl und Antwort klappt ebenfalls.
Werde in den nächsten Tagen mal versuchen das Programm zu erweitern, falls dann doch noch hakt, melde ich mich nochmal.

Danke für die Erklärungen. Hätte nicht gedacht, dass das so kompliziert ist :-).