TIA Fehler 80C3 an TRCV

Lipperlandstern

Lipperlandstern

Level-3
Beiträge
6.020
Reaktionspunkte
1.737
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Step 7 - TIA: TRCV Baustein Status 80C3

Hallo, ich habe in einer S7-1516F zwei statische Verbindungen zum selben PC angelegt. (zwei verschiedene Ports) Eine der Verbindungen fällt mir regelmässig weg mit Status 80C3 A block with this ID is already being processed in a different priority group. Internal lack of resources...
www.sps-forum.de www.sps-forum.de

Ich habe auch den Fehler 80C3 bei einer statischen Verbindung die ich aktiv aufbaue. Seltsamerweise hat es ca. 4 Wochen funktioniert und gestern trat der Fehler das erste Mal auf. Ich habe im Internet bisher nicht anderes gefunden als Programm komplett neu laden. Selbst Stop-Run hat nicht geholfen.
Dann war der Fehler auch erstmal weg bis er heute morgen wieder aufgetreten ist.

Hat jemand eine Idee wo man ansetzen kann um den Fehler zu beheben ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DeltaMikeAir schrieb:
Hier mal Ansätze:
https://support.industry.siemens.com/forum/it/en/posts/trcv-c-and-tsend-c-80c3/176658
Zum Vergrößern anklicken....

So wie ich das verstehe bauen die die Verbindung mit den Siemens-Bausteinen auf. Ich baue meine Verbindung über die Firmware der CPU /CP auf. Ich hatte mir das auch durchgelesen aber konnte keine Rückschlüsse draus ziehen.

Übrigens hilft Stop-Run dann doch. Ich war nur zu ungeduldig :)

Ein paar Dinge sind mir noch aufgefallen.

Im Webserver wird unter Verbindungsresoursen bei OpenUser-Kommunikation 0 reserviert und 1 als belegt angezeigt.
HMI sind 4 reserviert aber 10 belegt (4 Panels und 1 Runtime). Ich habe allerdings nicht gefunden wo ich diese Werte ggf. erhöhen kann.
Grundsätzlich sind von 256 möglichen Verbindungen noch 242 frei.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
Was meinst du mit "statische Verbindung"?
Welche Bausteine verwendest du: TSEND, TSEND_C, TRCV, TRCV_C, TCON ?
Den Fehler 80C3 erhältst du von TRCV?
Welche CPU und welche TIA-Version verwendest du?
Zum Vergrößern anklicken....

So viele Fragen :) Hab ich in der Eile vergessen.

Ich habe eine CPU 1516-3, kommuniziert wird über einen CP1543-1. TIA ist V17Upd6.

Ich habe die Verbindung in der CPU angelegt und nutze keine Bausteine die die Verbindung auf- oder abbauen. Ich habe nur den TSEND und TRCV im Programm. Beide senden bzw. empfangen über die selbe Verbindung.
Der Fehler steht am TRCV an. Während der Fehler ansteht kann ich senden und das Telegramm kommt auch an. Empfangen geht nicht.
 
Um mal nach dem Offensichtlichen zu fragen:
Und beide Aufrufe (Send und Receive) werden über den gleichen OB ausgeführt? Nicht einmal z.B. OB35 und einmal OB1?
 
funkey schrieb:
Um mal nach dem Offensichtlichen zu fragen:
Und beide Aufrufe (Send und Receive) werden über den gleichen OB ausgeführt? Nicht einmal z.B. OB35 und einmal OB1?
Zum Vergrößern anklicken....
sind beide in einem FB und dieser wird nur 1x aufgerufen.

was mich irritiert ist , das es einige Wochen ohne Probleme funktioniert hat. Änderungen gab es von meiner Seite nicht.
 
Was ist wenn der Fehler nicht auf deiner Seite ist, sondern auf der anderen?
Welche Software hängt da? Es gibt Möglichkeiten programmiertechnisch eine Richtung (Senden oder Empfangen) zu unterbinden.
Wenn dann die SPS wieder eine Verbindung aufbaut, obwohl sie noch besteht (auch wenn nur in eine Richtung) dann könnte es zu dem besagten Ressourcenmangel kommen.
 
funkey schrieb:
Was ist wenn der Fehler nicht auf deiner Seite ist, sondern auf der anderen?
Welche Software hängt da? Es gibt Möglichkeiten programmiertechnisch eine Richtung (Senden oder Empfangen) zu unterbinden.
Wenn dann die SPS wieder eine Verbindung aufbaut, obwohl sie noch besteht (auch wenn nur in eine Richtung) dann könnte es zu dem besagten Ressourcenmangel kommen.
Zum Vergrößern anklicken....
Ich habe auch die Vermutung, das es an der anderen Seite liegen könnte. Ich möchte das aber gerne mit Fakten untermauern. Auf der Gegenseite läuft irgendwas von Honeywell.
Dein Ansatz ist aber schon mal ein guter Hinweis. Es ist allerdings ein Unding das man da nur mit Stop-Run rauskommt.

Ich habe auch einen Supportrequest aufgemacht. Mal schauen was da so kommt.
 
funkey schrieb:
Oder du benutzt T_RESET, damit sollte es eigentlich auch funktionieren.
Zum Vergrößern anklicken....
das habe ich probiert und hilft nicht.

Das blöde ist auch das T-Diag weiterhin meldet das die Verbindung vorhanden ist. Alles etwas blöde.

Netzwerkkabel abziehen hilft übrigens auch nicht :) In der Doku steht das der KeepAlive dann die Ressourcen wieder freigibt. Funktioniert aber auch nicht.
Keep-Alive-Telegramme für TCP- und ISO-on-TCP Verbindungen
Sie können hier die Intervallzeit einstellen, mit der Lebenszeichentelegramme (Keep Alive) an den Partner einer Kommunikationsverbindung gesendet werden.
Der Ethernet-CP ist für alle verbindungsorientierten Dienste so konfiguriert, dass Keep-Alive-Telegramme gesendet werden. Dadurch ist gewährleistet, dass Verbindungen nach dem Ausfall eines Kommunikationspartners beendet, und die Verbindungsressourcen freigegeben werden. Die hier vorgenommene Einstellung gilt für alle über den CP betriebenen TCP- beziehungsweise ISO-on-TCP-Verbindungen. Eine verbindungsorientierte Einstellung ist nicht möglich.
Zum Vergrößern anklicken....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube nicht, daß es an der anderen Seite liegt. Selbst wenn die andere Seite die Ursache sein sollte, so sollte deine PLC nicht dieses Problem erzeugen.

Erzeugst du auch noch OUC-Verbindungen mit TCON? Haben die die selbe ID wie die projektierte statische Verbindung?
Gibt T_RESET einen Fehler?
 
PN/DP schrieb:
Ich glaube nicht, daß es an der anderen Seite liegt. Selbst wenn die andere Seite die Ursache sein sollte, so sollte deine PLC nicht dieses Problem erzeugen.

Erzeugst du auch noch OUC-Verbindungen mit TCON? Haben die die selbe ID wie die projektierte statische Verbindung?
Gibt T_RESET einen Fehler?
Zum Vergrößern anklicken....

Es gibt keine weiteren Verbindungen mehr. Der Support von Siemens hat geantwortet. Ich werde das heute Abend ( meiner Zeit) mal zusammenfassen und hier veröffentlichen.

Spoiler : Eine Lösung gibt es für dieses Problem nicht.
 
Der 80C3 Fehler darf nicht passieren. Der Baustein denkt, dass ein weiterer Receive Baustein aufgerufen wird, welcher mit der selben ID versehen ist (sich die Bausteine quasi gegenseitig die Daten von der Schnittstelle "wegklauen"). Daher ist das ein dauerhafter Fehler, welcher nur durch Stop/Run behoben werden kann.
Zum Vergrößern anklicken....
Das ist bei mir definitiv nicht der Fall. Sonst würde der Fehler immer auftreten und nicht das erste Mal nach ca. 4 Wochen und dann an 2 Tagen hintereinander.


Ich empfehle Ihnen einen InstanzDB für den RECEIVE anzulegen. Damit habe ich gute Erfahrungen gemacht. Bitte halten Sie mich auf dem Laufenden.
Zum Vergrößern anklicken....
Das habe ich heute gemacht. Mal schauen ob es etwas bringt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe da noch was in Erinnerung, dass wenn man von der SPS aus mit einer Software auf einem PC kommuniziert und dann nur die Software auf dem PC schließt und wieder startet, dass dann keine Verbindung zustande kommt und die SPS der Meinung ist, dass die Verbindung noch bestehen würde. Abhilfe ist dann in dem Fall, den Netzwerkstecker am PC zu ziehen und wieder einzustecken.
 

Similar threads

S
TIA ET200S Fehler aber keine SF an
2 3
Antworten
45
Aufrufe
5K
PN/DP
PN/DP
D
Profibus Busfehler
2 3
Antworten
53
Aufrufe
50K
daMichael
D
G
Step 7 S7-300 Backup einspielen auf neue MMC - Problem mit Profibus DP
Antworten
13
Aufrufe
12K
Onkel Dagobert
Onkel Dagobert
B
Step 7 S7 400 Fehler Profibus oder CPU
2
Antworten
34
Aufrufe
11K
BiBi
B
T
Step 5 Ag150s
Antworten
8
Aufrufe
5K
Rudi
R
Zurück
Oben