Step 7 DP-DP-Koppler Peripherie-Zugriffsfehler

Hallo,
Ich bin gerade dabei eine S7-300 über einen DP/DP-Koppler mit einer 416 zu verbinden. Die S7-300 wurde nicht von mir projektiert, ich habe nur einen Screenshot aus den TIA-Portal Einstellungen die ich auf meiner Seite so übernommen habe.
Der Datenaustausch funktioniert auch so weit, am DP/DP-Koppler ist alles auf grün. Ich erhalte auf meiner S7-400 jedoch in zyklischen Abständen eine Fehlermeldung bei einem Modul:
Peripherie-Zugriffsfehler bei Prozeßabbildaktualisierung der Ausgänge gekommen / gegangen.
Das betroffene Modul ist vom Partner als Reserve projektiert worden, d.h. ich übertrage auf dem Bereich keine Daten darum stört das den Datenaustausch auch nicht weiter. Aber den Zugriffsfehler möchte ich noch wegbekommen.
Die Größe des Prozessabbildes habe ich bei meiner CPU für Ein- und Ausgänge jeweils auf 2048 Bytes stehen, das sollte passen.

Ich habe auf meiner Seite schon versucht die Module gegen welche ohne Konsistenz auszutauschen, dann funktioniert die Kopplung jedoch überhaupt nicht mehr.

Vielleicht hat jemand noch eine Idee was ich auf meiner Seite ggf. noch ändern könnte, bzw. was der Partner ansonsten umzustellen hat. Meiner Meinung nach kann ich nicht mehr viel um- oder einstellen.

Hallo Thomas,

dass der Fehler kommt und geht, und das auch nur bei dem einen Modul, das ist schon seltsam. Was bringt denn der SFC15 für einen Rückgabewert?

Mit den konsistenten Datenblöcken hatte ich mal ein Problem. Und zwar erfüllt leider nicht jeder Busmaster die Profibusspezifikation bezüglich der konsistenten Blockgrößen und Datenmengen. Ich glaube bei den älteren Siemens DP/DP-Kopplern gabe es auch eine Einschränkung. In der HW-Konfig bekam man keinen Hinweis darauf, jedenfalls nicht in jeder Step7-Version. Aber ich denke, so eine Ursache würde permanent anstehen und nicht ständig kommen und gehen.

Den Rückgabewert der SFC15 solltest du aber mal nachsehen. Du verwendest sie doch sicherlich?


Gruß, Onkel

Ich rufe den SFC selber überhaupt nicht auf, das ist ja das seltsame. Das ist aber ein PCS7 Projekt, wenn dann müsste dort in den generierten Plänen eingebaut worden sein. Allerdings fehlt ja im Diagnosepuffer auch der Eintrag der Fehlerquelle. Im Offline-Bausteinordner habe ich auch keinen SFC15, der müsste dort ja eingefügt sein wenn er im Programm verwendet würde.

Der Fehler kommt immer im ca. 0,5 Sekunden Zyklus, wobei der OB1 bei einem CFC-Programm so gut wie leer ist, da alles im OB35 läuft.

Wenn ich beide Projekte hätte, würde ich auch die Konsistenz umstellen. Das hat der die 300er erstellt hat ja auch nicht einheitlich gemacht, die 8 Byte Blöcke sind immer als "nicht konsistent" projektiert. Könnte es denn daran liegen? Ich habe an der gleichen CPU noch ein zweites Profibus-Netz mit dem gleichen DP/DP-Koppler mit diversen Modulen aber alle vom Typ konsistent, auch 64 Byte Module.

Die SFC14/15 braucht man nicht aufrufen, weil die E/A-Adressen im Prozessabbild liegen und die konsistente Aktualisierung von der CPU gehandelt wird.
Hat die CPU die aktuellste Firmware-Version?

In dem Diagnosepuffer-Ausschnitt liegen zwischen den Ereignissen 4 (Fehler gekommen) und dem Ereignis 5 (vorheriger Fehler gegangen) fast 2 Sekunden. Da waren also auch einige DP-Buszyklen ohne Fehler dazwischen. Gibt es in dem Profibus mehrere Master (z.B. HMI)? Ist das im Profibus-Profil berücksichtigt?

Harald

Thomas_v2.1 schrieb:

.. die 8 Byte Blöcke sind immer als "nicht konsistent" projektiert. Könnte es denn daran liegen? ..

Zum Vergrößern anklicken....

Eigentlich dürfte es nicht daran liegen.

In deinen Diagnoseeinträgen ist ein Fehlercode "80C1" (Die Daten des auf der Baugruppe vorangegangenen Schreibauftrags sind von der Baugruppe noch nicht bearbeitet) erwähnt. Der könnte wiederum zu der SFC15 passen. Was passiert, wenn du die Größe des PAA bis unter den betreffenden Bereich verkleinerst?

Diagnosepuffer schrieb:

Peripherie-Zugriffsfehler bei Prozeßabbildaktualisierung der Ausgänge gekommen
temporärer Fehler bei konsistentem Nutzdatenaustausch siehe Rückgabewert W#16#80C1 des betroffenen SFC

Zum Vergrößern anklicken....

Bei dem Fehler 80C1 handelt es sich vermutlich um diesen Fehler:

SFC15 schrieb:

Fehlercode (W#16#...)	Erläuterung
80C1	Die Daten des auf der Baugruppe vorangegangenen Schreibauftrags sind von der Baugruppe noch nicht bearbeitet.

Zum Vergrößern anklicken....

Harald

Master gibt es an dem Bus nur einen. Der betroffene Koppler hängt an einem Profibus-Netz über einen CP443-5 Ext., der andere ohne Fehler hängt an der CPU DP-Schnittstelle.
Firmware der CPU bzw. CP müsste ich prüfen ob das noch aktuell ist, CPU ist eine 416-2XK04-0AB0 mit FW 4.1.0 und CP ist ein 443-5DX03-0XE0 und hat FW 5.3.6.

Prozessabbild verkleinern könnte ich machen, bei den Eingängen habe ich aber nach den Adressen noch andere funktionierende Teilnehmer, bei den Ausgängen ist das der letzte Bereich.

Die Fehlerbeschreibung hört sich für mich an, als ob es auch mit dem sehr kurzen OB1 Zyklus zu tun hat, da dieser wenn er nicht gerade von einem OB unterbrochen ist sehr kurz ist, ca. 3ms im kürzesten Fall. Baudrate ist z. Zt. 1,5 MBit/s, das könnte ich evtl. auch noch herabsetzen um das alles etwas langsamer zu gestalten, ich habe aber ein paar Teilnehmer dran von denen ich nicht weiß ob diese eine automatische Baudratenerkennung haben, das sind ein paar Exoten.

Ich habe gerade mal einen SFC47 WAIT Aufruf im OB1-Zyklus mit 2000 µs eingefügt, der Fehler tritt zur Zeit nicht mehr auf.

Ich werde es mal bis morgen durchlaufen lassen und prüfen ob das nochmal auftritt. Sieht zwar als Fehlerbehebung etwas unschön aus, aber stört den Programmablauf eigentlich nicht weiter.

Für mich klingt das so, als ob für den Datenaustausch mit dem CP443-5 über den Rückwandbus nicht genug Zeit ist --> also die Prozessabbild-Aktualisierung sprich OB1-Zykluszeit verlangsamen, z.B. durch Einstellen einer OB1-Mindestzykluszeit oder WAIT Aufruf. Ich meine, für E/A-Datenblöcke > 32 Byte ist das Protokoll für die Rückwandbus-Kommunikation aufwendiger. Konsistente Daten schreiben zu CP dauert bei der 416-2XK04 dreimal so lange wie zur in der CPU integrierten DP-Schnittstelle.

Thomas_v2.1 schrieb:

Firmware der CPU bzw. CP müsste ich prüfen ob das noch aktuell ist, CPU ist eine 416-2XK04-0AB0 mit FW 4.1.0 und CP ist ein 443-5DX03-0XE0 und hat FW 5.3.6.

Zum Vergrößern anklicken....

CPU 416-2XK04 Firmware V4.1.1
CP 443-5DX03 Firmware V5.3.6 dürfte die aktuellste Version sein

Harald

Ich musste den WAIT noch auf 4 ms erhöhen, weil alle paar Stunden immer noch ein Fehler im Diagnosepuffer auftrat. Bisher noch kein neuer Eintrag im Diagnosepuffer.

Dass ich im Diagnosepuffer Fehlercodes von SFCs wiederfinde habe ich jetzt auch das erste Mal gesehen. Scheint so, als wenn die Daten der Slaves am CP im Prozessabbild liegen, das intern über entsprechende SFC-Aufrufe realisiert wird.

Wenn ich die Daten der Teilnehmer am externen CP in entsprechende SFCs umrechne, dann bin ich in Summe bei ca. 2,5 ms, zumindest wenn ich für größere Blöcke dann die Zeiten für x-fache 32 Byte Blöcke verwende. Dann müsste der letzte (interne) DPWR_DAT Aufruf ja schon mehr als 4 ms benötigen damit der Fehler auftritt (2 ms für Aktualisierung der Eingänge + 2 ms für meinen Wait im OB1). Ich nehme einfach mal an, dass vor Beginn des OB1 die SFC DPRD_DAT intern aufgerufen werden um das Prozessabbild der Eingänge zu aktualisieren