CPU-STOP nach LAR2

[Fenix]

Hallo Leute!

Es ist Freitag und ich stehe im Moment ein wenig auf dem Schlauch.
Ich möchte in der 315 CPU Daten von einem DB in einen 2. übertragen.
Es sind 10 Speicherstellen und ich habe mir gedacht ich mache das mit inderekter Programmierung.
Also ein Zähler zählt von 9 bis 0 und bei jedem Schritt wird ein Block übertragen. Das Problem ist da die Speicherbereiche nicht im selben Abstand in den DBs liegen brauche ich 2 Adressregister.

So sieht das dann aus:

L #Zaehler_Fe
L 128 // 8 x 16 Byte für Offset
*I
LAR1

L #Zaehler_Fe
L 32 // 8 x 4 Byte für Offset
*I
LAR2

// Fehlernummer aus DB252 in DB421
AUF "DB-Anzeige"
L DBW [AR1,P#0.0]

AUF "DB Daten SWE"
T DBW [AR2,P#38.0]
// Stunden und Minuten aus DB252 in DB421
AUF "DB-Anzeige"
L DBW [AR1,P#11.0]

AUF "DB Daten SWE"
T DBW [AR2,P#40.0]

L #Zaehler_Fe
L 0
<=I
SPBN NW11
L 10
T #Zaehler_Fe
NW11: NOP 0
L #Zaehler_Fe

L 1
-I
T #Zaehler_Fe



Nur sobald ich den Befehl "LAR2" benutze geht die CPU mit Bereichslängenfehler in STOP. Wenn ich Testweise 2mal den Befehl "LAR1" ausführe läuft Sie durch, nur ich komme nicht zu meinem Ergebnis. Vielleicht hat ja jemand eine Idee.

[Golden Egg]

war falsch...lesen muss man können

[Gebs]

Hallo Fenix,

Du musst zum einen die Adresse vor dem LAR noch ins Pointerformat bringen
=> SLD 3

Wenn Du einen FB benutzt, muss Du vor der Schleife Deine Adressregister retten
und danach wieder herstellen, sonst funktioniert die Adressierung im IDB nicht mehr.

Grüße
Gebs

[Fenix]

@ Golden Egg
LAR2 lädt das Adreßregister AR2 mit dem Inhalt von AKKU 1 (32 Bit-Pointer).
AKKU 1 und AKKU 2 werden nicht verändert. Die Operation wird ausgeführt, ohne die Statusbits zu berücksichtigen oder zu beeinflussen.

Hallo Gebs,
also ich schiebe mein Rechenergebnis (Offset für die Speicherstelle) 3 Stellen nach links?
Aber dann hab ich doch ein anderes Ergebnis.
Ich hab ja schon mit 8 multipliziert (ich rechne bereits in Bit). Dann fällt das SLD ja eigentlich flach?

Ich benutzte einen FB, aber da ich jeden Durchlauf den Offset (Wert für das Adressregister) neu berechne muss ich ja nichts retten.
Nur der Zähler ist eine statische Variable.

[Ralle]

LAR2 lädt das Adreßregister AR2 mit dem Inhalt von AKKU 1 (32 Bit-Pointer).
AKKU 1 und AKKU 2 werden nicht verändert. Die Operation wird ausgeführt, ohne die Statusbits zu berücksichtigen oder zu beeinflussen.

??? Was soll uns das sagen?

Gebs hat es geschrieben.
Wenn du z.Bsp. auf Byte 20 eines DB zugreifen willst, dann

Auf DB xy

L 20     //LAde 20 in Akku 1
SLD 3   //überführen ins Pointerformat, indem Akku 1 3 mal nach links geschoben wird
LAR1    //Akku 1 in Adressregister laden

L DBB[AR1, P#0.0]

Achtung mit AR2, das kann in FB Probleme geben.
Zumindest solltest du vorher die AR retten und diese am Ende wieder restaurieren.
Siehe dazu LAR1, TAR1, LAR2, TAR2

PS: Schau mal in die Diagnose der SPS, da steht dann auch was zur Stopursache, aber es ist wohl sich er etwas in der Art Bereichsüberschreitung ect.

[Sarek]

Ist das Ganze ein FB und #Zaehler_Fe eine STAT, IN oder INOUT Variable ?

Falls ja hast du ein Problem mit dem AR2 weil falls der FB als
Multiinstanz-fähig deklariert ist, das AR2 als OFFSET für die Instanzdaten
benutzt wird.

d.h. beim Befehl

L #Zaehler_Fe ==>> hier
L 0
<=I

hat die CPU Bereichslängenfehler, da das L sich auf
AR2 + Offset von #Zaehler_Fe im Inst.-DB bezieht und diese
Adresse nicht existiert.

Kannst du das ganze nicht mit nem SFC20-Aufruf lösen??

[Fenix]

Ist das Ganze ein FB und #Zaehler_Fe eine STAT, IN oder INOUT Variable ?

Falls ja hast du ein Problem mit dem AR2 weil falls der FB als
Multiinstanz-fähig deklariert ist, das AR2 als OFFSET für die Instanzdaten
benutzt wird.

d.h. beim Befehl

L #Zaehler_Fe ==>> hier
L 0
<=I

hat die CPU Bereichslängenfehler, da das L sich auf
AR2 + Offset von #Zaehler_Fe im Inst.-DB bezieht und diese
Adresse nicht existiert.

Kannst du das ganze nicht mit nem SFC20-Aufruf lösen??

Ja, mein FB ist multiinstanzfähig, warum auch immer.
Also mit dem SFC20 lösen??? Den kenne ich noch garnicht.
Aber Da scheint der Hase begraben sein. Bekomme ich den FB irgendwie so hin dass er nicht mehr multiinstanzfähig ist? Weil ich muss den nur einmal pro Zyklus aufrufen?

[Ralle]

Siehe Sarek.

Ohne AR2 geht es auch, indem du immer das AR1 vor dem Benutzen umlädst. Etwas mehr Rechenzeit, aber das AR2 bleibt dann unberührt.

[Fenix]

Siehe Sarek.

Ohne AR2 geht es auch, indem du immer das AR1 vor dem Benutzen umlädst. Etwas mehr Rechenzeit, aber das AR2 bleibt dann unberührt.

Das hab ich mir auch schon überlegt, aber dann muss ich die Werte ja nochmal zwischenspeichern. Obwohl, das könnte ich ja in einer temp Variablen machen.

[Gebs]

Ohne AR2 geht es auch, indem du immer das AR1 vor dem Benutzen umlädst. Etwas mehr Rechenzeit, aber das AR2 bleibt dann unberührt.

Oder, er stellt das AR2 vor dem 3. L #Zaehler_Fe wieder her.
Ist aber eher 2. Wahl. Ich würde auch eher den SFC20 nehmen.

Grüße
Gebs