Multifunktionsbausteine zum anparametrieren schießen für mich auch am Ziel vorbei, oft zu schlecht dokumentiert und auch oft nicht alle (Sonder-)Funktionen ausgetestet. Leider.
Die "Standard"-Bausteine sind nur gut für die schnelle Erstprogrammierung des Lieferanten, der aus einer handvoll Standard-Bausteinen und zig Instanzen (am liebsten Arrays) (und am liebsten mit Codegenerator) möglichst schnell und billig das Grundprogramm für eine große Anlage zusammenklickt... auch mit nur wenig ausgebildetem Personal... bei der Inbetriebnahme wird dann erstmal der unerfahrenste und daher am leichtesten abkömmliche Kollege vorgeschickt, der muß nur Handy halten und mit der Maus klicken können zum Parametrieren des Programms, was der eine Kollege mit Ahnung bzw. der Entwickler der Standard-Bausteine ihm aus der Firma am Telefon durchgibt.
Wenn dann später beim Kunden irgendeine Änderung nötig wird, dann sitzt jeder Programmierer ewig am Nachdenken, wie die Änderung eingebaut werden muß, so daß sie nur eine einzige Instanz beeinflusst. Irgendwann wird dann doch entnervt eine Kopie des FB gemacht und daraus die x-te Variante des ursprünglichen "unser Multifunktions-Standard-Baustein kann alles", und der zu ändernde Förderer wird dann eine Instanz des neuen FB - zum Schluß ist man dann doch wieder bei: jeder Förderer hat seinen eigenen FB. Da hätte man gleich von Anfang an "oldschool" angstfrei jeden Förderer komplett ausprogrammieren können, ohne den für den Förderer überflüssigen Programm-Ballast, der nur für wenige andere Instanzen nötig ist.
Oft meint dann die Firma des Baustein-Entwicklers auch noch, daß die Bausteine ja ungeheuer wertvolles, zu schützendes Kapital/Druckmittel der Firma darstellen und die Bausteine haben dann NoHow-Schutz, den man dann erst knacken muß, um dem Lieferanten Software-Fehler in den Bausteinen nachweisen zu können oder um im Problemfall überhaupt eine Diagnose durchführen zu können, oft unter Zeitdruck während die Produktion steht und jede Minute Kosten verursacht, gegen die die vielleicht mal vom Erstprogrammierer eingesparten Arbeitsstunden lächerlich sind.
Das Thema reinitialisieren ist aber eigentlich auch kein reines TIA-Thema, eher eins der Datenhaltung.
In der S7 musste man doch bei Instanzdatenerweiterungen bzw. DB-Anpassungen den jeweiligen DB laden inkl. Verlust der Aktualwerte.
In Step7 classic konnte aber ein Programmierer, der weiß was er tut, die FBs und Instanzen im laufenden Betrieb ohne CPU-Stop und ohne Aktualwertverlust kontrolliert austauschen. Das TIA läßt solches überlegtes Handeln aber gar nicht zu. Leider. Für TIA sind die Programmierer doof und müssen vor dem eigenen Handeln geschützt werden.
Ich würde die IOs nicht mit UDTs zusammenfassen. zu oft muss dann doch die Reihenfolge der IOs geändert werden und dann passt der UDT nicht mehr. Insbesondere, wenn er mehrfach verwendet wird.
UDT für IO-Anbindung sind nach meiner Erfahrung nur sinnvoll als abstrakte Zwischenebene für hochentwickelte durchdachte Steuer- und Statuswords von FU oder komplexen Geräten. Sie sollten aber nicht auf echte E/A-Baugruppen angewendet werden, weil dann ein Umverdrahten einzelner E/A im laufenden Betrieb nur noch unnötig umständlich möglich ist. Nur weil der Erst-Programmierer keine Lust hatte, einzelne E/A zu den Instanzen oder Zwischen-Strukturen zu rangieren...
Harald
.
womit man wieder beim Thema Programmierstil wäre...
