# Twincat3, Solution für mehrere Maschinen mit gemeinsamen FBs



## alb (25 Januar 2022)

Hallo,

ich habe eine Reihe von ähnlichen Maschinen. Die Steuerungen sind so strukturiert, dass etwa 90% der FBs gleich sind. Die Unterschiede zwischen den Maschinen stecken in den restlichen 10 %. Bisher hat jede Maschine ihre eigene Solution. Es wird aber langsam sehr aufwendig die Änderungen an den gemeinsamen 90 % in die diversen Einzel-Solutions zu übertragen. Besonders ungünstig ist folgendes Szenario:

Änderung an Maschine A. Projektdatei von A wird auf dem Server abgelegt. Bevor sich eine Gelegenheit ergibt, die Änderungen auf die Maschinen B und C zu übertragen, haben B und C bereits ihre eigenen Änderungen entwickelt. Dann sitzt man mit dem Projektvergleichstool und vergleicht A mit B und C, B mit C und A, C mit A und B. Dabei muss man jedes Mal prüfen, ob die Änderungen den maschinenspezifischen Teil betreffen (kein Problem) oder den allgemeinen Teil (übertragen, aufspielen, testen, freigeben). Das Skaliert sehr schlecht!

Mein erster Ansatz war es, die gemeinsamen FBs in eine Library zu packen, welche dann in die einzelnen Projekte eingebunden wird. Nachteil ist aber, dass bei Änderungen an der Library kein Onlinechange mehr möglich ist. Das würde die Entwicklungsarbeit sehr behindern.

Ich könnte mir Folgendes vorstellen:

Eine Solution mit mehreren Projekten. Ein Projekt pro Maschine, dass die Hardware und die Maschinenspezifischen FBs enthält. Ein Projekt mit den allgemeinen FBs. Alles in einer Solution. Das Szenario sähe jetzt so aus: Änderung an Maschine A, Vergleich mit der letzten Version auf dem Server. Im Projektvergleich sieht man direkt, ob sich die Änderungen auf das maschinenspezifische Projekt beschränken (-> einfach einchecken), oder ob allgemeine Programmteile betroffen sind (-> erstmal Nebenversion, einchecken nach Test auf den anderen Maschinen). Man musste nur noch einen Projektvergleich machen und könnte sich darauf verlassen, dass der allgemeine Teil wirklich immer gleich ist.

Problem: FBs aus anderen Projekten können nicht genutzt werden. Was im Allgemeinen auch irgendwie sinnvoll ist ;-)

Mit dem Beckhoff Variantenmanagement habe ich schon etwas herumexperimentiert, bin damit aber noch nicht richtig warm geworden. Das führt bei mir zu eher unübersichtlichen Konstrukten. Kann aber auch sein, dass ich das System ungeschickt benutze.

Wie handhabt ihr das? Da es immer viele Wege zum Ziel gibt, schreibe ich mal noch ein paar Worte zu meinen Randbedingungen und Überlegungen:

Versionsverwaltung mit Git.
Es sind Entwicklungsmaschinen, an denen häufiger Anpassungen vorgenommen werden. Know-How-Protection und Zugriffsschutz spielen keine große Rolle.
Entwicklung und Tests meist lokal an den Maschinen während Wartungs- und Stillstandszeiten.
Es sollte möglichst einfach und übersichtlich funktionieren. Besonders wichtig wäre mir, dass es für den Entwickler immer offensichtlich ist, ob er einen maschinenspezifischem FB oder an einem allgemeinen FB vor sich hat.
Bisher werden Änderungen an den gemeinsamen Programmteilen bei Gelegenheit auf die anderen Maschinen übertragen, getestet und dann freigegeben.
Bin für alle Tipps und Denkanstöße dankbar.

Lieben Gruß
alb


----------



## PN/DP (25 Januar 2022)

alb schrieb:


> Es wird aber langsam sehr aufwendig die Änderungen an den gemeinsamen 90 % in die diversen Einzel-Solutions zu übertragen.


Willst Du denn bei jeder FB-Änderung die Änderung in alle Maschinen weltweit einspielen??? Wie behältst Du da den Überblick, welche Programmversion tatsächlich in der Maschine Nr. xyz ist? Nach Auslieferung einer Maschine sollte das Programm nicht mehr von irgendwelchen sich später ändernden/weiterentwickelten Software-Teilen abhängig sein, sondern es sollte ein eigenständiges Projekt werden.

Harald


----------



## Stirni (25 Januar 2022)

Irgend einen Tod wirst du wohl sterben müssen. Ich bevorzuge die Variante:
Allgemeine FB's welche nicht für jede Maschine geändert werden müssen werden in ein oder mehreren Librarys gehalten, welche mit Git verwaltet werden.
Wenn eine Maschine hochgerüstet werden soll wird die entsprechende Lib installiert und hochgerüstet, anschließend neu eingespielt. Da jede Änderung innerhalb der Lib die Version erhöht, ist in Git alles sauber dokumentiert und kein Stand geht verloren.

-Stirni


----------



## Ludewig (25 Januar 2022)

Ich betreue ein Projekt mit ca. 30 Anlagen, es gibt nur *ein *Programm, das über eine sehr große Parameterdatei (DB) die spezifischen Funktionen an- oder abschaltet.
Leider gibt es 30 Hardwarekonfigurationen.


----------



## Stirni (25 Januar 2022)

@Ludewig Und was hat das mit den Fragen/Problemen von @alb auf sich?

-Stirni


----------



## Ludewig (25 Januar 2022)

Mach eine einzige Version daraus!


----------



## oliver.tonn (26 Januar 2022)

Ich würde das Variantenmanagement empfehlen, aber da bist Du ja nicht so wirklich glücklich mit. Was meinst Du mit unübersichtlichen Konstrukten? Ja, das mit den Pragmas ist zunächst etwas gewöhnungsbedürftig, aber bei entsprechender Kommentierung sollte das gehen. Das Variantenmanagement hat ja auch den Vorteil, dass Du, im gewissen Rahmen,  sogar unterschiedliche Hardware in einem Projekt haben kannst und unterschiedliche Verknüpfungen.
Ich kann es gerade leider nicht nachprüfen, aber ich meine, dass bei Änderungen an einer Bibliothek sehr wohl ein Online-Change möglich ist. Ist dieser nicht möglich, wäre er auch nicht möglich, wären die Änderungen direkt im Projekt ausgeführt worden.


----------



## JSEngineering (26 Januar 2022)

alb schrieb:


> Mein erster Ansatz war es, die gemeinsamen FBs in eine Library zu packen, welche dann in die einzelnen Projekte eingebunden wird. Nachteil ist aber, dass bei Änderungen an der Library kein Onlinechange mehr möglich ist. Das würde die Entwicklungsarbeit sehr behindern.


[...]


alb schrieb:


> Entwicklung und Tests meist lokal an den Maschinen während Wartungs- und Stillstandszeiten.


Widerspricht sich irgendwie.... erstens glaube ich auch nicht, daß pauschal eine Änderung an der Library ein Onlinechange unmöglich macht und zweitens: Die Anlage steht doch in der Regel, wie Du schreibst...



alb schrieb:


> Besonders wichtig wäre mir, dass es für den Entwickler immer offensichtlich ist, ob er einen maschinenspezifischem FB oder an einem allgemeinen FB vor sich hat.


Das ist doch ein Thema für die Namensgebung... Entweder die FBs enstprechend benennen oder in einen gemeinsamen Ordner packen im Projekt.



alb schrieb:


> Bisher werden Änderungen an den gemeinsamen Programmteilen bei Gelegenheit auf die anderen Maschinen übertragen, getestet und dann freigegeben.


"Eigentlich" müßte ich doch Änderungen sowieso zuerst an allen Maschinen testen, bevor ich sie als allgemeingültig für alle Maschinen erkläre. An einer Anlage ändern und hoffen, daß sie dann an den beiden anderen Anlagen auch funktioniert, finde ich gewagt.

Wenn die Maschinen sich doch so ähnlich sind, bin ich auch fast bei @Ludewig : Mach ein Projekt draus und parametrier die Anlagen.


----------



## alb (26 Januar 2022)

Hallo,

Onlinechange mit geänderten Bibliotheken ist tatsächlich möglich. Da habe ich bei meinem ursprünglichen Versuchen wohl irgendetwas Komisches getrieben. Danke für den Hinweis, das hilft mir sehr, denn ich hätte mich hier verrannt.
Die Variante: Ein Projekt pro Maschine, gemeinsame Teile in Library + Versionsverwaltungssystem erscheint mir erstmal als die flexibelste und beherrschbarste Lösung. Das Beckhoff Variantenmanagement werde ich mir trotzdem nochmal genauer ansehen.

Harald:
Das Einspielen in Maschinen weltweit ist kein Thema. Wie gesagt: Es geht um 6 bis 10 Maschinen in für den Eigenbedarf. Änderungen und Weiterentwicklungen gemeinsamer Programmteile auf alle Maschinen zu übertragen ist aber tatsächlich mein Ziel. Ich erhoffe mir davon, dass der Pflegeaufwand langfristig geringer wird, als wenn sich die Steuerungen immer mehr auseinander entwickeln. Wie man da das am besten macht und den Überblick behält, ist Teil meiner Frage ;-)

JSEngeneering:
Das ist nicht direkt ein Widerspruch. Ein Neustart wäre möglich da nichts Kritisches läuft. Es kann aber trotzdem aufwendig sein, die Maschine nach Neustart wieder in den Zustand zu bringen, den ich für meine Entwicklungsarbeit brauche.
Änderungen an Maschine A zu entwickelt und zu vertrauen, dass diese an Maschine B funktionieren halte ich auch für gewagt. Ziel muss es sein, immer einen genauen Überblick zu behalten, was in welcher Variante wo läuft, was sich beim Hochrüsten auf eine neuere Version ändert und was wie weit erprobt ist.
Derzeit halte ich die Variante Library + Versionsverwaltung für vielversprechend, zeigen wirds die Praxis.

Strike:
"Einen Tod muss man sterben", Die die Aussage passt. So iss es leider oft im Leben ;-)

Danke für alle Antworten!

Gruß Alb


----------



## Heinileini (26 Januar 2022)

alb schrieb:


> "Einen Tod muss man sterben", Die die Aussage passt. So iss es leider oft im Leben ;-)


 (1-mal am Ende von X) <> (n-mal in X) insbesondere für n >> 1


----------



## alb (27 Januar 2022)

ja, dass is mal was zum nachdenken!


----------



## Pippen (27 Januar 2022)

Library + Versionsverwaltung ist wirklich sehr gut. So machen wir das auch.

Wir haben eigentlich die komplette Logik in den Libraries. Im eigentlichen Programm ist nur die Instanziierung aller Objekt, das Initialisieren und Treiben aller Objekte. So kann man alle Logik Bausteine mit Unit Tests komplett testen.


----------



## alb (28 Januar 2022)

Pippen: Schön zu hören dass ihr damit gute Erfahrungen macht, dass bestärkt mich erstmal.


----------



## Hack (28 Januar 2022)

Außerdem bieten Bibliotheken die Möglichkeit sie an eine fixe Version zu binden. Du kannst also die neue verwenden wenn gewünscht, wenn die Maschine aber z.B. keine Probleme macht, kannst du auf dem alten Stand bleiben. Die Änderungen kannst du dann gemütlich bei einer Revision nachziehen und musst nicht bei der nächsten kleinen Störung ein riesen Update mit einspielen.

Ich denke eine Kombination aus Bibliotheken und Varianten Management macht Sinn.


----------



## IBFS (28 Januar 2022)

PN/DP schrieb:


> Wie behältst Du da den Überblick, welche Programmversion tatsächlich in der Maschine Nr. xyz ist?



BOSCH macht das sehr gut vor mit ihren Peripherals und Objekten im OpconPlus (Nexeed).
Dort sind alle Objekte in einem separatem Std-Ordner. In diesem Ordner können auch 
mehrere Versionen des gleichen Objektes sein. Inwieweit man das für sich nachbauen kann,
dieses Prinzip, weiß ich nicht, aber es ist der einzig sinnvolle Ansatz und bei OpConPlus
perfekt gelöst.


----------



## alb (31 Januar 2022)

@Hack und IBFS:
So langsam wird der Thread inhaltlich interessant, auf genau solche Dankanstöße habe ich gehofft.

Hack, wenn ich dich richtig verstehe, meinst du Folgendes: Im Projekt Library markieren, Rechtsklick Properties, bei Resolution anstatt * eine Versionsnummer einstellen (* bedeutet, immer neueste Version verwenden). Jetzt verwendet das entsprechende Projekt eine feste Version. Änderungen an der Lib betreffen das Projekt nicht, bis dort die neue Lib eingestellt wird. Das ist praktisch.
Ich sehe da noch folgenden Stolperstein: Die Versionsnummern werden in Twincat von Hand eingegeben. Wenn man seine lokale Änderung zentral ablegt, darf man nicht vergessen, die Nummer zu erhöhen. B.z.w es darf nicht passieren das zwei Entwickler gleichzeitig von v1.1 auf v2.2 gehen. Das wird bei mir nicht lange dauern 

IBFS, interessantes Beispiel wie so etwas in "Vollausbaustufe" aussieht. Man kann vermuten, dass die Leute von Bosch so ein System gebaut haben, weil sie vorher einige Ärgernisse und Lehrgelderfahrungen hatten ;-)


----------



## Hack (31 Januar 2022)

Ja, genau so kannst du eine fixe Version wählen. Meines Wissens gibt es keine automatischen Versionsnummern, müsste man sonst nochmals klären.
Ich würde das so verhindern, dass ich nicht für jede Änderung eine Version machen. Sondern gewisse Releases mache. Jemand muss das ganz ja auch testen. Wenn Entwickler A was ändert und Entwickler B zur gleichen Zeit weiß ja kein Mensch ob das zusammen funktioniert.


----------



## Brro87 (2 Februar 2022)

alb schrieb:


> Ich sehe da noch folgenden Stolperstein: Die Versionsnummern werden in Twincat von Hand eingegeben. Wenn man seine lokale Änderung zentral ablegt, darf man nicht vergessen, die Nummer zu erhöhen. B.z.w es darf nicht passieren das zwei Entwickler gleichzeitig von v1.1 auf v2.2 gehen. Das wird bei mir nicht lange dauern


Ich denke mit einer Kombination aus Versionverwaltung (z.B. GIT), mehreren nach Funktionalität aufgeteilten eigenen Bibliotheken und dem verwenden des Varianten Management sollte dies am Schluss selten der Fall sein. Wichtig ist dabei der richtige gleich konsequente Umgang mit der Versionverwaltung,.. also verwenden von Main/Master und Branches, Tags, usw... und das dies alle Immer gleich machen! 

*kleines Beispiel*
Entwickler A ändert FB_XYZ und setzt neue Version (1.0 -> 1.1) in Branch A. Pusht Branch A auf den Server
Entwickler B ändert FB_123 und setzt gleiche Version (1.0 -> 1.1) wie Entwickler A in seinem Branch B. Pusht Branch B auf den Server
Entwickler A nimmt seinen Branch und will diesen ins Main Mergen, Fetch/Checkout von Main, Kontrolle in History, Merge mit Branch A, Commit, tagt auf V1.1, pusht.
Entwickler B nimmt seinen Branch und will diesen ins Main Mergen, Fetch/Checkout von Main, Kontrolle in History, sieht neuen Tag von Entwicler A, ändert seinen Branch bzw. Version auf 1.2, Merge mit Branch B, Commit, tagt auf V1.2, pusht.

*Wichtig *Dies ist nur einer von n Anwendungsfällen wie man mit einer Versionverwaltung und Aufteilung von Forks, Branches, usw, arbeiten kann. Interessant für dich/euch wäre wohl auch das Thema Pull Request was z.B. sicher bei GIT Repos auf Azure DevOps untersützt wird. Siehe auch diese Seite auf der Bergiffe wie Fork, Branch, usw. erklärt sind,..  https://docs.microsoft.com/de-de/azure/devops/repos/get-started/key-concepts-repos?view=azure-devops


----------



## alb (3 Februar 2022)

Hallo,

@Brro87:

Die geschickte Verwendung von Git ist ein wichtiges Thema. Da sind wir noch in der Einarbeitung. Danke für das Beispiel! Mein bisheriger Kenntnisstand dazu: Es gibt eine unüberschaubare Vielzahl von Branchingmodellen und Workflows, von einfach bis sehr komplex. Diese haben, je nach Anwendungsfall, alle ihre Vor- und Nachteile. Das war im Forum schon einmal Thema, und ein User hatte eine Modellbeschreibung verlinkt, mit der er gut zurechtkommt:






						Versionsverwaltung/Projektmanagement SW mit Codesys
					

Hallo zusammen,  ich interessiere mich für revisionssichere Dateiablagen von Codesys Projektdateien. Momentan nutze ich Codesys 2.3 - die Projektdateien sind hier nur als binary-file (.pro) vorhanden. Eine direkte diff-Betrachtung kann zwischen zwei Commits hier leider nicht erfolgen.  Ich habe...




					www.sps-forum.de
				




So würde ich erstmal anfangen, bin da aber noch vollkommen unerfahren und versteh erstmal nur die Hälfte ;-). Verwendet ihr ein Standardschema, was irgendwo beschrieben ist?

@Alle: Evtl. sollte man zum Thema Git-Workflow mal einen eigenen Thread aufmachen, damit es nicht zu übersichtlich wird. Besteht da Interesse? Ich muss selber erstmal ein paar Hausaufgaben machen, bis sich da konkrete Fragen ergeben.

Zum Thema Library

Ich bin auf die erste Stelle gestoßen, wo das Konzept mit meinem Programmierstil kollidiert. Konfigurationsdaten behandle ich folgendermaßen:

Die Daten stecken in Structs. Anstatt einer globalen Konfigvariablenliste gibt es ein Programm "Configdaten" darin sind die Struct-Instanzen der einzelnen Anlagenteile als Output-variablendas deklariert (dadurch schreibgeschützt). Beim Start wird dieses Programm einmal ausgeführt und schreibt die Daten in die Struckts. Man kann in dem Programm übersichtlich und flexibel initialisieren (struckt in struct, aus datei, hartgecoded). Zugreifen kann man kann genauso wie auf eine globale Variablenliste. Ggf. sind die Structs als Array deklariert für "ConfigAnlagenteil[1..n]".
Der FB, der für den Anlagenteil zuständig ist, kriegt nicht die Configdaten übergeben, sondern nur die Nummer des Anlagenteils. Ab da „weiß“ er selber, wo er hingucken muss.
Ich würde das Konzept ungern verwerfen, denn es hat meiner Meinung nach viele gute Eigenschaften.

Problem: Das Programm Configdaten ist anlagenspezifisch, die FBs in der Library „kennen“ es also nicht. Mähhhh!

Mein Ansatz:
Anstatt der Library gibt es im Projekt einen Ordner für FBs die zum Projekt gehören, aber auch in anderen Projekten verwendet werden. Git wird so konfiguriert, dass es den Inhalt dieses Ordnert in den verschiedenen Solutions gleich hält.


----------



## Hack (3 Februar 2022)

Vielleicht hilft dir das weiter:


			Objekt Parameterliste


----------



## Brro87 (4 Februar 2022)

Eventuell noch spannend zum Thema Git Worklflows die folgenden Links,..
https://git-scm.com/docs/gitworkflows
https://git-scm.com/book/de/v2/Git-Branching-Branching-Workflows
https://docs.github.com/en/get-started/quickstart/github-flow
https://www.atlassian.com/de/git/tutorials/comparing-workflows
https://www.atlassian.com/de/git/tutorials/why-git
https://infos.seibert-media.net/display/Productivity/Git-Workflows+-+Der+Gitflow-Workflow
https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops


----------



## Brro87 (4 Februar 2022)

alb schrieb:


> Anstatt der Library gibt es im Projekt einen Ordner für FBs die zum Projekt gehören, aber auch in anderen Projekten verwendet werden. Git wird so konfiguriert, dass es den Inhalt dieses Ordnert in den verschiedenen Solutions gleich hält.


Ist eine Möglichkeit,. wäre im GIT dann wohl das Thema Submodule oder Externals.. löst aber meiner Meinung nach nicht die von dir gewünschten Probleme. Auch macht es die Verwendung von Submodule noch schwieriger durchzublicken wo was wie geändert und grundsätzlich herkommt.

Bei einem solchen Wechsel muss halt immer alles überdenkt werden. Ein Ersatz deiner Confog-Strukturen wäre das was @Hack bereits geschrieben hat, Verwendung der Objekt Parameterliste. Bei Verwendung des neuen TwinCat HMI wäre wohl dann eine Kombination aus Objekt Parameterliste und Rezepturverwaltung die Lösung. Schau dir in diesem Zusammenhang auch mal das Theam FB_Init & Co an. Auch ist das Variant Management zu empfehlen, zusammen mit den am Anfang gewöhnungsbedürftigen Pragmas und Einstellungen ist dies auch in Sachen verschiedener Konfigurationen bei den IOs sehr zu empfehlen.

Aber wie immer, denke daran - es führen mehrere Wege nach Rom und der Weg ist das Ziel!?


----------



## Brro87 (4 Februar 2022)

alb schrieb:


> So würde ich erstmal anfangen, bin da aber noch vollkommen unerfahren und versteh erstmal nur die Hälfte ;-). Verwendet ihr ein Standardschema, was irgendwo beschrieben ist?


Noch zur der Frage,.. da ich immer für diverse Kunden arbeite und jeder Kunde sein eigenes Schema anwendet habe ich schon viel gesehen und gebraucht. Meist ist die grundlegende Art gleich, aber die spezifische Verwednung abhängig von Server, Tool und den Erfahrungen (auch Alter ) der einzelenen Entwickler die sich bei der Einführung eingebracht haben. Eine dabei finde ich super Entwicklung ist weg vom GIT Repositiorie auf dem Firmenserver hin zum Online Repositiorie. Push, Commit, Merge, usw. immer überall möglich, man braucht nur Internet. Kein Kampf mit VPN, nicht freigegebenen Ports beim Kunden, usw. 

Ebenso (betreffend Satandardschema) verhält es sich beim Thema Verwendung von Pragma, Variant Managment aber auch den Bibliotheken. Die eine haben gern alles in einer Bilbiothek, andere gerne verschieden Funktions -und Anwendungsgebiet getrennte Bibliotheken welche im Extremfall die gleiche Grundfunktionen aus andere Bibliotheken mit Bibliotheksplatzhalter holen.


----------



## Stirni (5 Februar 2022)

alb schrieb:


> Hallo,
> 
> @Brro87:
> 
> ...



Hallo alb,
wenn ich das richtig verstehe, dann greifst du im FB auf das Programm zu (welches analgenspezifisch und somit nicht in der Bib ist, richtig)?

Hier eine mögliche Lösung für dich, wodurch du dein Konzept bei behalten könntest. Zumindest theoretisch:
FB_Test soll in die Bibliothek, also nicht anlagenspezifisch sein, aber konfigurierbar (nach deinen Vorstellungen):

```
FUNCTION_BLOCK FB_Test
VAR_OUTPUT
    uiId : UINT;
END_VAR
VAR_STAT
    (*
    Alle VAR_STAT Variablen gibt es bei allen FB_Test-Instanzen nur genau 1x
    d.h., wird uiInstanceCount z.b. verändert, verändert sich der Wert in ALLEN Instanzen von FB_Test.
    -> Das ganze kann und von Nutzen sein. InstanceCount wird pro Instanz hoch gezählt, jeder FB vergibt sich selbst
    also eine Nummer.
    Auf diese Nummer schaut er auch später bei den Konfigdaten. Diese werden als VAR_STAT behandelt, werden jedoch von
    außen vom Config-PRG beschrieben
    *)
    aConfig         : ARRAY[1..100] OF ST_Config;
    uiInstanceCount : UINT := 0;
END_VAR
```
Dazu einen FB_init:

```
METHOD FB_init : BOOL
VAR_INPUT
	bInitRetains : BOOL; // if TRUE, the retain variables are initialized (warm start / cold start)
	bInCopyCode : BOOL;  // if TRUE, the instance afterwards gets moved into the copy code (online change)
END_VAR


uiInstanceCount := uiInstanceCount + 1;
uiId := uiInstanceCount;
```

ST_Config enthält logischerweise deine Configdaten.


Ich definiere jetzt in einer GVL mehrere Instanzen des FB, welche dann im Config-PRG konfiguriert werden:

```
{attribute 'qualified_only'}
VAR_GLOBAL
    fbTestX : FB_Test;
    fbTestY: FB_Test;
END_VAR
```

Jetzt kommt dein Config-PRG ins Spiel:

```
PROGRAM PRG_Config
VAR
    tmpTest : FB_Test;
END_VAR


tmpTest.aConfig[GVL.fbTestX.uiId].xBla := TRUE;
tmpTest.aConfig[GVL.fbTestY.uiId].xBla := FALSE;
```
HINWEIS: Der "tmpTest" wird benötigt, um überhaupt Zugriff auf die VAR_STAT zu erhalten.
Der eigentliche Zugriff in einer Hochsprache (z.B. C#) wäre: FB_Test.aConfig[GVL.fbTestX.uiId].xBla := TRUE usw...

Somit hättest du das erreicht was du haben willst:
1. Der FB und seine Komponenten (ST_Config) sind in einer Bibliothek.
2. Konfigurierbar über ein PRG 

Es gibt aber auch Nachteile:
1. Zugriff auf eine VAR_STAT von außen (ist nicht dramatisch, jedoch unsauber)
2. (und dieser ist eher entscheidend Du musst alle Instanzen des Typs Global deklarieren um vom PRG aus Zugriff zu haben
   Das ist meistens fatal. Warum? Wenn du z.B. einen Stations-FB hast und diesen kopierst, weil du eine ähnliche Station hast, dann
  bleibt logischerweise die Instanz in dieser Station die gleiche, da global deklariert und nicht in dem Stations-FB
  -> Das lässt sich nur vermeiden , wenn pro Stations-FB ein Config-PRG geschrieben wird, und der FB_Test in der Station deklariert wird.
  -> Diese Lösung würde ich bevorzugen.

Vielleicht willst du das mal testen. Hoffe ich konnte es einigermaßen verständlich erklären, wenn Fragen sind einfach fragen

-Stirni


----------



## alb (23 Februar 2022)

Hallo,

Ich bin etwas still geworden um meinen eigenen Thread. Bei uns war eine Zeitlang Land unter an anderen  Baustellen, und dieses Thema ist ertmal "untern Tisch gerutsch". Deshalb antworte ich erst jetzt. 
@Brro87, Hack: Danke für den Lesestoff. Werde ich mir bei Gelegenheit zu Gemüte führen.
@Stirni: Danke! Sehr interessante Programmierstrategie.


----------

