# TIA Portal - DB Zugriff -> nicht eindeutige Adresse



## rs-plc-aa (27 Januar 2012)

fiktives Beispiel:

Ich habe einen DB mit 16 Boolschen Variablen, diese zu einem Struct zusammengefasst und möchte an irgend einer Stelle alle zeitgleich auf den Signalzustand 0 setzen.

Nun ging ich da seither relativ simpel an die Sache heran und bemühte folgenden Code:


```
L  0
T  DB1.DBW0
```
 

Das TIA Portal scheint das aber nicht so gut zu finden und meckert beim übersetzen (nicht eindeutige Adresse)

Es ist zwar nur eine Warnung und kein Fehler aber trotzdem nicht schön...


----------



## rostiger Nagel (27 Januar 2012)

Na ja, das würde ich jetzt nicht als Störend ansehen. Die Software kann deine Zuweisung 
jetzt keinen Operanden zuordnen und warnt dich einfach, ob du das wirklich tun möchtest
was du da tust. Es könnte höchstens noch nützlich sein, das nach einer Quittierung dieser 
Warnung TIA das speichert und dann nicht mehr anmeiert.


----------



## rs-plc-aa (27 Januar 2012)

also eher ignorieren - weil ja nicht wirklich falsch - und gut sein lassen?

Mich würde trotzdem interessieren ob es einen Weg gibt die Warnung zu umgehen - ist doch jetzt nicht so ausgefallen das Beispiel, oder?

Dem neuen AT Befehl von dem ich bisher nur mal so was gehört habe hatte ich eigentlich mehr bedeutung zugetraut um eben solche gemischten Zugriffe endlich sauber umsetzen zu können - aber der lässt sich hierbei leider nicht verwenden...


----------



## Deltal (28 Januar 2012)

Du könntest jeden Wert einzelnd mit einer Schleife beschreiben. -> schlechte Lösung

Alternativ dürfte das auch mit der "Fill" Funktion gehen (SFC 21).

Oder du definierst eine andere Struktur die statisch "0" Werte hat und kopierst sie auf deine Zielstruktur (BLKMOV)


----------



## Rainer Hönle (28 Januar 2012)

Wenn der DB rein symbolisch (optimierter Zugriff) angelegt wurde, dann kann TIA im Prinzip die Adressen vergeben wie es will. Wenn der DB nur aus den 16 Bits besteht ist das kein Problem, aber wenn dort mehr Variablen drinstehen, könnte es passieren, dass die Adressen nicht in der erwarteten Reihenfolge verwendet werden. Abhilfe: beim *Erzeugen* des DB den optimierten Zugriff nicht anklicken bzw. abwählen. Eine spätere Änderung hat keine Auswirkungen.


----------



## Paule (28 Januar 2012)

rs-plc-aa schrieb:


> Das TIA Portal scheint das aber nicht so gut zu finden und meckert beim übersetzen (nicht eindeutige Adresse)
> 
> Es ist zwar nur eine Warnung und kein Fehler aber trotzdem nicht schön...


Also ich bin der gleichen Meinung wie TIA, denn wenn du symbolisch programmierst war ja die Lösung im Step7 Classic schon fragwürdig.
Ich würde da auch die Vorschläge von Deltal nach folgender Sortierung favorisieren:


Deltal schrieb:


> *(3)* jeden Wert einzelnd mit einer Schleife beschreiben. -> schlechte Lösung
> 
> *(1) *Alternativ dürfte das auch mit der "Fill" Funktion gehen (SFC 21).
> 
> *(2) *Oder du definierst eine andere Struktur die statisch "0" Werte hat und kopierst sie auf deine Zielstruktur (BLKMOV)


----------



## rs-plc-aa (28 Januar 2012)

Das ist ja genau das worauf ich hinaus wollte...

Nur weil es im Step7 Classic nicht als Fehler oder Warnung angezeigt wurde muss es ja nicht heissen dass es die beste Lösung ist und man an Ihr festhalten muss bis in alle Ewigkeit (Stichwort: "Das haben wir schon immer so gemacht...")

Ich würde gerne ein paar Änderungen in Kauf nehmen wenn es zielorientiert ist.

Das Beispiel ist zwar rein fiktiv gewählt gewesen, allerdings bin ich darauf gestossen beim Durchsehen von testweise migrierten Projekten um mal zu sehen was davon noch übrig geblieben ist.

Aber ist es nicht so dass wenn ich jetzt die Fill Funktion benutze das genau selbe passiert nur unter einem anderen Deckmantel?

Es wird doch auch genau der angegebene Bereich beschrieben - oder kann das Betriessystem sich dann "denken" was der Anwender haben möchte im Falle eines DBs mit optimiertem Zugriff?


----------



## Paule (29 Januar 2012)

rs-plc-aa schrieb:


> Es wird doch auch genau der angegebene Bereich beschrieben


Ja, aber du kannst ihn symbolisch angeben und damit wird ja bei späteren Erweiterungen die Länge automatisch angepasst.


rs-plc-aa schrieb:


> oder kann das Betriessystem sich dann "denken" was der Anwender haben möchte im Falle eines DBs mit optimiertem Zugriff?


Genau, das System schaut auf den Struct und erkennt in diesem fiktivem Fall dass es sich um zwei Byte handelt.


rs-plc-aa schrieb:


> Aber ist es nicht so dass wenn ich jetzt die Fill Funktion benutze das genau selbe passiert nur unter einem anderen Deckmantel?


Was die PLC intern macht kann uns doch egal sein, wichtig ist doch das Handling am Baustein / Programm selber.
Was meinst du mit Deckmantel?


----------



## rs-plc-aa (29 Januar 2012)

Na ja mit Deckmantel meinte ich halt dass die gleiche Aktion anders verpackt wird...

Jetzt habe ich aber an einem realen Beispiel eine andere Hürde entdeckt.

Die Funktion Fill oder auch Blkmov müssen ja versorgt werden.

Wenn ich jetzt in einem FB auf einen Global DB zugreifen will, dieser aber je nach Instanz des FBs eine andere Nummer hat - bin ich seither so vorgegangen:

Die benötigte DB Nummer als IN Parameter beim Aufruf dem FB übergeben, darin dann die Nummer in den TEMP Bereich kopieren (geht sonst nicht) und dann mit der Anweisung:


```
AUF DB [Nummer_des_DBs_aus_Temp_Bereich]
L DBD 0
usw...
```

Den ANY kann man leider auf die Art nicht bilden - oder etwa doch?


----------



## daschris (29 Januar 2012)

Hi

ich hab bisher noch nicht gelesen auf welcher SPS das laufen soll. Auf der 1200 hast du jetzt auch die Möglichkeit direkt ein BIT in einem DW oder ähnlichen anzusprechen. Also brauchst du da aus meiner Sicht hier keinen AT Befehl mehr.
Das sieht dann in SCL so aus:


```
FUNCTION_BLOCK "Baustein_1"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      "WordTest" : Word;
   END_VAR

   VAR_TEMP 
      "TestBit" : Bool;
   END_VAR


BEGIN
    #TestBit := #WordTest.X0; //Zugriff auf ein Bit
    #WordTest := 0; // Alles nullen

END_FUNCTION_BLOCK
```

daschris


----------



## rs-plc-aa (29 Januar 2012)

es handelt sich um eine 300er... - sorry (ich dachte immer das ist der Defaultwert, und nur wenn es was anderes ist muss man es extra erwähnen )

Ich habe auch noch ein wenig "geforscht" und habe herausgefunden dass wenn ich, bezogen auf das fiktive Beispiel, folgendes schreibe:


```
L  0
AUF  "Symbolischer_Name_von_DB1"
T  DBW  0
```

es dann zufrieden ist...

Ich denke die Warnung kommt dann wenn die Adresse keine Symbolische Zuordnung erlaubt (obwohl es ja genau so falsch sein kann wenn man vor der Variable später was anderes einfügt -> aber ich denke wenn man so etwas programmiert sollte man wissen was man wo einfügen darf).


----------



## vollmi (1 Februar 2012)

rs-plc-aa schrieb:


> Ich habe auch noch ein wenig "geforscht" und habe herausgefunden dass wenn ich, bezogen auf das fiktive Beispiel, folgendes schreibe:
> 
> 
> ```
> ...



Das finde ich böse. Ich laufe sehr oft an ältere Programme heran die mit solchen Zugriffen zugepflastert sind. Die Querverweisliste wird so nahezu unbrauchbar.

Wenn es irgendwie geht immer vollqualifizierte Zugriffe auf DBs.

mfG René


----------



## rostiger Nagel (1 Februar 2012)

zusätzlich kann mann auch noch sagen das die CPU's so leistungsfähig geworden sind, das mann
solche Kunstgriffe, eigentlich nicht mehr unbedingt braucht. Mann könnte eben mal jedes einzelene
Bit direkt zurücksetzen.


----------



## rs-plc-aa (1 Februar 2012)

Auf der einen Seite stimme ich zu, auf der anderen würde ich sagen dass es doch möglich *sein sollte* (Feature) so etwas ohne Einschränkungen programmieren zu können.

Ich glaube nicht dass der Vorschlag mit SCL, der weiter oben genannt wurde, besser in der QVWL dasteht wie "meine" Lösung...

Alle Bits einzeln rückzusetzen wäre sicher eine mögliche, wenngleich umständliche Vorgehensweise (es sind ja in der Praxis normalerweise ein Vielfaches von den 16 aus dem Beispiel).

Es kommt wohl auch immer darauf an wer Kunde ist oder für was die PLC eingesetzt wird (in Bezug auf die spätere Nachvollziehbarkeit durch andere Personen).


Wenn ich da an Adressregisteroperationen denke, die teilweise hardcoremäßig in AWL verwendet werden, ist das doch Kindergarten dagegen ​


----------



## Verpolt (1 Februar 2012)

Hallo,

Hab kein TIA 

Meckert es bei dieser Test-Variante auch?

```
L 0 
T "Temp0Word"

L "Temp0Word"
T "DB1.NullMichAb"
```


----------



## rs-plc-aa (1 Februar 2012)

Natürlich -> Weil "DB1.NullMichAb" nicht symbolisch geht wenn gleichzeitig Bits symbolisiert sind (dann könntest du dir das auch mit dem Temp Word sparen, es würde ja auch so gehen...)


----------



## Verpolt (1 Februar 2012)

Ahh...  lesen.....:sad:

Struct  16 bit.


----------



## rs-plc-aa (4 Februar 2012)

Mir ist gerade noch eingefallen dass eigentlich schon immer die Möglichkeit bestand, über die Symboltabelle (zumindest in Step7 Classic) im Falle eines Merkerspeicherbereichs, zum einen einzelne Bits symbolisch zu definieren und gleichzeitg das darüberliegende Byte/Wort/Doppelwort ebenfalls symbolisch zu definieren.

Hier ist dann eben genau das Möglich -> sowohl einzelne Bits als auch alle auf einmal vollständig symbolisch anzusprechen.

Leider existiert diese Möglichkeit für DB-Variablen nicht, und im TIA-Portal immer noch nicht.

Daher auch mein Vorschlag (weiter oben schon) daran etwas zu ändern...


----------



## Ralle (4 Februar 2012)

vollmi schrieb:


> Das finde ich böse. Ich laufe sehr oft an ältere Programme heran die mit solchen Zugriffen zugepflastert sind. Die Querverweisliste wird so nahezu unbrauchbar.
> 
> Wenn es irgendwie geht immer vollqualifizierte Zugriffe auf DBs.
> 
> mfG René



Aber es gibt noch immer Fälle, wo das durchaus Sinn macht, z.Bsp. wenn man den DB variabel halten muß, aber den Instandhaltern und Kollegen eine Orgie mit indirekter Adressierung ersparen will, besonders, wenn man auch noch mehrere DB gleichzeitig variabel nutzen muß. Ansonsten hast du durchaus Recht, immerhin findet man aber die nicht qualifizierten Zugriffe in der Referenz ("Gehe zur Verwendungsstelle"), indirekte Adressierung leider nicht.


----------



## rs-plc-aa (21 Februar 2012)

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.


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


----------



## Nordischerjung (27 Februar 2012)

rs-plc-aa schrieb:


> Habe gerade beim Stöbern die SFC "Reset" gefunden...
> 
> Nennt sich "Bereich bitweise zurücksetzen"
> 
> ...



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:


----------



## rs-plc-aa (27 Februar 2012)

Sorry, hatte noch nie eine 1200er in den Händen...

Kannst du da nicht die Startadresse des ersten Bits angeben?


----------



## Nordischerjung (27 Februar 2012)

rs-plc-aa schrieb:


> Kannst du da nicht die Startadresse des ersten Bits angeben?



Nur bei Merkern, bei DB MUSS es ein Array of Bool sein

siehe Bild


----------



## Verpolt (27 Februar 2012)

Geht das so nicht?

P#DB1.dbx10.0


----------



## Nordischerjung (27 Februar 2012)

Verpolt schrieb:


> Geht das so nicht?
> 
> P#DB1.dbx10.0



Nicht wirklich, ist doch TIA V11 und eine S7-1214


----------



## rs-plc-aa (27 Februar 2012)

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?


----------



## Verpolt (27 Februar 2012)

vielleicht:

SETI -- byteweise setzen
RESETI-byteweise rücksetzen
FILL--Bereich füllen


----------



## logo78 (29 August 2012)

...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?


----------



## HelleBarde (3 Mai 2013)

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 

Zurück zum Problem: Wie setzt man 16 Bools in einem Array auf FALSE? Man schreibe eine Schleife in SCL. 
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?


----------



## Thomas_v2.1 (4 Mai 2013)

@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 (4 Mai 2013)

Thomas_v2.1 schrieb:


> @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 :-(


----------



## HelleBarde (4 Mai 2013)

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.  (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.


----------



## Paule (21 Mai 2013)

HelleBarde schrieb:


> Lese-Zugriffe in optimierte DB sind in etwa Faktor 3 schneller als in nicht optimierte DB.


Was zum Geier ist ein "optimierte DB"?


----------



## PN/DP (21 Mai 2013)

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


----------

