Instanzen/Multiinstanzen?

[Sh4gr4th]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
wäre dankbar, wenn man mich diesbezüglich ein wenig aufklären könnte.
Will einige FBs (als AWL Quellen) programmieren, die oftmals die gleichen Variablen benutzen.
FB1 ist fertig und funktioniert auch. Dem FB1 habe ich jetzt am Ende der Quelle den InstanzDB DB1 zugeordnet, in dem die Variablen gespeichert werden.
Wenn ich jetzt den FB2 programmiere, wie geht das, dass die FB2 quasi auch die Variablen des DB1 mitbenutzt, oder muss ich für jede FB einen eigenen InstanzDB?
Ich denke mal, dass ich das nicht muß, aber dann hätte ich gleich noch eine Frage, wie ich das denn dann regel, dass der FB2 zwar die Variablen des DB2 nutzt, ich aber ja auch Variablen im FB2 habe, die ich im FB1 nicht brauche. Ist das Step7 so schlau, dass es die zusätzlichen Variablen dazuschreibt? Oder müsste ich quasi im FB1 sämtliche Variablen deklarieren, die in den restlichen FBs vorkommen?
Hoffe es ist verständlich, wo meine Frage liegt.

Programmiere in AWL, auf einer 300er, Siemens Step 7, Ver. 5.0 SP2,

 

[HeizDuese]

Bei Multiinstanzen kann man einen Baustein mehfach mit unterschiedlichen Datenbausteinen nutzen. D.h. eine FB 1 kann man mal aufrufen mit z.B. einem Instanz-DB 1, oder z.B. ein 2. mal mit beispielsweise dem Instanz-DB 2.
z.B.
call FB1, "Instanz-DB1"
call FB1, "Instanz-DB2"

Von "außen" kann man über den normalen DB-Zugriff auf die Daten zugreifen z.B. L "Instanz-DB1".Daten, wobei "Instanz-DB1" der symbolische Name des Instanz-DBs ist und "Daten" der symbolische Name der Variable in der Instanz.

Aus deiner Beschreibung werde ich noch nicht ganz schlau, vielleicht postest Du mal ein paar Zeilen deines Programms, damit es für mich verständlicher wird.

 

[Anonymous]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum muss man immer mit FBs programmieren? Mit FCs wäre ggf. das auch Problem zu lösen. Man projektriert einen x-beliebigen DB, der die Daten enthält, auf die dann in den FCs zugriffen wird.

Ich glaube, dass vielfach der Sinn und damit auch die Anwendung der Instanz-DBs nicht verstanden wird. Ein Instanz-DB ist immer dann ZWINGEND erforderlich, wenn LOKALE STATISCHE Variablen verwendet werden sollen, das geht nur innerhalb von FBs. Diese Erklärung ist zwar etwa so, wie von hinten durchs Auge in die Brust.

Aber wann verwendet man lokale statische Variablen? Z.B. dann, wenn man Zwischenergebnisse von einem in den nächsten Zyklus retten will und diese Zwischenergebnisse nur für die jeweilige Instanz des FBs Gültigkeit haben sollen.

Wann wendet man einen FB an? Immer dann wenn mehrere gleichartige Funktionsabläufe zwingend mit einem gleichen Algorithmus realisiert werden sollen und Zwischenergebnisse instanzbezogen gespeichert werden MÜSSEN, weil die Zwischenergebnisse im nächsten Zyklus wieder angewendet werden. Hiebei fällt jedoch in den meisten Fällen die Arbeit an, eine Initialisierung für den erstmaligen Durchlauf einer Instanz zu projektieren.

Haben Zwischenergebnisse nach Verlassen des FBs ihre Bedeutung verloren, so kann der Funktionsablauf auch mit einem FC realisiert werden. Zwischenergebnisse werden dann dynamisch auf den Stack gespeichert und sind nach Verlassen des FCs ohne Bedeutung.

Will man z.B. mehrere unterschiedliche FCs nutzen, dabei den Zugriff auf gemeinsame Daten haben und insgesamt mehrere Instanzen von diesem System erstellen, dann geht das ganz simpel, indem man den FCs z.B. die Nummer des gemeinsamen Datenbaustein als Parameter übergibt.

Beispiel:
Es sollen die Funktionsaufrufe FC1, FC2 und FC3 jeweils unterschiedliche Aufgaben einer Gesamtaufgabe erfüllen. Der Typ der Gesamtaufgabe ist einem Projekt 4 mal vorhanden.

Lösung:
Es werden die Datenbausteine DB10, DB20, DB30 und DB40 jeweils mit der gleichen Struktur angelegt. Die FCs werden so projektiert, dass ihnen die Nummer des Datenbausteins entsprechend der jeweiligen Instanz als Parameter übergeben werden kann. Es folgt die 1. Instanz einer Sequenz, welche die Aufrufe für den FC1, FC2 und FC3 ausführt, bei dem jeweiligen Aufruf wird der Parameterwert 10 übergeben, danach folgt die 2. Instanz einer Sequenz, als Parameterwert wird 20 übergeben, bei der 3. Instanz wird der Wert 30 und schließlich bei der 4. Instanz der Wert 40 übergeben.

Die o.g. Vorgehensweise ist nur ein Ansatz für einen Lösungsweg, ich würde jedenfalls wenn sich immer die gleiche Sequenz der Aufrufe von FC1, FC2 und FC3 ergeben würde, darüber nachdenken und die in den FC1, FC2 und FC3 verpackten Funktionsabläufe in einen FC oder ggf. in einen FB zusammenfassen.

Barnee

 

[Sh4gr4th]

Uff, da werde ich ja wieder mit Informationen erschlagen
Danke erstmal.
Eine kleine Frage nur noch, ich kann doch auch statt
call FB1, "Instanz-DB1"
call FB1, "Instanz-DB2"

verschiedenen Funktionen den gleichen DB zuordnen, oder?
Also:
call FB1, "Instanz-DB1"
call FB2, "Instanz-DB1"
Das ist eigentlich nur was ich brauche, durch die Erklärung von Barnee habe ich eingesehen, dass ich das mit den Instanzen mal so gar nicht verstanden hatte und ich die auch nicht wirklich brauche. Mir reicht ein DB, indem die Variablen gespeichert sind.

 

[Ralle]

@Sh4gr4th
Das geht nicht.
Wenn du auf die gleichen Variablen zugreifen willst, dann nimm einen globalen DB, definiere deine Variablen darin und öffne diesen DB im FB1, FB2, ... zum lesen und schreiben.

@HeizDuese
Es ist nicht unbedingt ratsam, von "außen" auf Instanz-DB zuzugreifen. Es geht natürlich, aber bei jeder Änderung an der FB-Schnittstelle, ändern sich die Adressen der Variablen im Instanz-DB und man muß das gesamte Programm "nachbasteln".

 

[Sh4gr4th]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hm, das ist ja schade dass das nicht geht. Sehr ärgerlich sogar, macht mir einen Strich durch sämtlich Ideen , die ich hatte....

Wie ist das denn dann mit den Output-Variabeln, die ich in der AWL Quelle deklariert habe, wie erkläre ich dann dem FB, dass er beispielsweise die jetzige Output Variable(Istwert oder Busy), aus dem DB nimmt?
Oder auch die Eingangsvariablen? Die hab ich ja oben in der AWL Quelle bei Input deklariert, beispielsweise Spindeladresse?
Muss ich die alle extra im FB in meinem DB abspeichern bzw. herausladen und dann zu den Variablen meiner Funktion transferrieren, also quasi zu Fuß? Genau das dachte ich könnte ich umgehen, wenn ich mit so einem InstanzDB arbeite, aber das bin ich wohl am Thema vorbeigerauscht, was so ein InstanzDB für eine Funktion hat...

 

[Ralle]

Input-, InOut-, und Outputvariablen trägst du ohnehin außen an den FB/FC an. Die tauchen zwar bei einem FB im Instanz-DB auch mit auf, aber sie kommen ja über die FB-Schnittstelle rein und raus. Wenn du also an jeden FB/FC die gleichen Variablen (aus einem DB oder Merker) anträgdt, wird auch mit diesen gearbeitet. Aber Vorsicht, Output-Variablen müssen unbedingt im FB/FC zugewiesen werden, sonst ist ihr Wert am Ausgang undefiniert. InOut-Variablen sind Durchgangsvariablen (wohl am Besten geeignet) die am Anfang im FB eingelesen und am Ende wieder ausgelesen werden.

 

[Anonymous]

@Sh4gr4th
Du solltest dir die Unterschiede zwischen FBs und FCs klarmachen. Der wesentlichste Unterschied zwischen diesen beiden Bausteinarten ist, dass ein FC KEINE statischen Variablen speichern kann! Werden für die Realisierung eines Algorithmus keine statischen Variablen benötigt, dann macht es in den meisten aller Fälle für die Realisierung keinen Unterschied ob ein FB oder ein FC verwendet wird, wenn man von der Ausnahme absieht, dass ein FB IMMER einen Instanz-DB benötigt, ein FC dagegen NICHT. Und wenn die Realisierung auch mit einem FC erfolgen kann, dann ist diese Art der Realisierung vorzuziehen, weil somit keine zusätzlichen Resourcen gefressen werden. Bei kleineren Programmen mag das so nicht ins Gewicht fallen, aber bei größeren Programmen, die auf kleinen CPUs laufen, kann das schon einen Gewinn bringen, einen FC anstatt eines FBs zu verwenden.

Ein Umsteiger von S5 auf S7 sollte sich merken, dass die Funktionalität eines S5-FBs IMMER in einem S7-FC realisiert werden kann, dagegen ist ein S7-FB nur äußerst selten auf einem S5-FB übertragbar.

Wie auch schon in diesem Thread angedeutet wurde, sollte ein Instanz-DB wie eine heilige Kuh behandelt werden, d.h. da ich keine heiligen Kühe mag, verwende ich FBs nur dort, wo es wirklich angebracht ist.

Wenn in deinem Fall zwei unterschiedliche FBs den gleichen Instanz-DB verwenden sollen, dann MUSS die Schnittstelle dieser beiden FBs völlig identisch aufgebaut sein, sich auf eine solche Konstruktion einzulassen, halte ich aber für eine waghalsige Aktion, wenn man dann Inhalte des Instanz-DBs anderswo manipulieren will.

Ich möchte das auch noch unterstreichen, was Ralle zu den OUT-Variablen geschrieben hat, d.h. es müssen immer ALLE OUT-Variablen mit einer Zuweisung bearbeitet werden, bevor die Programmbearbeitung in einem FB/FC beendet oder auch vorzeitig abgebrochen wird.

Gruß Barnee

 

[Sh4gr4th]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, danke, ist mir jetzt auch klar geworden, dass ich den InstanzDB missbraucht hätte.
Aber du schreibst ich kann in einer FC keine statischen Variablen speichern. Das heißt doch nicht etwa, dass ich aus einer Funktion heraus keine Werte in einen DB meiner Wahl abspeichern kann? Nee, damit sind jetzt wirklich nur speziell die Variablen die auch innerhalb der Funktion deklariert werden gemeint, richtig?
Dann werde ich mit FCs auskommen (glaube ich jetzt zumindest noch nach den ersten Überlegungen) und mir einen DB erstellen, auf den alle FCs ihre Daten ablegen können und dürfen.

 

[Ralle]

Du kannst in einem FC Daten speichern soviele du willst und in den DB in den du sie haben willst. In einem FB können intern statische Variablen deklariert werden, die dieser dann in seinem Instanz-DB ablegt. Die gibt es in einem FC nicht. Deswegen können aber trotzdem FC und FB immer Daten in andere Datenbausteine schreiben und lesen.

 

[Anonymous]

@Sh4gr4th
Es ist ganz einfach. Es geht um lokale statische Variablen. Bezogen auf eine Hochsprache ist das eine Konstruktion, die es dort schlicht weg nicht gibt!
Beispiel: INNERHALB einer C-Funktion werden lokale Variablen angelegt und verwendet. Diese Variablen sind NUR innerhalb der Funktion sichtbar, deswegen sie auch nur LOAKELEN Einfluß. Nach Verlassen der Funktion, haben diese Variablen ihre Bedeutung verloren und somit auch nicht mehr adressierbar! Werden für das Speichern Variablen benötigt, die auch nach dem Verlassen Bestand haben sollen, dann MÜSSEN diese Variablen GLOBAL angelegt sein, weil sie damit für die Funktion, die diese verwendet, einen STATISCHEN Charakter aufweisen müssen.

Aber bei der S7 kann ich nur entfernte Ähnlichkeiten zu einer Hochsprache herstellen. Und leider ist die Semantik bei Siemens oft nicht sehr präzise :evil: :evil: Daher kommen leider die Verwirrungen bei der Frage, wann muss ich einen FB programmieren und wann kann ich einen FC-Typ anwenden. Eine Variable, die nach VAR bei der Schnittstellendefinition eines FBs definiert wird, stellt IMMER eine GLOBALE Variable dar, obwohl es sich angeblich um eine LOKALE Definition handelt. Denn die Variablen dieses Typs werden in einem Instanz-DB gespeichert, der die gleichen Eigenschaften wie ein GLOBALER DB hat, das Kind hat nur einen anderen Namen bekommen. Und globale DBs sind in der S7 IMMER statisch. Der Unterschied zwischen statisch und dynamisch liegt darin, dass statische Variablen in einem Speichermodell (fast) immer die gleiche Adresse einnehmen, während dynamische Variablen auf dem Stack abgebildet werden und nach Verlassen der Funktion nicht mehr sichtbar sind.

Man kann in der Schnittstellendefinition eines FCs auch das Schlüsselwort VAR verwenden, was zu der Annahme verleitet, man könne statische Variabel anlegen. Die Annahme ist schlicht weg falsch! Bei der Übersetzung des FCs werden die Variablen, die hinter VAR definiert wurden, implizit zu dynamischen Variablen gewandelt, die normalerweise hinter dem Schlüsselwort VAR_TEMP definiert werden!

Verschiedene Instanzen des gleichen FCs können explizit auf unterschiedliche den jeweiligen Instanzen zugeordnete globale Variablen zugreifen, wenn dies beim Aufruf des FCs durch Parameterübergabe bekannt gemacht wird, dazu gibt es verschiedene Möglichkeiten, eine davon hatte ich schon einmal weiter oben beschrieben.

Ich nehme mal an, dass die die Daten deines Projektes wirklichen globalen Charakter haben, dann sollten diese auch in einem GLOBALEN Datenbaustein abgelegt werden. Die Tatsache, dass ein Instanz-DB natürlich auch einen globalen Charakter hat, sollte dich nicht dazu verleiten, die dort gespeicherten Daten im wirklichen globalen Sinne zu verwenden und zu manipulieren. Das ist was für Trickser und man sollte auch an die Menschen denken, die vielleicht einmal ein solches Programm warten müssen. Ich habe für mich die Regel aufgestellt, die Daten eines Instanz-DBs nur lokal innerhalb des FBs anzuwenden, dem diese zugeordnet sind. Und das deshalb weil es mit großem Ärger verbunden sein kann, wenn man die Schnittstelle des FBs ändert und dabei vergisst ggf. das Programm in dem FB entsprechend anzupassen.

Gruss Barnee

 

[Sh4gr4th]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Barnee
Ja, vielen Dank nochmal für die umfangreiche Erklärung. Zottel hatte mir vor einigen Tagen schonmal statische Variablen & Co. erklärt, aber nicht ganz so ausführlich. Deine Erklärung hat mich bestätigt, dass ich das zumindest schon verstanden hatte. Jetzt sehe ich klar und wie weiter oben schon beschrieben wird für mein Projekt das Erstellen eines globalen DB ausreichend sein.
Bin irgendwie auf die Instanzen und FBs gekommen, weil ich das genau anders verstanden hatte, nämlich dass sich mehrere FB´s einen DB teilen und nicht eine FB auf unterschiedliche Instanzen (Multiinstanzen) zugreifen kann. Jetzt ist mir das aber eingeleuchtet, (gerade auch durch deine Erklärung) wo der Sinn und Zweck hinter diesen Multiinstanzen stehen.
Schönes Wochenende!

 

[argv_user]

static in C

@Barnee
In C-Funktionen gibt es natürlich statische Variablen:
zb:

int nextvalue(void)
{
  static int value;
  return value++;
}

 

[Anonymous]

@argv_user

Erwischt! Du hast recht, das hatte ich schon vergessen, da ich kein Freund von in einer Funktion deklarierten statischen Variablen bin. Mein Prinzip: so wenig wie möglich globale Variablen und Funktionen nur so viel wie nötig spezialisieren. Aber dieser Typ der statischen Variablen ist mit dem "ähnlichen" Typ auf der S7 nicht vergleichbar, da in C eine solche Funktion meist auf einen Anwendungsfall spezialisiert wird, was bei einem S7-FB "normalerweise" nicht der Fall sein sollte.
1:0 für dich.

Gruß Barnee

 

[Torsten05]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hall o,

das ist eigentlich ein typischer Fall für Multiinstanzen. Du erstellst einen FB2, und deklarirest eine Variable vom Typ "FB1", und alle Variablen die du halt im FB2, aber nicht im FB1 brauchst.. Der FB2 wird z.B. vom OB 1 aufgerufen und in dem InstantzDB von FB2 stehen alle Variablen die du deklariert hast, plus den Variablen von FB1.

Torsten

 

[Anonymous]

@Torsten05

Ein echter Fall für Multiinstanzen? Wirklich? Ich würde an deiner Stelle noch mal nachlesen:
http://www.automation.siemens.com/doconweb/pdf/SINUMERIK_SIMODRIVE_0405_D/S7_gs.pdf?p=1

 

[Torsten05]

Hallo,

also ich weiss ja nicht was er mitlerweile macht, aber ich habe es so verstanden das er fbs mit unterschiedlichen Instanzen aufrufen möchte, aber in einem Baustein arbeitet, indem er zwar die Variablen der Instanzen braucht, aber nicht umgekehrt. Wofür das nun auch sein soll ist mir erstmal egal. Er würde jedenfalls im FB2 die Instanz vom FB1 stehen haben, plus der zusätzlichen Variablen die er gerne hätte. Natürlich würde das auch mit nem globalem gehen, aber genau für diesen Fall ist doch wohl die Multiinstanz geschafffen oder wofür nutzt man die sonst?

Torsten

 

[Anonymous]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Torsten05
Zum ersten wäre doch mal die Frage zu beantworten: Was steht in einem Instanz-DB? Auf einen einfachen Nenner gebracht: Ein Instanz-DB spiegelt die Schnittstelle zu einem FB wieder.
Ein FB beinhaltet normalerweise einen Algorithmus, der mehrfach angewendet werden soll. Wird ein und der gleiche FB n mal angewendet, dann wären "normalerweise" n mal verschiedene Instanz-DBs erforderlich.
Annahme: eine FB mit dem Objektnamen FB1 soll 5 mal angewendet werden, dann wären z.B. die Instanz-DBs DB1...DB5 zu projektieren, wobei die Objektnamen (DB1...DB5) willkürlich gewählt werden können. Kommt jetzt noch z.B. ein zweiter FB namens FB2 dazu, der ebenfalls 5 mal angewendet werden soll, dann wären weitere 5 Instanz-DBs fällig, die der Schnittstellenbeschreibung des FB2 entsprechen. Damit würde sich dieser Mechanismus zu einem Resourcenfresser entwickeln.

Der Ausweg aus dem Dilemma verspricht das Zauberwort Multiinstanzen. Man kreiert einen übergeordneten FB (z.B. FB10), dem natürlich auch ein Instanz-DB an die Seite gestellt werden muss. Jetzt kann man innerhalb des übergeordneten FB10 die bereits oben erwähnten FBs (hier FB1 bzw. FB2) beliebig oft anwenden, ohne für diese entsprechende Instanz-DBs zu projektieren, dies gilt aber nur dann, wenn die jeweilige Instanz des FB1 bzw. des FB2 in der Schnittstelle des übergeordneten FB10 angegeben wird. Wird wie in der obigen Annahme der FB1 5 mal angewendet, so sind 5 Einträge in der Schnittstelle des übergeordneten FB10 erforderlich. In den Distanz-DB des übergeordneten FB10 werden die Schnittstellenbeschreibungen aller eingeschlossenen FBs übernommen, sofern auf diese eingeschlossenen FBs in der Schnittstellenbeschreibung des übergeordneten FB10 die Verweise eingetragen wurden. In einem Multiinstanz-DB wird genau n mal die Schnittstellenbeschreibung eines FBs eingetragen, wenn n Instanzen dieses FBs eingeschlossen sind.

Er würde jedenfalls im FB2 die Instanz vom FB1 stehen haben, plus der zusätzlichen Variablen die er gerne hätte. Natürlich würde das auch mit nem globalem gehen, aber genau für diesen Fall ist doch wohl die Multiinstanz geschafffen oder wofür nutzt man die sonst?

Die Instanz-DBs werden von der IDE angelegt, in Step7 V5.3 (ich nehme an, früher auch schon nicht, hab's nie probiert) sind diese nicht editierbar und entziehen sich somit dem Manipulationswunsch eines Programmierers. Wird die Schnittstelle eines FBs geändert, so muss(müssen) der(die) Instanz-DB(s) NEU angelegt werden. Damit ist eine "missbräuchliche" Verwendung ausgeschlossen.

 

[Torsten05]

Hallo,

ich kann da immer noch keinen Widerspruch zu meinen Aussagen sehen. Die Multiinstanz macht das, was er IMO! machen möchte. Ob er nun den FB1 1 oder 12 mal aufruft ist egal. Es ist auch egal ob Siemens das ganze nur für n Aufrufe von FB 1 vorgesehen hat. Step7 meckert zum Glück nicht wenn man die Möglichkeiten nicht für die Zwecke nutzt für die es gedacht war. Er erreicht jedenfalls das was er IMO möchte. Aber vielleicht habe ich den ersten Beitrag nur nicht richtig verstanden. Keinen Ahnung...

Torsten

 

[Anonymous]

@Torsten05

Die Struktur eines Instanz-DB wird von der IDE angelegt und entzieht sich somit zusätzlichen Gestaltungswünschen des Programmierers. Man kann nur indirekt die Struktur eines Instanz-DB beeinflußen, nämlich bei der Schnittstellenbeschreibung eines FBs.

Nehmen wir mal an, es würden zwei unterschiedliche Algorithmen existieren, der erste wäre im FB1 und der zweite im FB2 verpackt. Jetzt würde der FB10 gestaltet, in dem zuerst der FB1 und danach der FB2 aufgerufen werden soll. In der Schnittstelle des FB10 werden die Instanzen des FB1 und FB2 bekanntgegeben. Die IDE legt dann die Struktur des Instanz-DBs fest, der für den FB10 eingerichtet werden muß, dabei werden die Schnittstellenbeschreibungen für den FB1 und FB2 auf unabhängige Datenpunkte gelegt.

Nehmen wir weiter an, es wäre in dem obigen Beispiel beabsichtigt, über statische Variablen Ergebnisse auszutauschen. So würde z.B. hinter VAR im FB1 z.B. die Variable "XYZ_von_FB1" eingerichtet, in der ein Ergebnis gespeichert werden soll, das vom Algorithmus des FB1 geliefert wird. So kann man vom FB2 aus auf diese Variable zugreifen. FB2 ist in diesem Falle spezialisiert, was bedeutet, dass von FB2 keine weitere unabhängige Instanz mehr angewendet werden kann.

Eine andere Variante wäre, den Austausch von Daten bei der Schnittstellenbeschreibung der Bausteine FB1 und FB2 durch entsprechende Ausgänge bzw. Eingänge zu berücksichtigen, sowie in der Schnittstellenbeschreibung des FB10 die erforderlichen statischen Variablen anzulegen, z.B. "XYZ_von_FB10". FB1 sollte dann ein Ergebnis liefern, das von FB1 über einen entsprechenden Ausgang in der Variablen "XYZ_von_FB10" abgelegt wird. FB2 liest über einen entsprechenden Eingang den Inhalt von "XYZ_von_FB10" und wendet die Date weiter an. Nehmen wir mal weiter, an FB1 und FB2 würden wegen dieser hier beschriebenen Möglichkeit des Datenaustauschs selbst KEINE statischen Variablen mehr benötigen (temporäre Zwischenergebnisse bedingen nicht die Notwendigkeit von statischen Variaben), so ergibt sich sofort die Möglichkeit die Algorithmen von FB1 und FB2 in FCs zu verpacken, womit zumindest für diese Ebene sofort die Notwendigkeit von Instanz-DBs entfällt!!!!!!! Da der FB10 nur die äußere Schale darstellt, um jeweils eine Instanz von nunmehr FC1 und FC2 anzuwenden, hat die Variable "XYZ_von_FB10" nur noch eine temporäre Bedeutung, was sie ohne hin bisher auch nur hatte! Aber hallo, dann kann ja der ganze Mechanismus des FB10 auch mit einem FC10 realisiert werden, aus "XYZ_von_FB10" wird "XYZ_von_FC10" und ist eine temporäre Variable, die auf dem Stack abgelegt wird und SCHWUPPS: jetzt haben sich allen Notwendigkeiten von Instanz-DBs in Luft aufgelöst.

Gruß Barnee