BLKMOV (SFC20) - falsche Reihenfolge beim Schieben

EliteGurke

Well-known member
Beiträge
78
Punkte Reaktionen
8
Zuviel Werbung?
->Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:

Blockmove

Supermoderator und User des Jahres 2019
Teammitglied
Beiträge
10.386
Punkte Reaktionen
3.028
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

Well-known member
Beiträge
2.665
Punkte Reaktionen
479
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

Well-known member
Beiträge
6.464
Punkte Reaktionen
794
Zuviel Werbung?
->Hier kostenlos registrieren
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

Supermoderator und User des Jahres 2019
Teammitglied
Beiträge
10.386
Punkte Reaktionen
3.028
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

Well-known member
Beiträge
6.464
Punkte Reaktionen
794
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

Well-known member
Beiträge
4.209
Punkte Reaktionen
484
Zuviel Werbung?
->Hier kostenlos registrieren
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

Supermoderator und User des Jahres 2019
Teammitglied
Beiträge
10.386
Punkte Reaktionen
3.028
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
 

Ralle

Supermoderator
Teammitglied
Beiträge
15.103
Punkte Reaktionen
3.820
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

Forums-Knochenbrecher
Teammitglied
Beiträge
15.045
Punkte Reaktionen
4.722
Zuviel Werbung?
->Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
Oben