TIA Portal - DB Zugriff -> nicht eindeutige Adresse

Zuviel Werbung?
-> Hier kostenlos registrieren
Habe gerade beim Stöbern die SFC "Reset" gefunden...

Nennt sich "Bereich bitweise zurücksetzen"

Das passt hierfür genau! Man gibt das erste Bit im gewünschten Bereich an und die Anzahl die zurückgesetzt werden soll, Fertig.

Code:
CALL  RESET
         S_BIT :="DB_XYZ".Erstes_Bit
         N     :=32

Moin,

ich benötig auch diese Funktion, dass ist aber nur für S7300/400 oder?

Ich hab hier eine 1214, dort gibt es zwar auch ein Baustein "RESET_BF: Bitfeld rücksetzen"
Nachteil: Bei einem DB oder einem IDB ein Element eines array[..] of BOOL.

Was soll denn der Mist. Wieso muss das in einem DB denn ein Array sein?
An den einzelnen Array-Elementen kann man im DB ja nicht mal ein Kommentar ran schreiben. :sm6::sm16::sb5:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tja, was soll man dazu sagen?Die "neuen" Befehle die nun mit der 300/400 eingeführt wurden muss man anscheinend auch "per Zufall" finden - oder habe ich da ein "Was ist neu - Dokument" zu wenig durchgelesen?
 
...und wie müsste man es machen, wenn ich 10 von den besagten Strukturen á 16Bits hätte,
und prüfen wollte, ob einer dieser Bits=true ist?
Einer eine Idee, wie man das bei einer 1214'er am einfachsten realisieren könnte?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Auf der 1500 gibt es in SCL seit neuestem einen Befehl namens Runtime. Damit kann man messen wie lange die Ausführung eines Stückchen Codes dauert. Das muss zwei mal aufgerufen werden, einmal zum Start dann wieder zum Stop und dann bekommt man Sekunden zurück als REAL also mit Nachkommastellen. Die Auflösung dieser Messung liegt bei der 1500 scheinbar -- nee ich müsste offensichtlich -- im µs-Bereich. Das gefällt mir. Viel besser als das was ich früher immer probiert habe. (Mach was 1000 mal und schau die Zykluszeit an -- viel zu viel unbekannte Schwankungen.)
Mit dem bin ich mal an die verschiedenen Möglichkeiten alte AWL Unsitten und sonstige Tipps und Tricks aus dem Berger Büchern nachzumessen. Dabei komme ich aus dem staunen nicht mehr raus.
Also klar ist, dass Runtime irgendwie Echtzeitmessungen macht. Wer also außer dem OB1 noch andere Zyklische OB hat, der bekommt heftige Ausreißer. Zum Messen immer nur einen OB verwenden :)

Auf der Messe wird gesagt, die 1516 sei so schnell wie eine 317. Das stimmt tendenziell aber das stimmt bei verschiedenen Gelegenheiten überhaupt nicht. Ausgehend von den Zykluszeitmessungen habe ich folgende grobe Erkenntnisse für die 1516 gewonnen.

Lese-Zugriffe in optimierte DB sind in etwa Faktor 3 schneller als in nicht optimierte DB.
Schreib-Zugriffe auf einzelne Bool sind in optimierte DB sind in etwa Faktor 6 schneller als in nicht optimierte DB.
Schreib-Zugriffe auf anderes als Bool sind in optimierte DB sind in etwa Faktor 2-4 schneller als in nicht optimierte DB.
Zugriffe auf Eingänge Ausgänge und Merker sind genauso langsam wie nicht optimierte DB.

AWL ist oft langsamer als SCL/KOP/FUP. Wenn man Glück hat, dann ist AWL genauso schnell wie SCL/KOP/FUP. Also Beispiel: Ein KOP-Netz mit einer Multiplikation, wobei zwei Werte aus zwei DB und das Ergebnis in einen dritten DB geschrieben wird sind in allen Sprachen gleich schnell. (Da Runtime nicht im KOP geht -- Hey Siemens warum denn das nun wieder? -- wickelt man das Messobjekt in einen Aufruf ein, und rechnet die ungefähr 4µs für den Bausteinaufruf ab)

Typische AWL Zugriffe wie die oben beschriebenen, also das Wort mal als Wort und dann wieder als 16 einzelne Bits zu verwenden kann man nur im nicht optimierten Speicher machen. Wenn man also auf die 16 Bits einzeln zugreift, dann dauert das 16*3 = 48 so lange wie der Wortzugriff. Aber hallo!
Legt man ein 16 Bool Array nun im optimierten Speicher an, dann dauert die SCL-Schleife über die 16 Bools auch 16 mal so lange wie ein Zugriff auf ein Wort. Deutlich besser als 48.

So kleine SCL-Schleifen sind verglichen mit der 317 rasend schnell. Ich habe keine Ahnung was da auf der 317 für ein AWL dahintersteckt, aber die 1516 brauchte nur ein zehntel der Zeit. (Ich konnte zehn mal soviele Durchläufe machen um auf die gleiche Zykluszeit zu kommen. Vergleichende Messung zwischen 317 und 1516 sind saumäßig schwer.

Was die 1516 am allerwenigsten mag sind Adressregister. Ich bin noch nicht dahintergestiegen; wann und wie und was. Aber ein migriertes AWL Programm hat zwar funktioniert -- ich geb ja zu, dass ich drei Anläufe gebraucht habe um es zu migrieren -- aber dann hat es funktionert. Die Zykluszeit des Programm war jedoch auf der 1516 deutlich schlechter als bei der 317 :-( Nach einigem suchen (Danke für Runtime) habe ich ein paar AWL Bausteine identifiziert. Dann hab ich mir genau angesehen, was diese AWL Teile eigentlich versuchen. Viel Adressregisterakrobatik, Anypointer zusammensetzen und auseinandernehmen, misteriöse SFC Aufrufe. Ein Baustein fiel besonders aus dem Rahmen, voller AR Verwendung. Die Ganze unsägliche Adressregisterorgie diente dazu einen Arrayzugriff auf das Element i zu bekommen, i wurde errechnet aus verschiedenen Inputs. Mal so, mal so. Also habe ich aus den 70 AWL Zeilen 10 SCL Zeilen gemacht, so mit IF-THEN-ELSE und #feld[ #index ]. Und plötzlich war die Zykluszeit verschwunden ... also für diesen Baustein in abgemagerter Testumgebung kleiner als 1ms. Auf der 317 dauerte es immernoch 58ms die gleiche Anzahl von Calls zu machen. Also zwischen der AWL Version und der SCL Version liegt in diesem Falle der Faktor 70 :ROFLMAO:

Zurück zum Problem: Wie setzt man 16 Bools in einem Array auf FALSE? Man schreibe eine Schleife in SCL. :D
Wie setzt man 16 Bools in einer Struktur auf FALSE. Man schreibe "dbname".strukturname.namedeserstenbools := FALSE; "dbname".strukturname.namedeszweitenbools := FALSE; ...
Kann man in der Sprache seiner Wahl machen, hier gibt es keinen Unterschied zwischen KOP/FUP/SCL/AWL!
Ja, das ist verdammt viel tippen. Aber es wird auf der 1516 im optimierten DB schneller ausgeführt als das AT auf der 317.

Das bringt mich zu der Frage. Wer kann das erklären?
Ich bilde mir ein irgendwo (vielleicht sogar hier) gelesen zu haben, dass die 317 (oder war das die 319) und die 1516 sogar die gleiche Hardwarebasis -- sprich Prozessor -- haben. Weiß einer, was in der 1516 für ein Prozessor drin ist?
 
Zuletzt bearbeitet:
@HelleBarde
Hast du keine 1500 die du mal aufschrauben kannst? Oder womit testest du?
Ich könnte mir eher vorstellen dass die Steuerung mehr Ähnlichkeit mit der 1200 hat. Beim Portal V11 habe ich mal etwas in den Programmdateien rumgeforscht, da ist zumindest ein Teil der Codegenerierung des SCL Compilers für die 1200 und 1500 identisch, vielleicht aber auch nur eine Zwischencodeerzeugung. Wobei in V11 die 1500 nur vorbereitet ist, vielleicht hat sich da ja noch das ein oder andere geändert.

Innenleben der 1200 habe ich schonmal dokumentiert:
http://www.sps-forum.de/simatic/61862-profinet-s7-1200-a.html#post433059

Der Code der vom SCL Compiler generiert und in eine 1200 hochgeladen wird habe ich mir auch schonmal angesehen. Ich bin aber noch nicht dahintergekommen ob das auch nur eine Art Zwischencode ist, oder ob der Prozessor das nativ abarbeiten kann.
Hier ein kleiner Test, den man auch schön mit dem was in eine 1500 hochgeladen wird vergleichen könnte:
http://www.sps-forum.de/stammtisch/39033-stuxnet-wincc-wurm-kann-industrieanlagen-steuern-14.html#post419596

Wenn die 1500 den gleichen Code erhält bin ich gespannt wie Siemens ein AWL-Programm in diesen Code umgesetzt hat. Denn was in die 1200 hochgeladen wird ist ja sozusagen ein Drei-Adress Code, AWL ist jedoch ein Zwei-Adress Code. Entweder der Übersetzer müsste prüfen ob er zwei oder mehr AWL-Anweisungen zu einer zusammenfassen kann, oder ggf. überflüssige bzw. nicht optimale Anweisungen erzeugen.
 
@HelleBarde
Hast du keine 1500 die du mal aufschrauben kannst? Oder womit testest du?

Wenn die 1500 den gleichen Code erhält bin ich gespannt wie Siemens ein AWL-Programm in diesen Code umgesetzt hat. Denn was in die 1200 hochgeladen wird ist ja sozusagen ein Drei-Adress Code, AWL ist jedoch ein Zwei-Adress Code. Entweder der Übersetzer müsste prüfen ob er zwei oder mehr AWL-Anweisungen zu einer zusammenfassen kann, oder ggf. überflüssige bzw. nicht optimale Anweisungen erzeugen.

Ich habe zwar 'ne 1516 auf dem Tisch stehen, aber da sie mir nicht gehört, darf ich sie auch nicht öffnen (solange einer zu schaut ;-). Ich kann nur mit Wireshark beim Download zuschauen.
Ich habe auch eine 1214 -- jedoch habe ich keinen Plan was die eine oder andere da wie kodiert. Bei der 1516 sieht das was da über den Draht geht auch jedes mal anders aus wenn man es neu übersetzt. Hängt vermutlich mit der versprochenen Absicherung gegen Manipulation zusammmen (Stuxnet hast du ja selber erwähnt). Bei meiner 1214 ist der Code immer gleich.

Für die 1200 habe ich mal ganz langsam mit einem Kontakt und einer Spule angefangen, dann bekommt man auch ungefähr eine Ahnung davon was da drin steht. Nur ist es unglaublich mühsam aus diesen Unmengen von Daten die da hin und her gehen das bischen OB1 raus zu kratzen.
Solange man mit Boolschen Operationen rum tut, ist es wie bei MC7 eine Ein-Address Maschine. Aus
U E0.0
U E0.1
= A0.0
(natürlich in KOP geschrieben) wird
? E0.0
U E0.1
= A0.0
Das erste UND ist kein UND mehr. Ich schätze das ist ein LOAD, wie es die Norm vorgibt.
Wenn man in der Hilfe der 1500 nach Statuswort sucht, dann steht da in etwa, dass nur noch BIE, A0, A1, OV und OS da sind. Die anderen gibt es nicht mehr. Wenn es also kein /ER mehr gibt, dann muss man die KOP Netze irgendwie anders auseinander halten. Wow wer hätte gedacht, dass sich Siemens nach all den Jahren endlich in Richtung Norm bewegt. Ist aber eine reine Spekulation.

Nach dem was ich rausgefunden habe, wird die reine Boolsche-Logik wie bei MC7 abgefahren. Die Kodierung ist jedoch eine andere.

Dann habe ich mich an
L MW 0
L MW 2
+I // und die anderen *I -I /I
T MW4
(also eine ADD box) gewagt

Ja, das sieht nach einen drei Addresscode aus.
+ I MW4 MW0 MW2

Wenn man jetzt noch vor die Box einen Kontakt und hinterher eine Spule hängt, dann bekommt man sowas wie
LOAD E0.0
+' I MW4 MW0 MW2
= A0.0
Irgendwie ist das + verändert worden -- um zwei Bits.
Was mich erstaunt, ist das das
SPBNB
...
UN OV
SAVE
CLR
label: U BIE
fehlt.

Leider hat mein Chef dann gesagt, ich solle doch jetzt was vernünftiges tun :-(
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Halt zurück, gerade habe ich behauptet die Boolsche Logik würde wie bei MC7 behandelt. Stimmt nicht ganz. Es scheint keine Klammerbefehle zu geben und auch das operandenlose OR ist irgendwie unter die Räder gekommen. :D (Das hat mich damals eine Woche Fehlersuche gekostet)

Dort wo Step7 V5
...
U(
O M0.0
O M0.1
...
)
...
gemacht hat finden sich
...
= ???
LOAD M0.0
O M0.1
...
U ???
...
Mir ist unklar um welchen Speicher es sich bei den ??? handelt. Ich dachte erst, dass das L wäre, ist es aber nicht.
Es sieht aber so aus, als würde der Klammerstack durch irgendeinen Speicher ersetzt, der aber nicht nur dafür verwendet wird.
Also das VKE soweit wird auf die Seite gelegt und dort wo die Klammer wieder zu geht, wird es mit dem Befehl, der an der Klammer stand wieder mit rein gerechnet. Eigentlich ganz logisch.
Welcher Prozessor (ARM, INTEL, MIPS, MICRCHIP,...?) hat schon einen Klammerstack.
 
Hi Paule,

das ist Siemens-Neusprech für Datenbausteine "mit optimierter Ablage der Variablen", auf die nur symbolisch zugegriffen werden kann, weil die Variablen ihre Adresse nicht verraten.

Harald
 
Zurück
Oben