Nur mit dem Unterschied, dass ich bei DPRD_DAT zb. das PEW256 (das erste der Baugruppe) ran schreiben kann und es dann funktioniert. [...]
mit DPRD_DAT funktioniert es und mit UBLKMOV auch
Ich habe es mit dem UBLKMOV gelöst.
Bitte zeige uns mal wie Du das mit dem UBLKMOV gelöst hast. UBLKMOV kann gar nicht aus Peripherie-Eingängen lesen. UBLKMOV müsste den Fehlerstatus W#16#8124 liefern (Bereichsfehler beim Lesen eines Parameters, und zwar des ersten Parameters SRCBLK), wenn Du bei "UBLKMOV"
SRCBLK:=PEW256 schreibst
DPRD_DAT funktioniert ebenfalls nicht, wenn Du
LADDR:=PEW256 schreibst, weil DPRD_DAT dann nicht von PEW256 liest sondern den gerade anliegenden Wert aus PEW256 als E-Adresse nimmt!
Hilfe zu Systemfunktionen schrieb:
Mit dem FB 22 "GETIO_PART" lesen Sie konsistent einen Teil des zu einem DP-Normslave / PROFINET IO-Device gehörenden Prozessabbildbereichs. Der FB 22 ruft dabei die SFC 81 "UBLKMOV" auf.
UBLKMOV (und damit GETIO_PART) kann nicht aus Peripherie-Eingängen lesen (z.B. nicht PEW256), sondern nur aus dem Speicherbereich der Eingänge E... (z.B. EW256). Damit bei dem Kopieren mit GETIO_PART was rüberkommt, muß in dem Speicherbereich EW256 auch was drinstehen - das Betriebssystem der CPU oder eine SFC wie SFC26 "UPDAT_PI" oder SFC126 "SYNC_PI" (oder SFC14 "DPRD_DAT") muß die Werte aus den Peripherieadressen zuvor in die Adressen im Speicherbereich der Eingänge kopiert (aktualisiert) haben. Das Prozessabbild der Eingänge liegt im Speicherbereich der Eingänge mit der selben Adresse: z.b. das Prozessabbild von PEW256 ist EW256. Das Prozessabbild wird allerdings nicht unbedingt automatisch mit den Werten aus der Peripherie aktualisiert.
Wenn ich ehrlich bin kann ich mit dem Hinweis in der Hilfe nichts anfangen. [...] „einem Prozessabbild zugeordnet“. Wird nicht von jedem Eingang am Anfang des Zyklus automatisch ein Prozessabbild erstellt? Also damit auch zugeordnet?
Wenn die projektierte Eingangsadresse des PN-IO-Device in HW Konfig keinem Prozessabbild zugeordnet ist ("---" anstatt OB1-PA, TPA1...), dann kopiert GETIO_PART nur Nullen (oder irgendetwas zuvor da hin Kopiertes), weil kein automatischer Vorgang zuvor die Werte von den Peripherieadressen (aus der Baugruppe) in den Speicherbereich der Eingänge kopiert hat.
Beispiel:
Wenn Du Dein PN-IO-Device auf die Eingangsadresse 256 Länge 10 Byte projektiert hast, und in der CPU ist das Prozessabbild der Eingänge (PAE) kleiner als 266 Byte eingestellt, dann werden die Werte aus PEB256..PEB265 nicht automatisch in EB256..EB265 kopiert. Man muß mit SFC14 "DPRD_DAT" die Werte aus den Peripherieadressen lesen.
Wenn das Prozessabbild PAE >= 266 Byte eingestellt ist, dann hat man die Wahl: man kann bei der Projektierung des PN-IO-Gerätes bei der E-Adresse wählen, zu welchem Prozessabbild diese E-Adresse zugeordnet werden soll (siehe [ Hilfe ] in dem Einstelldialog):
- "OB1-PA" : die Werte aus PEB256..PEB265 werden automatisch vor Aufruf des OB1 in EB256..EB265 kopiert
- "TPA 1" : die Werte aus PEB256..PEB265 müssen mit SFC26 "UPDAT_PI" oder SFC126 "SYNC_PI" in EB256..EB265 kopiert werden
- "---" : die Werte können nur mit SFC14 "DPRD_DAT" gelesen werden
Egal was bei der Zuordnung "Prozessabbild" eingestellt ist: man kann natürlich auch noch mit Ladebefehlen direkt auf die Peripherieadressen zugreifen (L PEB/PEW/PED...), doch das liefert unter Umständen nicht konsistente Werte.
Für mich ist der FB22 "GETIO_PART" etwas, was eigentlich so gut wie niemand braucht. GETIO_PART kapselt im Grunde nur den UBLKMOV, indem es aus "magic" Zahlenwerten den für UBLKMOV benötigten ANY-Pointer bastelt. In der Hilfe zu GETIO_PART wird sogar vor der dadurch möglichen unsachgemäßen Verwendung von GETIO_PART gewarnt, weil damit komponentenübergreifende Zugriffe in den Prozessabbildbereich möglich sind, deren Funktionieren Siemens für zukünftige oder fremde Systeme nicht garantieren will.
Harald
