war falsch...lesen muss man können
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.![]()
war falsch...lesen muss man können
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
@ 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.
Last edited by Fenix; 09.01.2009 at 12:07.
??? Was soll uns das sagen?
Gebs hat es geschrieben.
Wenn du z.Bsp. auf Byte 20 eines DB zugreifen willst, dann
Achtung mit AR2, das kann in FB Probleme geben.Code: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]
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.
Last edited by Ralle; 09.01.2009 at 12:11.
Gruß
Ralle
... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
and the third kinds of people … those who love TIA-Portal
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?
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.
Gruß
Ralle
... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
and the third kinds of people … those who love TIA-Portal
Bookmarks