# Wann FC und wann FB?



## Mephisto (20 Oktober 2011)

Hallo!

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

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

mfg mephisto


----------



## c.wehn (20 Oktober 2011)

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..


----------



## Mephisto (20 Oktober 2011)

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


----------



## Verpolt (20 Oktober 2011)

c.wehn schrieb:


> 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.


----------



## Verpolt (20 Oktober 2011)

Mephisto schrieb:


> 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.


----------



## vierlagig (20 Oktober 2011)

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


----------



## Ralle (20 Oktober 2011)

vierlagig schrieb:


> 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



Ok, hast Recht 4L, du hast den Job!


----------



## c.wehn (20 Oktober 2011)

Verpolt schrieb:


> 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.



Man lernt nie aus.


----------



## vierlagig (20 Oktober 2011)

Ralle schrieb:


> Ok, hast Recht 4L, du hast den Job!



c.wehn hat doch grad zeit und offensichtlich wissenslücken. kann er doch schön recherchieren und einen beitrag schreiben.


----------



## c.wehn (20 Oktober 2011)

vierlagig schrieb:


> c.wehn hat doch grad zeit und offensichtlich wissenslücken. kann er doch schön recherchieren und einen beitrag schreiben.



Gute Idee, mach ich, du kannst es dann verbessern.


----------



## Son of Wodan (27 Oktober 2011)

Ist es wirklich war? Das ist Stoff vom S7-Serv2!!!!
Mach einfach immer FC, der Inschdanz-DB wirt nur von wenige, gantz Schlaue geprauchd!


----------



## Tigerente1974 (27 Oktober 2011)

Hast Du Deine Pillen wieder nicht genommen???


----------



## 190B (27 Oktober 2011)

Vielleicht hat er ja nur eine Signatur ala VL vergessen?


----------



## Pittie (27 Oktober 2011)

Mephisto schrieb:


> 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


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.


----------



## Toki0604 (27 Oktober 2011)

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


----------



## MCerv (27 Oktober 2011)

Toki0604 schrieb:


> Hi Pittie,
> 
> Das ist, so glaube ich, nicht ganz korrekt.
> Ich würde sagen die Lokalvariablen sind nicht klar definiert.
> ...



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)!


----------



## wolder (28 Oktober 2011)

> 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
> ...


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


----------



## marlob (28 Oktober 2011)

Pittie schrieb:


> ...
> 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?


----------



## elektro_mensch (30 Oktober 2011)

*jau*



MCerv schrieb:


> 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


----------



## Tigerente1974 (30 Oktober 2011)

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.


----------



## Larry Laffer (30 Oktober 2011)

Hallo,
es ist keine Krücke - es hat nur seine Spielregeln.

Eine Temp-Variable ist sinnvoll dann eingesetzt, wenn man sie z.B. zur Bildung eines Zwischen-Ergebnisses (ob nun Binär oder Dezimal ist unerheblich) verwendet, das man dann *in der weiteren Folge des Bausteins* (*also nach der Wert-Zuweisung*) weiter verwenden möchte.

Gruß
Larry


----------



## Tigerente1974 (30 Oktober 2011)

Genau das habe ich mit anderen Worten auch gesagt.

Zugegeben hast Du den Nagel etwas schöner auf den Kopf getroffen.

Entscheidend ist eben, dass die Zuweisung VORHER kommen muss. Und wenn jemand sagt, eine Variable muss "initialisiert" werden, weil der Zustand beim Aufruf nicht eindeutig ist, ist das wohl nicht gegeben.

Die Krücke ist dann die Zuweisung mit 0 direkt am Anfang.


----------



## Larry Laffer (31 Oktober 2011)

@Tigerente:
Es ging mir eigentlich auch nur um die Vervollständigung deines Beitrages ...


----------

