Ist jetzt zwar nicht direkt die Antwort auf Deine Frage, aber anstelle einen FB mal aufzurufen oder nicht, würde ich einem FB doch lieber einen Eingang Enable spendieren.
Vorteile:
- der Code wird übersichtlicher
- der Baustein kann beim wegnehmen des Enable Signals kontrolliert irgendwelche Aktionen ausführen und befindet sich danach in einem definierten Zustand (oder auch beim Start, je nachdem)
So, Tochter ist fertig gewickelt, dann mal eben zu Teil 2:
Angenommen, der FB soll Licht beim Ein-und Ausschalten hoch und runterdimmen.
Er soll beim Eingang Freigabe=True hochdimmen, bei Eingang Freigabe=False runterdimmen.
Über diesen Eingang kann der FB erkennen was er tun soll, und intern alles dafür notwendige abarbeiten. Wenn er mit dem hoch und runterdimmen fertig ist, überspringt er intern alle unwichtigen Schritte, damit keine Rechenzeit verschwendet wird.
Wenn der FB von aussen bedingt aufgerufen würde, müsstest Du von aussen dafür Sorge tragen, das der FB mit seiner internen Arbeit fertig ist, und ihn dann überspringen. Auch das müsstest Du für jeden Aufruf separat auswerten. Dann doch lieber diese Arbeit einmal in den FB packen und dann beliebig oft ohne zusätzlichen Programmieraufwand aufrufen.
Ich habe es mir angewöhnt, einen FB nur einmal im Programm oder FB mit Parametern aufzurufen. Meist am Ende des Codes oder zusätzlich in einer Aktion verpackt.
Während des Programms verwende ich ausschließlich die einzelnen zu verändernden In/Outputs.
Sieht das in etwa so aus:
Code:
...
IF bVar1 THEN
myFB.Enable := TRUE;
ELSE
myFB.Enable := FALSE;
END_IF
...
myFB.Input1 := ...;
...
Output := myFB.Output1;
...
...
(* Ende des Codes *)
myFB(iParameter1 := 123
iParameter2 := 456);
Vorteil finde ich ist, dass der FB in jedem Fall ausgeführt wird. Unabhängig von irgendwelchen Bedingungen.
das habe ich auch schon gemerkt, dass das ganz praktisch ist. Dadurch ist man sicher, dass Funktionsblöcke immer ausgeführt werden bzw. nicht mehrfach. v.A. bei MotionControl-Bausteinen hat mir das den Quelltext immer erheblich gekürzt