Step 7 AWL Bits in einen Byte schreiben

Zuviel Werbung?
-> Hier kostenlos registrieren
?
Alles was du in die Akkus beförderst ist dort WORD/DWORD. AWL interessiert sich sowieso nicht für Datentypen.

Bei L und T nicht, aber bei Funktionsparametern ist es pedantisch.

Code:
L "DB_Mess_Err".XXX; T LW 8 ;U L 9.7; = Stoerbit[21];
Code:
L "DB_Mess_Err".XXX; T "XWORD" ;U "XBit7"; = Stoerbit[21];
Genau was PN/DP meinte. Wenn du die erste Variante in verschiedenen Tasks laufen lässt hast du Brösel.

Die Lokaldaten sowie die temporären Variablen sind auf dem Stack, und der wird mit dem Task gewechselt. Da besteht keine Gefahr.

Die zweite Variante ist halt auch die denkbar schlechteste Variante die man in AWL machen kann.
Die Verwendung von absoluten L-Adressen ist genauso wenig schlau wie absolute M-Adressen.

In der zweiten Variante sind es eben keine absoluten Adressen, sondern symbolische.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
RONIN hat den Code vertauscht gepostet. Mit "erste Variante" meinte er die Merker-Variante, mit "zweite Variante" meinte er die Variante mit den Lokaldaten/TEMP.

Mit temporären Variablen geht der Zugriff auf die nicht deklarierten Typen wieder nur umständlich über Pointer.
Und was ist da jetzt ein Problem? In C oder Pascal beschwert sich auch niemand über die Verwendung von Adress-Operatoren um sich auf die Adresse von Variablen zu beziehen und die Variable ggf. als anderer Datentyp anzusprechen, in Codesys ST sind Adress-Operatoren sogar direkt möglich. In S7-AWL geht der Adress-Operator halt über P##variable und AR1.

Harald
 
@LargoD
Ich verstehe ihn so, daß er nicht Kollisionen mit Lokaldaten anderer Bausteine meint, sondern wenn er seine Lösung mit LW8 und L9.7 in anderen Bausteinen nutzen will und das LW8 ist da schon verwendet, dann kollidiert seine Lösung, da muss er sich anstrengen und eine andere freie L-Adresse suchen (z.B. LW22 und L23.7).

Harald
 
Zurück
Oben