# TIA V15 - DBs aus FC/FB heraus öffnen



## shaggy0815 (28 Mai 2021)

Hallo liebes Forum,

ich kämpfe gerade mal wieder mit meinem neuen Freund TIA.

Ich möchte nur aus einem FC/FB heraus DBs öffnen, dessen DB-Nr. erst zur Laufzeit bestimmt wird. 
Die Nummer der zu öffnenden DBs stehen in einer Integer Variable. In diesen DBs möchte ich dann die Status einzelner Variablen abfragen.

In Klassik würde ich ganz einfach Programmieren:

AUF DB[NummerDB] // In NummerDB steht die Nummer des zu öffnenden DBs
U DBX10.0
U DBX10.1
= Blablabla

Sowas muss doch auch irgendwie in TIA gehen, nur wie? Den AUF Befehl würde es da zwar auch noch geben, aber das geht doch sicher 
irgendwie viel schöner mit ein paar SCL Anweisungen.

Kann mich jemand bitte in die Richtige Richtung schicken? Wahrscheinlich geht's irgendwie mit DB_ANY und dann irgendwie ein Variant
draus machen? 

Beste Grüße


----------



## Ralle (28 Mai 2021)

Ich denke, das ist ein Fall für Peek und Poke und nicht optimierte Bausteine. (Suche danach in der Hilfe von TIA-Portal oder hier im Forum.)
Leider ist die 1500-er für derartige Zugriffe nicht mehr so gut aufgestellt, was bei mir dazu führte, meine Software grundsätzlich so umzustellen, dass ich so etwas nicht mehr benötige. (Geht übrigens allen alten S7-Classic-Freunden so.)
Umkopieren geht auch noch, aber das ist noch aufwendiger.


----------



## shaggy0815 (28 Mai 2021)

Hallo Ralle,

danke für dein Feedback. 

Leider ist es ja bei den 1500-er Steuerungen wohl so, dass die den mix nicht optimiert und optimiert nicht mögen. Da geht wohl die Zykluszeit unglaublich in die Höhe. Ich benötige auch jede Menge Graph Ketten und die gehen dann wieder nur mit optimierten Bausteinen...

Man man man, ich dachte mit TIA ist alles so toll einfach... Im Moment bemerke ich nur das ich alles was ich in Klassik mal eben schnell machen
konnte in TIA nicht auf Reihe bekomm...


----------



## Ralle (28 Mai 2021)

Deswegen macht es Sinn, die Software komplett umzustellen und verstärkt Array und Struct zu nutzen. Hier muß man alte Zöpfe abschneiden, ging uns allen so.
Also nicht 100 DB mit ein paar Daten, sonden einen DB mit 100 Array und Struct. (Vereinfacht ausgedrückt)


----------



## shaggy0815 (28 Mai 2021)

Hallo Ralle,

noch hätte ich wahrscheinlich die Möglichkeit dazu.

Ich verstehe denke ich was Du meinst. Bei mir ist nur selbst der einzelne DB schon relativ groß.

Ich programmiere an Montagelinien. Ein DB entspricht hierbei dem „Bauplan“ eines Bauteils welches über eine komplette Linie gebaut wird. Wenn so eine Linie 20 Stationen hat, ist so ein DB schon recht groß.

Dann sind unter Umständen 20 Bauteile zur gleichen Zeit auf der Linie unterwegs. Das wären bei mir derzeit 20 DBs mit jeweils einem Bauplan.

Ich bräuchte dann quasi einen Super DB, welcher meine 20 Baupläne beinhaltet… 

Nur ein einzelner Bauplan DB ist unter Umständen schon 10000 Byte oder mehr…


----------



## Ralle (28 Mai 2021)

Verstehe, das ist schon sehr speziell, so ene großer Bauplan / Rezept.


----------



## ducati (29 Mai 2021)

shaggy0815 schrieb:


> Da geht wohl die Zykluszeit unglaublich in die Höhe.


Definiere mal "unglaublich"...


----------



## shaggy0815 (29 Mai 2021)

Also wir müssen zum Beispiel HMI Pro Panels und auch normale Panels mit HMI Lite einsetzen.

Beides erfordert nicht optimierte DBs.

Mit kaum was in der Steuerung haben wir schon Zykluszeiten von 25ms. Und da ist noch nix drin…

Ich hab mit TIA wirklich noch nicht viel Erfahrung gemacht. Kollegen berichten aber von extremen Zykluszeiten von mehreren 100ms…


----------



## Heinileini (29 Mai 2021)

shaggy0815 schrieb:


> ...
> Ich hab mit TIA wirklich noch nicht viel Erfahrung gemacht. Kollegen berichten aber von extremen Zykluszeiten von mehreren 100ms…


Meinen Deine Kollegen TIA im Allgemeinen oder speziell bei Deiner Anwendung?


----------



## PN/DP (29 Mai 2021)

shaggy0815 schrieb:


> Kollegen berichten aber von extremen Zykluszeiten von mehreren 100ms…


Ich glaube das liegt dann nicht an TIA und nicht an "optimiert"/nicht optimiert/gemischt. Da macht dann wohl eher der Kollege was falsch.

Harald


----------



## shaggy0815 (29 Mai 2021)

Bei Ähnlichen Anwendungen. Wir sind im Bereich der Automobilbranche unterwegs und hier besonders im
Bereich Montagelinie.

Da werden Dir teilweise Templates für die Programmierung vorgegeben an die wir uns halten müssen. Und
die sind nicht immer schön...

Das Konzept ist da immer in etwa Ähnlich. Ein Bauplan wird in einem DB Abgelegt. Ein Bauteil liegt auf einem
Werkstückträger und wird stationsweise aufgebaut. Je nachdem wieviele Werkstückträger es gibt, so viele 
DBs mit Bauplänen gibt es.

Deshalb brauch ich auch irgendeine Möglichkeit DBs Ereignisgesteuert aufzurufen, denn ich weiß erst zur Laufzeit 
auf welchen DB ich in einer Station gucken muss.

In Klassik hatte ich da keine Probleme mit in TIA irgendwie schon. Geht sicher auch irgendwie elegant in TIA. 
Leider bin ich derzeit noch Klassik durch und durch...


----------



## ducati (31 Mai 2021)

shaggy0815 schrieb:


> Leider bin ich derzeit noch Klassik durch und durch...


Sei froh...


----------



## ducati (31 Mai 2021)

shaggy0815 schrieb:


> Kollegen berichten aber von extremen Zykluszeiten von mehreren 100ms…


Beim Online beobachten geht die schon mal so hoch...
Aber hängt natürlich davon ab, was da an Software in welcher Steuerung drin ist.


----------



## JesperMP (31 Mai 2021)

20 Baupläne, je mal 10 kB. 
Also insgesammt 200 kB Daten. 
Kein Problem für TIA oder die S7-1500 CPUs.

Wechsle auf optimiert und eine Programmkonzept ohne Peek/Poke.
Kopiere die gesammte STRUCTs auf einmal, ohne Schleifen.
Ich kann mir nicht vorstellen dass es zu 100 ms Zykluszeiten kommt.


----------



## JesperMP (31 Mai 2021)

Max-Grösse von ein nicht-optimierten DB ist 64 kB.
Max-Grösse von ein optimierten DB ist 2 MB. 

Probier mal ein Proof-of-concept test-Programm. Dann weis du schnell ob das geht oder nicht.


----------



## shaggy0815 (31 Mai 2021)

Hallo Jasper,

genau das hab ich heute gemacht. Und es war in der Tat kein Problem.

Mir war nicht bewusst dass die DBs bei TIA so gross sein können.

Hab meine Datenverwaltung ein bisschen auf mehr Arrays optimiert, damit ich da noch besser indexieren kann. Da geht mit gewohnter Datenhaltung aus Klassik echt nix mehr…

Ich hab sonst immer ganz gerne sprechende Bezeichnungen in der Datenhaltung gehabt als nur Array Nummerierung.

Evtl. muss ich das noch mal Grundlegend anders aufbauen damit die Lesbarkeit nicht flöten geht…


----------



## hucki (31 Mai 2021)

shaggy0815 schrieb:


> ...Ich hab sonst immer ganz gerne sprechende Bezeichnungen in der Datenhaltung gehabt als nur Array Nummerierung.


Da helfen dann Konstanten, um den Zahlen Namen zu geben...


----------



## shaggy0815 (31 Mai 2021)

Absolut, allerdings nur um die Arrays zu dimensionieren. Zumindest hab ich das bis jetzt rausgefunden...

Ich hab für den Bereich Montagelinie sehr oft ein Schema, dass ich in einem DB ganz viele Stationen mit unterschiedlichen
Operationen pro Station abbilden muss. Dann hab ich es eigentlich immer ganz gerne auch genau so im DB abgebildet.

Dann kann man im aufgeschlagenen DB schon ablesen was genau welche Station macht und welche Operationen sie
hat.

Da aber nicht jede Station die gleichen Operationen oder die gleiche Anzahl von Operationen hat lässt sich das schlecht
Stationsweise in einem Array Raster abbilden. Oder man müsste die Anzahl der Operationen einer einzelnen Station, immer
auf die  Station mit den meisten Operationen auslegen, so dass sich wieder ein Raster ergibt. Dann hast Du aber immer viel
ungenutzte Reserven.

TIA würde aber wohl genau das Verlangen um einfach indexiert arbeiten zu können.

Wobei ich gerade darüber nachdenke, dass man mit Konstanten sicher auch ein Array Element statt mit Element[0].blabla mit
Element[Konstante].blabla adressieren könnte...


----------



## hucki (31 Mai 2021)

shaggy0815 schrieb:


> Absolut, allerdings nur um die Arrays zu dimensionieren. ...
> 
> Wobei ich gerade darüber nachdenke, dass man mit Konstanten sicher auch ein Array Element statt mit Element[0].blabla mit
> Element[Konstante].blabla adressieren könnte...



Genau, auch, um die Member außerhalb von Schleifen namhaft anzusprechen...


----------



## JesperMP (1 Juni 2021)

shaggy0815 schrieb:


> Da aber nicht jede Station die gleichen Operationen oder die gleiche Anzahl von Operationen hat lässt sich das schlecht
> Stationsweise in einem Array Raster abbilden. Oder man müsste die Anzahl der Operationen einer einzelnen Station, immer
> auf die  Station mit den meisten Operationen auslegen, so dass sich wieder ein Raster ergibt. Dann hast Du aber immer viel
> ungenutzte Reserven.


Wenn die CPU genügend Speicher dafür hat ist es wohl die einfache Lösung.


----------

