TIA instanzFB oder Multiinstanz

C

Credofire

Level-1
Beiträge
640
Reaktionspunkte
35
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

sicher wurde es schon mal irgendwo angesprochen, aber ich war zu dumm es zu finden ;)

Was ist programmtechnisch besser für die Zykluszeiten, instanzierter FB oder Multiinstanz FB?
Platztechnisch wird es sich sicher nicht groß auswirken denke ich.
Ich schaue gerade im Programm vom Kollegen, und überlege ob man es optimieren kann, wenn man auf Multiinstanzen geht.
Ich habe jetzt quasi 10 einzelne gleiche FB Objekte. Wenn ich diese jetzt so gestalte, dass ich einen Multiinstanz-FB daraus erstelle und jeweils die Parameter von aussen antrage, statt direkt im FB zu verwenden, erhoffe ich mir dadurch einen Zeitvorteil im Programmablauf.

Vielen Dank für eure Ideen

Gruß Credo
 
Welche SPS/CPU hast Du?
S7-300/400: Wenn Du den FB als "multiinstanzfähig" anlegst, dann ist es für die Programmlaufzeit egal, ob die Instanz einen eigenen IDB hat oder tatsächlich eine Multiinstanz ist. Es wird dann immer die aufwendigere und etwas langsamere Multiinstanz-Adressierung verwendet.
Wenn der FB nicht als "multiinstanzfähig" angelegt ist, dann wird der Code 5..10% kürzer und schneller.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie umfangreich soll der Zeitvorteil ausfallen?

Wegfällt bei Multiinstanz, der Aufruf der einzelnen Instanz-DBs.
Der Gewinn dürfte dementsprechend gering ausfallen.

Aus ästhetischen Gründen ist aber eine Multiinstanz durchaus wert, diskutiert zu werden.
 
Nachtrag: einen FB nachträglich tatsächlich multiinstanzfähig machen kann aufwendig werden. Besonders wenn indirekte Adressierung in die eigene Instanz verwendet wird - dann muß zu allen Adressen der Multiinstanzoffset aus AR2 addiert werden.

Harald
 
Hallöchen,

es handelt sich um eine 1512SP.
Derzeit sind die Variablen und Konstanten quasi von "überall her" direkt in dem instanzFB verarbeitet.
So aufwendig sollte die Arbeit nicht werden, da es sich ja um relativ wenige Variablen und Konstanten handelt.

Wie umfangreich der Zeitvorteil sein soll weis ich ja nicht, das versuche ich ja hier abzuschätzen.
Am Ende ist es vielleicht nur meine persönliche Note, dass ich lieber mit Multiinstanz arbeite, und das es zeitlich weder Vor- noch Nachteile hat.

Gruß
Credo
 
Ich würde es mal so sagen :
Wenn der einzulagernde FB sowieso schon Multi-Instanz-fähig ist und in ihm mit indirekter Adressierung gearbeitet wird dann finde darin die AR2-Geschichte sowie schon statt - ob benötigt oder nicht.
Ich sehe das so wie Steffen - die Multi-Geschichte macht es aus meiner Sicht schon "ein wenig" schicker ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Larry Laffer schrieb:
Ich sehe das so wie Steffen - die Multi-Geschichte macht es aus meiner Sicht schon "ein wenig" schicker ...
Zum Vergrößern anklicken....

ausser wenn mal abundzu Änderungen im laufenden Betrieb machen muss... dann wirkt sich die Reinitialisierungswut wenigstens gleich auf alles aus...

hab mal ne Anlage mit Multiinstanzen gebaut... würde es nicht nochmal wieder machen...

ich nehme lieber wieder FCs die Ihre Daten in nem zugehörigen GlobalDB haben...

Gruß.
 
Die Änderungen sind unabhängig von der Ausführung, sowohl als Global-DB als auch mit (Multi-)Instanz-DB im laufenden Betrieb immer mit größter Sorgfalt vorzubereiten. Keine Variante verzeiht Fehler. Im besten Fall sind noch Fehler-OBs geladen, im schlimmsten steht die CPU in Stop.

Aber das ist dann doch eher Instandhalter-mimimi jetzt. Denn ob ich nun eine Instanz durch Aufruf anlege oder eine Multiinstanz der Bausteindeklaration hinzufüge ist am Ende nun kein Aufwandsunterschied. Am schlimmsten ist, die stehende Anlage und die, wie oben beschrieben, droht immer bei Arbeiten im laufenden Betrieb.
 
ducati schrieb:
ausser wenn mal abundzu Änderungen im laufenden Betrieb machen muss... dann wirkt sich die Reinitialisierungswut wenigstens gleich auf alles aus...
Zum Vergrößern anklicken....
Die FBs man in ein andere FB als Multi-Instanz "einbettet" soll Nagelfest sein.
Sie sollen einfach, simpel und durchgetestet sein.
Es soll vorhersehbar sein dass es wird kein Bedarf sein die einegebettete FBs zu ändern.
Wenn man davon ausgehen kann ist Multi-Instanz eine wertvolle Verfahren um wiederverwendbare Code zu erzeugen.

Mehr komplexe FBs will ich auch nicht als Multi-Instanz FBs einbetten.

Ein bischen Speicher oder Zykluszeit zu sparen wurde ich nicht als vor oder gegen-Argument für Multi-Instanz verwenden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
vierlagig schrieb:
Aber das ist dann doch eher Instandhalter-mimimi jetzt. Denn ob ich nun eine Instanz durch Aufruf anlege oder eine Multiinstanz der Bausteindeklaration hinzufüge ist am Ende nun kein Aufwandsunterschied. Am schlimmsten ist, die stehende Anlage und die, wie oben beschrieben, droht immer bei Arbeiten im laufenden Betrieb.
Zum Vergrößern anklicken....

Eben nicht... Ne Instanz hinzufügen kannst immer im laufenden Betrieb. Beim Hinzufügen in ner Multiinstanz reinitialisiert das TIA Dings den kompletten MultiinstanzDB und Du verlierst ALLE Aktualdaten darin, sowas ist im laufenden Betrieb, also stoßfrei, überhaupt nicht zu gebrauchen (bei Anlagen der Prozessautomatisierung die 24/365 durchlaufen...

Gruß.
 
Wir verwenden nur Multiinstanzen weil der Programmordner übersichtlicher ist. Allerdings arbeiten wir in einer Branche wo CPU Stopp in der Schichtpause oder bei Ankündigung kein Problem ist.
 

Similar threads

D
TIA Problem mit Multiinstanzen?
Antworten
9
Aufrufe
2K
DCDCDC
D
P
TIA Daten in Variablen oder Datenbaustein abspeichern - Unterschied
Antworten
9
Aufrufe
1K
Patrick_L
P
S
Sonstiges Kommunikationsbaustein erstellen
Antworten
8
Aufrufe
1K
ducati
D
M
TIA Laden ohne Reinitialisierung
Antworten
5
Aufrufe
2K
JesperMP
JesperMP
O
WinCC Kommunikationslast bei WinCC & S7-1500F: Zugriff auf WORD vs. Struct mit BOOLs
Antworten
5
Aufrufe
614
Origilon
O
Zurück
Oben