Step 7 PB steigt sporadisch aus

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube das MSB und PN/DP sind auf den richtigen Spuhr.
Was ich erst jetzt verstanden habe ist das die Adressen ab 300 inklusiv 308 gehören zu der Prozessimage von der CPU und repräsentiert das CP342-5 karte.
Ich hatte gedacht das die Adressen gehörte zu das Prozessimage des CP342-5 und repräsentiert der Kuka Roboter, was aber falsch ist.
Auf diesen Grund kann man konkludieren dass das Problem liegt bei der CPU, das CP342-5 Karte, oder der Rückwandbus.

 

[Hoffe69]

Nein, ein IM 151 ist nicht in der Anlage verbaut. Als Slave fungiert eine KUKA CP5614 (6GK1 561-4AA00) und als Master der CP342-5 (6GK7 342-5DA02-0XE0 V5.0)

 

[Hoffe69]

Zuviel Werbung?
-> Hier kostenlos registrieren

PN/DP, du hast recht mit dem Adressraum des CPs. Dieser liegt laut HW-Konfig bei den Ein/Ausgängen bei 304 mit einer Länge von 16 (Einheit ist nicht angegeben). Meine Annahme, dass der jeweilige Bereich 32 Byte breit sein muss liegt wohl an der Tatsache, dass am Slave jeweils 2 EIN/Ausgangsmodule jeweils 16 Byte lang projektiert sind.
Laut Literatur kann der interne Datenspeicher eines CPs bis 2160 Bytes groß sein.
Mein Fehler.
Ich könnte den CP austauschen, allerdings sind damit Kosten verbunden, da es mitlerweile der 3. CP ist. (in 10 Jahren). Da die CPU aber eine integrierte DP-Schnittstelle besitzt und diese für nass rumliegt, dachte ich mir diese zu nutzen. Hardwarekonfig und Programm habe ich schon offline geändert, traue mich aber wegen der MPI Verbindung CPU-TP nicht, die HW zu übertragen. (seihe meine anderen Beiträge)

 

[JesperMP]

Ich finde es Sinnvoll der Konfiguration von CP342-5 auf integrierte DP Schnittstelle zu ändern.
Du kannst als erste Schritt nur den KuKa Roboter auf das DP Schnittstelle verbinden. Wenn dies scheint zu funktionieren, dann kannst du später der CP342-5 von Konfiguration, und von das Rack entfernen.
Ich bin sicher das es der MPI Kommunikation zwischen CPU und TP nicht beeinflüssen wird. MPI ist sehr einfach, wenn nur die MPI Adressen nicht geändert werden, dann kann nichts passieren.

 

[MSB]

Wichtig für dich nur:
Du musst definitiv die FC1/FC2 DP Send/Recv rausschmeißen, und z.B. gegen SFC14/15 ersetzen.
Die HW-Konfig alleine reicht nicht.

ABER: Da du schreibst es wäre der 3.CP in 10 Jahren, lässt darauf schließen, das an der Anlage insgesamt größere technische Probleme sind,
z.B. EMV, Spannungsschwankungen etc.
Speziell diese CPs kenne ich eigentlich eher als robuste Zeitgenossen, ohne echte Altersschwächen, insofern wäre zu vermuten,
das du das Problem damit mittelfristig auf die CPU schiebst, indem du diese schrottest.

Mfg
Manuel

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Laut Literatur kann der interne Datenspeicher eines CPs bis 2160 Bytes groß sein.

Die DP-Slavedaten werden mit den FC DP_SEND/DP_RECV zwischen der CPU und dem CP ausgetauscht. Meist in einen DB der CPU, daher kann der Profibus-E/A-Adressraum größer sein als der E/A-Adressraum der CPU.

Da die CPU aber eine integrierte DP-Schnittstelle besitzt und diese für nass rumliegt, dachte ich mir diese zu nutzen. Hardwarekonfig und Programm habe ich schon offline geändert

Gibt es in Deinem Programm eine Profibus-Diagnose mit DP_DIAG oder SFC51 oder SFC59 oder andere Spezialitäten wie DP_CTRL?
Gibt es Kommunikation zum CP342-5 mit AG_SEND/AG_RECV (z.B. für FDL-Verbindungen zu anderen Profibus-Teilnehmern)?
Gibt es irgendwelche Verbindungen über den CP342-5 (siehe NetPro)?
Wenn ja, dann wird das mit der CPU-integrierten DP-Schnittstelle nicht mehr funktionieren und müsste ggf. umprogrammiert werden.

Gibt es Konsistenzen > 4 Byte zu beachten? Dann muß mit SFC14/SFC15 gearbeitet werden oder einfacher: die E/A-Adressen der DP-Slaves in das Prozessabbild der CPU legen.
Wieviele Profibus-Slaves bzw. -Teilnehmer gibt es überhaupt? Ist das nur der Roboter?

traue mich aber wegen der MPI Verbindung CPU-TP nicht, die HW zu übertragen.

Man kann die aktuelle HW Konfig vorher sichern. AG-Abzug machen oder zumindest das komplette Systemdatenbausteine-Objekt von Online aus der CPU herauskopieren. Oder die MMC der CPU austauschen und für die Versuche mit einer anderen MMC arbeiten. Dann kann man im Notfall die original-MMC wieder in die CPU stecken. DB-Aktualdaten sichern nicht vergessen, falls notwendig.

Ziemlich sicher wird die Änderung der HW Konfig keinen Einfluß auf das TP170B haben, Hauptsache die MPI-Adresse und -Baudrate der CPU bleibt gleich.

Harald

 

[PN/DP]

Call "DP_RECV" ; FC 102
CPLADDR:= W#16#130 ; 304 dez
RECV :=P#DB35.DBx0.0 ;hier müsste eigentlich noch die Länge des Zeigers angegeben werden, ist aber nicht
NDR :=M162.0
ERROR :=M162.1
STATUS :=MW164
DPSTATUS:=MB166

Das ist nur ein uraltes Anzeigeproblem des FUP/KOP/AWL-Editors, der so lange wie möglich an der symbolischen Darstellung des ANY festhält.

Halte die Maus über das P#DB35.DBX0.0 --> dann wird im Tooltip "P#DB35.... / Zugriffsbreite xx Byte" angezeigt.
Oder schaue Dir den FC-Call online in der CPU über "Erreichbare Teilnehmer" an --> da wird der wirkliche ANY komplett angezeigt: P#DB35.DBX0.0 BYTE xx
(oder den Baustein mit dem Call in PLCSIM laden, dann über "Erreichbare Teilnehmer" in einen anderen Bausteine-Ordner herauskopieren, so daß die Symbolzuordnungen verloren gehen)

Harald

 

[Hoffe69]

Danke Harald für deine Hinweise,

an dem CP hängt nur der Roboter und kein anderer Slave. Da in der Anlage mit Asi gearbeitet wird und die ganzen Asi Sachen in einem DB "gesammelt" werden, kann ich mich im Prozessabbild "austoben". Ich habe in der neuen HW-Konfig den EIN-und Ausgangsbereich der integrierten DP Schnittstelle auf E80 und A80 mit der jeweiligen Länge von 32 Byte gelegt. Jetzt könnte ich doch über Lade und Transferbefehle auf diesen Bereich zugreifen, da dieser doch jetzt im Prozessabbild liegt und die Sachen sind trotzdem konsistent, oder habe ich mir das zu einfach vorgestellt?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vor Deiner Beitrags-Änderung sah das schon wieder falsch aus, doch OK, nun sind es je 32 Byte.

Es ist total wichtig, daß die Modulkonfiguration des Slave exakt zum neuen Master übernommen wird, sonst spricht der Roboter nicht mit dem neuen Master (E/A-Adressen können geändert werden). Man kann irgendwie die DP-Slaves einzeln "umhängen" (ausschneiden+einfügen?), am besten aber das gesamte DP-Mastersystem vom CP abkoppeln und am CPU-integrierten DP wieder ankoppeln (oder so ähnlich, ich habe jetzt kein Step7).

Ich würde die vorhandenen Aufrufe von DP_RECV und DP_SEND ersetzen durch SFC20 BLKMOV von E80... nach DB35.DBX0.0... und vom DP_SEND-DB nach A80... (also einfach die E/A Umrangieren), dann brauchen im restlichen Programm keine Adressen geändert werden. Wenn der Slave am CP jeweils ab E0/A0 projektiert war. Falls nicht oder falls irgendwelche Adresslücken sind, dann kannst Du auch mit L ED80 / T DB35.DBD0 ... die E/A-Bytes in/aus die entsprechenden Adressen in dem/den DP-DB kopieren.

Harald