BLKMOV (SFC20) - falsche Reihenfolge beim Schieben

EliteGurke · 3 Dezember 2012

Guten Tag liebe SPSler,

Ich hätte da gerne mal wieder ein Problem...

Folgender Code:

Code:

MOVE: L     #AnfangDB      L     8
      +I    
      T     #QuellDW
      T     #ZielDW


      LAR1  P##Quelle                   //Anfangsadresse des ANY-Pointers in AR1 laden


      L     B#(16, 2)                   //Syntax-ID und Typ: Byte laden
      T     LW [AR1,P#0.0]
      L     #AnzahlDBB                  //Transferlaenge
      T     LW [AR1,P#2.0]
      L     #QuellDB                    //Quelle-DB
      T     LW [AR1,P#4.0]
      L     P#DBX 0.0                   //Anfangs-DW im Quell-DB
      L     #QuellDW
      SLD   3
      +D    
      T     LD [AR1,P#6.0]


      LAR1  P##Ziel                     //Anfangsadresse des ANY-Pointers in AR1


      L     B#(16, 2)                   //Syntax-ID und Typ: Byte laden
      T     LW [AR1,P#0.0]
      L     #AnzahlDBB                  //Transferlaenge
      T     LW [AR1,P#2.0]
      L     #ZielDB                     //Ziel-DB
      T     LW [AR1,P#4.0]
      L     P#DBX 4.0                   //Anfangs-DW im Ziel-DB
      L     #ZielDW
      SLD   3
      +D    
      T     LD [AR1,P#6.0]
      L     B#16#84
      T     LB [AR1,P#6.0]


      CALL  "BLKMOV"
       SRCBLK :=#Quelle
       RET_VAL:=#retval.blkmov
       DSTBLK :=#Ziel

macht 2 unterschiedliche Sachen auf PLCSIM und echter 315-2 PN/DP.

Es sollte eigentlich als FILO funktionieren, was es auf der PLCSIM ja auch tut.
Auf der echten CPU schreibt das gute Ding aber leider nur den ersten Wert auf alle nachfolgenden...

Gibt es auf den CPUs verschiedene SFC Versionen oder bin ich falsch gewickelt, wenn ich
annehme, dass der SFC20 rekursiv, also von hinten nach vorne schiebt?

Vielleicht sollte ich noch vorab bemerken, dass hier QuellDB und ZielDB identisch sind.
Die Daten werden quasi nur 4 byte nach hinten geschoben.

Tigerente1974 · 3 Dezember 2012

Aus der Hilfe des SFC20:

Bedingungen für Quell- und Zielfeld

Quell- und Zielfeld dürfen sich nicht überlappen.

Ich denke das dürfte bei Dir der Fall sein.

EliteGurke · 3 Dezember 2012

Hmm ok, auch gerade gelesen.

Dann ist das wohl mal wieder so ein Ding das nur in der PLCSIM hinhaut...

Blockmove · 3 Dezember 2012

Nein das funktioniert nicht nur in PLCSIM. Es funktioniert auch bei einigen realen CPUs
Hängt wohl vom verbautem Prozessortyp ab.
Bin neulich auch drübergestolpert als ich nen Baustein von einer 400er auf einer 312C verwenden wollte.

Gruß
Dieter

Oberchefe · 3 Dezember 2012

Bedingungen für Quell- und Zielfeld

Quell- und Zielfeld dürfen sich nicht überlappen.

würde ich nicht generell sagen, soweit ich weiß geht's solange das Ziel eine niedrigere Adresse hat als die Quelle, CPU-intern läuft das wohl in einer Schleife ab bei der mit der niedrigsten Adresse begonnen wird und dann Byte für Byte (oder Wort für Wort?) nach oben weiter gemacht wird.

bike · 3 Dezember 2012

Bei solchen Funktionen verwende ich Ar1 und AR2 für Quelle und Ziel.
Da habe ich weder in 300er noch 400er CPU ein Problem bisher gehabt.

Das mit den überlappenden Bereichen habe ich auch gelesen, doch habe ich auch schon überlappen lassen, wenn mehr als 4 Byte Abstand sind, funktioniert es.

bike

Blockmove · 3 Dezember 2012

bike schrieb:
Bei solchen Funktionen verwende ich Ar1 und AR2 für Quelle und Ziel.
Da habe ich weder in 300er noch 400er CPU ein Problem bisher gehabt.

Das mit den überlappenden Bereichen habe ich auch gelesen, doch habe ich auch schon überlappen lassen, wenn mehr als 4 Byte Abstand sind, funktioniert es.

Meiner Erfahrung nach, macht AR1/AR2 oder statische Pointer keinen Unterschied.
Auch das mit den größer 4 Byte kann ich nicht bestätigen.
Es liegt wohl wirklich an der CPU.
Eine 317-2 verhält sich anders als eine 315 und eine 312 wieder anders.
Nur die 400er schlucken das problemlos.

Das nervige ist, dass PLCSIM den CPU-Typ nicht berücksichtigt.

Gruß
Dieter

bike · 3 Dezember 2012

Blockmove schrieb:
Meiner Erfahrung nach, macht AR1/AR2 oder statische Pointer keinen Unterschied.
Auch das mit den größer 4 Byte kann ich nicht bestätigen.
Es liegt wohl wirklich an der CPU.
Eine 317-2 verhält sich anders als eine 315 und eine 312 wieder anders.
Nur die 400er schlucken das problemlos.

Das nervige ist, dass PLCSIM den CPU-Typ nicht berücksichtigt.

Gruß
Dieter

Das kann sein, dass es bei den kleineren CPU nicht funktioniert.
Wir haben keine CPU kleiner als 315 2DP.
Und ab dieser CPU bis 416 funktioniert die von mir geschriebene Funktion.
Denn ich habe bisher keine Reklamation bekommen.

bike

Jochen Kühner · 3 Dezember 2012

Ich würde mich darauf das es Funktioniert nicht verlassen, das kann dann mit dem nächsten Firmwareupdate schon wieder nicht mehr der Fall sein. Lieber das ganze selbst in einer Schleife abhandeln... dann geht der Code auch später mal noch in einer 1500er ... ;-)

Blockmove · 3 Dezember 2012

Jochen Kühner schrieb:
Ich würde mich darauf das es Funktioniert nicht verlassen, das kann dann mit dem nächsten Firmwareupdate schon wieder nicht mehr der Fall sein. Lieber das ganze selbst in einer Schleife abhandeln... dann geht der Code auch später mal noch in einer 1500er ... ;-)

Mit der Firmware bzw. dem Ausgabe-Stand hast du recht. Ich mein sogar, dass es bei der 315-2DP sogar so ist.

Schleife nehme ich nicht. Ich kopiere Quelle mit Blockmove in einen temporären Speicherbereich (wenn möglich Lokaldaten) und dann mit einem 2. Blockmove in den Zielbereich. Ist meist schneller als eine Schleife.

Gruß
Dieter

Gruß
Dieter

Tigerente1974 · 3 Dezember 2012

Mir gefallen solche vabanque-Spielchen auch nicht. In den Code gehört eine saubere Lösung, wie auch immer die dann aussieht.

rostiger Nagel · 3 Dezember 2012

Ist schon irgendwie Merkwürdig, da bekommen die Siemens Leute nicht einmal
einen Block_Move Bugfrei hin. Was Funkioniert bei denen überhaupt noch?

PN/DP · 3 Dezember 2012

Das erfolgreiche überlappende Kopieren mit SFC20 wurde hier schon öfters diskutiert, z.B.
http://www.sps-forum.de/showthread.php/38394-Array-füllen
http://www.sps-forum.de/showthread.php/44119-SFC20-Schieberegister
Benchmark auf 315-2EH13

Harald

Ralle · 4 Dezember 2012

rostiger Nagel schrieb:
Ist schon irgendwie Merkwürdig, da bekommen die Siemens Leute nicht einmal
einen Block_Move Bugfrei hin. Was Funkioniert bei denen überhaupt noch?[/QUOTE

Warum "nicht bugfrei" ? In der Hilfe steht "nicht überlappende Speicherbereiche". Damit ist doch alles klar. Das es in manchen Fällen trotzdem geht, ok... Wie gesagt, wenn man aufpaßt. in eine Richtung dürfen die Speicherbereiche überlappen, das geht immer.

rostiger Nagel · 4 Dezember 2012

Ralle schrieb:
Warum "nicht bugfrei" ? In der Hilfe steht "nicht überlappende Speicherbereiche". Damit ist doch alles klar. Das es in manchen Fällen trotzdem geht, ok... Wie gesagt, wenn man aufpaßt. in eine Richtung dürfen die Speicherbereiche überlappen, das geht immer.

mit Bugfrei meine ich, das es auf unterschiedlichen Plattformen, zu unterschiedlichen Ergebnissen kommt, das darf nicht sein....meiner Ansicht nach.

BLKMOV (SFC20) - falsche Reihenfolge beim Schieben

EliteGurke

Well-known member

Tigerente1974

Well-known member

EliteGurke

Well-known member

Blockmove

Supermoderator und User des Jahres 2019

Oberchefe

Well-known member

bike

Well-known member

Blockmove

Supermoderator und User des Jahres 2019

bike

Well-known member

Jochen Kühner

Well-known member

Blockmove

Supermoderator und User des Jahres 2019

Tigerente1974

Well-known member

rostiger Nagel

Forums-Knochenbrecher

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

Ralle

Super-Moderator , User des Jahres 2006-2007

rostiger Nagel

Forums-Knochenbrecher

Similar threads