Allgemeines zu Multiinstanzen

M

MikeJ

Level-1
Beiträge
80
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

kann eigentlich die Visualisierung auf so einen Multiinstanz DP genau so zugreifen wie auf einen "normalen" DB?!
Wenn ja, habe ich das was grundlegend nicht verstanden: unter Multiinstanz verstehe ich etwas, was zur gleichen Zeit mehrfach "Existiert". Wenn nun die Visualisierung oder auch das SPS Programm auf diesen Multi-DB zugreifen kann, auf welche Instanz des DB´s greift sie denn dann zu, denn jede Instanz kann doch auch andere Werte enthalten?!

Kann mir vielleicht auch jemand ne "Lektüre" empfehlen wo ich so ein paar allgemeine Dinge zur SPS-Programmierung nachlesen kann.

Gruß Mike
 
Multiinstanz bedeutet, dass die Instanz-DBs von einem oder mehreren FBs in einem Insanz-DB eines anderen (aufrufenden) FBs enthalten sind.

Damit werden mehrere DBs von mehreren FBs in einem DB zusammen gefasst.

Bedingung: Die FBs müssen in einem FB ("multiinstanzfähig") aufgerufen werden und dort dann als Multiinstanz in den statischen Datenbereich aufgenommen werden.

Auf diese Daten kann dann auch ganz normal zugegriffen werden.
 
oh sch... das klingt kompliziert. Abgesehen davon bringt das meine komplette Vorstellung von Multiinstanzen durcheinander :confused:


Jetzt stellt sich mir folgende Frage: Angenommen ich habe eine Anlage mit sehr vielen Pneumatikzylindern. Um diese anzusteuern und vor allem zu überwachen baue ich mir einen FB, der neben der Ansteuerung die Laufzeit überwacht. Wenn nun die Multiinstanz nicht das ist, wofür ich sie gehalten habe, bekomme ich doch spätestens bei der Überwachungszeit ein Problem, da ich für jeden Zylinder einen eigenen Timer benötige, oder?! Ich habe zwar jetzt schon was von IEC-Timern gehört, aber deren "Basis" liegt ja auch im DB und kann somit nicht "mehrfach nebeneinander bestehen"?!

Gruß Mike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
MikeJ schrieb:
Wenn nun die Multiinstanz nicht das ist, wofür ich sie gehalten habe, bekomme ich doch spätestens bei der Überwachungszeit ein Problem, da ich für jeden Zylinder einen eigenen Timer benötige, oder?! Ich habe zwar jetzt schon was von IEC-Timern gehört, aber deren "Basis" liegt ja auch im DB und kann somit nicht "mehrfach nebeneinander bestehen"?!
Zum Vergrößern anklicken....

Bei so etwas ist der IEC-Timer für dich die richtige Wahl.
Und davon können schon mehrere nebeneinander bestehen.
Du mußt bei den Instanzen beachten, dass du dann für jede zylinder-Überwachung (dein Beispiel) einen eigenen Instanz-DB hast und brauchst.

Gruß
LL
 
wenn auch viele andere meinung sind, ich finde das du auf Instanz Daten
schreibend zugreifen kannst. Ich mache das z.b. um bei den IEC-Timern zu
bleiben, bei der Zeit. Ich ziehe dann die Zeitvorgabe "PT" in die HMI weil
ich es mit meinen Altersstarsinn einfach nicht einsehen möchte diese
Variabel zweimal in meinen Programm anzulegen.
 
Als ich 1997 damit begann, Moeller SPSen vom Typ 141 zu programmieren, da war so'was noch einfach. Ich habe demselben Codebaustein zwanzig Namen verpasst und ihn zwanzigmal instanziert und den Rest machte der Compiler. In solche Instanzdaten reinschreiben ging schon aus Prinzip nur, wenn man es explizit wollte. Das war noch übersichtlich!

Heute wird einfach alles komplizierter!?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ludewig schrieb:
Als ich 1997 damit begann, Moeller SPSen vom Typ 141 zu programmieren, da war so'was noch einfach. Ich habe demselben Codebaustein zwanzig Namen verpasst und ihn zwanzigmal instanziert und den Rest machte der Compiler. In solche Instanzdaten reinschreiben ging schon aus Prinzip nur, wenn man es explizit wollte. Das war noch übersichtlich!

Heute wird einfach alles komplizierter!?
Zum Vergrößern anklicken....

was hat sich daran den geändert, es funktioniert
doch heute genauso wie 1997!
 
Nicht immer FB erforderlich

MikeJ schrieb:
Jetzt stellt sich mir folgende Frage: Angenommen ich habe eine Anlage mit sehr vielen Pneumatikzylindern. Um diese anzusteuern und vor allem zu überwachen baue ich mir einen FB, der neben der Ansteuerung die Laufzeit überwacht. Wenn nun die Multiinstanz nicht das ist, wofür ich sie gehalten habe, bekomme ich doch spätestens bei der Überwachungszeit ein Problem, da ich für jeden Zylinder einen eigenen Timer benötige, oder?! Ich habe zwar jetzt schon was von IEC-Timern gehört, aber deren "Basis" liegt ja auch im DB und kann somit nicht "mehrfach nebeneinander bestehen"?!

Gruß Mike
Zum Vergrößern anklicken....

Gegenfrage :roll:
Warum muss es den ein "FB" sein ?
Pack doch den ganzen Kram in einen FC,
Bausteinparameter "DB" und "DATA" (=DB-Nr und 1.Byte im DB) dran,
(oder mit Pointer)
Ein UDT für die benutzten Daten erstellen,
dieses UDT im "normalen" DB sooft wie benötigt einbauen,
Fertig.

Im FC baust du dir intern einen Zeiger, der auf das Datenfeld zeigt.

Wenn du einen Parameter "Zeitimpuls" einbaust,
kannst du deine Zeiten gleich mit in den DB legen.
Wenn die Zeit nicht läuft, wird die Zeitvorgabe in eine Zeitzelle geschrieben.
Ist die Zeit angesteuert, wird diese Zeitzelle im Zeittakt dekrementiert.
Ist sie bei "Null" angekommen, Zeitzelle begrenzen und Funktion ausführen.

Gruß Roland
 
Zuletzt bearbeitet:
Der Pfälzer schrieb:
Gegenfrage :roll:
Warum muss es den ein "FB" sein ?
Pack doch den ganzen Kram in einen FC,
Bausteinparameter "DB" und "DATA" (=DB-Nr und 1.Byte im DB) dran,
(oder mit Pointer)
Ein UDT für die benutzten Daten erstellen,
dieses UDT im "normalen" DB sooft wie benötigt einbauen,
Fertig.

Im FC baust du dir intern einen Zeiger, der auf das Datenfeld zeigt.
Zum Vergrößern anklicken....
:sb5: :sw5: :sw18:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
vierlagig schrieb:
:sb5: :sw5: :sw18:
Zum Vergrößern anklicken....
Hallo 4L,
warum findest du meinen Vorschlag zum kotzen?

Ist doch eine einfache Lösung wenn der TS sich mit Multiinstanzen nicht auskennt. Oder er braucht eben für jeden Antrieb einen eigenen I-DB.
Vielleicht nicht die eleganteste Methode mit dem FC, aber einfacher zu handeln. Und die Hilfe soll doch für den TS nachvollziehbar sein.

Gruß Roland
 
Der Pfälzer schrieb:
Hallo 4L,
warum findest du meinen Vorschlag zum kotzen?

Ist doch eine einfache Lösung wenn der TS sich mit Multiinstanzen nicht auskennt. Oder er braucht eben für jeden Antrieb einen eigenen I-DB.
Vielleicht nicht die eleganteste Methode mit dem FC, aber einfacher zu handeln. Und die Hilfe soll doch für den TS nachvollziehbar sein.

Gruß Roland
Zum Vergrößern anklicken....

du willst wissen warum?
vielleicht, weil ich
a) 4 Jahre lang Instandhalter war
b) Programme bevorzuge, bei denen die automatisch generierten Referenzen sinn ergeben
c) handlebaren und wartbaren Code bevorzuge und
d) strikt zwischen sinnvoll und sinnlos trenne

und feststelle, dass dein Vorschlag sinnlos ist, da nicht nur b bis d nicht zutreffen sondern auch dem Fragensteller damit nicht weitergeholfen ist, weil er es nicht verstehen wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke, es ist alles leichter zu verstehen, wenn man die Marketingsprache in normale Begriffe aus dem Programmieren übersetzt. Dann ist eine Multiinstanz nichts als eine Variable von einem bestimmten selbstdefinierten Datentyp (mit Beschränkungen).

Allgemein:
Step7 - C
UDT (TYPE) = struct
DB (DATA_BLOCK) = struct { ... } variable (anonyme struct)
oder DB = struct udt_oder_fb_name variable
FC = Funktion
FB = struct oder class (objektorientiert) mit einer einzigen Member-Funktion und Einschränkungen

Die genannte Frage hat nichts mit Multiinstanzen zu tun. Das "Problem" tritt schon auf, wenn mehrere DBs von einem FB oder auch UDT angelegt werden. Die Variablen innerhalb des UDT (oder FB) existieren mehrmals - so oft wie eine Variable des Typs angelegt wurde.

Einen FB-Typ kann man nicht wie UDTs beliebig verschachteln oder in DBs benutzen. Er ist nur im VAR(STAT)-Bereich eines anderen FBs benutzbar. Der Funktionsaufruf dazu, also der Aufruf der FB-Funktion mit der gegebenen Variable, geht nur aus dem direkt übergeordneten FB heraus und sieht dann z.B. so aus:

CALL #ton_whatever

Was nicht geht:
CALL #x.ton_whatever
CALL "db_x".ton_whatever

Alle VAR_INPUT, _OUTPUT, _IN_OUT und "STAT"-Variablen einer FB-Funktion werden Bestandteil des FB-Typs. In der FB-Funktion werden sie als lokale Variablen gesehen, von außerhalb sind sie wie Bestandteile eines DBs zu benutzen, so kann "db_x".ton_whatever.PT von außen gesetzt werden, selbst wenn es ein VAR_INPUT ist.

Jeder FB kann durch FC ersetzt werden, indem der passende UDT angelegt und als VAR_IN_OUT übergeben wird. Das ist aber, zusätzlich zu vierlagig's Bemerkungen, sehr ineffizient.

VAR_TEMP-Variablen sind immer lokale Variablen wie in C (auf dem Stack) und werden nicht FB-Typ-Bestandteil.
 
Also den Ausführungen und Vergleichen mit einer Hochsprache kann ich verstehen, doch wenn jemand keine Hochsprachenprogrammierung kann?

Multiinstanzen sind unter bestimmten Bedingungen sinnvoll, doch ich versuche diese so wenig wie möglich zu verwenden.
Es ist eben nicht so ganz einfach bei einer laufenden Anlage einen geänderten FB in dem FBs sind mit dem geänderten DB einzuspielen, da es eben sein kann, dass die Adressen sich verschieben.

bike
 
vierlagig schrieb:
du willst wissen warum?
vielleicht, weil ich
a) 4 Jahre lang Instandhalter war
b) Programme bevorzuge, bei denen die automatisch generierten Referenzen sinn ergeben
c) handlebaren und wartbaren Code bevorzuge und
d) strikt zwischen sinnvoll und sinnlos trenne

und feststelle, dass dein Vorschlag sinnlos ist, da nicht nur b bis d nicht zutreffen sondern auch dem Fragensteller damit nicht weitergeholfen ist, weil er es nicht verstehen wird.
Zum Vergrößern anklicken....

zu a) ich nicht, bin erst seit 1979 an dem Thema S5/S7
zu b) ich auch, wenn aber alle (zB Antriebsdaten) in einem DB liegen, kann ich mal darauf verzichten. Die findet man trotzdem.
zu c) ich auch, zum Wohle des Instandhalters und weil ich "Arbeitsplatzsichernde Programme" nicht mag.
zu d) ich auch, vermutlich ist die Interpretation eine Andere.
Mag sein, dass der TS es (noch) nicht versteht.

Ich denke mal, ihr wollt auf die Lösung mit einem FB jedoch ohne Multiinstanz hinaus.
Da er "sehr viele" Pneumatikzylinder hat, braucht er eben sehr viele I-DBs.

Ich wollte dich auf keinen Fall zum Kotzen animieren.
Schließlich stimmen wir in fast allen Punkten überein.
Und ich halte grosse Stücke auf die Antworten von dir, wie auch von LL, PN/DP, HelmutvReparatur und einigen Anderen, die mir grade nicht einfallen.
Wollt ich schon lange mal loswerden.
Um so mehr war ich auf deine harte Reaktion erstaunt.
(Keine Angst, ich pinse mich nicht ins Koma)

Gruß Roland
 
Mahlzeit zusammen,

ich wollte mit meiner Frage eigentlich keinen "Kleingrieg" starten :)

Also erstmal danke Euch allen für die vielen Antworten. Ich finde es gut, verschiedene Lösungsvorschläge zu bekommen - auch wenn ich wirklich noch nicht alle verstehe.
Das jeder Lösungsweg seine Vor- und Nachteile hat ist klar, und darum geht es mir ja auch: herauszufinden, wie man es lösen könnte und was die Vor- und Nachteile sind.

Vielen Dank übrigens auch an DrutBbuck für den Vergleich - das hat auch schon wieder etwas weiter geholfen.

Ich will das auch nicht "unbedingt" mit FB, FC, Multiinstanzen lösen, mir wäre es jedoch wichtig, eine Lösung z.B. zur Ansteuerung und Überwachung eines Zylinders zu haben um diese bei Bedarf einfach aus der "Tasche ziehen" zu können. Dabei sollte diese Lösung nach Möglichkeit keine öffentlichen Variablen nutzen wie z.B. Merker oder die S5Timer und auch nicht einen DB pro Zylinder "verschwenden".


Wenn ich den Vorschlag von "Der Pfälzer" richtig verstanden habe, würdest Du einen DB für die Überwachung aller Zylinder nehmen und beim Aufruf der Funktion einfach nur übergeben, wo die Daten für "diesen" Zylinder liegen?! Bei der Überwachungszeit wäre ich dann jedoch wieder auf die S5Timer angewiesen, oder?

ahxlvi: WinCC flexible.


Viele Grüße
Mike
 
MikeJ schrieb:
Dabei sollte diese Lösung nach Möglichkeit keine öffentlichen Variablen nutzen wie z.B. Merker oder die S5Timer und auch nicht einen DB pro Zylinder "verschwenden".

Wenn ich den Vorschlag von "Der Pfälzer" richtig verstanden habe, würdest Du einen DB für die Überwachung aller Zylinder nehmen und beim Aufruf der Funktion einfach nur übergeben, wo die Daten für "diesen" Zylinder liegen?! Bei der Überwachungszeit wäre ich dann jedoch wieder auf die S5Timer angewiesen, oder?
Zum Vergrößern anklicken....

Hallo Mike,
ich traue mich ja fast schon nicht mehr auf meinen Vorschlag einzugehen. :ROFLMAO:

Richtig, du hättest einen DB für die Überwachung aller Zylinder (sofern die Länge für alle ausreicht, wenn nicht eben einen weiteren).

S5Timer brauchst du keine. Wie oben erwähnt, kann man ein Zeitverhalten auch durch dekrementieren (runterzählen) eines Variableninhaltes erreichen. Die Zeitbasis wird dann von einem Takt-Impuls bestimmt.

Den Nachteil dieser Lösung hat 4L schon erwähnt. Alle nicht absolut angesprochenen Datenpunkte erscheinen nicht in den Referenzdaten.
Dies ist für jemand dem das Programm fremd ist, schon ein Nachteil.
Da aber alle Überwachungen in einem DB liegen, doch überschaubar.

Vorteil gegenüber der Muliinstanz-Lösung hat BIKE schon angesprochen.
Wenn durch Änderungen das Neugenerieren des Instanz-DBs erforderlich wird, ist in der laufenden Anlage überlegtes Handeln geboten.

Gruß Roland
 

Similar threads

S
TIA PUT/Get als Multiinstanz : In/Out Variable
Antworten
1
Aufrufe
529
DCDCDC
D
M
TIA Laden ohne Reinitialisierung
Antworten
5
Aufrufe
912
JesperMP
JesperMP
L
TIA TIA V18 HMI liest keine Variablen
Antworten
9
Aufrufe
965
Linux
L
C
WinCC Unified Datenaustausch Faceplate mit Faceplate Popup
Antworten
1
Aufrufe
420
Cal_TDI
C
Botimperator
TIA F-Peripherie-DB in FC lesen & diesen FC in eine Bibliothek einbinden
Antworten
10
Aufrufe
1K
Botimperator
Botimperator
Zurück
Oben