-> Hier kostenlos registrieren
Hallo, Forengemeinde,
derzeit bin ich an der Entwicklung einer Software zur automatisierten Quellcodeerstellung für Siemens TIA (das soll hier aber bitte nicht das Thema sein).
Da die SPS-Entwickler selbst über Perfomanceprobleme hinsichtlich Zykluszeit klagen, habe ich es mir einmal angeschaut und versucht, es sehr vereinfacht mit Xmind aufzuzeigen. Parallel dazu noch ein Entwurf (ebenfalls sehr vereinfacht) von mir, den ich zukünftig dafür hernehmen würde.
Die Anlage besteht aus mehreren Stationen, die über Transportbändern miteinander verbunden sind. Man könnte sich grob an folgendem Bild orientieren:
Bestand:
Das Programm besteht im Wesentlichen aus den beiden Funktionsbausteinen (es gibt noch einige mehr FBs, allerdings wird 95 % des Programms in diesen beiden FBs aufgerufen) FB_Process und FB_Actors, die beide nacheinander im OB1 aufgerufen werden.
Im statischen Bereich des FB_Process sind alle Stationen definiert, die in der Anlage verbaut sind, z.B. Bänder oder Umlenkstationen (nennen wir diesen der Einfachheit FB_Station). Je nach Anlage sprechen wir hier von rund 100 Stationen.
Die Sensoren und Freigaben sind direkt an FB_Station angebunden. Schrittkette der Station befindet sich innerhalb des FBs. Kommunikation nach "außen" wird über den DB_Communication Datenbaustein realisiert. Zylinder oder Motoren tauschen die Informationen über CylinderControl bzw. EngineControl aus.
Nach Abarbeitung der Stationen werden die Aktoren im FB_Actors aufgerufen. Ebenfalls sind dort alle Aktoren der Gesamtanlage (Zylinder, Servoantriebe, Motoren, Pneumatikventile) im statischen Bereich definiert.
Ob nun ein Aktor angesteuert wird oder nicht, erhält er über den DB_Communication Baustein.
Problematisch finde ich:
- Jede Station/Aktor hat rund 3-4 Strings als Input
- Jede Station/Aktor hat 4-5 Strings im statischen Bereich
- Beim Aufruf eines FB wird der komplette statische Bereich in den Speicher (Akku?) geladen. Unabhängig davon ob ich alle Daten für diesen Zyklus brauche oder nicht.
- Beim Aufruf der FBs werden sämtliche Inputs (vor allem die der Strings) kopiert (siehe SPS-Leitfaden 3.3.3)
Nachdem der FB abgearbeitet wurde, wird der Inhalt des Speichers freigegeben oder neu überschrieben.
Bitte korrigiert mich, wenn ich hier falschliege!
Bei dieser Art des Programmaufbaus wird quasi (vereinfacht ausgedrückt) beim Aufruf des FB_Process das halbe Programm in den Speicher geladen und dann beim Aufruf des FB_Actors die zweite Hälfte.
Neuer Ansatz:
Gesehen als Pendant zum vorherigen Schema, wird der komplette Ablauf im FC_Process stattfinden. Jede der 100 Stationen erhält einen separaten FC (z.B. FC_Station1) in dem die zugehörige Schrittkette (FC_Specific_Station), sowie die zu dieser Station zugehörigen Aktoren aufgerufen werden.
Die Daten für den Datenaustausch zwischen Station, Aktor und HMI würden in DB_Stations, DB_Cylinders und DB_Engines liegen.
Die einzelnen FCs (FC_Specific_Station, FC_Cylinder, FC_Engine) greifen per Referenz auf das entsprechende "Ablagefach" im Datenbaustein zu. Die ganzen Strings würden in den Datenbausteinen liegen und müssten so nicht mehrmalig kopiert werden. Ein mehrmaliges Kopieren ist so ausgeschlossen bzw. würde diese erst gar nicht in den Speicher gelangen. Es würden auch generell nur die Daten verwendet werden, die im Zyklus jetzt gerade gebraucht werden, und nicht immer alle, da es keinen statischen Bereich gibt.
---
Im Leitfaden und auch im Siemens Forum wird mehr oder weniger davon geschwärmt und empfohlen, man solle oder könne alles recht einfach und dynamisch mittels Array lösen. Gleichzeitig wird davor "gewarnt" nicht optimierte Bausteine zu verwenden, da ja das Programm sehr langsam werden würde.
Jedoch habe ich eine interessante Auflistung der Zugriffsgeschwindigkeiten gefunden. Wenn dem so wäre, ist der Zugriff auf nicht optimierte Bausteine schneller als das Benutzen von Arrays?
Nun noch ein paar Infos zu mir.
Ich selbst habe rund 5 Jahre SPS (300er; ausschließlich in AWL) programmiert und bin inzwischen seit mehr als 7 Jahren im Umfeld der Hochsprachen unterwegs.
Vielen Dank und auf einen konstruktiven Austausch
derzeit bin ich an der Entwicklung einer Software zur automatisierten Quellcodeerstellung für Siemens TIA (das soll hier aber bitte nicht das Thema sein).
Da die SPS-Entwickler selbst über Perfomanceprobleme hinsichtlich Zykluszeit klagen, habe ich es mir einmal angeschaut und versucht, es sehr vereinfacht mit Xmind aufzuzeigen. Parallel dazu noch ein Entwurf (ebenfalls sehr vereinfacht) von mir, den ich zukünftig dafür hernehmen würde.
Die Anlage besteht aus mehreren Stationen, die über Transportbändern miteinander verbunden sind. Man könnte sich grob an folgendem Bild orientieren:
Bestand:
Das Programm besteht im Wesentlichen aus den beiden Funktionsbausteinen (es gibt noch einige mehr FBs, allerdings wird 95 % des Programms in diesen beiden FBs aufgerufen) FB_Process und FB_Actors, die beide nacheinander im OB1 aufgerufen werden.
Im statischen Bereich des FB_Process sind alle Stationen definiert, die in der Anlage verbaut sind, z.B. Bänder oder Umlenkstationen (nennen wir diesen der Einfachheit FB_Station). Je nach Anlage sprechen wir hier von rund 100 Stationen.
Die Sensoren und Freigaben sind direkt an FB_Station angebunden. Schrittkette der Station befindet sich innerhalb des FBs. Kommunikation nach "außen" wird über den DB_Communication Datenbaustein realisiert. Zylinder oder Motoren tauschen die Informationen über CylinderControl bzw. EngineControl aus.
Nach Abarbeitung der Stationen werden die Aktoren im FB_Actors aufgerufen. Ebenfalls sind dort alle Aktoren der Gesamtanlage (Zylinder, Servoantriebe, Motoren, Pneumatikventile) im statischen Bereich definiert.
Ob nun ein Aktor angesteuert wird oder nicht, erhält er über den DB_Communication Baustein.
Problematisch finde ich:
- Jede Station/Aktor hat rund 3-4 Strings als Input
- Jede Station/Aktor hat 4-5 Strings im statischen Bereich
- Beim Aufruf eines FB wird der komplette statische Bereich in den Speicher (Akku?) geladen. Unabhängig davon ob ich alle Daten für diesen Zyklus brauche oder nicht.
- Beim Aufruf der FBs werden sämtliche Inputs (vor allem die der Strings) kopiert (siehe SPS-Leitfaden 3.3.3)
Nachdem der FB abgearbeitet wurde, wird der Inhalt des Speichers freigegeben oder neu überschrieben.
Bitte korrigiert mich, wenn ich hier falschliege!
Bei dieser Art des Programmaufbaus wird quasi (vereinfacht ausgedrückt) beim Aufruf des FB_Process das halbe Programm in den Speicher geladen und dann beim Aufruf des FB_Actors die zweite Hälfte.
Neuer Ansatz:
Gesehen als Pendant zum vorherigen Schema, wird der komplette Ablauf im FC_Process stattfinden. Jede der 100 Stationen erhält einen separaten FC (z.B. FC_Station1) in dem die zugehörige Schrittkette (FC_Specific_Station), sowie die zu dieser Station zugehörigen Aktoren aufgerufen werden.
Die Daten für den Datenaustausch zwischen Station, Aktor und HMI würden in DB_Stations, DB_Cylinders und DB_Engines liegen.
Die einzelnen FCs (FC_Specific_Station, FC_Cylinder, FC_Engine) greifen per Referenz auf das entsprechende "Ablagefach" im Datenbaustein zu. Die ganzen Strings würden in den Datenbausteinen liegen und müssten so nicht mehrmalig kopiert werden. Ein mehrmaliges Kopieren ist so ausgeschlossen bzw. würde diese erst gar nicht in den Speicher gelangen. Es würden auch generell nur die Daten verwendet werden, die im Zyklus jetzt gerade gebraucht werden, und nicht immer alle, da es keinen statischen Bereich gibt.
---
Im Leitfaden und auch im Siemens Forum wird mehr oder weniger davon geschwärmt und empfohlen, man solle oder könne alles recht einfach und dynamisch mittels Array lösen. Gleichzeitig wird davor "gewarnt" nicht optimierte Bausteine zu verwenden, da ja das Programm sehr langsam werden würde.
Jedoch habe ich eine interessante Auflistung der Zugriffsgeschwindigkeiten gefunden. Wenn dem so wäre, ist der Zugriff auf nicht optimierte Bausteine schneller als das Benutzen von Arrays?
Nun noch ein paar Infos zu mir.
Ich selbst habe rund 5 Jahre SPS (300er; ausschließlich in AWL) programmiert und bin inzwischen seit mehr als 7 Jahren im Umfeld der Hochsprachen unterwegs.
Vielen Dank und auf einen konstruktiven Austausch