Das stimmt natürlich auch. Mit dem anpassen der Symbolik kann man schon so einiges erschlagen.
Es gibt aber trotzdem noch Anwendungsfälle dafür.
In dem Fall den ich
HIER beschrieben hatte, habe ich für die 3 Anlagen drei FC-Paare am Anfang und am Ende von OB1 die mit einem einfachen INT-Selektor umgeschaltet werden.
Hat den Vorteil dass, wenn ich die Anlage wechsle, ich gar nichts ändern muss. Nur wenn ich OB1 neu einspiele muss ich drauf achten dass ich den richtigen Selektor habe.
Das wäre mit einfacher Symbolik schon schwerer zu lösen, ich könnte zwar beim Anlagen-Wechsel eine andere Symbolik ins Projekt kopieren, ist aber umständlich.
Nachteil ist natürlich dass die Querverweise über alle drei FCs gehen wenn ich sie im Projekt lasse. Aber ich kann ja nicht alles haben.
Ohne jetzt als Verfechter aussehen zu wollen...
Wenn man z.B. ein Optionenhandling hat bei der eine zusätzliche Option als ein weiterer Datenbaustein eingebunden wird, der zusammen mit einem FB die komplette Option bildet...
dann verweist man normalerweise auch nur mehr die Eingänge auf die zugehörigen Datenbaustein-Datenpunkte und die Option ist fertig. Im Endeffekt ist das auch I/0-Mapping oder?
Obwohl es unter TIA jetzt zumindest die Möglichkeit gäbe die Options-I/Os als separate Variablentabelle einzubinden.
Aber gerade da finde ich die Version, die I/Os direkt auf den zugehörigen DB zu legen, schöner.
Wie man sieht, muss man eigentlich zuerst genau definieren was man mit I/O-Mapping meint.
Das klassische S5-Style-I/O-Mapping dass ohne erkennbaren Grund die I/Os in DBs ablegt, ist eigentlich abzulehnen. Außer bei Sonderfällen wie oben.
Wenn man das Thema I/O-Mapping ein wenig fein-granularer anschaut, so wie mit dem Optionenhandling beschrieben, dann sehe ich kein Problem damit.
Zum Schluss gilt wie immer: Man sollte die Techniken anwenden die für einen Selbst und den Kunden (im großen Ganzen) das Beste ist und nichts gleich von vorn herein verteufeln.
