Step 7 indirekte Adressierung / Pointer

[S.Schleich]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi zusammen.

Ich befasse mich zum ersten mal in AWL mit Pointern. Das Prinzip ist mir klar, ich habe nur in einem Programm eine Besonderheit gesehen, wozu ich im Internet nichts finde und hoffe, dass mir jemand helfen kann.

Was bedeutet denn (siehe Bild) die zweite Raute (#) ???

Vielen Dank schon mal.

Beste Grüße
Silas

 

[PN/DP]

Was bedeutet denn (siehe Bild) die zweite Raute (#) ???

lokale Variablen bekommen immer ein Doppelkreuz # vorne dran
P##Taster bedeutet: P# #Taster : die Adresse der lokalen Variable Taster (Lokal: Static oder TEMP)

 

[S.Schleich]

Zuviel Werbung?
-> Hier kostenlos registrieren

lokale Variablen bekommen immer eine Raute vorne dran
P##Taster bedeutet: P# #Taster : die Adresse der lokalen Variable Taster (Lokal: Static oder TEMP)

Okay, also blöd gesagt, er soll nicht auf den möglichen Inhalt der Variable schauen, sondern auf die Adresse, in dem die Variable steht?
Habe ich das richtig verstanden ?

 

[PN/DP]

L #Taster lädt den Wert, der in der Variable #Taster drin steht.
L P##Taster lädt nicht den Wert, der in der Variable #Taster drin steht, sondern die Adresse der Variable #Taster.
Beispiel mit deiner Adresse nötig? Wie ist deine Variable deklariert?

 

[S.Schleich]

L P##Taster lädt nicht den Wert, der in der Variable #Taster drin steht, sondern die Adresse der Variable.
Beispiel mit deiner Adresse? Wie ist deine Variable deklariert?

genau, so hatte ich das vermutet. Er soll hier auf die Adresse (56.0) gucken und den Wert dann in 58.0 transferieren?

Mit einer Raute würde er das "Word" in der Variable auswerten?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe ich das richtig verstanden ?

Dein Code macht:

//Adresse der Word-Variable #Taster in AR1 laden
L P##Taster
LAR1

//Wert aus der Word-Variable #Taster (STAT des IDB) ins darauf folgende Word kopieren
L DIW [AR1,P#0.0]
T DIW [AR1,P#2.0]

Achtung! Der Code ist nicht für Multiinstanzen geeignet!

Bei dir: P##Taster_0_15 ist die Adresse P#DIX56.0
Der Code kopiert das Word aus DIW56 nach DIW58

PS: das Zeichen # ist keine Raute, sondern ein Doppelkreuz

 

[S.Schleich]

Dein Code macht:

//Adresse der Word-Variable #Taster in AR1 laden
L P##Taster
LAR1

//Wert aus der Word-Variable #Taster (STAT des IDB) ins darauf folgende Word kopieren
L DIW [AR1,P#0.0]
T DIW [AR1,P#2.0]

Achtung! Der Code ist nicht für Multiinstanzen geeignet!

alles klar, vielen Dank, habe ich verstanden.

Was genau ist denn nicht für Multiinstanzen geeignet? Also wird hier in dem Projekt nirgends verwendet (Multiinstanzen), aber würde mich trotzdem interessieren.

 

[PN/DP]

Der Code funktioniert nur mit FB-Instanz als ganzer DB, aber nicht als FB-Instanz eingebettet in einem Mutter-IDB.
Für Verwendung auch mit Multiinstanzen muss noch der Multiinstanz-Offset aus AR2 addiert werden.
Zu Multiinstanzen siehe auch die Hilfefunktion deines Step7
Ich wette, der FB ist bei dir aber als "multiinstanzfähig" gekennzeichenet... war dann wohl ein schlampiger oder unwissender Programmierer...

 

[S.Schleich]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Code funktioniert nur mit FB-Instanz als ganzer DB, aber nicht als FB-Instanz eingebettet in einem Mutter-IDB.
Für Verwendung auch mit Multiinstanzen muss noch der Multiinstanz-Offset aus AR2 addiert werden.
Zu Multiinstanzen siehe auch die Hilfefunktion deines Step7
Ich wette, der FB ist bei dir aber als "multiinstanzfähig" gekennzeichenet... war dann wohl ein schlampiger oder unwissender Programmierer...

Ja

 

[Onkel Dagobert]

... Ich wette, der FB ist bei dir aber als "multiinstanzfähig" gekennzeichenet... war dann wohl ein schlampiger oder unwissender Programmierer...

Naja, soweit der Code es uns erkennen lässt , wird ja auch nur das Adressregister 1 verwendet, was soweit erst einmal multiinstanzfähig wäre. Aber wie so "schlampig"? Wird denn das Prädikat "multiinstanzfähig" nicht automatisch vergeben? Ich kann mich nicht erinnern, es jemals händisch gesetzt zu haben.

 

[ducati]

Was ich in so nem Fall gern mache, die 16Bits in ne Struktur packen und dann mit Blockmove das Word in die Struktur kopieren... dann bleibts einigermaßen symbolisch... und man braucht die Pointerei nicht...

 

[S.Schleich]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was ich in so nem Fall gern mache, die 16Bits in ne Struktur packen und dann mit Blockmove das Word in die Struktur kopieren... dann bleibts einigermaßen symbolisch... und man braucht die Pointerei nicht...

ja, an besseren bzw. einfacheren Lösungen mangelt es uns auch nicht. Leider sind die Anlagen sehr alt...

 

[PN/DP]

Naja, soweit der Code es uns erkennen lässt , wird ja auch nur das Adressregister 1 verwendet, was soweit erst einmal multiinstanzfähig wäre.

Nein, das ist ganz und gar nicht multiinstanzfähig! P##Taster ist der Offset der Instanz-Variable innerhalb der Instanz, was bei einer Instanz mit eigenem Instanz-DB gleichzeitig die Adresse im IDB ist. Bei Multiinstanzen muß die Instanz aber nicht am Anfang des Mutter-IDB liegen, deshalb wird beim Aufruf von als "multiinstanzfähig" markierten FB-Instanzen der Offset ("Anker", Anfangsadresse) der Instanz innerhalb des IDB im AR2 mitgegeben und muß dann noch zum Offset innerhalb der Instanz addiert werden, um auf die wirkliche Adresse der Variablen im Mutter-IDB zu kommen.

Wird denn das Prädikat "multiinstanzfähig" nicht automatisch vergeben? Ich kann mich nicht erinnern, es jemals händisch gesetzt zu haben.

Beim neu anlegen eines FB kann man die Option beeinflussen, später dann aber nicht mehr ändern. Doch wie so of im Leben wird einfach nur zugestimmt, ohne die Frage und die Konsequenzen zu verstehen...

Was ich in so nem Fall gern mache, die 16Bits in ne Struktur packen und dann mit Blockmove das Word in die Struktur kopieren... dann bleibts einigermaßen symbolisch... und man braucht die Pointerei nicht...

Ja, wenn man BLKMOV verwendet und die Quell- und Zielvariablen symbolisch angibt, dann wird vom AWL-Compiler der Multiinstanzoffset aus AR2 automatisch berücksichtigt und addiert. Doch leider haben viel zu viele Programmierer nicht wirklich Ahnung von dem, was sie da mit ihrer vermeintlich einfacheren AWL-Pointerei tun.

 

[ducati]

ja, an besseren bzw. einfacheren Lösungen mangelt es uns auch nicht. Leider sind die Anlagen sehr alt...

in unseren älteren Anlagen wird da immer auf die Absolutadressen geschrieben von daher find ich die Pointervariante schon bissl besser Vor allem, wenns Temp.Variablen sind

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei TEMP-Variablen gibt es keine Multiinstanzen. Die angebliche Absolutadresse ist immer nur der Offset der eigenen Instanz innerhalb des TEMP-Speicherbereichs.

 

[ducati]

Bei TEMP-Variablen gibt es ja auch keine Multiinstanzen. Die angebliche Absolutadresse ist immer nur der Offset der eigenen Instanz innerhalb des TEMP-Speicherbereichs.

ja.
Bei Stat-Variablen bzw. allgemein (I)DBs würde nie jemand auf die Idee kommen, mitendrinn Variablen einzufügen, weil da öfter absolut adressiert wird. Bei Temp.-Variablen find ich absolute Adressierung aber einfach Scheisse. Ich fall da alle par Jahre mal ordentlich auf die Nase, weil ich mal wieder nicht dran gedacht hab. Vorallem wenn man ne Temp.Variable löscht, weil man was rückbaut

Grundsätzlich versuche ich Pointerei zu vermeiden. In 1500er-AWL brauchst Du das ja eigentlich garnicht mehr, da Array dort variabel adressiert werden können...

 

[PN/DP]

Man braucht eigentlich nur konsequent symbolisch adressieren und das Berechnen der Adressen dem Compiler überlassen. Bei AWL-Pointern auf FB-Multiinstanzen gibt es historisch keinen symbolischen THIS-Pointer, mit dem man die Anfangsadresse der eigenen Instanz symbolisch angeben kann. Da muss man wissen, dass das AR2 die Funktion des THIS-Pointers hat.

 

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da Taster_0_15, eine statische Variabel ist und keine IN,
würde ich sogar noch auf die maximale Katastrophe wetten, dass das dann auch noch direkt adressiert irgendwo in den Instanz DB geschrieben wird. Wahrscheinlich noch so, dass man es mit Querverweisen kaum findet. Evtl. greift dann die Visu auch noch direkt auf den Instanz DB zu, so dass bei einer kleinen nötigen Änderung das ganze Kartenhaus zusammenbricht!

Mein Mitgefühl hast du, muss mich auch ständig mit sowas rumschlagen und das ausbaden!

 

[ducati]

Man braucht eigentlich nur konsequent symbolisch adressieren und das Berechnen der Adressen dem Compiler überlassen.

Problem sind immer "Umrangierungen" Wort->16Bits oder aus nem Wort nen Bit rausfummeln... Oder aus nem Date_And_Time die einzelnen Werte rauszufummeln...

Da Taster_0_15, eine statische Variabel ist und keine IN,
würde ich sogar noch auf die maximale Katastrophe wetten, dass das dann auch noch direkt adressiert irgendwo in den Instanz DB geschrieben wird. Wahrscheinlich noch so, dass man es mit Querverweisen kaum findet. Evtl. greift dann die Visu auch noch direkt auf den Instanz DB zu, so dass bei einer kleinen nötigen Änderung das ganze Kartenhaus zusammenbricht!

Mein Mitgefühl hast du, muss mich auch ständig mit sowas rumschlagen und das ausbaden!

wenn man halt öffters an fremden/alten Anlagen arbeiten muss, bleibt einem sowieso nichts erspart. Grundsätzlich würde ich an fremden/alten DBs nur ungern was ändern. Ich nehm da lieber nen neuen DB, wenn möglich. Im Notfall Variablen nur am Ende anfügen!

 

[DCDCDC]

wenn man halt öffters an fremden/alten Anlagen arbeiten muss, bleibt einem sowieso nichts erspart. Grundsätzlich würde ich an fremden/alten DBs nur ungern was ändern. Ich nehm da lieber nen neuen DB, wenn möglich. Im Notfall nur am Ende anfügen!

This. Wenn's läuft, dann sollte man es laufen lassen, anstatt alte Anlagen in den Tod zu optimieren bei bestehenden Funktionen.