Step 5 Operation "P" in Step 5

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe darin nie einen Vorteil gesehen, sondern immer nur einen Nachteil.
In Funktionsbausteinen (FB) kann man aus Verknüpfungen herausspringen ohne VKE-Abschluss/-Begrenzung (z.B. SPZ=) (und auch in Verknüpfungen hineinspringen). Damit dabei nicht unbeabsichtigt das VKE verschleppt wird, brauchte man eine explizite Anweisung für den garantierten Beginn einer neuen Verknüpfung unabhängig vom "Erstabfrage"-Konzept ---> direktes Laden ins VKE ohne mit dem vorhandenen VKE zu verknüpfen. Das wird wohl auch der Grund sein, warum die P/PN Operationen nur in FB möglich sind.

Ein paar Jahre später in der IEC 61131 wurde für den Beginn einer Verknüpfung in IL (IEC-AWL) explizit die Anweisung LD festgelegt. Das entlastet den Compiler vom Konzept der Erstabfrage.
Code:
// IEC 61131 Instruction List (IL)
LD operand1
OR operand2
ST result
 
Ich habe darin nie einen Vorteil gesehen, sondern immer nur einen Nachteil.
Für mich war es eine miserable bis unbrauchbare Vorstufe von Verknüpfungen wie U, UN, O, ON.
Gab es denn überhaupt CPUs, die einerseits P als Operator kannten und andererseits auch U, UN, O, ON angewandt auf DatenBits?
Wenn ich nicht wieder falsch liege, mindestens die 945 und 948.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab das so in Erinnerung, dass sich dieses "P" irgendwann in die 115er Steuerungen "eingeschlichen" hat.
Das direkte Abfragen eines Datenbits gab es Anfangs nicht bei 115. Genauso wenig wie viele mathematische Funktionen.
Bei einem Produktupdate der 115er kam dann P und ein paar mehr mathematische Funktion wie Integer-Multiplikation.
Damals gab es große Einschränkungen bei den Funktionsbaugruppen (IP, WF, CP). Viele funktionierten nicht in der 115er.
Also hat Siemens mal die 115er modernisiert und leistungsfähigere CPUs rausgebracht.
Das P blieb aus Kompatibilität.
Auch bei der S5-Reihe hat Siemens schon ziemlich viel gebastelt. Viele CPU mit vielen Ausgabeständen. Da es damals noch kein Internet gab, kamen die Produktmitteilungen schriftlich. Wir hatten 2 dicke Ordner davon im Büro.
 
Ich habe auch nie mit dem P Befehl gearbeitet, aber auch nie mit dem U D x.y Befehl, ich habe aus Perfomance Gründen bei Bitabfragen von DW's immer das DW in ein Schmiermerkerwort kopiert und das entsprechende M-Bit abgefragt.
 
Ich habe auch nie mit dem P Befehl gearbeitet, aber auch nie mit dem U D x.y Befehl, ich habe aus Perfomance Gründen bei Bitabfragen von DW's immer das DW in ein Schmiermerkerwort kopiert und das entsprechende M-Bit abgefragt.
Naja Performance konnte man gerade bei den 100er und 115er nie so pauschal beurteilen. Da gab es extreme Unterschiede zwischen den CPUs und teilweise sogar den Ausgabeständen. Zumindest konnte man bei
Less:
A  DB 5
L  DW 10
T  MW 200
U  M 201.5
=  A 40.0
sicher sein, dass es funktioniert. Bei P oder U Dx.y war das nicht so sicher.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe auch nie mit dem P Befehl gearbeitet, aber auch nie mit dem U D x.y Befehl, ich habe aus Perfomance Gründen bei Bitabfragen von DW's immer das DW in ein Schmiermerkerwort kopiert und das entsprechende M-Bit abgefragt.
Au ja, "SchmierMerker", die haben wir auch sehr, sehr viel benutzt. Unser S5-DokumentationsSystem (anfangs auf Commodore in BASIC programmiert und später auf PG685 in C geschrieben) hatte deswegen extra die Fähigkeit bekommen, automatisch "ZuordnungsTexte" von DatenBits, -Bytes, -Worten und -DoppelWorten in den MerkerBereich zu übernehmen (= temporär zu kopieren). Dazu hat das DokuSystem das S5-Programm "mitgelesen" und entsprechend interpretiert. Der S5-Programmierer musste lediglich darauf achten, dass sich das Öffnen eines DB (oder DX) eindeutig auf die nachfolgende Verwendung der Daten-Bits, -Bytes, -Worte oder -DoppelWorte bezog. Sprünge innerhalb des AWL-Programms konnte die MitleseFunktion also nicht korrekt nachvollziehen, aber das war auch nicht nötig, wenn man sich damit abgefunden hatte, mit dieser Einschränkung zu leben und dies beim Programmieren in AWL zu berücksichtigen.

Zumindest konnte man bei
Code:
A  DB 5
L  DW 10
T  MW 200
U  M 201.5
=  A 40.0
sicher sein, dass es funktioniert. Bei P oder U Dx.y war das nicht so sicher.
Vermutlich war bei verschiedenen CPU-Typen die Wirkungsweise seitens Siemens unterschiedlich umgesetzt? Egal, das interessiert wohl niemanden mehr.
Bei der Eingabe eines AWL-Programmes hat der Editor vieles geprüft und zugelassen bzw. nicht zugelassen, abhängig vom "voreingestellten" "SprachRaum", von denen es aber nicht so sehr viele gab (erinnere mich nur vage an A und B).
 
... Das entlastet den Compiler vom Konzept der Erstabfrage.
Bei S5 gab es diesen Compiler nicht. Es war ein Interpreter, der zur Laufzeit des Programmes die CPU mit der Aufgabe beschäftigt hat.
Die wenigen anderen Nicht-Siemens-PLCs, mit denen ich zu tun hatte, hatten alle nicht die Fähigkeit, die ErstVerküpfungen zu erkennen und automatisch richtig zu behandeln. Da gab es meines Wissens nix und der Programmierer musste entsprechend kodieren, was ich aber für durchaus zumutbar halte.
Bei Siemens hatte man zwar die Möglichkeit der "bedingten ErstVerknüpfung" durch Springen mitten in eine Verkettung von logischen Verknüpfungen ... aber wer hätte das vermisst, wenn es das nicht gegeben hätte? ;)
Den "Vorteil" der SiemensVariante sehe ich allein darin, dass man sich die OP-Codes für das Laden bei ErstVerknüpfungen sparen konnte.
Das waren sowieso nicht so viele? Doch, doch, waren es, weil sie mit den Operanden zu 16-Bit Gruppen kombiniert gewesen wären.
 
Zuletzt bearbeitet:
Die wenigen anderen Nicht-Siemens-PLCs, mit denen ich zu tun hatte, hatten alle nicht die Fähigkeit, die ErstVerküpfungen zu erkennen und automatisch richtig zu behandeln. Da gab es meines Wissens nix und der Programmierer musste entsprechend kodieren, was ich aber für durchaus zumutbar halte.
Die Verfahren ist in Siemens dass die VKE beim Abschluss von den vorigen Netzwerk gesetzt wird.
Wenn die Netzwerk nicht korrekt beendet wird, startet den nächsten Netwerk eventuell mit VKE=0. Und wenn diese Netwerk mit ein U startet, wird die erste Befehl als 0 ausgwertet, egal was mit die U sonnst verknüpft ist.
Als Anfänger hat man sicherlich erlebt dass wenn man ein AWL Netzwerk auskommentieren will, dann genügt es nicht nur den lezten Zeile, die Zuweisung, auszukommentieren. Man muss den ganze Netzwerk auskommentieren.
Meiner Meinung nach sollte dies nicht den Verantworlichkeit von der Programmierer sein.
Noch ein Grund dafür das ich AWL meide.

Viele Jahren her habe ich ein SPS gesehen (TI glaube ich) der eine boolsche Ladebefehl hatte. Genau für den Zweck einen neuen Netzwerk starten zu können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn die Netzwerk nicht korrekt beendet wird, startet den nächsten Netwerk eventuell mit VKE=0. Und wenn diese Netwerk mit ein U startet, wird die erste Befehl als 0 ausgwertet, egal was mit die U sonnst verknüpft ist.
Ein VKE = TRUE macht eine folgende OderVerknüpfung ebenfalls ziemlich konfus.
Bedingte Negationen (XOR) gab es ja zu S5-Zeiten noch nicht, höchstens selbstgestrickt.
Meiner Meinung nach sollte dies nicht den Verantworlichkeit von der Programmierer sein.
Na ja, ein Bisschen Mitdenken sollte man den faulen bis bösen Programmierern schon zutrauen (oder zumuten?) dürfen.
Noch ein Grund dafür das ich AWL meide.
Ein Grund dafür, dass Du heute (immer noch) AWL meidest oder dafür, dass Du schon in S5 AWL gemieden hast?
Viele Jahren her habe ich ein SPS gesehen (TI glaube ich) der eine boolsche Ladebefehl hatte. Genau für den Zweck einen neuen Netzwerk starten zu können.
Boolesche LadeBefehle waren in Nicht-Siemens-Sprachen keine Seltenheit, sondern "normal" und (Achtung! Meine Unterstellung: ) fast alternativlos.
Gab es sogar bei Siemens in der Form von P bzw. PN. Was sich der Herr Siemens allerdings bei der Einführung dieser OP-Codes gedacht hat ... ich weiss es wirklich nicht. Vielleicht waren die kleinen grauen Zellen vorübergehend abgeschaltet oder der Wunsch eines Kunden war ausnahmsweise mal wichtiger oder GewissensBisse waren mal vorübergehend zu stark geworden?
 
Gab es sogar bei Siemens in der Form von P bzw. PN. Was sich der Herr Siemens allerdings bei der Einführung dieser OP-Codes gedacht hat ... ich weiss es wirklich nicht.

In Funktionsbausteinen (FB) kann man aus Verknüpfungen herausspringen ohne VKE-Abschluss/-Begrenzung (z.B. SPZ=) (...) Damit dabei nicht unbeabsichtigt das VKE verschleppt wird, brauchte man eine explizite Anweisung für den garantierten Beginn einer neuen Verknüpfung unabhängig vom "Erstabfrage"-Konzept ---> direktes Laden ins VKE ohne mit dem vorhandenen VKE zu verknüpfen. Das wird wohl auch der Grund sein, warum die P/PN Operationen nur in FB möglich sind.
 
In Funktionsbausteinen (FB) kann man aus Verknüpfungen herausspringen ohne VKE-Abschluss/-Begrenzung (z.B. SPZ=) (...) Damit dabei nicht unbeabsichtigt das VKE verschleppt wird, brauchte man eine explizite Anweisung für den garantierten Beginn einer neuen Verknüpfung unabhängig vom "Erstabfrage"-Konzept ---> direktes Laden ins VKE ohne mit dem vorhandenen VKE zu verknüpfen. Das wird wohl auch der Grund sein, warum die P/PN Operationen nur in FB möglich sind.
Tja, in FunktionsBausteinen (FB und FX) war so einiges zulässig, was man in OB oder PB (ProgrammBaustein) oder SB (SchrittBaustein) nicht programmieren konnte/durfte.
Warum war es nicht zulässig? Keine Ahnung. Das war vermutlich eine Art und Weise, mit einfachen Mitteln gewisse Strukturierungen vornehmen zu können. Wahrscheinlich mehr im Hinblick auf KOP und FUP, wo man wohl aus guten Gründen auf Möglichkeiten verzichtet hat, die nur in AWL sinnvoll und darstellbar erschienen.
Ja, bei bedingten Sprüngen musste man schon genau hinsehen, welche Eigenschaften sie hatten und welche nicht.
Zum Glück tat es fast immer der SPB und der hat dafür gesorgt, dass nach seiner Abarbeitung - egal, ob gesprungen wurde oder nicht - eine Erstverknüpfung ausgeführt wurde und das VKE = TRUE war. Diverse andere (z.B. der SPZ) eigneten sich hingegen sehr gut, um z.B. ein VKE zu "verschleppen", egal, ob beabsichtigt oder unbeabsichtigt.
Es war manchmal angenehm bis nützlich, mit einer im Akku gerade nicht vorhandenen 0 vergleichen zu können. Nötig war es jedoch nicht.
Eigentlich konnte man mit einer kleinen Auswahl an Befehlen so programmieren, dass alles möglich war, was man so benötigte. Das war den Inbetriebnehmern viel wichtiger, als etwas "trickreiches" programmieren zu können, was sowieso nicht jeder sofort verstanden hätte.
 
Zurück
Oben