fc als multiinstanz gut oder böse?

[Markus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du hast das da oben vermutlich nicht ganz verstanden.

Einen FC bekommst du nicht Multiinstanzfähig.
Muss er auch gar nicht sein, du rufst ihn einfach beliebig oft auf - wenn er so gemacht ist dass das geht.

Wenn du lokalen Speicher (Stat) brauchst, dann musst du einen FB nehmen.
Diesen kannst du multiinstanzfähig machen.
Grundsätzlich ist er das von Haus aus. Wen du aber z.B. eine 300er hast und in dem FB mit Pointern spielst, dann musst du ggf. am Bausteinanfang die Adressregister sicheren und im letzten Netzwerk zurück sichern. Ansonsten verhagelst du dir die Adressen im aufrufenden FB.

Hier gehts aber um etwas vollig anderes.
Hier soll einem FC quasi ein Statischer Speicherbereich aus einem anparametrierten Speicherbereich (Z.B. Array in einem Global DB) übergeben werden. Im Prinzip eine Missbräuchliche Anwendung die Vor- und Nachteile bringt die da oben diskutiert werden.

Der Beitrag ist aus 2007 - wir reden von S7 300.

 

[MFreiberger]

Moin,

was ich selber nutze, ist die Möglichkeit, einen UDT als eine Variable an eine FC (InOut) zu übergeben und damit auf einmal einen ganzen Schwung an Variablen zwischen zwei FCs auszutauschen, ohne, dass die Bausteinschnittstelle so unübersichtlich groß wird, dass man erstmal lange rumscrollen muss, um alle Parameter zu sehen.
Das ist auch nett, wenn mehr Informationen übergeben werden müssen, als in ein Steuer- und/oder Statusword hinein passen.
Auch bei FCs, die unterschiedlich sind, gibt es zum Teil bei uns einen "Standardteil", der bei allen FCs gleich ist. Auch da bietet es sich an, diese Standardvariablen in einem Array[*] of udt abzulegen. In dem Array kann man jedem Element ja auch einen separaten Kommentar geben. Damit kann die UDT-Variable auch objektspezifisch beschrieben werden.

 

[EMZ]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo an alle vielen Dank für die schnelle Infos.
OK dann hat sich das erledigt. nutze es so ähnlich dachte es gibt neue Alternativen. Ich habe um ehrlich zu gestehen nicht auf das Datum geachtet

Vielen Dank und Viele Grüße

 

[Markus]

Auch bei FCs, die unterschiedlich sind, gibt es zum Teil bei uns einen "Standardteil", der bei allen FCs gleich ist. Auch da bietet es sich an, diese Standardvariablen in einem Array[*] of udt abzulegen. In dem Array kann man jedem Element ja auch einen separaten Kommentar geben. Damit kann die UDT-Variable auch objektspezifisch beschrieben werden.

Wenn du maximal Performance willst, dann deklariert du den Anfang des Temp Bereichs in jedem FC gleich. Z.b. mit UDT.

Dan rufst dur die FC nacheinander auf.
Keine Aufrufe von anderen Bausteinen dazwischen. Auch auf Alarm-OB Achten!

Du hast die Daten dann in allen FC konsistent zur Verfügung und kannst lesen und schreiben ohne Speicher zu verbrauchen oder die Zykluszeit mit den Pointern von INOUT zu belasten.


Achtung, Spass:
Das darf man aber nicht jedem erzählen es gibt durchaus Leute die einen verprügeln wenn man sowas baut. Meistens die mit den großzügigen Chefs wo das Störmeldehandlung an einem Anlagenteil alleine 30ms auf der 315 frisst... Aber da die immer ne 417 bekommen kennen sie das Problem nicht.

Aufgrund des Alters des Beitrags: alles in Bezug auf 300er!


Ich glaube aber das verstehen nur Leute die bei der S5 damals die freien Eingangsadressen als zusätzliche Merkerbereiche missbrauchen mussten

 

[Oberchefe]

Wenn du maximal Performance willst, dann deklariert du den Anfang des Temp Bereichs in jedem FC gleich. Z.b. mit UDT.

Dan rufst dur die FC nacheinander auf.
Keine Aufrufe von anderen Bausteinen

Funktioniert aber nur bei nicht optimierten Bausteinen

 

[Markus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Funktioniert aber nur bei nicht optimierten Bausteinen

S - 7 - 3 - 0 - 0 - !