Step 7 BLKMOV und überlappende Bereiche

Löwensenft

Level-1
Beiträge
43
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich hätte da mal eine Frage, die ich so hier im Forum noch nicht gefunden habe: Es geht um die Funktion BLKMOV (SFC20). Es wird in der Dokumentation beschrieben, dass Quell- und Ziel-Bereich nicht überlappen dürfen.

Folgendes Szenario: Ich habe ein ARRAY[1..10] OF UDT4711 (stellt es euch als FIFO vor). In einer Funktion bearbeite ich nun das FIFO, das heißt immer das erste Element in einem Zyklus. Bin ich mit dem Element fertig, sollen die Elemente 2..10 eins nach vorne rutschen, also auf die Plätze 1..9.

Ich vermute mal stark, dass BLKMOV das Kopieren byte-weise durchführt. Sofern das Ziel *vor* der Quelle liegt, sollte hierbei kein Fehler passieren, oder? Alternativ (so mache ich es bisher) kopiere ich ein Element nach dem anderen eins nach vorne.

Gruß
Max
 
Egal ob BLKMOV Byte- oder DWord-weise kopiert: es kommt nicht drauf an, weil er ja zuerst aus dem Quellbereich lesen muß bevor er in den möglicherweise überlappten Zielbereich schreiben kann. Solange BLKMOV aufsteigend arbeitet und der überlappende Zielbereich nicht hinter dem Quellbereich beginnt, funktioniert das Kopieren. Und das tut er schon immer so. Doch wenn man sich nicht darauf verlassen mag, dann kann man zunächst in einen zweiten temporären Bereich kopieren und danach von da zum eigentlichen Zielbereich.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ob überlappende Zugriffe mit Blockmove funktionieren hängt von der Hardware ab.
Mit einer CPU312 klappt es nicht, mit einer 315 oder 317 schon.
Da es die schnellste Funktion ist um ein FIFO zu schieben, verwende ich die Sache auch gerne.
Wenn es nicht klappt, dann brauchst du eben einen Temp-Bereich in zuerst deine Daten reinschiebst und anschliessend in den Zielbereich überträgst.
Aber selbst mit 2 Blockmove-Aufrufen ist es meist immer noch schneller als die üblichen Schleifen-Konstrukte.
Besonders elegant lässt sich sowas mit Views (AT) in SCL lösen.

Gruß
Dieter
 
Deine Überlegung würde dann stimmen, wenn BLOCKMOV immer mit dem ersten Byte des Blockes beginnt. Wenn es aber intern von 'hinten' nach 'vorne' arbeitet, sieht es anders aus. Es gibt irgendwo im Forum Beiträge, in denen das Verhalten erforscht wurde, ich würde mich auf Dauer nicht auf vorhersagbares Verhalten verlassen.
Gruß
Erich
 
SFC20 arbeitet immer in Richtung aufsteigender Adressen.
Versucht man als ein Array[10] of Word überlappend umzukopieren, so das die ArrayMembers 0-9 auf 1-10 landen, dann bekommt man.
Code:
Quelle: P#DB10.DBx0.0 Byte 18
Ziel: P#DB10.DBx2.0 Byte 18

Byte 0/1 auf Byte 2/3
Byte 2/3 auf Byte 4/5
Byte 4/5 auf Byte 6/7
Byte 6/7 auf Byte 8/9
In dem Fall hätte man überall den Wert von Byte0/1 drin.

Was mich noch interessiert, wie es den genau mit der Einheitsgröße die SFC20 beim kopieren nimmt.
Hängt das vom Quell/Ziel-Pointer ab ob er nun Byteweise(String), Wortweise, oder DWORD-Weise kopiert?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was sind Views AT in SCL?:?:

Damit kannst du vereinfacht gesagt Datenbereichen mit anderen Variablentypen ansprechen.
Damit kannst du z.B. sehr einfach einen Any-Pointer aufschlüsseln.
Hab nur gerade kein Step7 greifbar um mal ein Beispiel anzuhängen.

Gruß
Dieter
 
Hmm, ich habe noch nie gehört, daß der BLKMOV auf einer 312 anders funktioniert als auf den anderen S7-300/400
:confused:

Harald

Ist aber so ;)
Laut Handbuch dürfen sich Quell- und Zielbereich beim Blockmove nicht überlagern.
Bei einer 315er funktioniert das aber problemlos und man kann ein sehr schnelles und einfaches FiFo programmieren.
Auf einer 312 funktionieren diese überlappenden Zugriffe nicht.

Gruß
Dieter
 
Hi,

interessant @ 312er. Ich bin immer wieder erstaunt wie gut es Siemens schafft in den verschiedenen (aber irgendwie gleichen) Produkten doch immer wieder elementare Unteschiede reinzubringen. Anyway, darum gehts ja jetzt nicht. ;)

Wenn Siemens nicht doch mehr Logik eingebaut hat, dann werden mit Sicherheit Bytes kopiert, da das nunmal die kleinste Speichereinheit ist (und wegen der Anmerkung in der Hilfe: "Wenn ein Bereich vom Datentyp BOOL kopiert wird, muss die angegebene Länge des Bereichs durch 8 teilbar sein, da sonst die Anweisung nicht ausgeführt wird.").

Dass die Kopierreihenfolge in Richtung aufsteigender Adressen erfolgt, steht auch in der Hilfe. Da hatte ich nicht mehr dran gedacht, danke. :)

Was mich auch noch im Zusammenhang mit BLKMOV interessieren würde ist die tatsächliche Performance. Also wie viele BLKMOVs von der max. DB-Größe (also 64kByte) können in einer Sekunde ausgeführt werden? Hat das zufällig schonmal jemand ermittelt? Wenn nein prüfe ich es selbst. Dass es hier keine Zahl für alle vorhandenen Steuerungen gibt ist mir schon klar, aber typenspezifische Aussagen wären mal nett.

Viele Grüße
Max
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist aber so ;)
Laut Handbuch dürfen sich Quell- und Zielbereich beim Blockmove nicht überlagern.
Bei einer 315er funktioniert das aber problemlos und man kann ein sehr schnelles und einfaches FiFo programmieren.
Auf einer 312 funktionieren diese überlappenden Zugriffe nicht.

Ich hätte ja sehr starke Bedenken etwas zu verwenden, wovon die Herstellerdokumentation sagt es funktioniert nicht, und ich dann selber an einer bestimmten Version feststelle dass es gerade zufällig hier funktioniert. Denn damit ist nicht garantiert, dass es bei einer kleinsten Firmwareänderung immer noch funktioniert.

Evtl. wird da im SFC in der SPS unterlagert die C-Funktion memcpy() aufgerufen. Und bei dieser ist bei überlappenden Speicherbereichen die Funktion mit "undefined behaviour" gekennzeichnet. Das heißt es kann funktionieren oder auch nicht. Jedes Tool zur statischen Codeanalyse wird dir das zu Recht anmeckern.
 
@Thomas
Natürlich hast du damit recht.

Es ist nicht unbedingt empfehlendswert Blockmove so zu nutzen.
Laut Siemens liegt es wirklich am memcpy

Gruß
Dieter
 
Zuletzt bearbeitet:
Hi,

das wäre natürlich auch noch eine Möglichkeit @ Verwendung von memcpy. Da hatte ich auch bereits dran gedacht. Manchmal (Untertreibung) vermisse ich die ganzen C-Standardfunktionen in S7-Programmen.

Gruß
Max
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

das wäre natürlich auch noch eine Möglichkeit @ Verwendung von memcpy. Da hatte ich auch bereits dran gedacht. Manchmal (Untertreibung) vermisse ich die ganzen C-Standardfunktionen in S7-Programmen.

Gruß
Max

Thomas bezog sich auf das memcpy des Compilers mit dem die Firmware für die S7-CPU geschrieben wurde.

Für die S5-Steuerungen konntest du bei Siemens früher für richtig viel Geld sogar einen C-Compiler bekommen.

Gruß
Dieter
 
Hi,

ich weiß schon. ;) Ich komme eigentlich auch aus der schönen und luxuriösen Hochsprachen-Welt (man lernt etwas erst zu schätzen wenn man es nicht mehr hat) und greife mir in letzter Zeit immer öfter an den Kopf und frag mich wer bei Siemens die Entscheidungen für den Programmiersprachenumfang und die Entwicklungsumgebung trifft. Man versucht scheinbar krampfhaft alles einfach zu halten ohne die Möglichkeiten zu geben doch etwas anspruchsvollere Dinge in AWL/SCL umsetzen zu können. Denn im Grunde steckt da ein kleiner µC dahinter, der so funktioniert und so viel kann wie jeder andere µC auch, den ich mit C und nem entsprechenden Compiler programmieren kann. Naja.

Gruß
Max
 
Hi,

eventuell eine Nice-To-Know-Information. Ich habe nun mal die Performance von BLKMOV auf meinem Zielsystem getestet (IPC427D, i7-3517UE, 4GB RAM, WES7 SP1, 80GB SSD, WinAC RTX 2010, Bestell-Nr. 6AG4140-8BL04-0HB0).

Hier braucht der Aufruf
Code:
CALL "BLKMOV" (
    SRCBLK  := P#DB30001.DBX 0.0 BYTE 65534,
    RET_VAL := #tmpRetVal,
    DSTBLK  := P#DB30002.DBX 0.0 BYTE 65534)
im Schnitt 7.6µs.

Mit nur 10000 Bytes sind es ca. 1.4µs. :eek:

Ich glaube, bevor ich in Zukunft nochmal mit Absolutadressen rumhantiere (aufgrund von dynamisch zu verwendenden DBs), kopiere ich mir den benötigten DB ab sofort in einen Arbeits-DB und greif symbolisch drauf zu. Schön ist zwar anders (ich würde ja lieber bspw. nen Pointer in nen UDT casten), aber hauptsache symbolisch auf die Daten zugreifen.

Gruß
Max
 
Zurück
Oben