Das kann man einfach über ein Enum lösen.
Initial Fleißarbeit, aber es macht den Code lesbarer.
Ich nutze sonst Bausteine die auf die Modbusvariablen referenzieren.
Dort sind dann Eigenschaften zum ansprechen des Wertes vorhanden. Gerade wenn man dann noch Klemmen zuweisen möchte und/oder aus der visu Schreibrechte benötigt.
Mfg
Paul
Bei Bedarf send mir dein Projekt zu.
Ich kann nochmal optimieren, kommentieren und ergänzen
@paule
Das mit der Enumeration klingt interessant.
Ich melde mich, wenn ich mal dazu komme und sende Dir ein Bespielprojekt zu analog zu meinem.
Grundsätzlich sollte ich mein Projekt eh optimieren, damals als ich angefangen habe, wurde alles mit FUP programmier [programmieren kann man das nicht nennen].
Jetzt wo ich in ST fit bin, könnte man so einiges optimieren.
Kein Problem, einfach melden .
Ich arbeite beruflich seit 10 Jahre mit Codesys. Zwar HLK-Anlagen und kein Smarthome, aber am Ende ist das auch nur Wasser zum kochen 
Danke euch beiden für die Inputs.
Das ist wiederum eine Menge Stoff den ich da durchdenken muss. Da brauche ich wohl noch etwas Zeit.
@ Paul
Danke für dein Angebot. Komme ich gerne auf dich zu. Will mir aber zuerst mal selber ein paar Gedanken machen.
@goifalracer
Ich glaube ich habe nun letze Nacht begriffen wie du das mit den flüchtigen und nicht flüchtigen Variablen händelst.
Der eine Modbus Slave ist für flüchtige Variablen. Ok alles klar.
Der andere Modbus Salve ist für nichtflüchtige Variablen aber die dazu definierten Varibalen sind „normale“ Variablen also flüchtig. Du schreibst Sie dann im Programmschritt 3 persistent weg bzw, holst sie mit Programmschritt 1 beim Start aus dem peristenten Bereich. Somit denke ich ist mir klar warum in der GVL_IP_Symcon nur „normale“ Variablen deklariert sind.
Grüsse Pit
Du musst nicht zwingend zwei Slave Instanzen erzeugen. Das geht auch mit einer. Wenn du die Adressbereiche bewusst unterscheiden willst zw. Persistent und nicht Persistent kannst du den Advance Master Slave Baustein aus der Lib nehmen.
Ansonsten kannst du auch die Adressen durchgehen verwenden und musst dann nur betroffenen Variablen auf Persistent setzen.
Gibt viele Lösungswege dafür.
Mfg
Paul
@Pit Ja genau so sollte es laufen.
@paule: Das mit dem Advance Baustein wusste ich gar nicht.
Wenn ich nur bestimmte Adressen auf „Persistent“, das war auch anfangs meine Idee, hat aber dann Irgendwie nicht geklappt, deswegen die getrennte Lösung.
Warum das nicht geklappt hat weiß ich nicht, (wsl saß das Problem vorm Rechner) 
Hallo zusammen
Sorry ich weiss nicht wo ich einen Knopf im Kopf habe, aber irgenwie raffe ich diese Sache nicht.
Ich denke ihr seit gedanklich einfach schon viel weiter.
Ich habe zum Beispiel folgenden Funktionsbaustein.
Der digitale Eingang befindet sich an Adresse %IX328.2
Der digitale Ausgang befindet sich an Adresse %QX173.5
Jetzt haben wir Variablen erstellt zur Kommunikation des Modbus Slave (SPS) und dem Modbus Master (IPS).
ax: ARRAY [0..0] OF BOOL;
acoil: ARRAY [0..1300] OF BOOL;
Aber nun, da verzweifle ich dran, wie bringe ich das nun zusammen bzw. ist es schon zusammen oder nicht? Warum ax Bereich 0…0 und acoil 0…1300?
Ich denke ihr habt gerade darüber diskutiert wie man das mit ganz vielen Variablen elegant, übersichtlich und effizient lösen kann, ich kapiere aber nicht mal wie man eine einzelne digitale Verbindung herstellt.
Ergänzung:
Ich habe nun auch Zugriff auf Bibliotheksdokumentation WAGOAppPlcModbus.library. Als Erkenntnis daraus würde ich sagen, keines der Datenmodelle greift auf meinen K-Bus zu. Ist das richtig?
Grüsse Pit
Ich kann sie anbieten mal über AnyDesk und am Telefon bei dir rauf zu kommen und dir mal die Grundlagen an deinen Beispiel zu erläutern.
Aber trotzdem nochmal kurz was dazu:
Ich denke er hat das Array mit [0…0] als Art Platzhalter erstellt, weil der Baustein den Eingang beschaltet haben muss. Er nutzt aber z.B. die Coils nicht.
Die [0…1300] definiert ein Array welches ziemlich groß ist, du kannst es anpassen auf dein Anwendungsfall. Der Baustein kann mit dynamischen Größen umgehen.
Es gibt jetzt mehrere Lösungswege. Der einfachste ist du mappst die Ein - und Ausgänge auf die Arrayeinträge deiner Wahl und nutzt im Programm dann nur noch die Werte aus dem Array.
z.B.
_Digitaler_Ausgang1 := ax[0]; // Wert aus dem Array an DO1
ax[1]:= _Digitaler_Eingang1; // Wert des DI1 an Array
Die kompliziertere ist du machst dir ein Funktionsbaustein welches eine Referenz zu einen Arrayeintrag besitzt und im Baustein kannst du dann deine ganze Logik zum Thema Datenzugriff Modbus und I/O realisieren.
Mfg
Paul
So ich denke jetzt komme ich weiter. Ich denke mein grosser Gedankenfehler war, dass ich immer der Meinung war, dass der Modbus auf meinen K-Bus zugreift. Offensichtich scheint dies nicht zu sein, sondern ich habe einfach einen Stabel Variablen definiert worüber ich Datenaustauschen kann.
Ich habe beim EA-Abbild ein Variable aus dem Stapel eingefügt.
Beim Funktionsbaustein habe ich dies entsprechend angepasst.
Ein kleiner Schritt für die Menscheit aber ein grosser für mich. Nun wird es ziemlich geil, weil ich kann nun die Lampe über den Taster oder Symcon schalten und habe überall immer den korrekten Zustand angzeigt.
Was mir an dieser Lösung nicht gefällt, das mein Variblenname DO_088_14 nicht mehr vorhanden ist. Der Name heisst aufgeschlüsselt, dass es sich um einen digitalen Ausgang handelt, das es das Modul 88 ist und der 14 Kanal diese Modusl. Diese Bezeichner habe ich in meinen Stromlaufplänen und sonstigen Dokumentationen verwendet und möchte dies nicht aufgeben.
Also habe ich zwei Variablen einmal acoil[0] und DO_088_14 die für das selbe da sind. Cool währe es, wenn ich die beiden Variblen so vernküpfen könnte, dass wenn sich eine Variable verändert, die andere Variable den neuen Wert annimmt. Hätte den Vorteil das ich „nur“ noch diese Verknüpfung machen bräuchte und die Variablen im KBus sowie den POUs nicht ändern bräuchte. Nach einem halben Tag Suchen, bin ich zum Entschluss gekommen, dass dies nicht geht. Ich lasse mich gerne eines besseren belehren.
Alternative:
Ich schaffe mir entsprechende Adressräume z.B.
ax_DI : Array [2101…7708] Modul 21 Kanal 1 bis Modul 77 Kanal 8
ax_DO:Array [7801…13208] Modul 78 Kanal 1 bis Modul 132 Kanal 8
Damit hätte ich wieder eine ähnliche Notation welche etwas kompatibel ist mit meiner bestehenden Dokumentation. Nachteil ich generiere viele Variablen welche ich nicht benötige. Z.B. Modul 78 ist ein 8 Kanal Modul als brauche ich 7809 bis 7899 nicht. Ich gehe mal davon aus, dass ich keine Mehrdimensionalen Arrays definieren kann, womit man diesen Nachteil eventuell entschärfen könnte.
Diese Adressräume kann ich mit FbMbSlaveDataModel definieren und dann mit FbMbKompositorDataModel zusammen basteln. Wenn ich das mal so grob richtig verstanden habe.
Persistente Variablen habe ich im Moment mal aussen vorgelassen. Ob mir bei dieser Geschichte Enum mir weiterhilft kann ich im Moment nicht abschätzen aber jetzt raucht mir der Kopf sowieso.
Grüsse Pit
Du kannst als Arrayindex auch ein ENUM nutzen, das macht es dann wieder lesbar.
und dann den Zugriff so gestalten
Und nun nochmal eine weitere Lösung, wenn es nur um solche Lichtschalter geht.
An den Baustein kommen Ein- und Ausgang ran und zusätzlich ein Coil was aus Symcon kommt. Sehr einfach und 100-fach duplizierbar.
Ich denke das sollte jetzt erstmal zum forschen und einer fundierten Lösungsstrategie reichen. Melde dich wenn du weitere Hilfe benötigst.
Mfg
Paul
