BLKMOV VS. Einzelanweisungen

BerndHa81

Level-1
Beiträge
6
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
ich hab mal eine Frage bzgl BLKMOV und seiner Arbeitsweise.
Kopiert die CPU sagen wir mal 100 Bytes schneller mit BLKMOV oder wenn ich z.B. in AWL 100x Lade-> Transferiere programmier? Im Endeffekt muss der BLKMOV ja das gleiche tun oder nicht?
Also mal abgesehen vom "Programmierstil", was ist schneller?

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das bedeutet, weil BLKMOV eine Systemfunktion ist benötigt es weniger Anweisungen um ein Byte zu kopieren? Klingt für mich gerade nicht einleuchtend aber ich bin gerne bereit das zu akzeptieren ;)

Wie unterscheidet sich dann genau die Arbeitsweise?
 
beispielhaft für 300er:

blkmove: 10µs + 0,01µs/byte
ublkmove: 11µs + 0,01µs/byte
L/T: L 0,10µs/byte + T 0,10µs/byte

ab 53 byte wird sfc20 interessant...

aber ob ich nun 4zeilen sfc aufruf habe oder 106zeilen L/T ist auch eine ästethische frage...
 
Sehr schöne Antwort, Dankeschön! :)

Bzgl ästhetisch, ja, dessen bin ich mir auch bewusst, das dumme ist nur, dass ich viele nicht zusammenhängende Bereiche kopieren muss.
Allerdings muss ich die Daten eh in Excellisten zusammenfassen, von daher kann ich leicht AWL Code mit Excel erstellen, der dann in einer Funktion verschwindet.

Ok, wie dem auch sei, jetzt bin ich schlauer. Danke!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Blkmove

Wenn ich dann Blkmove mit einer Flanke triggere. Ist dann sichergestellt, daß der ganze Bereich kopiert wird oder muß ich irgendwie die letzten übertragenen bytes vergleichen
 
Hallo Guste,
das kann man schön mit knappen Worten beantworten. :D

Typischerweise passiert das Kopieren innnerhalb eines CPU-Zyklus.
Dann ist das mit der Flanke auch in Ordnung.

Leider scheint es CPUs zu geben, wo diese "goldene" Regel nicht stimmt.

Ich kenne eine größere Firma, die mit gewissen CPUs Probleme hatte.
Fehlerfunktionen waren nachher eindeutig auf den SCF20 zurückzuführen.

Seit der Zeit keine Flanke mehr an den Eingang sondern eine Nummer
einer Schrittkette, die erst dann weiterschaltet, wenn das RETVAL
den richtigen Wert hat.

Alternativ kann man das Triggern auch mit einem SR machen, wobei der
RETVAL-Vergleicher das Rücksetzen übernimmt.

Gruß

Frank
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Leider scheint es CPUs zu geben, wo diese "goldene" Regel nicht stimmt.
Hallo Frank,
wieso soll das an der CPU hängen?
Das Programm läuft in den SFC20 rein und der kopiert (wahrscheinlich) in einer Schleife (übers Adressregister) die Daten von Eingang zum Ausgang.
Das steht auch so in der Hilfe.

Aber die Diskussion gab es hier schon einmal:
http://sps-forum.de/showthread.php?p=250527#post250527

Schau mal meinen Post Nr. 6 von dem genannten Thread
 
Das bedeutet, weil BLKMOV eine Systemfunktion ist benötigt es weniger Anweisungen um ein Byte zu kopieren? Klingt für mich gerade nicht einleuchtend aber ich bin gerne bereit das zu akzeptieren ;)

Wie unterscheidet sich dann genau die Arbeitsweise?

Ich glaube die Systemfunktionen sind in Assembler (bzw direkt in MC7) geschrieben. Dadurch wird es möglich sein das die einzelnen Register direkt angesprochen werden können und nicht nur Akku1. Bzw werden überhaupt mehr Register zur Verfügung stehen.
Wenn jetzt die CPU Pipelining (mehrere Befehle gleichzeitig bearbeiten) beherrscht dann dann kann es sein das zwischen L MBx und T MBx ein oder mehrere Takte der CPU freigelassen werden müssen da der Wert von MBx noch nicht im Akku steht wenn der Transferbefehl ihn schon wieder wegspeichern will.
Dadurch ist es sinnvoll wenn mehrere Register angesprochen werden können weil dann können mehrere Ladebefehle hintereinander stehen und die Transferbefehle dann im entsprechenden Abstand zu den jeweiligen Ladebefehlen. Dadurch hat die CPU keine Leertakte.

Ein weiterer Vorteil ist das der Interpreter (bei S7-300) wenn er zum Interpretieren der SFC kommt genau weiß wieviele Bytes kopiert werden müssen. Also er kann den zu Ausführenden Code besser optimieren als wenn er jeden Befehl einzeln interpretieren muss.
Deshalb ist auch so eine Offsetzeit von 10µs für das interpretieren der SFC vorhanden.
Allerdings kann auch sein das die SFC zum teil schon Kompiliert sind was sie natürlich auch schneller macht.

Naja das waren jetzt nur ein paar Gedanken von mir.
Kann natürlich ganz andere Gründe auch haben warum die SFC 20 schneller ist als einzelne Lade und Transferbefehle.

godi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Zeit zum Kopieren hängt von der CPU ab, manche CPUs kopieren in AWL schneller als im SFC20 (z.B. Speed7).

Und es hängt, wie bereits gesagt worden ist, von der Datenmenge ab. Der Wert, ab dem der SFC20 schneller wird hängt von der CPU ab.

Der SFC 20 ist aber unterbrechbar durch höherpriore OBs!
Dann erwischt man den Datenbestand eventuell in der Mitte!

Wenn es wirklich drauf ankommt: Ausprobieren und Messen!

Die Werte aus dem Handbuch geben einen typischen Wert wieder,
es gibt zu viele Kombination aus Quell und Ziel Anypointer!
 
Aber dieses problem habe Ich ja bei einer eigenen Schleife auch! Der Sfc20 wird aber nach abarbeitung des höherprioren ob's wieder fortgesetzt, oder etwa nicht?

Richtig! SFC20 und AWL-Copy-Loop sind bezüglich Unterbrechbarkeit gleich.

Für den meist selten Fall, dess es doch notwendig sein sollte, dass ununterbrechbar kopiert werden muss, ist der SFC81 nötig.
 
Zurück
Oben