Lesen und Scheiben von und in den Peripheriebereich

[Chräshe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo allerseits,

ich krieg hier gerade einen Vogel!
Es sollten nur 200 Byte und ein Steuerwort an eine PROFINET IO- Slave gesendet werden.
Das geht auch, aber nur wenn ich manuell in den Peripherie- Bereich schreibe:

      L     DB1.DBD  350
      T     PAD  530
      L     DB1.DBD  354
      T     PAD  534        
       …

Bei 200 Byte sind das ja nur 100 Programmzeilen, aber trotzdem finde ich das nicht akzeptabel.

Der "BLKMOV" (SFC20) funktioniert ja im Peripherie- Bereich nicht.
SFC14 und SFC 15 funktionieren nur mit 4 Byte! Sehr Sinnvoll, man braucht nicht ein Doppelwort kopieren und mit der Hex-Eingabe wirkt das viel wichtiger… :evil:

      CALL  "DPRD_DAT"
       LADDR  :=W#16#210                //HEX für EW528
       RET_VAL:=#Ret_Val_01
       RECORD :=P#DB1.DBX92.0 BYTE 4
 
      CALL  "DPWR_DAT"
       LADDR  :=W#16#210                //HEX für AW528
       RECORD :=P#DB1.DBX348.0 BYTE 4
       RET_VAL:=#Ret_Val_02

Bei mehr als 4 Byte kommt der Fehler:
80B1 Die Länge des angegebenen Quellbereichs ist ungleich der mit STEP 7 projektierten Nutzdatenlänge.

Gibt es da irgendein Trick?
Hab ich was übersehen?
Gibt es eine andere Funktion, die ein paar Byte kopieren kann?

Gruß
Chräshe

Hardware:
IM151-8 PN/DP CPU
PROFINET IO-Device CE (TwinCAT Slave)
KTP600

Softwarestand:
STEP 7 - 2010 Professional V5.5 V5.5.0.0_25.6.0.1 V5.5.0.0
SIMATIC WinCC flexible 2008 SP2 K1.3.2.0_1.58.0.1 K1.3.2.0

 

[Manfred Stangl]

Hallo!

Das muss gehen, wenn du beim Pointer zb BYTE10 dranschreibst. Hab soeben bei mir geprüft (mit einem Servo).
Stimmt die Länge des Quell und Zielbereichs sicher überein?

 

[Verpolt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Die Hardware-P-Eingänge/P-Ausgänge müssen bei Verwendung von SFC14/15 konsistent sein.

Mit der SFC 14 "DPRD_DAT" (read consistent data of a DP-normslave) lesen Sie konsistente Daten eines DP-Normslaves/PROFINET IO-Devices aus, wobei für die Maximallänge folgendes gilt: Die Maximallänge entnehmen Sie für die S7-300-CPUs den Handbüchern Automatisierungssystem S7-300: Aufbauen, ET 200S Interfacemodul IM151-7 CPU oder Basismodul BM147CPU. Bei den S7-400-CPUs entnehmen Sie die Maximallänge dem Handbuch Automatisierungssystem S7-400 CPU-Daten. Falls bei der Datenübertragung kein Fehler auftrat, werden die gelesenen Daten in den durch RECORD aufgespannten Zielbereich eingetragen.

SFC14 und SFC 15 funktionieren nur mit 4 Byte! Sehr Sinnvoll

???. Mehr als 4 byte

Sie benötigen die SFC 14 "DPRD_DAT", weil Sie mit den Ladebefehlen, die auf die Peripherie bzw. auf das Prozeßabbild der Eingänge zugreifen, maximal vier Bytes zusammenhängend auslesen können.

 

[Chräshe]

Hallo Manfred,

ich kann da doch nur die Zugriffs- Breite angeben!?
So sieht das aus:

 

[Verpolt]

Könntest ein Bild der Hardwareconfig laden?

 

[Chräshe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, klar...


Ob die Daten konsistent oder nicht konsistent übertragen werden wäre egal. Da kann ich mich selber drum kümmern...

 

[MSB]

Das geht nur, wenn du die gesamte Länge, in der Hardware-Konfig als konsistent parametriert hast, bzw. parametrieren kannst.
Das hängt zu aller erst mal vom Slave bzw. dessen GSD-Datei ab.

Mfg
Manuel

 

[Chräshe]

OK, jetzt geht es!

Wenn ich bei den SFC14 und SFC15 je 200 Byte angebe, so wie in der HW-Konfig, dann funktioniert es. Ich hatte erwartet dass das ähnlich wie beim "BLKMOV" funktioniert. Daher hatte ich es nur mit 4, 10 und 32 Byte probiert.

Gruß
Chräshe

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielleicht noch so als Tip:
Bei der IM151 kannst du das Prozessabbild auf bis zu 2048 Byte parametrieren,
mehr kann der eh nicht adressieren ...

Sprich dann klappts auch mit dem SFC20 ...

Mfg
Manuel

 

[hovonlo]

Nein MSB, SFC20 geht leider nicht (hab' ich mir aucgh schon öfter gewünscht). Der unterstützt keine direkten Peripheriezugriffe. Siehe hierzu auch die Hilfe im Simatic Manager:

Parameter  Deklaration  Datentyp  Speicherbereich  Beschreibung
SRCBLK     INPUT        ANY       E, A, M, D, L    Angabe des Speicherbereichs,  der kopiert werden soll (Quellfeld). Arrays vom Datentyp STRING sind  nicht erlaubt.
RET_VAL    OUTPUT       INT       E, A, M, D, L    Tritt während der  Bearbeitung der Funktion ein Fehler auf, enthält der Rückgabewert einen  Fehlercode.
DSTBLK     OUTPUT       ANY       E, A, M, D, L    Angabe des Speicherbereichs,  in den kopiert werden soll (Zielfeld). Arrays vom Datentyp STRING sind  nicht erlaubt.

Als Bereiche sind leider nur Speicherbereiche (also eben Eingangs- und Ausgangsabbild, Merker, DBs und Lokaldaten) zulässig.

Aber in einer kleinen Schleife lässt sich sowas notfalls auch selber rauskopieren - allerdings auf Kosten der Konsistenz, hier geht dann maximal ein DW konsistent.

@Cräshe, vorletzter Post: Den Gedanken, den Peripheriezugriff selber konsistent regeln zu können sollte man sich mal ganz schnell abschminken. Außer über SFC14 / 15, das Eingangs-/Ausgangsabbild oder im taktsynchronen Betrieb hat man keinerlei Einfluß auf den Zeitpunkt der Übertragung der Daten zwischen CPU und PB/PN Master. Das kann mitten im Zyklus, zwischen zwei Befehlen passieren. Das Gemeine ist, dass solche Sachen über Tage und Wochen wunderbar laufen können, aber wenn's dann zu einem Konsistenzproblem kommt sucht man sich 'nen Elch.

 

[Onkel Dagobert]

..und mit der Hex-Eingabe wirkt das viel wichtiger… :evil:..

Schreibe dir doch eine FC, die deine nicht konsistenten Blöcke in einer Schleife kopiert. Die Startadresse kannst du dann auch dezimal übergeben.

Gruß, Onkel

 

[Chräshe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielleicht noch so als Tip:
Bei der IM151 kannst du das Prozessabbild auf bis zu 2048 Byte parametrieren,
mehr kann der eh nicht adressieren ...

Das kann ja jeder!
Dann hätte ich keinen Grund mehr, mich über Siemens zu ärgern…

Den Gedanken, den Peripheriezugriff selber konsistent regeln zu können sollte man sich mal ganz schnell abschminken.

Einen Handshake hätte ich der Kommunikation schon spendiert. Das ist für meine Anwendung sowieso erforderlich. Wenn es dann im gesamten 3-4 Zyklen länger dauert, ist das OK.

 

[MSB]

Nein MSB, SFC20 geht leider nicht (hab' ich mir aucgh schon öfter gewünscht). Der unterstützt keine direkten Peripheriezugriffe.

Leider hast du meinen Post nicht gelesen oder nicht verstanden ...
P.S. Der SFC20 muss den Peripheriebereich in dem Fall auch gar nicht unterstützen ...