TIA TRCV funktioniert nur wenige Male

SPS-Koch

Level-2
Beiträge
24
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,
Ich erstelle gerade eine Kommunikation von einer 1214C mit einem Messgerät aus eigenem Hause.
Das geschieht via TCP und funktioniert im Grunde auch schon. TCON richtet die Verbindung ein, per TSend kann ich senden und mit TDISCON kann ich die Verbindung abbauen. Mein Problem, der Baustein TRCV empfängt die ersten Datenpakete und ich kann sie schön verarbeiten. Nach ein paar Datenpaketen kommt allerdings nichts mehr an. In Wireshark sehe ich allerding, dass sowohl mein Kommando an das Messgerät als auch die Antwort gesendet werden. Baue ich die Verbindung ab und wieder neu auf funktioniert es wieder ein paar mal. TRCV läuft im ADHOC Modus (LEN=0) und legt die Daten in einen Array[0...255] of Char.

Gruß SPS-Koch
 
Hast du den TRCV auf dauerhaft Listening?
Wenn die Verbindung dauerhaft aktiv gehalten wird, müsste das funktionieren.
Falls die Verbindung aber von einer Seite abgebrochen wird, stellt auch TRCV seinen Dienst ein. Kann man über den Statuswert feststellen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was zeigt denn der Parameter STATUS des TRCV-Bausteins an? Meistens kann man damit das Problem gut einkreisen.
Fehlercodes sind die Zahlen ab h8085 (oder dezimal Werte >32900).

ERRORSTATUS* (W#16#...)Erläuterung
00000Auftrag erfolgreich ausgeführt. Die aktuelle Länge der empfangenen Daten wird am Parameter RCVD_LEN ausgegeben.
07000Baustein nicht für den Empfang bereit.
07001Baustein ist für den Empfang bereit, Empfangsauftrag wurde aktiviert.
07002Zwischenaufruf, Empfangsauftrag wird bearbeitet.
Hinweis: Während dieser Bearbeitung werden Daten in den Empfangsbereich geschrieben. Währenddessen kann der Zugriff auf den Empfangsbereich inkonsistente Daten liefern.
18085
  • Parameter LEN ist größer als der größte zulässige Wert.
  • Der Wert des Parameters LEN oder DATA wurde nach dem ersten Aufruf geändert.
  • Beide LEN-Parameter und der Parameter DATA haben den Wert "0" oder LEN ist länger als der maximal zulässige Wert (65536).
18086Der Parameter ID liegt außerhalb des zulässigen Adressbereichs (1 .. 0x0FFF).
18088
  • Empfangsbereich ist zu klein.
  • Der Wert am Parameter LEN ist größer als der am Parameter DATA angegebene Empfangsbereich.
180A1Kommunikationsfehler:
  • Die angegebene Verbindung wurde noch nicht aufgebaut.
  • Die angegebene Verbindung wird gerade beendet. Empfangsauftrag über diese Verbindung ist nicht möglich.
  • Die Verbindung wird gerade neu initialisiert.
180B3Die parametrierte Protokollvariante (Parameter connection_type in der Verbindungsbeschreibung) ist UDP. Bitte verwenden Sie bei einer UDP-Verbindung die Anweisung "TURCV".
180C3
  • Ein Baustein mit dieser ID wird bereits in einer anderen Prioritätsgruppe bearbeitet.
  • Interner Mangel an Ressourcen.
180C4Temporärer Kommunikationsfehler:
  • Die Verbindung zum Partner kann derzeit nicht aufgebaut werden.
  • Die Schnittstelle empfängt neue Parametereinstellungen oder die Verbindung wird aufgebaut.
180C5Der remote Partner hat die Verbindung abgebaut.
180C6Der remote Partner kann nicht erreicht werden (Netzwerkfehler).
180C7Zeitüberschreitung der Ausführung.
180C9Die Länge des Empfangsbereichs ist kleiner als dieLänge der gesendeten Daten.
 
Zuletzt bearbeitet:
Der Status von TRCV ist 7002. Ich versuche wollte gerne den Ausgang NDR nutzen um zu erkennen, dass neu Daten vorhanden sind. Aber der scheint auch dann nichts zu machen.
 
Sollte die Datenlänge immer gleich lang sein, so wäre der "Datenempfang mit angegebener Länge" unproblematischer. Könnte bei einem Messgerät sinvoller sein, falls es immer gleichgrosse Datenpakete verschickt.
 
Der Status von TRCV ist 7002. Ich versuche wollte gerne den Ausgang NDR nutzen um zu erkennen, dass neu Daten vorhanden sind. Aber der scheint auch dann nichts zu machen.
Der ist nur einen Zyklus lang an. Als Flanke sozusagen.

Nutze den NDR um die Daten entweder in dem Zyklus auszuwerten, oder in einen anderen Speicher zu schreiben.
 
Moin, Ich bin nach einer Weile mal wieder an diesem Projekt. Ich habe immernoch das Problem, dass der TRCV Baustein nur sporadisch Daten empfängt. In Wireshark sehe ich, aber dass alle Daten die vom Messgerät gesendet werden sollen auch gesendet werden. Das senden per TSEND funktioniert auch ohne Probleme. Den Ausgang NDR vom TRCV nutze ich direkt om die Daten die der Baustein in einen ARRAY of Char schreibt in einen String zu kopieren.
 
Und selbst wenn ich das Signal NDR nicht nutze, müsste in dem Array of Char der an der INOUT Variable DATA hängt ja etwas geschrieben werden.
Ist dein Datenbereich groß genug?
Ich verwende immer NDR und kopiere damit in einen anderen Datenbereich.
Array of Char ist nicht das gleiche wie String.
Ein String hat zusätzlich Längen-Informationen.
Diese muss man u.U. manuell anpassen.
 
Ich nutze einen Array[0...255] of Char und schreiben den in einen String. Dann war mein Plan immer, wenn NDR true ist den Array in den String zu Kopieren und den Array zu löschen/leeren. Die länge Reicht auf jeden Fall, dann aus. Ein paar mal geht es und dann mit den gleichen Zeichen nicht mehr.
 
Deine 1214C ist Firmware >= V4.0?
Vermutlich sendet das Messgerät Nachrichten die kürzer als 256 Zeichen sind?
Können die erwarteten Antworten des Messgerätes unterschiedlich lang sein?? Kannst Du nicht an TRCV.LEN die Länge der erwarteten Antwort einstellen?

NDR wird erst aktiv, wenn die angeforderte Anzahl Zeichen empfangen wurde. Bei LEN=0 ist das die Größe des Empfangspuffers an DATA, bei Dir also 256 Zeichen.

Lies Dir mal die TIA-Hilfe zu "TRCV: Daten über Kommunikationsverbindung empfangen" durch, den Abschnitt
Parameter LEN, DATA und RCVD_LEN

Ist LEN = 0, werden die empfangenen Daten in dem am Parameter DATA angegebenen Empfangsbereich gespeichert. Die Anzahl der empfangenen Bytes werden am Parameter RCVD_LEN angezeigt.

Bei LEN = 0 (Voreinstellung des Parameters LEN) wird die Länge der zu empfangenden Daten über den Parameter DATA festgelegt. Es wird empfohlen, dass der Empfangsbereich (Parameter DATA) dieselbe Größe hat wie die von TSEND übertragenen Daten.

Falls LEN den Wert 0 hat und die gesendeten Daten in Segmenten übertragen werden, die kleiner sind als der Empfangsbereich DATA, dann gilt das Folgende. Es wird empfohlen, EN_R so lange gesetzt zu halten, bis die zugehörige TSEND-Anweisung alle Daten gesendet hat. Solange die Größe der von TSEND gesendeten Daten ungleich der Größe des Empfangsbereichs DATA ist, zeigt STATUS den Wert 7002. EN_R muss gesetzt sein, bis die Anzahl der empfangenen Daten gleich der Größe des Empfangsbereichs DATA ist. Wenn Sie EN_R pulsen, müssen Sie dies so lange tun, bis BUSY=0 bzw. ERROR <> 0.

Die Daten im Empfangsbereich DATA sind erst dann gültig, wenn BUSY den Wert 0 annimmt.

Ändern sich die Status-Ausgänge BUSY und RCVD_LEN?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin SPS-Koch,

Was steht denn im RCVD_LEN? Vielleicht werden Daten empfangen, die zu groß für Deinen Datenbereich sind?
Entsteht zwischendurch mal ein Fehler bei dem Lesen? => Mit dem Error-Bit mal den Status wegspeichern.
Verschieben sich die erwarteten Daten in dem angegebenen Speicherbereich, in dem sie abgelegt werden sollen (DATA)?

VG

MFreiberger
 
Ich nutze aktuell dafür TIA V14, weil es schonmal vor kommt, dass ein Kunde der dies Messgerät in seiner Anlage bekommt Tia V14 haben will. Meine CPU die ich zum Testen nutze hat eine Firmware V3.0.2 und sollte das vermutlich der Grund für Probleme sein kann ich mal schauen, dass ich eine neuere CPU ran bekomme. Die Datenlänge ist leider nicht immer gleich daher nutze ich den Ad-hoc-Modus.
Ich habe das mal ausprobiert mit dem Abspeichern von Error und RCVD LEN. Komischerweise scheint es jetzt zu funktionieren. Und der NDR kommt auch zuverlassig, wenn ich vom TRCV daten bekomme. Ich baue mir jetzt erstmal weiter den Baustein für das Gerät und wenn es nochmal Probleme gibt melde ich mich.
 
Moin, Ich hab endlich wieder Zeit an dem Projekt weiter zu arbeiten.
Weiterhin habe ich das Problem, dass der TRCV sich aufzuhängen scheint.
Von dem Messgerät bekomme ich nach Herstellung der Verbindung eine Willkommensnachricht mit ein paar Infos.
Die Nachricht ist in zwei Pakete mit 128 und 42 Zeichen aufgeteilt. Es kommt häufig vor, dass das zweite Paket mit 42 Zeichen nicht empfangen wird. (Zumindest gibt TRCV das nicht aus). Zuerst dachte ich, dass das zweite Paket nur empfangen wird, wenn das Aknowledge auf das erste Paket vor dem zweiten kommt. Zumindest hat Wireshark es anfangs immer so mitgeschrieben, wenn es funktioniert hat.
Das hat sich aber nicht bestätigt. Teilweise liest er das zweite Paket auch, wenn das Aknowledge auf das erste Paket erst nach nach dem zweiten Paket kommt und teilweise teilweise liest er es auch nicht, wenn das schön hinter einander kommt.
Wirkt komplett zufällig.
Wird die Willkommensnachricht nicht komplett empfangen ließt TRCV danach nichts mehr ein.
Jedoch sehe ich mit Wireshark, dass alle Pakete gesendet werden wie sie es sollen.

Hier mal der Aufbau um den TRCV.
Receivedate.char ist ein Array[0..127] of Char und ich weiß von dem Entwickler das Messgerätes, dass er keine Pakete über 128 Zeichen senden kann. Verlängern des Array habe ich aber auch schon probiert.
Mit Tag ein würde ich mir eine Fehler speichern. Aber bisher kam keiner.
Screenshot 2022-02-04 100523.png

Vielleicht hat ja noch jemand eine Idee.

Grüße SPS-Koch
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Neues komische Sache.
Über den Tag 2 (Siehe Bild letzte Nachricht) habe ich die länge den Parameter RCVD_LEN mitgeschrieben und da zeigt er mir nur 128 Zeichen an.
Das letzte Paket mit 128 Zeichen war jedoch der erste Teil der Willkommensnachricht. Danach habe ich noch ein paar mehr Pakete bekommen, die auch ankamen. Das letzte ist mit 69 Zeichen. Dann habe ich Befehle an das Gerät gesendet die keine Antwort erwarten und seit dem kamen wieder keine Antworten vom Gerät bei der SPS an. Im Tag 2 steht immer noch 128.
 
Abgesehen von der Willkommensnachricht sendet das Messgerät mir nur dann etwas, wenn ich vorher einen Befehl schicke.
Heißt es kann sein, dass ich auch minutenlang nichts sende und auch nichts bekomme und wenn ich dann einen Befehl sende ich die Antwort nicht lesen kann. Meine Vermutung geht in die Richtung, dass es etwas Zeitkritisches ist. Dass vielleicht eine kleine Wartezeit zwischen den beiden Paketen der Willkommensnachricht und zwischen Befehle an das Gerät und Antwort reichen, würde um das zu lösen.
 
Zurück
Oben