Fehler bei RS232 Bytes at Port = 0

Hallo Zusammen,

Beschreibung:
Ich lese mehrere M-Bus Geräte über die RS232 Schnittstelle und Pegelwandler (Relay PW20) aus.
Hierzu sende ich Befehle (HEX bzw. ASCII) an die Geräte. Und gebe vor wieviel Bytes at Port ausgelesen werden sollen.
Die Befehle als auch die Vorgabe für Bytes at Port werden nacheinander im Array durchlaufen.
Hier der Aufbau des Visa schreibe- und leseteils:

   

Problem: Das Problem ist, dass irgendwann - erst nach mehreren Durchläufen des Programms Bytes at Port = 0 anstehen und die
Bedingung >= der Bytes at Port Vorgabe nicht erfüllt ist. Somit hängt das Programm an dieser Stelle fest.

Frage1: Woran könnte es liegen, dass nach einer Anzahl v. Durchläufen (ich glaube es ist nicht immer die selbe Anzahl an Durchläufen) plötzlich 0 Bytes at Port anstehen.
Frage2: Könnte ich für diesen Fall eine Art Sicherheit einbauen sodass beide Arrays wieder neu von vorne abgearbeitet werden sobald eine 0 ansteht.

Danke schon mal für eure Tipps und Hinweise!
LG
Newlabviewer1

Anzeige

Zunächst mal: Das Programm schreit nach Ersetzung der while-Schleife durch eine For-Schleife!
Das Programm müßte an sich funktionieren, es ist aber so keine gute Lösung. Das Beste wäre, wenn die gelesenen Antwort mit einem Abschlusszeichen endet. Dann könnte man mit TermChar zu arbeiten - was ohnehin schon aktiviert ist. Das ist nach meinen Erfahrungen die stabilste Art der Kommunikation.
Ein weitere Möglichkeit wäre, nach Senden des Kommandos eine Zeitlang zu warten, bis alle Bytes im Empfangspuffer sein müssten. Und dann alles was im Empfangspuffer ist auszulesen.
Ganz allgemein sollte man bei Serieller Kommunikation über die feindselige Außenwelt hinweg immer mit gelegentlichen Fehlern rechnen. Ein gutes Programm sollte gewisse Fehler abfangen und im Falle eines Falles vernüftige Entscheidungen treffen, anstatt sich zu beenden oder alles zu blockieren.

Hallo Lucki,
Danke schonmal für deine Tipps.

Ich habe die While Schleife durch die For Schleife ersetzt - hattest natürlich recht.
Ich habe auch 200ms Zeit vor dem Empfangspuffer eingebaut.
Der Fehler mit 0 Bytes at Port tritt dennoch auf sollte aber auch damit nichts zu tun haben.
Das mit dem Abschlusszeichen funktioniert leider nicht da dies variiert (2 Varianten).

Hättest du evtl. einen Vorschlag wie ich solch einen Fehler Abfangen kann?
Könnte ich das Programm automatisch neu starten lassen.

Danke nochmals!

   

(05.04.2011 15:29 )newlabviewer1 schrieb:  Hättest du evtl. einen Vorschlag wie ich solch einen Fehler Abfangen kann?

Ja, schon, aber warum soll ich mich hier wortreich abschinden, wenn man das am VI machen könnte. Du müßtest Dich nur entschließen, das VI zu posten.

Den Fehler kann man so erklären, daß die Gegenseite ab und zu das gesendete Kommando nicht hört. Dann kommt natürlich keine Antwort, und die Schleife bleibt hängen. Es sind immer Null Byte im EmpfangsPuffer. Es muß also nicht unbedingt am VI liegen.

Hier das Vi.
Allerdings in LV 7.1
Gruß

  RS232_COM.vi (Größe: 67,3 KB / Downloads: 301)

(05.04.2011 15:29 )newlabviewer1 schrieb:  Hättest du evtl. einen Vorschlag wie ich solch einen Fehler Abfangen kann?

IMHO bleibt dir nur ein Timeout übrig, soll heißen, wenn nach x Sekunden immer noch keine Antwort gekommen ist, dann ist offenbar etwas beim Senden des letzten Kommandos schief gegangen. Dann Abbruch oder nochmal versuchen oder, oder, oder...

Gruß, Jens

Anzeige

Beipiel nach Jens für X=200ms. Bei Timeout wird in die Ausgabe ein leerer String geschrieben. Sicher nocht schön - aber das Leben geht weiter. (An das Wait wollte ich 5ms anschließen)
   
Bessere(?) Alternative: Wenn keine Antwort kommt, wird das gleiche Kommando 3 mal wiederholt, und erst dann die Sache aufgegeben und der leere String in die Ausgabe geschrieben. (F: Wieso 3 mal? A: Keine Ahnung)

Hallo Zusammen,
ich habe nun den Timeout in meinem Programm umgesetzt, anfags war die Wartezeit noch zu kurz und die Antworten unvollständig aber nun scheint es einigermaßen stabil zu laufen...
der Tipp mit dem , mehrfachen wiederholen des Befehls ist auch nicht schlecht...-aber noch nicht umgesetzt.

Bei meinen ersten Tests lief alles gut, ich muss das Programm aber noch über einen längeren Zeitraum (ein paar Stunden) laufen lassen um sicher gehen zu können, dass es funktioniert.

Danke nochmal an euch!