Fehlerhafte RS232-Kommunikation (KL6031)

forellengarten

forellengarten

Level-1
Beiträge
217
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein Stromzähler schickt seine Daten über einen RS232-Infrarot-Lesekopf auf die Beckhoff RS232-Klemme. Alle 2 Sekunden kommen exakt 474Byte (9600-1-Even). Ich habe mit HTERM den RS232-Bus belauscht und eine fehlerfreie Kommunikation ermittelt.

ABER:
Twincat (comLib V2) ließt jedesmal nur zwischen ca. 400 bis max 474Byte ein. Die ersten ca. 400 Byte stimmen auch noch, danach werden falsche, wirre Zeichen eingelesen. Konkret lese ich mit der Funktion "fbReceiveByte(RXbuffer:=RXbuffer). If fbReceiveByte.ByteReceived then...Repeat...Until" die Daten ein. Ich steige nicht dahinter wo das Prolem liegen könnte.

Info am Rande: hatte in einem Testlauf den Zähler über RS485-Schnittstelle ausgelesen und selbiges Prolem gehabt.

Kann mir vielleicht jemand aus meiner hilflosen Situation helfen?
 
Hi,

das Thema interessiert mich auch. Habe einen Easymeter Q3D1004 als Zähler. Mir fehlt aber noch die passende Hardware.
Parameter sind bei meinem Zähler 7E1 9600.
Welchen Zähler nutzt du?

Gruß
CF
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meiner ist ein ITF-Fröschl Zähler. Wohl ein eher exotisches Exemplar. Das Auslesen klappt weitgehend problemlos (nach IEC 1107), die Daten kommen im Klartext als ASCII-Zeichen aus dem Gerät.
 
Datenpuffer : 1024-Byte-Empfangspuffer, 128-Byte-Sendepuffer

Breite im Prozessabbild: Input/Output: 22 x 8-Bit-Nutzdaten, 2 x 8-Bit-Control/Status (bis 22-Byte-Nutzdaten möglich)

8bit= 1byte

d.h. pro zyklus 22byte

474 byte Daten / 22byte pro zyklus = 21,6 Zyklen

2s (sendegeschwindigkeit) / 22 Zyklen = 90,9ms

Schaut mal ach eurer Zykluszeit........... wäre eine Erklärung.
 
Scheint auch nicht der richtige Ansatz zu sein. Mein Task hat eine Zykluszeit von 50ms. Selbst das Runtersetzten auf 1ms bringt keine Besserung
 
Beava schrieb:
Kommen die Daten den auch richtig an? Hast Du das mal mit Putty geprüft?
Zusätzlich prüf ob du auch mit einer Fasttask die Kommunikation entkoppelt hast:

siehe: http://infosys.beckhoff.com/content/1031/tcplclibserialcom/html/tcplclibsercom_concept.htm?id=31481
Zum Vergrößern anklicken....

Ich habe die Beckhoff-Literatur x-mal durchforstet und meine das mit dem schnellen Task auch verstanden zu haben. Hatte ich testweise auch so eingerichtet und den gleichen Effekt. Jetzt läuft wieder alles zusammen in einem 50ms-Task. Ich werde es aber nochmals testen, weil das mit dem Task mein einziger Lösungsansatz ist.

Getestet habe ich schon ob die Daten an der Klemme richtig anliegen. Mit HTERM (ist wohl ähnlich wie PUTTY). HTERM empfängt immer exakt die gewünschten 474Byte, das ganze fehlerfrei.

Wie wird denn eigentlich die notwendige Taskgeschwindigkeit für den Background-Task berechnet. Hat Beckhoff irgendwo eine "offizielle" Formel versteckt die ich noch nicht gefunden habe?
 
Hab einen K-Bus, ca. 23 Digitalein/ausgangsklemmen, ein paar wenige intelligente Klemmen und 2xRS232, 1xRS485. Du meinst daß ihm am K-Bus die Daten zu viel werden :confused:
 
ohh mit dem bus von beckhoff kenne ich mich nicht wirklich aus. meine vermutung war, dass ein can benutzt wird und den kann man bei falschen einstellungen(oder sehr langen leitungen) sehr langsam laufen lassen.
wäre noch eine möglichkeit gewesen.

hab keine ahnung wie schnell der k-bus ist. es ist aber ein "rückwand-/spsbus". der sollte mehre 100kb/s haben und damit schnell genug sein.
 
So, getestet. ABER. Keine Verbesserung. Die SPS seufzt unter dem schnellen Task. Die Enttäuschung bleibt jedoch: der aktivierte 1ms-Task läuft nicht besser wie früher im 50ms-Task.
Was habe ich gemacht:
- Background-Task läuft jetzt in einem 1ms-Task
- diesem Task die höchste Priorität zugewiesen (Priorität 0)
- InData und OutData-Variablen dem schnellen Task zugeordnet
- SPS-Neustart

Momentan bin ich mit meinem Latein am Ende....
 
Fanta-Er schrieb:
hab auch keinen rat mehr. kannst zu versuchszwecken mit HT mal 1000byte schicken und dann schauen wie es crasht. vieleicht gibt es ein muster......
Zum Vergrößern anklicken....

War noch zu faul, hab aber auch schon dran gedacht.... melde mich wieder... Trotz allem wundert mich: warum funktionieren die ersten ca. 400Byte, nur die darauffolgenden 74 mal schon, mal nicht....
 
Zuletzt bearbeitet:
Fanta-Er schrieb:
hab auch keinen rat mehr. kannst zu versuchszwecken mit HT mal 1000byte schicken und dann schauen wie es crasht. vieleicht gibt es ein muster......
Zum Vergrößern anklicken....

Das war ja nun wirklich interessant: ich habe mit HTERM einen Datensatz des Zählers ausgelesen (474Byte) und diesen anschließend zig-mal auf die RS232-Klemme gesendet. Und siehe da: Mein Twincat-Programm liest jedes mal korrekt 474Byte ein. Das ganze übrigens im langsamen, originalen 50ms-Task. Also doch kein Problem mit der Taskzeit.

Daher zusammenfassend die bisherigen Erkenntnisse:
- Die Daten werden vom Stromzähler korrekt gesendet, da sie von HTERM richtig eingelesen werden
- Beckhoff ließt die Daten jedoch fehlerhaft
- Sende ich die gleichen Daten von HTERM an Beckhoff, so werden sie richtig gelesen

Wo liegt nun der Hund begraben (wünschte ich hätte ein Oszilloskop....)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Könnte es evtl. ein Potential-Problem sein? Ich hatte schonmal so eine Glückspielsituation mit einem programmierbaren LC-Display das über RS-232 Kommuniziert hatte. Am Desktoprechner angeschlossen, alles kein Problem. Am Lappi aber ging garnichts. 7 von 10 Versuchen ein Makro auf das Display zu laden sind fehl geschlagen. Ausserdem hatte das Display immer leicht geflackert am Laptop. Als ich es dann mit einem USB zu RS232 Konverter laufen ließ, hatte es dann auch am Laptop funktioniert. Der techn. Support von Display Vertrieb meinte dann auch das es da evtl. Probleme mit dem Massepotential gab .....
 
HTERM läuft auch bei mir über USB-RS232-converter. Aber Massen hin und herklemmen hat zumindest nichts verändert. Kann ja irgendwie auch kaum sein, es hängt ja nur der optische RS232-Lesekopf auf der Klemme. Ohne dass da sonstwohin eine elektr. Verbindung wäre.
Unsicher bin ich mir allerdings bezüglich RTS/CTS der Klemme. Vermutlich bezieht ja der optische RS232-Lesekopf seine Stromversorgung aus einen der beiden? Muss ich denn irgendwie sicherstellen dass an diesen Klemmstellen Spannung anliegt bzw. nicht durch irgendeinen Modus abgeschaltet wird?
Mein Background-Task läuft jedenfalls unter folgenden Einstellungen:

Mode := SERIALLINEMODE_DEFAULT,
Baudrate := 9600,
NoDatabits := 7,
Parity := PARITY_EVEN,
Stopbits := 1,
Handshake := ,
ContinousMode := FALSE,
 
blöde idee, klemm mal einseitig den schirm ab. vieleicht hast dir eine potenzialverschleppung eingefangen. hilft bei analogwerten auch öfters (zappeln reduzieren).
und leg den handshake auf 0. kenne das problem zwar nur bei siemens, dass noch irgend ein wert im IDB steht und nicht gelöscht wurde aber schaden tut es auch nicht :).
 

Similar threads

F
BX9000: externes Gerät über RS232 steuern
Antworten
3
Aufrufe
2K
Forest
F
Zurück
Oben