Wann FC und wann FB?

Mephisto

Level-1
Beiträge
242
Reaktionspunkte
12
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Ich genier mich richtig zu fragen, so saublöd erscheint mir das.:oops:

Wann verwende ich einen FB und wann einen FC?
Die theoretische Siemens Beschreibung ist mir bewusst. Hab auch das Einsteiger Tutorial in Step 7 hinter mir.

Wenn ich nun ein Programm schreiben möchte, in dem nur einige Eingänge logisch verknüpft und auf Merker und Ausgänge geschrieben sollen und vielleicht noch der eine oder andere Timer/Zähler mit im Spiel ist, reicht dann ein FC, oder muss ich dann einen FB für mein Programm kreieren?
Und wenn ich einen FB kreiere, muss ich dann einen Instanz-DB dazu machen? Reinspeichern tu ich ja eigentlich nichts. Oder treiben da die Zähler/Timer ihr eigenes Spiel?

Bitte entschuldigt nochmals die dumme Frage:oops:

mfg mephisto
 
FB's braucht man nur wenn man "wiederverwendbare" Funktionen in einen Baustein Programmieren möchte um diese über Instanz DB's immer und immer wieder aufzurufen mit anderen Parametern. so gennante "Multiinstanzen"

Oder wenn man intern mit statischen Variablen arbeiten möchte....
Macht manchmal sinn, zur übersicht, wenn man viele zwischergebnisse und werten rumhantiert..
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das würd dann heißen, dass ich mein Programm auch in einen FC packen könnte, oder?
Wenn ich es dann im FB lasse, muss ich dann einen iDB dazu erstellen, oder ist ein FB auch ohne zugehörigen DB lauffähig?

mfg mephisto
 
FB's braucht man nur wenn man "wiederverwendbare" Funktionen in einen Baustein Programmieren möchte um diese über Instanz DB's immer und immer wieder aufzurufen mit anderen Parametern. so gennante "Multiinstanzen"

Wobei eine Multiinstanz eigentlich ein FB Aufruf in einem FB darstellt. Nur ein Instanzdatenbaustein des 1.FB's, der die Instanzdaten der weiteren (multi) fb's beinhaltet.
 
Das würd dann heißen, dass ich mein Programm auch in einen FC packen könnte, oder?
Wenn ich es dann im FB lasse, muss ich dann einen iDB dazu erstellen, oder ist ein FB auch ohne zugehörigen DB lauffähig?

mfg mephisto

UC "FB1" <---ohne Parameter

Beschreibung

UC <Kennung des Codebausteins> (unbedingter Bausteinaufruf) ruft einen Codebaustein vom Typ FC, FB, SFC oder SFB auf. Die Operation UC gleicht der Operation CALL, mit dem Unterschied, daß keine Parameter übergeben werden können. Die Operation speichert die Rücksprungadresse (Selektor und relative Adresse), die Selektoren der beiden aktuellen Datenbausteine sowie das MA-Bit im B-Stack, deaktiviert die MCR-Abhängigkeit, erstellt den Lokaldatenbereich des Bausteins, der aufgerufen werden soll, und beginnt, den aufgerufenen Code auszuführen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
kann mal bitte einer einen FAQ-artikel zu OB, FB, FC, UDT, VAT, DB und iDB schreiben?

hier werden mal wieder fundamentale dinge durcheinander geworfen, es ist ne pracht... so zieht ihr keinem die wurst vom teller
 
Ist es wirklich war? Das ist Stoff vom S7-Serv2!!!!
Mach einfach immer FC, der Inschdanz-DB wirt nur von wenige, gantz Schlaue geprauchd!
 
Wenn ich nun ein Programm schreiben möchte, in dem nur einige Eingänge logisch verknüpft und auf Merker und Ausgänge geschrieben sollen und vielleicht noch der eine oder andere Timer/Zähler mit im Spiel ist, reicht dann ein FC, oder muss ich dann einen FB für mein Programm kreieren?
Und wenn ich einen FB kreiere, muss ich dann einen Instanz-DB dazu machen? Reinspeichern tu ich ja eigentlich nichts. Oder treiben da die Zähler/Timer ihr eigenes Spiel?

Bitte entschuldigt nochmals die dumme Frage:oops:
Es gibt keine dummen Fragen, nur dumme Antworten ;)

Also.... Ich hab schon viele Maschinen programmiert, die nur mit OB1 und lauter FC`s ausgestattet waren, dazu alles in FUP! Das hatte noch den Vorteil, das der Inbetriebnehmer und Instandhalter sich schnell und prima im Programm zurecht fanden.

Bitte nicht nur einen riesigen FC erstellen, sondern mehrere, nach (Maschinen)funktionen getrennt.

Zähler und Timer sind eigene und komplette Funktionen, du musst hier nichts weiter beachten. Die können im OB, FB oder FC stehen. (Die Siemens- Zähler habe ich noch nie verwendet, da programiere ich lieber selber einen Zähler mit einem MD, erhöhe den um 1 und frage dann den Zustand ab)

Ein grosser Unterschied zwischen FC und FB ist die Remanenz der lokalen Variablen, diese werden beim FB im DB gespeichert (DB`s sind grundsätzlich remanent), Lokalvariablen im FC sind im nächsten Zyklus alle auf 0.

Eine beliebte Prüfungsfrage ist: Mit Flanke M1.5 soll MW660 um 1 erhöht werden, funktioniert das hier im FC?

U M 1.5
FP #H1_Aenderung
SPBNB _001
L MW 660
L 1
+I
T MW 660
_001: NOP 0


Antwort: Im FC nicht, im FB ja


Bei Verwendung von FC kann man aber remanente Merker verwenden (Remanenz wird in der CPU eingestellt, Standard 16?) oder "unabhängige" DB verwenden, hier muss die Datenstruktur aber von Hand erstellt werden (Beim Instanz- DB eines FB wird die Datenstruktur automatisch erstellt).

Man muss aber keine DB verwenden, heutzutage gibt es genug Merker, die sollten bei kleinen Maschinen reichen!

Vorteil eines FB ist, das man hier eine Funktion programmieren kann, die man dann mehrmals mit verschiedenen DB aufgerufen wird. Ist elegant, aber kompliziert um online zu beobachten, besonders wenn mehrere Funktionen ineinander aufgerufen werden, insofern freue ich mich, wenn darauf verzichtet wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Pittie,

Lokalvariablen im FC sind im nächsten Zyklus alle auf 0.
Das ist, so glaube ich, nicht ganz korrekt.
Ich würde sagen die Lokalvariablen sind nicht klar definiert.
Je nach Aufrufstruktur und damit welcher Belegung im Lokaldatenstack stehen dort die richtigen Daten oder die völlig falschen.
Man darf sich nicht darauf verlassen das dort die richtigen Daten stehen,
aber darf sich auch nicht darauf verlassen das dort alles auf NULL steht.
Lokale Variablen in einem FC sollten vor einer Abfrage innerhalb des FC´s geschrieben worden sein.

So habe ich das in Erinnerung, aber ich lasse mich (wenn richtig) gerne eines besseren belehren. ;-)

Gruß
Toki
 
Hi Pittie,

Das ist, so glaube ich, nicht ganz korrekt.
Ich würde sagen die Lokalvariablen sind nicht klar definiert.
Je nach Aufrufstruktur und damit welcher Belegung im Lokaldatenstack stehen dort die richtigen Daten oder die völlig falschen.
Man darf sich nicht darauf verlassen das dort die richtigen Daten stehen,
aber darf sich auch nicht darauf verlassen das dort alles auf NULL steht.
Lokale Variablen in einem FC sollten vor einer Abfrage innerhalb des FC´s geschrieben worden sein.

So habe ich das in Erinnerung, aber ich lasse mich (wenn richtig) gerne eines besseren belehren. ;-)

Gruß
Toki

Stimme dem voll und ganz zu. Ich habe das vor längerer Zeit auch mal als Problem gehabt! Also evtl. den Inhalt vorher initialisieren (löschen)!
 
Eine beliebte Prüfungsfrage ist: Mit Flanke M1.5 soll MW660 um 1 erhöht werden, funktioniert das hier im FC?

U M 1.5
FP #H1_Aenderung
SPBNB _001
L MW 660
L 1
+I
T MW 660
_001: NOP 0


Antwort: Im FC nicht, im FB ja
Naja, das stimmt so auch nicht ganz. In einem FC geht das auch.
Du hast leider nicht beschrieben was #H1_Aenderung für ne Variable ist.
Wenn es eine INOUT-Variable ist, funktioniert das auch, bei Anlegen eines z.B. remanenten Merkers von Aussen.

@Toki:
Ich stimme dir voll und ganz zu.

Gruß wolder
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...
Ein grosser Unterschied zwischen FC und FB ist die Remanenz der lokalen Variablen, diese werden beim FB im DB gespeichert (DB`s sind grundsätzlich remanent), Lokalvariablen im FC sind im nächsten Zyklus alle auf 0.

...
Datenbausteine sind nicht grundsätzlich remanent. Es gibt die Baustein-Eigenschaft "Non-Retain" die für die Remanenz zuständig ist.
In welchen Fällen sie gilt, kannst du in den angegebenen FAQs nachlesen.
Es könnte dir also jemand deine Remanenz geändert haben.

* Remanenzverhalten der S7-300 CPU 31x sowie der Komplettgeräte C7-6xx mit MMC
* Remanenzverhalten der S7-400 CPUs und der CPU 318-2 CPUs
* Welche unterschiedliche Definitionen der Remanenz sind zwischen STEP 7 V10.5 und V11 beim Erzeugen eines Global-DBs zu beachten?

P.S.
Ist der von VL angefragte FAQ-Artikel schon in Arbeit?
 
jau

Stimme dem voll und ganz zu. Ich habe das vor längerer Zeit auch mal als Problem gehabt! Also evtl. den Inhalt vorher initialisieren (löschen)!

Das hatte ich auch schon mal und hab sparsam geguckt :)
Ich hab mit temp-variablen sprungbefehle ausgeführt und auf einmal wurden prg-zeilen übersprungen die nach der logik her nicht übersprungen werden durften.

Danach hab im ersten NW (FC) alle temp-variablen auf 0 gesetzt und das Problem war weg.

Später hab ich das auch in einem anderen Prg. gesehen. Der Programmierer der Maschine hatte wohl ähnliche Probleme.

mfg
elektromensch
 
Nach dem was ich darüber zu wissen glaube, ist das eine Krücke...

Wenn der Zustand von TEMP-Variablen bei der Verwendung nicht eindeutig ist, darf man diese einfach nicht verwenden. Sofern der Zustand über mehr als einen Zyklus gespeichert werden soll, muss man eben eine STAT-Variable oder einen Merker, etc. verwenden.

Wenn vor der Verwendung eine Zuweisung gemacht wird, ist der Zustand eindeutig. Dann muss man auch nicht "initalisieren". Da sehe ich den Sinn von TEMP-Variablen.
 
Zurück
Oben