CPU-STOP nach LAR2

[Fenix]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

 

[Fenix]

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

Sorry für die dumme Frage, wsa mach ich mit dem SFC20? Welche Daten verschiebe ich da? Weil die Daten um die es eigentlich geht, die kann ich mit dem Befehl nicht schieben, weil sie leider im neuen DB ganz anders angeordnet sind.

Kann man den FB eigentlich umbauen, damit er kein Multiinstanzfähiger FB ist? Weil aufrufen muss ich den nur einmal pro SPS-Zyklus?

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der SFC20 kann ganze Blöcke von A nach B kopieren. Aber die müssen natürlich zusammenhängend sein. Dazu werden Any-Zeiger benutzt. Such mal hier im Forum SFC20 oder BlockMove oder Block_Move.

 

[Fenix]

Der SFC20 kann ganze Blöcke von A nach B kopieren. Aber die müssen natürlich zusammenhängend sein. Dazu werden Any-Zeiger benutzt. Such mal hier im Forum SFC20 oder BlockMove oder Block_Move.

Also wenn ich das richtig erfasst habe ist der SFC20 dann nicht die Lösung.

 

[vierlagig]

ich bin für die AR2-lösung inkl. offset-einpflegung für die mi-fähigkeit wenn notwendig ... keine angst vor ARzwee, des tut nicht weh

 

[Fenix]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich bin für die AR2-lösung inkl. offset-einpflegung für die mi-fähigkeit wenn notwendig ... keine angst vor ARzwee, des tut nicht weh

und wie sieht die AR2 Lösung denn aus?
Eigentlich hab ich ja die AR2 Lösung, nur leider geht die CPU mit Bereichslängenfehler in STOP.

war das:
"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"
die Lösung

 

[Ralle]

ich bin für die AR2-lösung inkl. offset-einpflegung für die mi-fähigkeit wenn notwendig ... keine angst vor ARzwee, des tut nicht weh

Zeigen

 

[Fenix]

Zeigen

...genau, dafür bin ich auch!

 

[Gebs]

Zuviel Werbung?
-> Hier kostenlos registrieren

So sollte es gehn:

[COLOR=Red]TAR2
T #Rett:AR2[/COLOR]

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]
 
[COLOR=Red]L #Rett_AR2
LAR2[/COLOR]

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

Grüße
Gebs

 

[vierlagig]

danke fürs zeigen Gebs, ich war grad zum mittag :-D

eine anmerkung noch:

*
      TAR2  #dSaveAR2
      ...
      LAR2  #dSaveAR2

 

[Ralle]

danke fürs zeigen Gebs, ich war grad zum mittag :-D

eine anmerkung noch:

*
      TAR2  #dSaveAR2
      ...
      LAR2  #dSaveAR2

Das war aber noch nicht die wirklich komlett multiinstanzfähige Lösung (ok, die gezeigte ist schon multiinstanzfähig) mit Zugriff auf interne Variable. Da drück ich mich echt gerne drumrum, man macht da schnell mal Fehler.