LabVIEWForum.de
COM Port RS485 Kommunikation - Druckversion

+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: COM Port RS485 Kommunikation (/Thread-COM-Port-RS485-Kommunikation)

Seiten: 1 2


COM Port RS485 Kommunikation - Mistered - 11.05.2020 08:35

Hallo,
mal wieder auf eine neue Schwierigkeit gestossen. Wir wollen Temperatur/Feuchte Sensoren über RS485 abfragen. Verkabelung und Schnittstelle sollten funktionieren, da das aus einem anderen Programm heraus funktioniert. Daher gehe ich davon aus, dass es ein programmierproblem ist. Angehängt habe ich einen "versuchsaufbau", noch nicht aufgeräumt, schreibt auch nix weg, ist also nur zum testen wie ausgelesen wird. Sendebefehl besteht aus{H"ID""Befehl"}0D, danach wird der String empfangen aus dem dann die Werte extrahiert werden. Prinzipell funktioniert das, es kommen 135 Byte zurück, alles wie im Manual. Nur nicht immer. manchmal 127, 111 oder 109, wobei dann die wichtigen Teile fehlen. Ich umgehe das nun, indem ich nur die 135er verwerte, aber das ist ja keine Lösung. Woran könnte das liegen?
Schönen Gruß
ed


RE: COM Port RS485 Kommunikation - GerdW - 11.05.2020 08:43

Hallo Ed,

Zitat:Sendebefehl besteht aus{H"ID""Befehl"}0D, danach wird der String empfangen aus dem dann die Werte extrahiert werden. Prinzipell funktioniert das, es kommen 135 Byte zurück, alles wie im Manual. Nur nicht immer. manchmal 127, 111 oder 109, wobei dann die wichtigen Teile fehlen. Ich umgehe das nun, indem ich nur die 135er verwerte, aber das ist ja keine Lösung. Woran könnte das liegen?
Wenn du einen Link auf das Manual bereitstellen würdest, könnten wir das für dich nachlesen…

Du fragst 135 Bytes vom seriellen Port ab und bekommst eine dieser 3 Optionen geliefert:
1. 135 Bytes
2. Weniger Bytes, wenn das TermChar gelesen wurde
3. Weniger Bytes, wenn es zu einem TimeOut (oder einem anderen Fehler) kam

Da Option 1 ausscheidet: welche der anderen beiden Optionen trifft wohl zu?
Und wieso leerst du sowohl Transmit- als auch RecieveBuffer in jeder Iteration? Ich hatte bisher keinen praktischen Fall, wo das geholfen hätte…

Außerdem: Du musst nur die Parameter am VISAInit anschließen, die nicht den Standardwerten entsprechen.

Tipp: Bei Stringkonstanten (wie im Write-State) immer den Displaystyle anzeigen lassen - für deutlich bessere Codedokumentation…


RE: COM Port RS485 Kommunikation - Mistered - 11.05.2020 08:54

Hallo Gerd,
Ich frage entsprechend den Vorgaben ab. Wenns gut läuft kommen 135, das ist richtig, deswegen hab ich auf 135 eingestellt. Mit Bytes at port gehts auch nicht. Timeout ist es nicht. Der TermChar ist richtig, es soll ein 0D sein. TermChar deaktivieren geht auch nicht, dann kommt es zu TimeOuts. Nicht immer aber recht oft. Aber auch dann sind manchmal korrekte Rückmeldungen.

Manual ist im Anhang

Nachtrag 09:59, hatte ich eben nicht gesehehen:
Buffer leeren war nur ein Versuch den ich beibehalten habe, wirkliche Hilfe wars nicht, aber ich dachte schadet ja erstmal nix und kann wieder ohne probiert werden, wenn es läuft. Ähnlich wie die Visa-Einstellungen, das hab ich so übernommen. ich selber mach das eigentlich anders, aber so schadet es ja auch nicht.
den Tip mit dem Displaystyle nehm ich gern an, Danke


RE: COM Port RS485 Kommunikation - GerdW - 11.05.2020 09:46

Hallo Ed,

danke für das Manual.

Erstmal einfacherer Write-Code:
[attachment=60937]

Zum Read-Problem:
Häng doch mal ein paar typische Receive-Strings an, die eben nicht 135 Bytes lang sind.

Und frage mal 140 Zeichen mit VISARead ab: du solltest dann zuverlässig 135 Bytes bekommen. (Ich würde gleich auf "299" erhöhen.)
Siehe oben Option 2: man sollte mehr Bytes abfragen, als die erwartete Botschaft enthält, da ja sowieso beim TermChar der ReceiveString zurückgemeldet wird!


RE: COM Port RS485 Kommunikation - Mistered - 11.05.2020 10:12

Gut, den Platzhalter %d kannte ich nicht. Hab das jetzt mal eingebaut und die Bytes auf 200 gesetzt, aber ähnliche Ergebnisse, vielleicht etwas weniger Ausfälle. Hier ein richtiger String:
1;47.170; %rh;0;+;20.180; °C;0;=; ; --.--; ;0; ;020;V1.2-1;0020225158;Probe 1 ;000;6;053;V2.3-1;0061871951;HF5 ;000;2
Hier ein unvollständiger mit 127 Bytes:
; %rh;0;=; 1.930; °C;0;=; ; --.--; ;0; ;020;V1.2-1;0020312764;Probe 1 ;000;6;053;V2.3-1;0061792353;HF5 ;000;B
und 119:
=; 2.140; °C;0;=; ; --.--; ;0; ;020;V1.2-1;0020225158;Probe 1 ;000;6;053;V2.3-1;0061871951;HF5 ;000;0

ich brauche die Werte vor dem %rh und °C, der Rest ist nicht so wichtig


RE: COM Port RS485 Kommunikation - GerdW - 11.05.2020 10:16

Hallo Ed,

schön, dass du die Strings in die Forumsmessage kopiert hast, aber so fehlen leider die evtl. enthaltenen Steuerzeichen! Wie soll ich erkennen, ob der String durch ein korrektes CR (aka \r aka 0Dx) beendet wurde?

Zitat:Hier ein unvollständiger mit 127 Bytes:
; %rh;0;=; 1.930; °C;0;=; ; --.--; ;0; ;020;V1.2-1;0020312764;Probe 1 ;000;6;053;V2.3-1;0061792353;HF5 ;000;B
und 119:
=; 2.140; °C;0;=; ; --.--; ;0; ;020;V1.2-1;0020225158;Probe 1 ;000;6;053;V2.3-1;0061871951;HF5 ;000;0
Beide Strings enden mit der typischen Endekennung laut Manual: "000;checksum". Ich vermute, da war das korrekte CR noch hintendran!?

Also liegt der Fehler darin, dass du vorher entweder den Buffer (un)absichtlich gelöscht hast oder dort nicht den vollen String eingelesen hattest. Irgendein Grund muss es ja haben, dass du nur den zweiten Teil einer ganzen Botschaft einliest: der erste Teil ist vorher schon gelesen worden!


RE: COM Port RS485 Kommunikation - Mistered - 11.05.2020 10:24

Tschuldigung, is nich so leicht mit Anfängern wie mir:
127 mit Steuerzeichen:
;\s%rh;0;=;\s1.800;\s\s\B0C;0;=;\s\s;\s--.--;\s\s\s\s;0;\s;020;V1.2-1;0020225038;Probe\s1\s\s\s\s\s;000;6;053;V2.3-1;0061866947;HF5\s\s\s\s\s\s\s\s\s;000;7\r

Ja, dass vorne fehlt ist mir auch aufgefallen, ich weiss nur nicht warum. Daher hatte ich schlechte Programmierung vermutet. Aber das scheint ja so nicht grundsätzlich falsch zu sein. Insgesamt sieht es jetzt besser aus, weniger als 127 kamen erstmal nicht an

auf die Vermutung, das Teile gelöscht werden, hab ich nun das Transmit und Receive-Buffer flushen rausgenommen. Jetzt erhalte ich 143 Bytes, ziemlich konstant mit ein paar seltenen Ausfällen. Wäre jetzt die Frage, warum die da was löschen... Aber das ist nicht so wichtig. Vielleicht für Experten...
143 Bytes:
{H02rdd\s1;99.980;\s%rh;0;=;\s1.570;\s\s\B0C;0;=;\s\s;\s--.--;\s\s\s\s;0;\s;020;V1.2-1;0020312764;Probe\s1\s\s\s\s\s;000;6;053;V2.3-1;0061792353;HF5\s\s\s\s\s\s\s\s\s;000;B\r

Vielen Dank für die Denkanstösse!

Aber einen hab ich noch. Ich glaube es ist besser, die Daten den Sensoren über die Antwort zuzuordnen, das heisst wenn ich H03rdd zurückbekomme sind das die Daten von ID03. Dann ist es sicherer und man ist auch flexibler falls noch welche dazukommen.


RE: COM Port RS485 Kommunikation - GerdW - 11.05.2020 10:49

Hallo Ed,

Zitat:auf die Vermutung, das Teile gelöscht werden, hab ich nun das Transmit und Receive-Buffer flushen rausgenommen. Jetzt erhalte ich 143 Bytes, ziemlich konstant mit ein paar seltenen Ausfällen. Wäre jetzt die Frage, warum die da was löschen... Aber das ist nicht so wichtig. Vielleicht für Experten...
143 Bytes:
{H02rdd\s1;99.980;\s%rh;0;=;\s1.570;\s\s\B0C;0;=;\s\s;\s--.--;\s\s\s\s;0;\s;020;V1.2-1;0020312764;Probe\s1\s\s\s\s\s;000;6;053;V2.3-1;0061792353;HF5\s\s\s\s\s\s\s\s\s;000;B\r
Vielen Dank für die Denkanstösse!
Diese Vermutung hatte ich schon vor 2 Stunden geschrieben…
Wer ist "die" in dem Satz "warum die da was löschen"?
Nochmal: du musst mehr Bytes abfragen als du in der Message erwartest! Wenn du jetzt 140 Bytes liest (leider wieder kein aktuelles VI angehangen), liest du wieder 3 Byte zu wenig. Also doch meiner Meinung folgen und 299 Bytes abfragen…

Zitat:Ich glaube es ist besser, die Daten den Sensoren über die Antwort zuzuordnen, das heisst wenn ich H03rdd zurückbekomme sind das die Daten von ID03. Dann ist es sicherer und man ist auch flexibler falls noch welche dazukommen.
Ja!


RE: COM Port RS485 Kommunikation - Mistered - 11.05.2020 10:58

Hatte die Bytes dann auf Dein anraten 200 gesetzt. Na die Flush-Module. ich wollte nach dem Empfang den receive Buffer leeren und vor dem Senden den Transmit. war bestimmt ein Denkfehler.
Und das Vi ist dabei, der Vollständigkeit halber.

Bin gespannt, wieviel Denkfehler ich noch in dem Projekt habe...


RE: COM Port RS485 Kommunikation - GerdW - 11.05.2020 11:11

Hallo Ed,

Zitat:ich wollte nach dem Empfang den receive Buffer leeren und vor dem Senden den Transmit. war bestimmt ein Denkfehler.
Ja, das ist ein Denkfehler!
Wenn du einen Befehl sendest, dann sollte der auch ankommen und verarbeitet werden: kein Grund, den Transmit-Buffer mutwillig zu löschen!
Wenn du eine Antwort (vollständig) empfangen willst, solltest du auch den kompletten Receive-Buffer verwenden: kein Grund, den Buffer mutwillig zu flushen!

Zitat:Und das Vi ist dabei, der Vollständigkeit halber.
Dieses VI liest immer noch nur 135 Bytes und leert die Buffer mutwillig…