TIA Prüfen ob eine Instanz in einer Multiinstanz noch existiert

Zuviel Werbung?
-> Hier kostenlos registrieren
Man könnte innerhalb des Bausteins den aktuellen Zeitstempel für die jeweilige Instanz ablegen. Dann könnte man (in einer Schleife) alle Zeitstempel prüfen und wenn älter als x die "Bereinigung" vornehmen. Das würde ich dann aber schon in einem separaten Baustein machen, zur Not noch einen globalen Zeitstempel für die letzte Bereiningung um dieses nicht x-mal in einem Zyklus machen zu müssen.
 
Wer vergibt die Nummer, also den Index des ArrayElements? Wenn aus dem Array doch Elemente gelöscht werden sollen und anschliessend das Array sortiert werden soll, dann ändern sich hierduch ggfs die Zuordnungen von Instanz und ArrayIndex!
Der Programmierer halt...
Man hat halt z.B. ein Array für 100 Messungen. Die nicht benutzten sind halt Reserve... große Anlagen kriegen halt ein Array mit 1000 oder 10000 Elementen...
Doppelt vergebene Nummern lassen sich für mein Verständnis nach dem beabsichtigten Verfahren nicht feststellen und wären eine zusätzliche "Baustelle".
So groß ist die Baustelle nun auch wieder nicht ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Baustein der seinen Namen mit GetInstancePath holt, könnte diese Information in seinen eigenen Daten speichern. Und wenn sich sein eigener Name ändert, an die übergeordnete Instanz melden "bitte alten Namen aus Liste löschen" und danach "bitte neuen Namen in Liste eintragen".
 
Ich sehe schon, wir beide verstehen uns, @Oberchefe, aber ich verstehe weiterhin @spsqem nicht so richtig ...

Ein Array, in dem ausschliesslich die Präfixe eingetragen werden, ohne die Möglichkeit, dazu weitere Informationen abzulegen?
Das wäre für mich irgendwie undenkbar bzw. zu viel Aufwand für zu wenig Sinn und Zweck.

So groß ist die Baustelle nun auch wieder nicht ;)
Das wollte ich damit auch nicht gesagt haben, ducati.
Mir ist immer noch nicht so richtig klar, was @spsqem eigentlich genau beabsichtigt.
Wenn ich die Absicht hätte, auf nicht mehr benötigte Präfixe hinzuweisen, würde ich nicht aus der Liste jegliche Spur auf diese Präfixe löschen wollen.

Versehentlich doppelt belegte Instanzen entlarven zu können, fänd ich absolut wichtig genug, um die "zusätzliche Baustelle" zu rechtfertigen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Baustein der seinen Namen mit GetInstancePath holt, könnte diese Information in seinen eigenen Daten speichern. Und wenn sich sein eigener Name ändert, ...
:unsure: Das überfordert jetzt meine Fantasie, Thomas.
Woran erkennt ein Baustein, ob er derselbe ist, der zuvor unter einem anderen Namen aufgerufen wurde?
Meinst Du, wenn zwei Bausteine denselben Pfad nachweisen können?
Ich muss dabei irgendwie an Münchhausen denken, wie er sich selbst am eigenen Schopf aus dem Wasser zieht. ;)
 
Der Baustein der seinen Namen mit GetInstancePath holt, könnte diese Information in seinen eigenen Daten speichern. Und wenn sich sein eigener Name ändert, an die übergeordnete Instanz melden "bitte alten Namen aus Liste löschen" und danach "bitte neuen Namen in Liste eintragen".

Wird dann aber interessant beim Reinitialisieren.
 
Versehentlich doppelt belegte Instanzen entlarven zu können, fänd ich absolut wichtig genug, um die "zusätzliche Baustelle" zu rechtfertigen.
Naja... man könnte das automatisch prüfen. Muss man aber nicht, da es ja in der Regel ne Inbetriebnahme gibt, bei der dann schon auffallen sollte, wenn eine Instanz Quatsch macht.
Bei mir sind solche Instanzen auch nicht wirr über die ganze Software verstreut, sondern jede Instanz krigt ein eigenes Netzwerk aufsteigend in nem FC. Also Instanz 47 wird im Netzwerk 47 aufgerufen...
Aber kommt dann im Einzelfall drauf an, was man eigentlich konkret machen will/muss...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hatte zwar nicht vor großartig auf die Applikation einzugehen, aber anscheinend ist dies notwendig für eine Lösungsfindung oder zumindest damit kein Unmut im Forum entsteht :)
Also diese Präfixe werden in einem VB Skript verwendet um die Visualisierung zu dynamisieren.
Konkret heißt das; es gibt ein Bild in dem jeder Aufruf eine Teil-Visualisierung in diesem Bild darstellt. Was das genau ist, ist zweitrangig. Ich habe es schon umgesetzt, es funktioniert und wird eingesetzt.

Ein Beispiel wie das Konzept funktioniert:

Globaler DB mit Präfixen:
PräfixArray[1] := "FB_BausteinAufrufInstanz1"
PräfixArray[2] := "FB_BausteinAufrufInstanz2"
... usw.

Im VB-Skript nehme ich nun diese Präfixe her und baue mir mit den jeweiligen Suffixen den gesamten symbolischen Variablennamen zusammen, die in den jeweiligen Instanzen vorhanden sind.

VB-Skript:
Dim Variable1

Variable1 = smarttags(PräfixArray[1] & ".HmiVariable1")

If Variable 1 = 1 then
screenitems("IrgendeinBildobjekt").height = irgendwas

... bla bla bla usw.

Wir müssen an dieser Stelle auch keine Diskussion lostreten weshalb ich dies mit VB Skripten realisiert habe und keine Faceplates verwende.
Es gibt verschiedene Gründe dafür, aber der wichtigste ist, dass sich die Art der Dynamisierung mit Faceplates gar nicht umsetzen lässt. Ich habe es getestet und es hat absolut nicht funktioniert.
 
Zuletzt bearbeitet von einem Moderator:
Das Verfahren als solches ist klar, haben wir auch so ähnlich mal angewandt. Allerdings hatten wir beim SPS-Anlauf die entsprechenden Initialisierungen drin.
Ist im Prinzip ein weiterer Baustein, der ja sehr wahrscheinlich rückwirkungsfrei integriert werden kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hatte zwar nicht vor großartig auf die Applikation einzugehen, aber anscheinend ist dies notwendig für eine Lösungsfindung oder zumindest damit kein Unmut im Forum entsteht :)
Nein, niemand soll hier verleitet werden, seinen konkreten AnwendungsFall, das komplette Umfeld, BetriebsGeheimnisse oder was auch immer preiszugeben.
Manchmal bis oft ist es jedoch hilfreich, das Umfeld ein wenig abzuklopfen, um die Aufgabenstellung besser bzw. überhaupt zu verstehen oder zumindest zu erahnen.
Jeder von uns hat ganz unterschiedliche Erfahrungen und (Spezial-)Kenntnisse.
Da unsere GlasKugeln unterschiedlich gut trainiert sind, mag der eine schon den ersten Beitrag richtig deuten, während ein anderer bis zum letzten Beitrag nur Bahnhof versteht.

1. Das Kriterium, das Dir sagt, "die Instanz XY wird benutzt", ist mir klar.
2. Das Kriterium, das Dir sagt, "die Instanz XY wird neuerdings benutzt (= wurde bisher nicht benutzt)", ist mir auch klar. Aber nach diesem Fall fragst Du gar nicht.
3. Welches Kriterium hast Du, das Dir sagt "die Instanz XY wird nicht mehr benutzt"? Das ist mir nach wie vor ein Rätsel.

Eine Instanz, die aufgerufen wird, ermittelt ihren Pfad und kann die Liste (das Array) durchsuchen, ob ihr Präfix dort eingetragen ist.
- Ist es eingetragen, so ist für Dich der Fall erledigt. Der FB kann sich seiner eigentlichen Aufgabe widmen.
- Ist es nicht eingetragen, so interessiert Dich das anscheinend nicht (?) und der FB kann sich ebenfalls seiner eigentlichen Aufgabe widmen.

Eine Instanz, die nicht aufgerufen wird, kann nicht ihren Pfad und Präfix ermitteln und auch nicht ein evtl. Vorhandensein in der Liste prüfen, geschweige denn einen Eintrag in der Liste löschen und die Liste danach Sortieren. Was also tun?

Z.B. könnte in einer einzigen der Instanzen eine SonderFunktion[-alität] aktiviert werden, so dass diese Instanz mehr tut, als die anderen Instanzen. Wird aber ausgerechnet diese Instanz nicht mehr benutzt, so steht man im Regen.
Darum schwebt mir vor, die erste in einem "Zyklus" benutzte Instanz bekommt diesen SonderStatus.
Was das für ein Zyklus sein könnte, weiss ich nicht. Vielleicht ein OB1 Zyklus?
Verwaltet werden müsste dieser Zyklus z.T. ausserhalb der FB-Instanzen, indem das "zentrale" ZyklusErster-Bit gesetzt wird.
Jede aufgerufene Instanz kopiert das "zentrale" ZyklusErster-Bit in eine lokale Variable zur späteren Verwendung und löscht das "zentrale" ZyklusErster-Bit.
Ist das "lokale" ZyklusErster-Bit TRUE, so wird in dieser Instanz die SonderFunktion[-alität] aktiviert.
Sie geht den belegten Bereich des Array durch und prüft, ob das Benutzt-Bit (das zusätzlich zum Präfix vorhanden sein muss) bei einem der belegten ArrayElemente FALSE ist.
Falls das Benutzt-Bit=TRUE ist, wird es gelöscht und die Prufung mit dem nächsten ArrayEintrag fortgesetzt.
Falls es FALSE ist, wird der Eintrag im Array gelöscht und das Array sortiert.
Vermutlich genügt es, den erstbesten Eintrag mit dem Kennzeichen Benutzt-Bit=FALSE zu löschen und weitere Einträge mit diesem Kennzeichen erst in folgenden Zyklen (nach und nach) zu löschen.
Im "allgemeinen" Teil der FB-Instanz kommt hinzu, dass das Benutzt-Bit bei dem Eintrag, bei dem sich die Instanz wiedergefunden hat, gesetzt werden muss.
Im ersten Zyklus muss noch verhindert werden, dass Einträge im Array gelöscht werden. Dazu ist vermutlich ausser dem "zentralen" ZyklusErster-Bit ein "zentrales" ErsterZyklus-Bit erforderlich.
Mit "zentral" meine ich den Ort, wo auch das Array abgelegt ist.
Die Liste müsste zu einer Tabelle erweitert werden, so dass für das Benutzt-Bit eine eigene Spalte entsteht. Also Array of Struct, of UDT, of "eigenem Datentyp". Wie auch immer.
 
3. Welches Kriterium hast Du, das Dir sagt "die Instanz XY wird nicht mehr benutzt"? Das ist mir nach wie vor ein Rätsel.
Sowas lässt sich auch nicht ermitteln.
Und daher sehe ich als einfachste Lösung das entsprechende Array beim SPS-Anlauf (OB100) zu löschen und dann können sich die FBs bei ihrem ersten Aufruf wieder eintragen.
Was die Visu dabei macht, ob z.B. falsche Werte geschrieben werden, muss halt getestet werden.
Zumindest ist so die Forderung von spsqem erfüllt, dass die FBs nicht geändert werden dürfen.
 
Gibt es hierfür eine Möglichkeit ohne einen extra Baustein zu schreiben und die Instanz-DBs an zu parametrieren?
:unsure:
Was ist denn an Zusatz akzeptabel?
Denn ganz ohne irgendetwas Neues wird es ja eh nicht gehen, oder?



Ich würde das Array mit den Präfixen vermutlich in 2 gleichartige "teilen":
- ein temporäres zum Eintragen für die Instanzen, das nach dem Sortieren/Übertragen wieder abgelöscht wird
- ein ständiges für das HMI zum Arbeiten, das dann nur noch die aktuellen Instanzen enthält
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein, niemand soll hier verleitet werden, seinen konkreten AnwendungsFall, das komplette Umfeld, BetriebsGeheimnisse oder was auch immer preiszugeben.
Manchmal bis oft ist es jedoch hilfreich, das Umfeld ein wenig abzuklopfen, um die Aufgabenstellung besser bzw. überhaupt zu verstehen oder zumindest zu erahnen.
Jeder von uns hat ganz unterschiedliche Erfahrungen und (Spezial-)Kenntnisse.
Da unsere GlasKugeln unterschiedlich gut trainiert sind, mag der eine schon den ersten Beitrag richtig deuten, während ein anderer bis zum letzten Beitrag nur Bahnhof versteht.

1. Das Kriterium, das Dir sagt, "die Instanz XY wird benutzt", ist mir klar.
2. Das Kriterium, das Dir sagt, "die Instanz XY wird neuerdings benutzt (= wurde bisher nicht benutzt)", ist mir auch klar. Aber nach diesem Fall fragst Du gar nicht.
3. Welches Kriterium hast Du, das Dir sagt "die Instanz XY wird nicht mehr benutzt"? Das ist mir nach wie vor ein Rätsel.

Eine Instanz, die aufgerufen wird, ermittelt ihren Pfad und kann die Liste (das Array) durchsuchen, ob ihr Präfix dort eingetragen ist.
- Ist es eingetragen, so ist für Dich der Fall erledigt. Der FB kann sich seiner eigentlichen Aufgabe widmen.
- Ist es nicht eingetragen, so interessiert Dich das anscheinend nicht (?) und der FB kann sich ebenfalls seiner eigentlichen Aufgabe widmen.

Eine Instanz, die nicht aufgerufen wird, kann nicht ihren Pfad und Präfix ermitteln und auch nicht ein evtl. Vorhandensein in der Liste prüfen, geschweige denn einen Eintrag in der Liste löschen und die Liste danach Sortieren. Was also tun?

Z.B. könnte in einer einzigen der Instanzen eine SonderFunktion[-alität] aktiviert werden, so dass diese Instanz mehr tut, als die anderen Instanzen. Wird aber ausgerechnet diese Instanz nicht mehr benutzt, so steht man im Regen.
Darum schwebt mir vor, die erste in einem "Zyklus" benutzte Instanz bekommt diesen SonderStatus.
Was das für ein Zyklus sein könnte, weiss ich nicht. Vielleicht ein OB1 Zyklus?
Verwaltet werden müsste dieser Zyklus z.T. ausserhalb der FB-Instanzen, indem das "zentrale" ZyklusErster-Bit gesetzt wird.
Jede aufgerufene Instanz kopiert das "zentrale" ZyklusErster-Bit in eine lokale Variable zur späteren Verwendung und löscht das "zentrale" ZyklusErster-Bit.
Ist das "lokale" ZyklusErster-Bit TRUE, so wird in dieser Instanz die SonderFunktion[-alität] aktiviert.
Sie geht den belegten Bereich des Array durch und prüft, ob das Benutzt-Bit (das zusätzlich zum Präfix vorhanden sein muss) bei einem der belegten ArrayElemente FALSE ist.
Falls das Benutzt-Bit=TRUE ist, wird es gelöscht und die Prufung mit dem nächsten ArrayEintrag fortgesetzt.
Falls es FALSE ist, wird der Eintrag im Array gelöscht und das Array sortiert.
Vermutlich genügt es, den erstbesten Eintrag mit dem Kennzeichen Benutzt-Bit=FALSE zu löschen und weitere Einträge mit diesem Kennzeichen erst in folgenden Zyklen (nach und nach) zu löschen.
Im "allgemeinen" Teil der FB-Instanz kommt hinzu, dass das Benutzt-Bit bei dem Eintrag, bei dem sich die Instanz wiedergefunden hat, gesetzt werden muss.
Im ersten Zyklus muss noch verhindert werden, dass Einträge im Array gelöscht werden. Dazu ist vermutlich ausser dem "zentralen" ZyklusErster-Bit ein "zentrales" ErsterZyklus-Bit erforderlich.
Mit "zentral" meine ich den Ort, wo auch das Array abgelegt ist.
Die Liste müsste zu einer Tabelle erweitert werden, so dass für das Benutzt-Bit eine eigene Spalte entsteht. Also Array of Struct, of UDT, of "eigenem Datentyp". Wie auch immer.
Hallo Heinileini, ich denke du hast den Kern des Problems verstanden nur wir haben aneinander vorbei geredet.
Genau darum geht es diejenigen Instanzpräfixe, die nicht mehr in Verwendung sind zu prüfen und zu eliminieren.

Wenn es nämlich eine solche Präfix"leiche" in dem globalen DB gibt, funktioniert meine Visu nicht mehr ordentlich.
Aber während ich mir deinen Kommentar durchgelesen habe ist mir eine andere Lösung eingefallen.
Ich prüfe einfach in meinem VB Skript ob die jeweiligen Instanzen noch existiert mit der "Is Nothing" Funktion. Vorgabe meines Bausteins ist ohnehin die SiVArc Generierung. Das heißt wenn es eine Instanz nicht mehr gibt, gibt es auch die dazugehörigen HMI Variablen nicht mehr.
Sollte es nicht erreichbar wird dieser Teil übersprungen und mit dem nächsten Präfix weiter gearbeitet.

Das eigentliche Problem mit den Präfix"Leichen" wird sich spätestens zum nächsten CPU Neustart von selbst erledigt haben, da alle DBs initialisiert werden und somit der globale DB frisch beschrieben wird
 
Und daher sehe ich als einfachste Lösung das entsprechende Array beim SPS-Anlauf (OB100) zu löschen und dann können sich die FBs bei ihrem ersten Aufruf wieder eintragen.
Naja, ohne SPS-Neustart können aber auch FB-Aufrufe hinzukommen oder wegfallen... Sollte ja eigentlich die Regel sein, Änderungen ohne CPU-Neustart zu machen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wieso werden bei Dir beim CPU Neustart "alle DBs initialisiert"?
Die Daten im globalen Präfix DB sind nicht remanent und die FB Aufrufe führen eine Initialisierung durch, durch eine nicht remanente Bool Variable die nach der Initialisierung true geschrieben wird.

Nach dem Konzept:

Var
Init : BOOL := false;
End Var

If Init = false then
….
*schreibe präfix in db*

Init := True;
End_if;
 
Naja, ohne SPS-Neustart können aber auch FB-Aufrufe hinzukommen oder wegfallen... Sollte ja eigentlich die Regel sein, Änderungen ohne CPU-Neustart zu machen...
Wenn neue Aufrufe hinzukommen ist das kein Problem, denn dann trägt dieser Aufruf sich selbstständig in den globalen DB ein und gut ist. Problematisch ist nur wenn mittendrin welche gelöscht oder umbenannt werden
 
Da müsste jeder Baustein der auch seinen Namen einträgt, über eine Art Lebensbit mitteilen, dass er noch aktiv ist. Und wenn nicht, dann muss den Eintrag ein übergeordneter Baustein löschen.
 
Zurück
Oben