Konfig: Siemens CP 342-5 (Slave) verbunden über Profibus mit KUKA-Rob. (Master)

Also wie es mit Kuka als Master genau ist weiß ich jetzt nicht 100%ig. Aber beim slave sit es so, daß du die Daten die vom Roboter kommen erst vom Adressbereich in den DB laden musst, dann kannst du mit den Daten auf S7 Seite arbeiten und deine Ausgänge sezten und danach als letztes Netzwerk schreibst du dann die Daten von deinem DB in den Ausgangs-Adressbereich.

Also bei dir müsste eigentlich netzwerk 2 und 3 getauscht werden. im moment schiebst du die daten auf den roboter und erst danach arbeitest du die anweisung ab.

hatte halt mal so ein problem bei einem Kuka als slave wo mir E/A's nicht reagiert haben. dA war dann auch der letzte Send baustein ganz oben im 2. netzwerk im S7

hä?
Der KUKA ist Master. Der KUKA braucht also die die Daten des Slave.
Du mußt mit einem passenden Programm (ComProfibus oder NCM) eine Datei exportieren (wird mit Hilfe der GSD-Datei der Slave-Baugruppen erstellt) und ins init-Verzeichnis des Robots stellen.
In der pbmasl.ini wird unter MASTER dieses File angegeben. Slave ist deaktiviert

@ WolfHenk.
Ich bearbeite die Aufgabe mit Mona zusammen.
Dein Tip hatten wir bereits erfüllt.
Hast du noch ´ne Idee?

Hallo,
also ich hab's immer mit den SFC's 14/15 DPRD_DAT DPWR_DAT gemacht.
Dabei ist es wichtig, dass die Länge des Datenblocks (also das hinter Byte
bei P#DBxxx.DBx.x BYTE 257) genau mit der projektierten Länge in der Hardware
übereinstimmt. Sonst geht's nicht.

Wenn Du nur ein Byte eingestellt hast, dann sollte da auch BYTE 1 und nicht BYTE 257 stehen.
Schau Dir mal die Rückgabewerte des Bausteins an, da steht bestimmt irgend ein Fehlercode drin,
die Beschreibung findet man dann in der Hilfe zum Step7

Und besser wäre es das Projekt zu posten, und nicht nur einen Screenshot.
Hermann

Hallo Hermann,
wie hast du die SFC´s genau Konfiguriert? Ich hab´s jetzt mal so probiert.
"DPWR_DAT"
EN=...
LADDR=W#16#100
RECORD= P#DB2.DBX 4.0 BYTE 16
RET_VAL = MW2
ENO=

und

"DPRD_DAT"
EN=...
LADDR=W#16#100
RECORD= P#DB1.DBX 4.0 BYTE 16
RET_VAL= MW1
ENO=

Hab mal beide Programme
1. Mit FC-Bausteinen
2. Mit SFC-Bausteinen angehängt.

In dem Programm mit den SFC steht noch BYTE 4. Das muss Byte 16 heissen.
Ausserdem muss der angesprochene DB aus genau 16 Bytes bestehen, nicht mehr und nicht weniger.
Als Adresse dann P#DB1.DBX0.0 BYTE 16 angeben.
Siemens lässt grüssen.
Viel Spass noch mit dem ganzen Mist.

..also ich hätte den Robi an euerer Stelle als Slave an die SPS gehängt und die Aufgaben die der Roboter selbst händeln muss im Masterteil gemacht, also beide Schnitstellen genutzt.

Sehe ich das richtig, daß ihr dann in der Variablentabelle nix an A 3.0 seht?

Also,
irgendwie kann ich das Objekt mit SFC-Bausteinen nicht in die SPS laden.
Fehlermeldung: "Baustein konnte nicht kopiert werden".
Mein zweites Problem ist, dass es mit den FC´s auch nicht funktioniert.
Habe in dem angehängten PDF ein paar Baugruppenzustandsfehler von der CP und der CPU eingefügt, die ich angezeigt bekomme.
Frage: Wenn bei den Fehler kein Datum dabei steht treffen diese dann überhaupt zu?

Hallo..

Wenn du SPS-Probleme hast kannst auch hier schauen und Fragen stellen,die haben bestimmt auch schon sowas gemacht...

http://www.sps-forum.de/

Kann es sein, daß die 313C da irgendwas limitiert oder die bereiche zu groß sind? Guckt mal im Datenblatt nach, ob die die Funktionen überhaupt unterstützt.

Wenn wir den Kuka in Slavebetrieb haben schicken wir die Daten immer mit SFC 20.
Hab mal das Programm so angehängt evtl. ist ein denkanstoss dabei. Ist aber nur auf die Simulation geladen worden.

nö, die ldb muß im init-ordner vom KUKA liegen und in der pfbms.ini erwähnt werden.