Step 7 PUT / GET, S7-300 zu mehreren S7-1200, Fehler Code dezimal 20

mst

Level-1
Beiträge
463
Reaktionspunkte
89
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich habe hier eine S7-300 mit einem CP343-1 über den ich mit PUT/GET insgesamt drei S7-1200 auslesen bzw. einen Sollwert schreiben möchte.


Ich habe dazu für jede Verbindung einen FB welcher insgesamt 15 GET und einen PUT Aufruf enthalten (Diese werden der Reihe nach abgearbeitet). Jede diese Verbindung funktioniert für sich alleine ohne Probleme. Der Plan war, dass ich die Daten von der ersten S7-1200 lesen und wenn das abgeschlossen ist die nächste beginne – also nie mehrere Verbindungen gleichzeitig. Da kommt jedoch dann der Fehler 20:


„Maximale Anzahl paralleler Aufträge/Instanzen ist überschritten
Die Instanzen wurden bei CPU-RUN überladen (STOP-RUN-Übergang der CPU oder des CP ist erforderlich.)
Ist beim Erstaufruf möglich“


Es funktioniert dann immer nur die Verbindung die ich als erster gestartet habe, die anderen beiden nicht. Nach einem Stopp/Start der CPU, kann ich jeweils eine der drei Verbindungen ohne Probleme aufrufen.


Gibt es da irgendeine unbekannte Grenze? Kann der CP343-1 nur eine Verbindung?


Bitte um Hilfe.

Lg Stefan

2018-10-10 at 13-08-24.jpg2018-10-10 at 10-53-19.jpg
 
Verwendest Du die richtigen FB14/FB15 aus der Bibliothek SIMATIC_NET_CP?
Schaltest Du erst zum nächsten Auftrag wenn der vorherige mit NDR oder ERROR beendet ist?
Verwendest Du für eventuell parallele Aufträge auch verschiedene GET-Instanzen?
Versuche mal nach STOP/RUN den Auftrag mit der größten Datenlänge zuerst auszuführen.

Welche CPU hast Du genau? Bestellnummer und Firmwareversion
Welchen CP hast Du genau? Bestellnummer und Firmwareversion
Sind da noch weitere Verbindungen aktiv? Wie sieht Baugruppenzustand > Kommunikation der CPU aus? (zeig mal ein Bild)

Harald
 
Hallo Harald, danke für die Hilfe.

Verwendest Du die richtigen FB14/FB15 aus der Bibliothek SIMATIC_NET_CP? – Natürlich hatte ich die Falschen, jatzt hab ich die besagten aus der SIMATIC_NET_CP Bibliothek.
Schaltest Du erst zum nächsten Auftrag wenn der vorherige mit NDR oder ERROR beendet ist? – JA
Verwendest Du für eventuell parallele Aufträge auch verschiedene GET-Instanzen? - JA
Versuche mal nach STOP/RUN den Auftrag mit der größten Datenlänge zuerst auszuführen. – Ist bereits so, ich lese 14x149Bytes 1x49Bytes

Welche CPU hast Du genau? Bestellnummer und Firmwareversion 317-2AK14-0AB0 V3.3.12
Welchen CP hast Du genau? Bestellnummer und Firmwareversion 343-1EX30-0XE0 V3.0.0
Sind da noch weitere Verbindungen aktiv? Wie sieht Baugruppenzustand > Kommunikation der CPU aus? (zeig mal ein Bild) – Ich habe ISO on TCP Verbindungen, diese laufen über einem anderen CP 343-1 Lean

Harald


Ich habe jetzt die richtigen Bausteine, und es laufen auch zwei der drei Verbindgen jetzt reibungslos. Wenn ich die dritte Verbindung starte (gleiche Maschine, gleicher Verbindungspartner), bleibt das ganze bei einem GET Befehl stehen (meistens beim ersten), dieser gibt die Meldung aus DEC11
„Warnung: Neuer Auftrag ist unwirksam, da vorangegangener Auftrag noch nicht abgeschlossen ist. Der Auftrag wird bereits in einer Prioritätsklasse mit niedrigerer Priorität bearbeitet.“
Ich sehe auch Im Web Interface vom CP, das sich die Anzahl der gesendeten Aufträge permanent erhöht. Jedoch wird der GET Aufruf nicht mit DR oder ERROR quittiert. Stopp/Start der CPU und des Verbindungspartners hab ich schon mehrmals gemacht.

2018-10-11 at 10-12-06.jpg2018-10-11 at 10-13-05.png
 
Versuche es mal mit einer etwas größeren OB1-Zykluszeit und/oder mit den Ressourcen-Einstellungen "Zyklusbelastung durch Kommunikation" in der HW-Konfig der CPU. Wie groß ist die Zykluszeit überhaupt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Versuche es mal mit einer etwas größeren OB1-Zykluszeit und/oder mit den Ressourcen-Einstellungen "Zyklusbelastung durch Kommunikation" in der HW-Konfig der CPU. Wie groß ist die Zykluszeit überhaupt?

Anbei die Screenshots zu den Einstellungen bzw. Zykluszeiten.
Du meinst das ich eine minderst Zykluszeit einstellen soll? - Das ist bei mir ausgegraut.
Zum Thema Belastung der Zykluszeit durch Kommunikation - die eingestellten 20% berufen sich auf die Zykluszeitüberwachung von max. 150ms oder auf die Tatsächliche Zykluszeit?

2018-10-11 at 13-26-02.png2018-10-11 at 13-25-35.png
 
Hab jetzt zum Probieren die Zykluszeit durch Kommunikation auf 50% gestellt. Nach wie vor gleiches verhalten
 
Zum Thema Belastung der Zykluszeit durch Kommunikation - die eingestellten 20% berufen sich auf die Zykluszeitüberwachung von max. 150ms oder auf die Tatsächliche Zykluszeit?
auf die tatsächliche Zykluszeit. siehe den [Hilfe]-Button in dem Einstelldialog

„Warnung: Neuer Auftrag ist unwirksam, da vorangegangener Auftrag noch nicht abgeschlossen ist. Der Auftrag wird bereits in einer Prioritätsklasse mit niedrigerer Priorität bearbeitet.“
[...]Jedoch wird der GET Aufruf nicht mit DR oder ERROR quittiert.
Wie sieht Dein Programm der GET-Aufrufe aus? Läuft da was in verschiedenen OBs? Hast Du vielleicht einen Fehler in der Auftragssteuerung?

Warum verwendest Du PUT/GET? Kannst Du nicht eine ISO-on-TCP- oder TCP-Verbindung programmieren mit AG_SEND/AG_RECV? Da könntest Du die reichlich 2100 Bytes zu einem Telegramm zusammenfassen und in einem Rutsch übertragen. Ohne großartige Auftragsverriegelung. Und schneller.

Harald
 
Um die Zykluszeit auf ein Minimum zu verlängern, kannst du z.Bsp. den OB1 mit dem OB35 synchronisieren. Dazu am Ende des OB1 einen Merker abfragen, der im OB35 gesetzt wird.

Etwa so:
Code:
FUNCTION "ONKELS_ZYKLUSSYNCHRONISER ;-)": VOID

VAR_IN_OUT
  SYNCH                : BOOL;                         // 1==Zyklusende, muss extern zyklisch gesetzt werden!
END_VAR

BEGIN

//*** Schleife, bis Mindestzykluszeit erreicht ist
   REPEAT;
     UNTIL SYNCH
   END_REPEAT;
   SYNCH := false;

END_FUNCTION

Ich glaube aber eigentlich nicht wirklich, dass es in diesem Fall hilft.

Es ist nun an der Zeit, uns einen weiteren Hinweis auf des Rätsels Lösung zu liefern! Ein bisschen Programmcode wäre nicht schlecht. Der wahrscheinlichste Fehler ist wohl der, dass ein neuer Auftrag angestoßen wird, während ein anderer noch nicht abgeschlossen ist. Zumindest sagt das die Diagnose.
 
Firmewareupdate habe ich gemacht.
PUT/GET nutze ich eigentlich nur deswegen, weil ich mit dieser Art der Kommunikation schon gearbeitet habe, werde mir aber AG_SEND/AG_RECV mal anschauen, funktionieren diese auch ohne das beim Zielsystem was gemacht werden muss?

Ich habe drei idente Bausteine bzw. Aufrufe für die PUT/GET Verbindungen zu den drei identen Maschinen.
Ich bin jetzt auf was gestoßen:
Diese drei Bausteine rufe ich hintereinander im OB1 auf, der erste dieser Aufrufe funktioniert nicht, wenn ich den zweiten Aufruf an erster Stelle gebe, dann funktioniert dieser nicht, jedoch die beiden anderen schon. VKE ist False vor dem Bausteinaufruf.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
werde mir aber AG_SEND/AG_RECV mal anschauen, funktionieren diese auch ohne das beim Zielsystem was gemacht werden muss?
Das Zielsystem-Programm muß aktiv mitarbeiten: Sendedaten in Sendenachricht/Puffer kopieren, Sendenachricht mit TSEND senden, Empfangsdaten mit TRCV empfangen, Empfangspuffer in Zieldaten kopieren. Es müssten also im Zielsystem-Programm Änderungen programmiert werden.

Ich bin jetzt auf was gestoßen:
Diese drei Bausteine rufe ich hintereinander im OB1 auf, der erste dieser Aufrufe funktioniert nicht, wenn ich den zweiten Aufruf an erster Stelle gebe, dann funktioniert dieser nicht, jedoch die beiden anderen schon. VKE ist False vor dem Bausteinaufruf.
Ohne einen Blick auf Dein Programm können wir hier vielleicht noch ewig rumrätseln.

Bei Verdacht daß ein VKE von davor in den Programmteil verschleppt wird (und beeinflußt), dann eine explizite VKE-Abgrenzung setzen: irgendeinen Befehl einfügen der das /ER-Statusflag auf 0 löscht, z.B. SET oder CLR oder eine (Dummy-)Zuweisung mit =

Harald
 
Hallo,

hier ein bischen Code.

OB 1 Aufruf, hier Kommunikation 2 als erster - dies Funktioniert nicht, 1 und 3 funktionieren:
OB1.png

FC Kommunikation 2 - mit CLR am Anfang:
FC Kommunikation 2.png

FC Kommunikation 1:
FC Kommunikation 1.png

FC Kommunikation 3:
FC Kommunikation 3.png

Timer sind nicht Doppelt vergeben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du verwendest für alle GET-Aufträge auf einer Verbindung die selbe GET-Instanz. Du rufst die selbe GET-Instanz in jedem Zyklus 15 mal mit 15 verschiedenen Auftragsparametern auf. Versuche mal die Aufträge mit 15 verschiedenen GET-Instanzen.
Code:
VAR
...
  PLC_GET_1 : "GET";	
  PLC_GET_2 : "GET";	
...
  PLC_GET_15 : "GET";	
...
END_VAR

Das #ON an EN des GET-CALLs gefällt mir auch nicht gut. Es sollte sichergestellt werden, daß GET nach einem REQ solange aufgerufen wird bis NDR oder ERROR aktiv wird, am besten noch einmal mehr (damit NDR und ERROR wieder FALSE werden). Dann ist der Auftrag garantiert vollständig abgeschlossen.

Harald
 
Du verwendest für alle GET-Aufträge auf einer Verbindung die selbe GET-Instanz. Du rufst die selbe GET-Instanz in jedem Zyklus 15 mal mit 15 verschiedenen Auftragsparametern auf. Versuche mal die Aufträge mit 15 verschiedenen GET-Instanzen. - Hab jetzt einzelne Instanzen für jeden GET Aufruf.


Das #ON an EN des GET-CALLs gefällt mir auch nicht gut. Es sollte sichergestellt werden, daß GET nach einem REQ solange aufgerufen wird bis NDR oder ERROR aktiv wird, am besten noch einmal mehr (damit NDR und ERROR wieder FALSE werden). Dann ist der Auftrag garantiert vollständig abgeschlossen. – Habe ich jetzt so gemacht.
Harald


Es funktionieren jetzt alle drei Verbindungen – Ich konnte die Datenmenge zum Glück so reduzieren, so dass es je Verbindung nur mehr 4 GET-Aufrufe sind. – Also insgesamt 12 Stk.
Ein CP343-1 ist auf maximal 16 Instanzen beschränkt und die CPU auf Maximal 32 Instanzen. – Ich nehme an das es mit meinen Ursprünglichen 45 Instanzen sowieso nicht funktioniert hätte.


Danke nochmal für eure Unterstützung.
Lg Stefan

2018-10-24 at 15-54-35.png
 
Zurück
Oben