BLKMOV (SFC20) - falsche Reihenfolge beim Schieben

[EliteGurke]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag liebe SPSler,

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

Folgender 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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hmm ok, auch gerade gelesen.

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

 

[Blockmove]

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]

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]

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]

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]

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]

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]

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]

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

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

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.