Ich möchte mir Standartfunktionsbausteine bauen für die klassischen Antriebsarten in Step7. Auch die Ansteuerung der Antriebe mittels Simocode sollten berücksichtigt werden, sowie über FU. Aber auch der klassische Weg für ältere Anlagen mit Schaltern am Schrank möchte ich berücksitigen.
Nun, die grundsätzliche Frage:
Wo überwiegen die Vorteile, wo die Nachteile?
Das Erstellen der Bausteine wie, ist nicht das Problem.
Ich möchte mich mur nicht in eine "Programmiersackgasse" begeben.
Ich denke, bevor Du Dir diese Frage stellst, ist viel wichtiger, dass Du Dir im Klaren bist, was Du in einen Standardbaustein überhaupt alles reinpacken willst. Meiner Meinung nach macht es wenig Sinn, ganze Abläufe in einen FB zu packen, oder eine komplette Motorsteuerung, welche per Visu und per Taster und vielleicht auch noch per Codierschalter bedient werden kann.
Bei uns werden Standardbausteine in der Regel als kleine Einheiten programmiert, welche sich bei Bedarf zusammenstöpseln lassen - und bei Bedarf auch erweitern.
Ein Beispiel:
Eine Gießanlage hat 50 Kühlkreise, welche im Prinzip gleich funktionieren. Man möchte natürlich nicht alles 50 mal Programmieren, da macht der Einsatz eines Standardbausteins sinn, welcher dann 50 mal aufgerufen wird.
Oder:
Zylinderansteuerung mit der ganzen Schalterüberwachungsgschichte dran. Hier macht es z.B. keinen Sinn, alle möglichkeiten (4/2-Wege-Ventil 5/2 Wege 5/3 Wege, 1 Schalter pro Seite, Schalter nur auf 1 Seite usw.) in einen FB reinzupacken. Spätestens wenn man dann einen Sonderzylinder hat und seinen FB daran anpasst wird man sich ärgern, dass man nun bei den FBs für 50 andere Zylinder einen Zeitstempelkonflikt hat. Hier ist sinnoll, 3 oder 4 Verschiebene Bausteine für verschiedene Zylinderkonstellationen zu machen.
Beispiele, wo wir Standardfunktionen als FC verwenden sind z.B.
- Berechnungen, Datenmanipulation (lineare Skalierung, Kennlinien verbiegen, Daten indiziert kopieren, ....)
Beispiele für FB
- Schnittstellenabwicklung eines FU oder eines Movimot. nur 1 FB, für jeden FU ein eigener Instanz-DB in dem die PE/PA-Daten und Soll/Istwerte liegen.
- Funktionen, welche intern viele Statische Daten brauchen (z.B. Steuerung eines Prop-Ventils, 2-Punkt Regler)
- Funktionen, welche Statistische Daten oder Diagnosedaten aufzeichnen (z.B. DP-Diagnose, Schrittkettendiagnose, Taktzeitmessung)
Die dritte Variante, welche wir immer wieder einsetzen, ist die Mischform. Das Programm ist in einem FC geschrieben, ihm ist fix ein DB zugeordnet (welcher indiziert per AUF DI[#...] aufgerufen wird.). Diese Variante ist von der Bearbeitungszeit auf der CPU her schneller als ein FB und hat natürlich auf diverse Vor- und Nachteile.
Vorteil sind
- dass man im Instanz-DB die Daten ab DBX0.0 nutzen kann, auch wenn am FC IN und OUT-Daten verwendet werden
- dass Adressregister 1 und 2 uneingeschränkt nutzbar sind
- werden im Instanz-DB strukturelle Änderungen gemacht, muss nur der Instanz-DB neu generiert werden - nicht der FC-Aufruf
Nachteile sind:
- das gesamte Programm muss per DIX/DIW usw auf den DB zugreifen - eine gewissenhafte Dokumentation ist absolut notwendig
Diese dritte Variante setzen wird in der Regel dann ein, wenn der Code im Standard-Baustein sehr Umfangreich ist. Der Instanz-DB wird als UDT deklariert - anschließend wird für jede Instanz ein DB vom Typ UDTxxx angelegt.
mfg
Maxl
.
