TIA Zu blöd für DPRD_DAT und DPWR_DAT

Matze001

Level-3
Beiträge
2.809
Reaktionspunkte
568
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

ich fühle mich ein wenig dumm ;)

Zum Aufbau:

TIA V13 SP1 UPD1

IM151-8-F PN/DP mit DP Anschaltmodul.
Kuka KRC2 mit CP1616 als Slave am Profibus. Die GSD Datei passt und ich kann mit dem Roboter kommunizieren (PEW und PAW kann ich beobachten / steuern)
Aufbau der GSD-Datei:

16 Byte Out
16 Byte Out
16 Byte IN
16 Byte IN

Bisher habe ich immer mit DPRD_DAT und DPWR_DAT die Daten in einen DB kopiert und alles war gut.
Nun bekomme ich den Fehler h#80B1 -> Die Datenlänge des Zielbereichs ist ungleich der projektierten Nutzddatenlänge.
Okay, die Meldung kenne ich ;) Also geguckt, im DB habe ich immer 16 Byte STRUCTs, somit müsste es eigtl. passen.

Ich habe nun zum Spaß ein Array of Byte bzw. Struct mit 16 Bytes angelegt -> klappt trotzdem nicht.
Auch versuche mit 15 byte oder 17 byte (man kann es ja mal probieren) haben das gleiche Ergebnis (Habe ich aber erwartet).

Muss ich ggf. etwas anders machen wenn ein Slave modular ist? Es gibt da so einen schönen Satz in der Hilfe von TIAP der aber irgendwie kryptisch ist.

"Der Zielbereich muss die Selbe Länge aufweisen, die Sie für die selektierte Baugruppe projektiert haben. Bei einem DP-Normslave mit modularem Aufbau bzw. mit mehreren DP-Kennungen können Sie mit einem DPRD_DAT Aufruf jeweils nur auf die Daten einer Baugruppe/DP-Kennung unter der projektierten Anfangsadresse zugreifen. "

Okay... das heisst für mich ich muss 2 mal DPRD_DAT aufrufen mit 16 Byte -> Wie ich es schon mache.
Zum Spaß habe ich mal einen mit 32 Byte auf die erste Adresse gemacht, und siehe da: auch nix.

Wäre super wenn mir jemand einen Tipp geben könnte!

Danke!

Grüße

Marcel
 
Sind die Slave-Module auch "konsistente" Module?
Das würde aber wahrscheinlich W#16#8093 als Fehler ergeben....
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Du könntest auch die E/A-Adressen ins Prozessabbild legen und auf EW/AW zugreifen, da brauchst Du keine DPRD_DAT und DPWR_DAT, egal wie die Konsistenz eingestellt ist.

Harald
 
Du könntest auch die E/A-Adressen ins Prozessabbild legen und auf EW/AW zugreifen, da brauchst Du keine DPRD_DAT und DPWR_DAT, egal wie die Konsistenz eingestellt ist.
Rein der Interesse wegen...

Wenn man den Slave ins Prozessabbild nimmt hat man ja nur Konsistenz zwischen dem Peripheriebereich und dem Prozessabbild hergestellt.
Man hat aber trotzdem keine Garantie dass man vom Slave konsistente Daten hat, oder?

Gerade bei Einheit Byte fürchte ich mich im Hinterkopf immer dass, wenn z.B. ein Float übertragen wird, man durch ein Konsistenzproblem Blödsinn erhält.
Ist mir in der Praxis aber noch nie unter gekommen.

Hatte jemand hier schon mal so ein Problem?
 
Zurück
Oben