Twincat3, Solution für mehrere Maschinen mit gemeinsamen FBs

 
Zuletzt bearbeitet:
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.
Zum Vergrößern anklicken....
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!? ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?
Zum Vergrößern anklicken....
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.
 
alb schrieb:
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 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.
Zum Vergrößern anklicken....

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):
Code: 
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:
Code: 
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:
Code: 
{attribute 'qualified_only'}
VAR_GLOBAL
    fbTestX : FB_Test;
    fbTestY: FB_Test;
END_VAR

Jetzt kommt dein Config-PRG ins Spiel:
Code: 
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
 
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.
 

Similar threads

S
Neuer Produktname + Neuer Hersteller Inverkehrbringen
2
Antworten
24
Aufrufe
13K
stevenn
S
X
WinCC Runtime für 2 Maschinen auf einem PC ?
Antworten
12
Aufrufe
3K
DeltaMikeAir
DeltaMikeAir
D
Sonstiges [Service Tool] PlcProgramLoader
Antworten
11
Aufrufe
623
blackpeat
B
J
WinCC "BackFillStyle" eines Buttons mit C oder VB anpassen
Antworten
6
Aufrufe
1K
leo
L
inray
SPS und IT-Kopplung mit wenigen Klicks!
Antworten
0
Aufrufe
730
inray
inray
Zurück
Oben