Initialisierung bei Mehrfachinstanzen

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Kollegen,

Ich habe eine Aufgabe bei welcher ich keine gute Lösung finden kann.

Codesys 3.5

Es existiert eine Mehrfachinstanz, diese hat eine Struktur welche von der CODESYS Visu genutzt wird.
Der Inhalt von dieser Struktur sind Parameter für Funktionseinheiten. Jede Funktionseinheit hat eigene Parameter welche Eingestellt werden können.
Der Gedanke ist es nun, dass der die Person welche die Anlage in Betrieb nimmt diese Parameter anpasst. Die Voreinstellung der Parameter soll bei der Programmvorbereitung vorgenommen werden. (Auch die Voreinstellung hat unterschiedliche Parameter).
Heißt, es wird ein Initialisierungsbaustein geben welcher nach dem erstmaligem Herunterladen einmalig abgearbeitet wird.

Ich sehe nur den aufwendigen Weg, für jede Einheit einen eigenen Initialisierungsbaustein zu erstellen.
Unsere Anlagen haben ca. 30 Einheiten welche gepflegt werden müssten. Es wäre somit machbar aber nicht schön.

Wenn jemand noch eine gute Idee hätte, wäre ich sehr dankbar.

MfG Rici

 

[KLM]

Initialisierung ginge ja schon bei der Deklaration ganz ohne Codeabarbeitung in einem Baustein. Aber für mich klingt es eher, als wäre eine Rezeptverwaltung die bessere Variante.

 

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

Tatsächlich ist die Struktur mehrfach vorhanden (Für jede Einheit), diese befinden sich wiederum in einer Oberstruktur welche bereits in einer Rezeptverwaltung integriert ist. Die Rezeptur wird genutzt um die Daten Speicherremanent abzulegen.

Dadurch, dass die Struktur alle Einheiten abdeckt ist diese recht unübersichtlich.
Aber die Idee ist eine Überlegung Wert.

 

[Rici]

Es wird nun für jede Einheit ein Init Baustein Angelegt.
Hier ist zwar mehr Arbeitsaufwand, hat aber den Vorteil dass es eine gute Übersicht gegeben ist.

 

[KLM]

Anstelle eines separaten, selbsterstellten Init-Bausteins (Funktions Baustein) könntest Du auch eine FB_Init Methode zum eigentlichen FB hinzufügen und es somit bei der Deklaration der FBs definieren. Macht es aber nicht unbedingt übersichtlicher. Ich mache viele Initialisierungen von FBs gern in Aktionen direkt am FB, aber das ist geht nicht, wenn Du verschiedene Instanzen brauchst. Dem Gedanken folgend könnest Du aber eine Art Basis-FB erstellen und für jede Instanz eine Ableitung (OOP), in der dann die Initialisierung z.B. in einer Methode erfolgt. Dann brauchst Du zumindest nicht je eine zusätzliche Instanz für den Init-FB.
Bei Initialisierungen bei der Deklaration oder bei Verwendung von Strukturiertem Text, würde sich sonst auch Excel anbieten für die Code-Generierung. Unabhängig von Funktionen in Excel werden nur die Zellwerte kopiert, jeder Zeile in Excel wird eine neue Zeile in CS und jede neue Excel-Spalte erzeugt einen Tab-Stop. Aber mit der Rezeptur hast Du es eigentlich eh schon in Excel.
Hmmm...Viel Optimieren kann man einfach nicht, wenn individuelle Paramerter zu setzen sind. Aber das Deklarieren von zwei Instanzen (Basis-FB und Init-FB) finde ich zu aufwendig.

 

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke KLM,

die FB_Init kannte ich gar nicht. Ist interessant.
Wir haben aber jetzt auch Aktionen im jeweiliger Einheit hinterlegt. Somit ist es ähnlich zu euch.


Etwas anderes, ich weiß nicht ob es Sinn macht es unter diesem Thema zu erwähnen, aber ich probiere es mal.

KLM, du hast Excel erwähnt. Wir würden einige Parameter auch gern aus einer Excel Datei einlesen.
Diese Datei nutzt die Konstruktion für die Anlagenzusammenstellung, wir habe die Möglichkeit einige Einstellungen aus dieser auszulesen.
Wie kompliziert ist es von einer Excel Datei aus unterschiedlichen Mappen und Zellen Daten einzulesen? habt ihr Erfahrung damit?

Gruß Rici

 

[KLM]

Eine Rezepturdatei ist, je nach Konfiguration, einer CSV-Datei ähnlich, die mit Excel bearbeitet werden kann und anschließend wieder vom Rezeptverwalter eingelesen werden kann. Eine *.xlsx geht manuell via WagoAppFileDir vieleicht auch manuell, aber das ist vermutlich nicht ganz einfach, weil das eine Art ZIP-Container ist, der verschiedenste Ordner und Dateien enthält. Die Verwendung von CSV- oder TXT-Dateien (mit oder Rezeptverwalter) ist deutlich einfacher.
Oder gleich eine Datenbank oder JSON-Datei. Das hängt davon ab, ob die Quelle der Datei ein Mensch mit Office-Erfahrung ist oder ein Programm dazwischen ist. JSON hätte den Scharm, dass das klarer definiert ist und es daher fertige Bausteine zum Auslesen der einzelnen Werte gibt (WagoAppJSON). Die Frage, wie die Datei, die Information auf den Controller kommen, ist aber fast wichtiger, weil das dass Dateiformat mitbestimmt. Für Rezeptdateien, CSV und TXT bietet sich FTP an, JSON würde man über http austauschen. Damit sind wir dann wieder bei der Frage, wer oder was die Gegenstelle/Datenquelle ist.
Auch wie oft sich die Werte ändern ist interessant. Für eine einmalige Initialisierung bei der IBN ist eine CSV/TXT/Rezeptur vermutlich am einfachsten.