# Unterschied FB  FC



## Anonymous (19 Mai 2005)

Wer kann mir den Unterschied zwischen  FB und FC nennen
Wann sollte besser ein FB genommen werden
Ich programmiere alles in FCs


----------



## kpeter (19 Mai 2005)

Hallöchen

FB hat statische variabeln die im DB gespeichert werden

fc Daten werden nur in Lokaldatenstack hinterlegt
damit sind z.b. temp Daten nur 1 Zyklus kültig
und könnnen nur für z.b. zwischenergebnisse genommen werden

fc kein gedächniss
fb hat seinen db


----------



## plc_tippser (19 Mai 2005)

FB´s machen dann sinn, wenn der Baustein öfters genutzt werden soll, da er ohne Probleme komplett mit lokalen Variablen arbeiten kann. Dafür benötigt er aber mehr Resourcen.

pt


----------



## e4sy (29 Juni 2005)

sind die temporären variablen in einem FB länger als ein zyklus gültig?!? die werden doch auch beim FB nich im DB abgelegt ^^

und kann man FC´s nich auhc öfter aufrufen? 

Ich dachte immer das man FCs nimmt wenn man keine ergebnisse zurück bekommt und FBs wenn ich diese zurück haben will. wurde aber auch die tage eines besseren belehrt... daher bin ich auch grad hier


----------



## RMA (29 Juni 2005)

> sind die temporären variablen in einem FB länger als ein zyklus gültig?!? die werden doch auch beim FB nich im DB abgelegt ^^



Die Temp Variablen im FB sind, wie der Name es schon sagt, nur für einen Zyklus gültig.



> und kann man FC´s nich auhc öfter aufrufen?



Ja, man kann einen FC öfter aufrufen um die selbe Funktion mit unterschiedlichen Parameter auszuführen. 


```
Ich dachte immer das man FCs nimmt wenn man keine ergebnisse zurück bekommt und FBs wenn ich diese zurück haben will. wurde aber auch die tage eines besseren belehrt... daher bin ich auch grad hier
```

Man hat drei Möglichkeiten Ergebnisse von einem FC zurück zu kriegen:

OUT Parameter
IN/OUT Parameter
RET_VAL


----------



## Zottel (29 Juni 2005)

RMA schrieb:
			
		

> > sind die temporären variablen in einem FB länger als ein zyklus gültig?!? die werden doch auch beim FB nich im DB abgelegt ^^
> 
> 
> 
> Die Temp Variablen im FB sind, wie der Name es schon sagt, nur für einen Zyklus gültig.


Nein, für einen Aufruf.


> > und kann man FC´s nich auhc öfter aufrufen?
> 
> 
> 
> Ja, man kann einen FC öfter aufrufen um die selbe Funktion mit unterschiedlichen Parameter auszuführen.


Man kann sowohl FBs als auch FCs mehrmals in einem Zyklus aufrufen. In beiden Fällen sind die lokalen Variablen nur *innerhalb desselben Aufrufs* gültig. (Obwohl sie die Werte des letzten Aufrufs beibehalten werden, wenn zwischendurch kein anderer Baustein aufgerufen wird, der lokale Variablen nutzt. In diesem Fall bleibt einfach der Inhalt des Stacks unverändert.)


----------



## kpeter (29 Juni 2005)

Mal eine kleine Diskussion in den raum stellen werde

ok laut lehrbuch tempvar in FB nur einen Zyklus gültig

aber

die Tempvar im FB werden im DB hinterlegt sollten sie somit nicht auch beim nächsten zykluss noch dort sein wo man sie hingetan hat  :lol: 

im fc ist ja klar da steht das ganze im stack

viel spass beim nachdenken


----------



## sps-concept (29 Juni 2005)

*Temp*

Hallo Peter,

schau mal den Instanz-DB an... da liegen meiner düsteren Erinnerung nach nur IN  OUT  IN/OUT  und STAT.

MfG
André Räppel


----------



## kpeter (29 Juni 2005)

hallöchen

ups  :shock:  :shock:  :shock: 

hab ich mich mal verschaut dachte die sind auch drinnen  :shock: 

tja dann ist ja alles gut

vergesst meine frage schande über mich 

und danke


----------



## RMA (29 Juni 2005)

> Verfasst am: 29.06.2005, 13:55    Titel:
> 
> --------------------------------------------------------------------------------
> 
> ...



Stimmt, hab' ich gewusst aber zu schnell geantwortet!


----------



## e4sy (30 Juni 2005)

also kann ich eigentlich nehmen was ich will. nur das der FB im nächsten zyklus - dank DB - noch weis was er getan hat.


----------



## leo (30 Juni 2005)

Jetzt ist Bernd (und mir) aber immer noch nicht klar wozu es FBs gibt. Ich habe zumindest noch keinen gebraucht, ausser bei Systemfuktionen wo ich vorgefertigte Beispiele umgefrickelt habe.
Gruß, Leo


----------



## RMA (30 Juni 2005)

Abgesehen von dem was schon gesagt worden ist, einer der grossen Vorteile von FBs ist das man Local Daten (STATs) statt Merker benutzen kann. Damit kann man sauberer programmieren und behält den Überblick. Insbesonders wenn man Multi-Instanzen benuzt ist dies vom Vorteil.


----------



## Anonymous (30 Juni 2005)

hi,
außerdem was ist wenn ich einem parametrierbaren fb eine pos flanke als eingang verschalte , der mir einen ausgang dieses fb´s ausgibt ? es wäre ja äußerst ungünstig wenn dieser nur einen zyklus anstehen würde  ,
dann ist es auch noch unheimlich praktisch keine merker verheizen zu müssen.
mfg


----------



## leo (30 Juni 2005)

Hm - ich greife immer von FCs auf Global-DBs zu deren bits ich als merker verwende. Wo liegt der Unterschied, Zykluszeit?
Gruß, Leo


----------



## Anonymous (30 Juni 2005)

na also unterschiede gibt ´s genug, z.b. der Speicherplatz der größer wird,
unnötiges auslasten der datenbausteine ( kann bei rezeptverwaltungen auch mal eng werden ) und außerdem ist man ja meist versucht, seine Bausteine Bibliotheksfähig zu machen, da würde ein globaler db ja auch stören lieber eine instanz die dann automatisch generiert wird. Auch sind dabei multiinstanzen eine interesannte Sache.ob es unterschiede in der zykluszeit gibt kann ich dir leider nicht sagen.
mfg


----------



## RMA (30 Juni 2005)

> außerdem was ist wenn ich einem parametrierbaren fb eine pos flanke als eingang verschalte , der mir einen ausgang dieses fb´s ausgibt ?



Es hängt natürlich davon ab wie man es programmiert, aber normalerweise wenn man etwas in einem FB mit einer Flanke dann setzt man einen localen variablen mit der Flanke, der als STAT deklariert ist und weil dies im DB gespeichert ist, ist er auch im nächsten Zyklus da - und im nächsten und im nächsten ... bis man es zurücksetzt.



> Hm - ich greife immer von FCs auf Global-DBs zu deren bits ich als merker verwende. Wo liegt der Unterschied, Zykluszeit?



Wenn man nur ein Instanz hat, dann geht das. Aber wenn man mehrere Instanzen hat muss man andere Bits deklarieren für jeden Instanz. Mit lokalen VAriablen (STATs) deklariert man die nur einmal und das Betriebssystem organisierten selbstständig unterschiedliche Speicherbereiche für jeden Instanz.


----------



## Anonymous (25 August 2005)

Wichtiger Punkt, der bislang noch nicht angesprochen wurde. 
Beim FC müssen alle Parameter beschaltet werden, beim FB nicht; das macht ihn einstück weit flexibler in der Handhabung


----------



## RMA (25 August 2005)

Weiter wichtiger Punkt der noch nicht angesprochen ist, weil der lokale Speicher für die Temps vom Betriebssystem zur Verfügung gestellt wird, ist der Inhalt dieser Speicher unbekannt. Deswegen *mussen *alle Temps in einem FB/FC geschrieben werden bevor sie abgefragt oder benutzt werden, sonst ist der Zustand undefiniert. Dies kann insbesondere bei Programmteilen die bedingt übersprungen werden zu Problemen führen.

Was vielleicht auch hier zu erwähnen wäre, es gibt einen Unterschied zwischen Sprünge mit einem 300er CPU und einem 400er. Unter Umständen kann der VKE-Zustand bei einem Sprung in einem 300er CPU "mitgeschleppt" werden, was unter Umständen eine folgende logische Auswertung verfälschen kann. Deswegen wenn man mit einem Sprung zum Anfang einer neuen logischen Kette springt soll man mit SET oder CLR den Ausgangszustand festlegen. Die Details dazu findest Du bei einem FAQ auf die Siemens Support Seiten hier.


----------



## Anonymous (26 August 2005)

Hallo

Wichtigster Unterschied:

Parameterübergabe an den FC/FB:

FC: Die Parameteradresse wird im Code des AUFRUFENDEN Bausteins direkt nach dem CALL FC hinterlegt, die Daten selber liegen dann im L-Stack, beim Zugriff aus dem FC auf den Parameter muss deswegen immer erst die Adresse ermittelt werden, dauert also etwas aber dafür muss man sich nicht um die DBs kümmern!

FB: Der Editor sorgt hier dafür das alle Parameter in den Instanzdatenbaustein geschrieben werden, dort holt sie dann der FB heraus, ist schneller aber man braucht für jeden FB einen eigenen DB oder Multiinstanzen

Temporäre Variablen:

FC: es gibt nur temporäre Variablen auf dem L-Stack, diese müssen wie bereits erwähnt, initialisiert werden. Nach Verlassen des FCs sind die Daten dann auch weg!

FB: es gibt temporäre Variablen auf dem L-Stack (siehe FC) und temporäre Variablen (statisch) im Instanzdatenbaustein welche dann nur vom User verwaltet werden.




FC sind gut für modulare Programmierung geeignet, da sie beliebig oft (was der B-Stack halt so hergibt) und aus jeder Stelle ohne Kenntnisse des restlichen Programms aufgerufen werden können


Gruß


----------



## rabit (1 Februar 2014)

Hallo interpretiere ich das nun richtig:

FC1 : Bsp. Out: mw2
FC2 : Lade  mw2 
Würde FC2 den Wert aus mw2 nich finden da die Daten gelöscht sind?
Wenn ich aber in FC1 schreibe Out: db2.dbw2 würde ich den doch ausserhalb von FC1 wiederfinden oder?

Fb1 : Bsp. Out: mw3
Was müsste ich nun machen wenn ich den mw3 haben möchte ohne einzugeben zu müssen dbx.dbw3?

Kann ich auch gnz normal die Daten aus einem Instanz db beispielsweise DB1 Wort 0 mit : DB1.DBW0 abrufen?


----------



## Larry Laffer (1 Februar 2014)

Hallo,
- es ist immer besser etwas an eigenem Beispiel zu erfragen.
- mit ungeraden Merkerwörtern solltest du dir erst gar nicht angewöhnen zu arbeiten (überlappende Speicherbereiche)
- du kannst auf die Daten eines Instanz-DB's (wie auf die eines beliebigen anderen DB's) zugreifen - ich persönlich halte das aber außerhalb des FB's für schlechten Stil.

Gruß
Larry


----------



## hucki (1 Februar 2014)

rabit schrieb:


> FC1 : Bsp. Out: mw2
> FC2 : Lade  mw2
> Würde FC2 den Wert aus mw2 nich finden da die Daten gelöscht sind?


Das sind die globalen Speicher, die außerhalb (beim Aufruf) der FC angegeben werden. Somit findet FC2 die ausgegebenen Daten von FC1 auch wieder.
Nur die lokalen Daten, die innerhalb der FC verwendet werden (zu erkennen an der Raute #), werden mit der Beendigung der FC zum Überschreiben frei gegeben.


----------



## rabit (1 Februar 2014)

Vollkommen richtig was ihr beide sagt.
Ich mache das auch nicht so, klar MW 2, 4 ,6 usw 
Auch Funktionen mit zu speichernde Daten lege ich in einen FB.
Jedoch wollte ich erfragen ob es möglich ist was Ihr ja beantwortet habt.
Die Raute ist ein super Hineweis.
Ich habe es mal ausprobiert und sehe keine Raute?
Habe ich was falsch gemacht?
Wie kann ich denn nun ausserhalb vom FB1 und FC1 auf die
In Variable (2567) zugreifen und auf die Merkerwörter ohne dies in einem DB separat zu speichern?

Ich bekomme nicht in meine Hirse welche daten verloren gehen?

Oder meint Ihr in etwa wenn ich anstelle 2567 eine PEW 256 in FB 1 abfrage und diese dann irgendwo abgespeichert werden? Etwa in EW 256 und das gleiche mit FC 1 mache, und auf EW 256 nicht zugreifen kann weil Daten temporär gespeichert und beim verlassen des FC1 gelöscht wird?


----------



## shutdown_TIA12 (1 Februar 2014)

Ich habe das Gefühl, dass du die grundlegenden Sachen nicht verstanden hast bzw. nicht verstehst
Die Raute ist *im* Baustein zu sehen, nicht außerhalb deines Bausteins. die zahl 2567 ist eine konstante Zahl, keine Variable. *Im* Baustein wirst du auf die Variable mit #In2 zugreifen können.

```
L #In1
L #In2
+I
T #Out
```

Du übergibst zwei Werte für In1 und In2... Ob das jetzt ein fester konstanter Wert, ein Merkerwort, ein Eingangswort ist oder im Datenbaustein abgelegt ist, ist dem Baustein egal (Typ muss jedoch stimmen). Den Wert, den du an #Out übergibst, muss außerhalb des Bausteins gespeichert werden (z.B. in einem Merkerwort).

In deinem Beispiel macht ein FC mehr Sinn. 
Wenn du Variablen im Baustein verwendest, die für den nächsten Aufruf wichtig sind, gehören die in den static Bereich rein, ergo brauchst du ein FB. Alternativ geht auch ein FC mit InOut Variablen.

Deine letzten zwei Sätze sind mir zu umständlich und kann den Gedankengang nicht ganz nachvollziehen. Kannst du dich da noch etwas klarer ausdrücken? Danke

EW - Eingangswort  (wird zu Beginn eines Zykluses aktualisiert)
PEW - Prozesseingangswort (Wert wird zum Zeitpunkt der Abfrage ermittelt)


----------



## rabit (1 Februar 2014)

Ich habe vermutet wenn ich einen PEW 256 abfrage dan frage ich ihn in dem Moment des Abfragezeitpunktes ab wenn ich aber eine weile später den PEW 256 zum Zykluszeitpunkt
 haben möchte da sich die Werte von PEW wieder geändert haben dachte ich frage ich den EW 256 ab da die Zyklusmäsige PEW Abfrage in einem EW abgelegt wird??


----------



## hucki (1 Februar 2014)

rabit schrieb:


> Die Raute ist ein super Hineweis.
> Ich habe es mal ausprobiert und sehe keine Raute?
> Habe ich was falsch gemacht?


Du hast keine Variablen im oberen Bereich bei IN, OUT usw. angelegt.
 Das ist die Schnittstelle des Bausteins. Mit deren Hilfe werden beim Aufruf Daten von außerhalb des Bausteins, z.B. das MW2 auf die lokalen Variablen, das sind die, die Du dort oben angelegt hast, übergeben.
Dadurch kann man bei mehreren Aufrufen des Bausteins verschiedene globale Variablen an die gleichen lokalen Variablen zur immer gleichen Verarbeitung übergeben bzw. von diesen zurück bekommen.


----------



## rabit (1 Februar 2014)

Ich habe es versucht nachzubauen.
Kann mir nun jemand in Fup ergänzen wie ich diese Schnittstellen von einem anderem Baustein lesen /beschreiben kann?


----------



## hucki (1 Februar 2014)

Ruf doch mal Deinen FB jetzt im OB1 auf.

Dann wirst Du 3 neue PINs sehen und zwar mit den Namen Deiner erstellten Variablen. Deswegen heißen sie Schnittstelle. Sie stellen die Verbindung von der "Außenwelt" zum "Innenleben" des FBs dar.

Direkt auf das "Innenleben" des FBs (den IDB) zuzugreifen geht zwar, löst hier aber sicher kontroverse Diskussionen aus, ob das einen guten Programmierstil darstellt oder nicht. Ich persönlich bin da eher Larrys Meinung:


Larry Laffer schrieb:


> - du kannst auf die Daten eines Instanz-DB's (wie auf die eines beliebigen anderen DB's) zugreifen - ich persönlich halte das aber außerhalb des FB's für schlechten Stil.


----------



## rabit (1 Februar 2014)

Ok habe ich aufgefufen sehe zwar die 3 Pinne nicht aber habe verstanden was Du meinst.
Wäre super den Fehler rauszubekommen.
So also könnte ich diese 3 zusätzlichen "Pinne" immer mit mir belibigen Konstante, Wörter etc. beschalten?


----------



## hucki (1 Februar 2014)

rabit schrieb:


> Ok habe ich aufgefufen sehe zwar die 3 Pinne nicht aber habe verstanden was Du meinst.
> Wäre super den Fehler rauszubekommen.
> So also könnte ich diese 3 zusätzlichen "Pinne" immer mit mir belibigen Konstante, Wörter etc. beschalten?


Im Bild sehe ich die 3 Pins zwar noch nicht, aber naja.

Weiter oben hast du direkt an die Addition das MW6 und 2567 direkt an die Eingänge der Addition gegeben und das Ergebnis ins MW8 schreiben lassen. Das machst Du jetzt an den 3 Pins des FB. Bei ner einfachen Addition macht das zwar noch nicht wirklich Sinn, aber lass mal im FB beide Werte addieren und zusätzlich das Ergebnis mit jedem einzelnen Eingangswert multiplizieren.
Dann kannst Du das immer wieder mit verschiedenen Eingangswerten machen.
Bei solch einfachen Operationen bräuchtest Du noch keinen Zwischenspeicher (=IDB). Deshalb würde dafür auch eine Funktion FC ausreichen.
Wenn aber Daten anfallen, die Du nur innerhalb dieses Bausteins, aber für den nächsten Zyklus, brauchst, wählst Du einen FB. Solche Daten sind z.B. Flankenmerker, Zustandsmerker für Ausgänge, die über Setzen und Rücksetzen eingestellt werden, Timer, Zähler, Zwischenergebnisse u.ä..


----------



## rabit (1 Februar 2014)

Ok alles verstanden aber warum sehe ich diese 3 Pinne nicht ?


----------



## hucki (1 Februar 2014)

rabit schrieb:


> Ok alles verstanden aber warum sehe ich diese 3 Pinne nicht ?


Weil der Aufruf noch nicht aktualisiert ist. Eventuell mußt Du den OB1 noch mal neu öffnen, um über das Kontextmenü aktualisieren zu können.
Und der FB muss natürlich nach dem Anlegen der Variablen auch gespeichert worden sein.


----------



## rabit (1 Februar 2014)

Nein macht er nicht, habe alles aktualisiert.
Kann es daran liegen das es eine Lite Version ist?


----------



## hucki (1 Februar 2014)

rabit schrieb:


> Nein macht er nicht, habe alles aktualisiert.
> Kann es daran liegen das es eine Lite Version ist?


Kann sein. Sieht aber auch nicht wie Step7 bei mir aus.


----------



## Mich89 (29 Mai 2019)

hucki schrieb:


> Im Bild sehe ich die 3 Pins zwar noch nicht, aber naja.
> 
> Weiter oben hast du direkt an die Addition das MW6 und 2567 direkt an die EingÃ¤nge der Addition gegeben und das Ergebnis ins MW8 schreiben lassen. Das machst Du jetzt an den 3 Pins des FB. Bei ner einfachen Addition macht das zwar noch nicht wirklich Sinn, aber lass mal im FB beide Werte addieren und zusÃ¤tzlich das Ergebnis mit jedem einzelnen Eingangswert multiplizieren.
> Dann kannst Du das immer wieder mit verschiedenen Eingangswerten machen.
> ...



Hallo!
FCs und FBs sind mir schon klar, aber ich bin mir noch nicht sicher, wann ich was wirklich einsetzen soll.

Wenn ich einen Baustein habe, der nur intern Daten verarbeitet und nicht von außen zugegriffen werden soll (auch nicht von Visu), dann nehm ich natÃ¼rlich einen FB (wenn Stat-Daten benötigt werden).

Aber wie sieht es aus, wenn ich Signale aus anderen Bausteinen abfragen muss?

Beispiel Schrittkette:

STEP ist eine interne Variable, die erhalten bleiben muss. -> Also erstelle ich einen FB.
In der Schrittkette wird aber abgefragt, ob Bedingungen aus anderen Bausteinen erfüllt sind. -> Für globale Daten erstelle ich einen Datenbaustein ("GDB"), in dem alle globalen Variablen drinnen stehen.

Variablen auf die von einer Visu zugegriffen wird, schreibe in auch in den "GDB", damit STAT Daten wirklich Interne Variablen sind. 
(Auch wenn sie nur gelesen werden, es sei denn es handelt sich um fertig getestete FBs (FB283,...), wo sich die Schnittstelle nicht mehr verändert)


Habt Ihr bessere Vorschläge, wie man den Programmaufbau möglichst übersichtlich und modular hinbekommt?

mfG
Michael


----------

