Step 7 PN-PN Koppler - "Statusfehler / Übertragene Nutzdaten ungültig (teilweise ungültig gekennzeichnet)"

Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,
Das hört sich doch schon mal gut an.

Deine Daten könnten aufgrund der DB Grenzen nicht gelesen werden. Was sagen DPRD und DPWR? Oder schaust du direkt auf die I/O´s?
Bezüglich des DS (Datastatusbyte) sollte es passen, 8 Byte Output auf der einen Seite ergeben dann aber halt 9 Byte Input ( 8 Byte Daten + 1 Byte Diagnose). Hierbei ist das nur bei der Auswertung relevant, da dein DB mit den Eingängen nun 9 Byte groß sein muss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
die Frage passt nicht zu CPU 315-2 DP + CP 343-1
Mit PNPN per CP in dieser speziellen Kombination habe ich noch nicht gearbeitet, ich habe nur Erfahrungen direkt an der 315-2 PN/DP.
Wir nutzen dabei immer SFC14 DPRD_DAT und SFC15 DPWR_DAT um die Daten in einen entsprechenden DB zu kopieren.

Woraus schließt du das?
Ist mein eigener Lieblingsfehler bei PNPN Kopplern beim Datenstatus das "extra" Byte zu vergessen.
Hierbei muss halt der Datenbereich im DB für die Eingänge mindestens 9 Byte groß sein (Bei 8 Byte+DS), da sonst die DPRD_DAT einen Fehler ausgibt und gar keine Daten ausließt. Erkennbar auch an der RET_VAL.
 
Also - tatsächlich war einfach mein Fehler, nicht die Bausteine genutzt zu haben. Es werden jetzt Daten ausgetauscht, nachdem ich die Größe des Prozessabbildes der CPU angepasst habe. Der Fehler "Statusfehler / Übertragene Nutzdaten ungültig" kommt also daher, dass ich einfach "Nichts" gesendet habe - auch wenn ich das etwas merkwürdig finde. Verstehe aber denn Sinn dahinter irgendwo.

Aktuell wird im ersten Byte, das ich mit dem PNIO-Send Baustein versende, noch eine "1" mitgeschickt, die dort nicht hingehört. Das bekomme ich aber bestimmt noch raus.

Viele Dank für eure schnelle und kompetente Hilfe!
 
Moin,

ich bin es wieder. Ich bin vom Testaufbau an die Anlage gegangen und habe meines Wissens alles so konfiguriert wie beim Testaufbau. Ergebnis: Die letzten Module haben immer mal wieder einen Fehler, dieser wandert über die vier letzten Karten. Heißt: Jedes mal, wenn ich mir in der HW-Konfig die Online-Daten hole, sind immer andere der letzten 4 Karten im Fehler (bei den Bildern z.B. die letzten beiden bzw. letzten drei Karten).

Hat irgendjemand eine Idee, was der Fehler sein kann? Ich habe die Konfiguration mehrmals geprüft, aber irgendwo muss ja noch ein Fehler liegen. Größe des Prozessabbildes kann es ja eigentlich nicht sein, die letzten vier Karten liegen ja in einem eher kleinen Bereich.

Edit: Wobei die Größe des Prozessabbildes der CPU ja eigentlich nichts mit dem CP zu tun haben sollte, wenn ich das richtig verstanden habe.

PNPN_Fehler_492_X1.PNGPNPN_Fehler_492_X2.PNG
 
Zuletzt bearbeitet:
Ja, auf der X1-Seite (Profinet an CPU) finden sich folgende Fehler:
1731407163926.png

Der Peripherie Zugriffsfehler ist das Schreiben vom PAW12, auf die erste "Ausgangskarte" des PN-PN Kopplers.

Der Diagnosespeicher des CP's auf der X2-Seite liefert aus meiner Sicht keine weiteren Informationen. Die CPU hat mit dem Profinet nichts zu tun und liefert deshalb auch keine Infos.
1731407328318.png
 
Es werden mir ja nur Bytes zum Parametrieren ermöglicht:
1731407713353.png

Wenn ich den Schreibbefehl entferne, bleiben die Meldungen im Diagnosepuffer, dass die Submodule den Status von Bad nach Good gewechselt haben - diese Meldungen kommen aber permanent weiter, sodass sie anscheinend immer wieder in "bad" gehen.

Der Peripherie-Fehler scheint also immer dann aufzutreten, wenn das entsprechende Submodul nicht erreichbar ist ("bad").
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Auf der X1-Seite ist das Profinet-Netzwerk an der CPU. Deshalb schreibe ich direkt auf den PAW. Der tritt der Zugriffsfehler auf.
Auf der X2-Seite ist das Profinet-Netzwerk am CP, deshalb nutze ich dort PNIO Send/Recv.
 
Kannst du mal probieren per Move Befehl anstelle des FC111 die Daten in deine PAW zuschreiben. Die EA Adressen liegen ja noch im normalen PIP deiner SPS. Somit solltest du den PNPN wie "normale" EA beschreiben/lesen können.
 
Kannst du mal probieren per Move Befehl anstelle des FC111 die Daten in deine PAW zuschreiben. Die EA Adressen liegen ja noch im normalen PIP deiner SPS. Somit solltest du den PNPN wie "normale" EA beschreiben/lesen können.
Mein Stand ist, dass dies nicht geht, weil der CP sein eigenes "Prozessabbild" hat - in diesem Fall ist der PN/PN Koppler daran angebunden. Deshalb sind die Festo-Ventilinseln im gleichen E/A-Bereich wie manche Submodule des PN-PN Kopplers - das würde der Hardwaremanager ja sonst garnicht zulassen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mein Stand ist, dass dies nicht geht, weil der CP sein eigenes "Prozessabbild" hat - in diesem Fall ist der PN/PN Koppler daran angebunden. Deshalb sind die Festo-Ventilinseln im gleichen E/A-Bereich wie manche Submodule des PN-PN Kopplers - das würde der Hardwaremanager ja sonst garnicht zulassen.
Stimmt, dass hatte ich übersehen. Hattest du probiert das gesamte Prozessabbild des CP abzurufen? Oder nur den Teil des PNPN? Werde aus deiner LADDR am FC leider nicht schlau, welches Modul es ist.
 
Dass die anderen Submodule keinen Fehler haben heißt leider auch nicht, dass etwas gesendet wird... ich habe bisher keine Kommunikation in beiden Richtungen...

Auffällig ist aber schon, dass die "oberen" Submodule alle in Ordnung sind und nur die unteren Flackern. Mein Bausteinaufruf auf der X2-Seite sieht aber für mich soweit in Ordnung aus. Auffällig ist halt, dass das "Check_IOPS" Bit immer 1 ist, wenn Daten empfangen werden.
1731409052980.png
 
Stimmt, dass hatte ich übersehen. Hattest du probiert das gesamte Prozessabbild des CP abzurufen? Oder nur den Teil des PNPN? Werde aus deiner LADDR am FC leider nicht schlau, welches Modul es ist.
Tja, gute Frage, bin damit leider nicht so Vertraut.

Die LADDR ist die Adresse des CP's selbst, also 500dez=1F4hex.
1731409227299.png
 
Zurück
Oben