TIA Code von AWL in SCL umsetzen

dweber283

Level-2
Beiträge
27
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich habe den unten folgenden Code in AWL und hätte diesen jetzt gerne in SCL um von AWL weg zu kommen. Ist dies möglich?

L #E_Adresse // Lade Adresse (z.B 400) SLD 3 // Bitbereich ausblenden LAR1 L #byte0 T AB [ AR1 , P#0.0 ] L #byte1 T AB [ AR1 , P#1.0 ] L #byte2 T AB [ AR1 , P#2.0 ]

Danke Euch
 
Für welche SPS und welche Step7- oder TIA-Version soll das sein?
Weil je nachdem muß die indirekte Adressierung von Ausgängen anders formuliert werden.

PS: der Kommentar zu "SLD 3" ist falsch. Da wird kein Bitbereich ausgeblendet, sondern eine Nummer auf eine Byte-Adresse umgerechnet, indem mit 8 multipliziert wird.

Harald
 
hätte diesen jetzt gerne in SCL um von AWL weg zu kommen.
Wenn Du von AWL wegkommen willst, dann solltest Du nicht stupid den AWL-Code möglichst 1:1 in SCL übersetzen, sondern den Programmierstil ändern.

Für S7-1500 sollte man nicht mehr Speicheradressen ausrechnen, sondern das Speicherziel symbolisch angeben. Für symbolische indirekte Adressierung muß das Speicherziel indiziert ansprechbar sein, also als Array deklariert sein, gerne auch als Array of Struct oder Array of Benutzerdatentyp.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
POKE ist nicht gerade elegant.
In TIA kannst du E/As auch Datentypen zuordnen.
Also z.B. ein ARRAY[0..2] of BYTE.

Wenn du dann dein #byte0, #byte1, #byte2 in den gleichen Datentyp packst, dann funktioniert es vollsymbolisch ohne POKE und dergleichen.

Hab gerade kein TIA hier um dir ein Codebeispiel zu geben
 
PS: der Kommentar zu "SLD 3" ist falsch. Da wird kein Bitbereich ausgeblendet, sondern eine Nummer auf eine Byte-Adresse umgerechnet, indem mit 8 multipliziert wird.
:unsure: ... sondern eine ByteAdresse in eine BitAdresse umgerechnet ...

Da wird kein BitBereich ausgeblendet, sondern im Gegenteil, für den in der ByteAdresse noch nicht vorhandenen BitBereich wird durch die Multiplikation mit 8 der nötige Platz (Bit0..Bit2) geschaffen/bereitgestellt.
 
Ich denke die Haarspalterei kann man sich sparen.
Natürlich blendet SLD Bits aus.
Für uns Dinosaurier ist mit einem Blick klar, was der AWL-Code hier macht.
Aber welcher Einsteiger kommt heute mit den 300/400er Zeigern klar?

Zumindest was die Adressierung angeht hat Siemens viel bei der 1200/1500er richtig gemacht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Natürlich blendet SLD Bits aus.
Ja, "am anderen Ende" fallen die drei höchstwertigen Bits der ByteAdresse heraus, was bei 32 Bit aber eher "nice to know" sein dürfte.
Gerade für die Nicht-S7-Dinosaurier, finde ich, sollte die Erklärung so sein, dass keine falschen Vorstellungen entstehen - wenn auch die S7-Dinosaurier das als Haarspalterei empfinden mögen.

Das Arbeiten mit BitAdressen bei der S7-Pointerei ist zugegebenermassen mehr als gewöhnungsbedürftig. Aber es zeugt davon, dass demjenigen, der es erfunden hat, die Bedürfnisse der SPS-Programmierung wichtiger waren, als die "Vereinfachungen", die uns von den Hochsprachen-Künstlern angedient werden.
Das Chaos, das dadurch entstanden ist, dass immer wieder andere/neue LösungsMöglichkeiten (Sprach-, "Dialekt"-, ... CPU-abhängig) für das Adressieren der Bits in Bytes, Worten, u.s.w. nachgereicht (oder noch schlimmer: nicht angeboten) werden, lässt sich wohl kaum wegdiskutieren (siehe den enormen Anteil der entsprechenden Fragen hier im Forum).
Ich sage nicht, dass die BitAdressen der S7-Pointerei auch nur annähernd eine gute oder schöne Lösung sind. Ich sage lediglich, hier hat sich jemand frühfzeitig ("vorausschauend") überhaupt Gedanken über ein Problem gemacht, das die anderen (praxisfremd) einfach ignoriert bzw. gar nicht vorausgesehen haben. Die Portierbarkeit und Konvertierbarkeit von SPS-Programmen leidet/scheitert immer wieder an diesen ärgerlichen "feinen" Unterschieden.
 
Zurück
Oben