# FC gegen FB



## martin3885 (20 Juli 2006)

Hi,
die Frage:Was ist der Unterschied:
Fall 1: ein FB mit einem InstanzDB. In diesem FB werden statische Variablen benutzt. 
Fall 2. ein FC ohne InstanzDB aber ein globaler DB. In dem globalen DB werden die Variablen gespeichert, die statt statischen Variablen im Fall 1 benutzt werden.

Was ist eigentlich der Unterschied zwischen den beiden Faellen? 
Werden die beide Programmen immer gleich funktionieren?

Gruss.
Martin


----------



## PeterEF (20 Juli 2006)

Hallo,

das kommt mir ein wenig vor wie Äpfel mit Birnen zu vergleichen . Im Prinzip funktioniert beides gleich. Die Probleme gehen los wenn:

1. Der Baustein mehrfach verwendet werden soll: bei FB einfach anderen Instanz-DB nehmen, andere Ein- und Ausgänge und gut ist (mehr dazu s.a. Multiinstanz im Handbuch). Im Fall des FC müssen alle relevanten Adressen im Code des FC angepaßt werden - fehleranfällig.

oder 2. Der Baustein in einem anderen Programm laufen soll: bei FB einfach anderen Instanz-DB nehmen, beim FC (falls die Adressen für die globalen Daten schon anderweitig verwendet werden): es müssen alle relevanten Adressen im Code des FC angepaßt werden - fehleranfällig.

Weiß jemand, ob es Unterscheid im zeitbedarf zur Laufzeit bei den verschiedenen Varianten gibt?


----------



## Supervisor (20 Juli 2006)

*Step 7 Hilfe*



			
				martin3885 schrieb:
			
		

> Hi,
> die Frage:Was ist der Unterschied:
> Fall 1: ein FB mit einem InstanzDB. In diesem FB werden statische Variablen benutzt.
> Fall 2. ein FC ohne InstanzDB aber ein globaler DB. In dem globalen DB werden die Variablen gespeichert, die statt statischen Variablen im Fall 1 benutzt werden.
> ...


 
In der Hilfe von Step 7 mal in der Suchmaske Index die Begriffe "FC" bzw. "FB" eingeben. Da findest du auch nochmal Erklärungen.

Grüße!


----------



## Unregistrierter gast (20 Juli 2006)

martin3885 schrieb:
			
		

> Hi,
> die Frage:Was ist der Unterschied:
> Fall 1: ein FB mit einem InstanzDB. In diesem FB werden statische Variablen benutzt.
> Fall 2. ein FC ohne InstanzDB aber ein globaler DB. In dem globalen DB werden die Variablen gespeichert, die statt statischen Variablen im Fall 1 benutzt werden.
> ...



Ein Unterschied ist, dass der FB die Organisation der Daten (Lokaldaten und I/O)  selber durch die Deklarationstabelle vornimmt.

Bei einen FC mit Global - DB musst du die Daten selber sichern und rückladen.

Ich halte es so:
Sollen wenig Daten im "Gedächniss" bleiben (nur ein Hilfsdatenwort z.B.) dann FC mit Hilfdatenwort als Parameter.

Ist der Umfang der zur Funktion gehörigen Daten grösser (mehrere Worte), dann FB mit Instanz-DB.


----------



## nade (9 Februar 2020)

Das erste was ich zu meiner Frage hin gefunden habe. FC oder FB, das ist nun die Frage.

Hab mich bisher nie damit beschäftigen müssen, aber jetzt kam da die Gelegenheit, eine Anlage mit Klappertechnik und sehr viel von Hand geschaltet etwas technischer zu machen.
Vorgabe war die Sicherheit bei Not Aus zu erhöhen, und die Technik aus 1970.. 1980 so um den dreh rum etwas neuer zu Gestalten.
Logo ungeeignet, Easy.. nicht so einfach wie sie heißt. Mal von ab, dass zu viele ein und Ausgänge benötigt werden. Also wurde es eine S1200 1214 c.
<-- Soweit die Vorgeschichte.
Jetzt habe ich 7* die selbe Funktion in der Anlage. 7* via Taster einen Teilbereich ein/aus. (<-- da wo ich mir mit dem FC oder FB nicht ganz sicher bin) und dann das ganze noch mit einem Anlagen Starten gesamt ein.

Der FC/FB beinhaltet 2* positive Flanke, ein RS, was ja alles einen Merker brauch, 1 Eingang für ein bzw Ausschalten, Eingänge für Anlage aus, Notaus von einem Sick Relais und 1-2 Eingänge für Phasenüberwachungsrelais. 

Jetzt, da es sich hier ja um Programierstrategie handelt, was ist für einen FC/FB mehrfach zu verwenden die bessere Wahl?
Der FC? Geht der überhaupt ohne DB und ohne großen Aufwand mit Merker neu vergeben? Oder doch lieber einen FB mit Instanz DB?
Die Merker werden nirgends sonst im Programm benötigt.


----------



## ducati (9 Februar 2020)

Die Mehrfachverwendung von FC + Global DB funktioniert auch ohne dass man die stat. Variablen im FC "umverdrahten" muss.
Man verwendet im Global DB ein Array für die Stat. Variablen des FC. Der FC bekommt dann einen Eingang mit der jeweiligen lauffenden Nummer des Arrayelements....
Variante 2 wäre die Daten des Global DB als UDT jeweils als INOUT an den FC dranzuhängen...


Aber alles Ansichtssache welche Variante jedem persönlich besser gefällt ist.


----------



## nade (9 Februar 2020)

ducati schrieb:


> Die Mehrfachverwendung von FC + Global DB funktioniert auch ohne dass man die stat. Variablen im FC "umverdrahten" muss.
> Man verwendet im Global DB ein Array für die Stat. Variablen des FC. Der FC bekommt dann einen Eingang mit der jeweiligen lauffenden Nummer des Arrayelements....
> Variante 2 wäre die Daten des Global DB als UDT jeweils als INOUT an den FC dranzuhängen...
> 
> ...



okeh. Also reicht ein FC. Jetzt fängts aber auch gerade an. Ein und Ausgänge habe ich aus dem FC als quasie Blackbox verdrahtet bekommen. Wie geht das nun mit den Merker? Und wie das mit dem Array für Stat. Variablen? Sorry so weit hab ich mich leider nicht mit S7 beschäftigt, da seit der Meisterschule nun die erste Firma die sich mal mit Steuerungen mehr beschäftigt als nur großspurig zu behaupten, was mit zu machen.


----------



## Paul (11 Februar 2020)

Hallo


nade schrieb:


> okeh. Also reicht ein FC. .....


Wie sieht es denn mit dem verfügbarem Speicherplatz aus?
Wenn der ausreichend vorhanden ist würde ich zum FB raten.
Einfach aus dem Grund, weil du dann deine Flanken etc. in den STAT-Bereich legen kannst und sie nicht via IN_OUT übergeben musst.

Wenn du Ein- und den Selben FB oder FC (mit dem selben Funktionsablauf) mehrfach aufrufen willst musst du folgendes *unbedingt* beachten:
Eine Variable wie zum beispiel "NOT-AUS OK" kannst du natürlich *lesend* bei jedem Aufruf abfragen (auch mit absoluter Adresse).
Andere Sachen wie z. B. Wartezeiten dürfen bei Mehrfachaufruf im Baustein *nicht* *absolut* adressiert werden weil der Baustein ja in jedem OB1 Zyklus 7 mal durchlaufen wird. Die müssen also beim FC über IN_OUT übergeben werden. 
Der Vorteil beim FB ist auch dass du sowas dann im STAT-Bereich des Instanz-DB  ablegen kannst und du somit nie Überschneidungen hast.

Wenn es der Speicherplatz zulässt würde ich sogar so weit gehen 7 eigene FBs für die 7 Stationen zu machen.
Grund: Du tust dir leichter bei der Fehlersuche und wenn bei einer der 7 "Gleichen" Stationen was doch nicht so
Gleich sein soll (z. B. irgend eine zusätzliche Meldeleuchte) dann bist du wesentlich flexibler wenn jede Station einen 
eigenen FB / FC hat.


----------



## ms_gp (11 Februar 2020)

Da du mit einer neueren Steuerung (S7-1200) arbeitest, nimmst du auf jeden Fall einen FB. Dann bist du flexibler.
Über Speicherplatz sollte man sich heutzutage ja wohl keine Gedanken mehr machen müssen.

Zur Historie, so wie ich es mit den FCs zusammenreime:
_Diese Sache mit den FCs und dem externen Gedächtnis ist eine Krücke aus S7-Classic Zeiten. Man verwendete die INOUT Daten als Gedächtnis der Funktion, weil der Nummernkreis für die Instanz-DBs bei der Verwendung von FBs begrenzt war.
So war es zumindest bei uns. Man hatte hatte für eine Funktion/Teilmaschine so 10DB Nummern zur Verfügung. Ich konnte also nur maximal 10 Instanz-DBs anlegen, zumindest wenn man im definierten Nummernkreis bleiben wollte. Deshalb hat man dann einfach in einem DB ein Array von Instanzdaten angelegt und die per INOUT verschaltet. Das Ergebnis ist dann technisch fast gleichwertig. Nachteil ist der etwas höhere Programmieraufwand, weil du ja die Daten in einem externen DB anlegen muss und dann noch verschalten muss._

Ich würde das heute nicht mehr machen, wozu auch? Nummern gibt es nicht mehr. Alles ist symbolisch.

Du programmierst einen FB und instanziierst diesen. Fertig. Wozu sich Gedanken machen, wo die Daten von irgendwelchen Timern und Flanken rumliegen. Wenn du dann merkst, dass ein Teil der Maschine doch noch extra Funktionen braucht, dann kannst du ja den FB kopieren, ändern und nur diesen Teil der Maschine neu instanziieren. 
Mit dem FC müsstest du jetzt noch einmal extra das externe Gedächtnis auseinanderreißen. Geht auch, aber wozu machen? Hat keine Vorteile.


----------



## nade (11 Februar 2020)

Paul schrieb:


> Hallo
> 
> Wie sieht es denn mit dem verfügbarem Speicherplatz aus?
> Wenn der ausreichend vorhanden ist würde ich zum FB raten.
> ...



Da komm ich glaub auch etwas ehr mit der Datenbank anlegen klar. Mit Array.. da war ich grad etwas  

Also Speicher usw. müsste reichen, da es sich hierbei um "gerademal" 56 ein und Ausgänge. Merker werden dann ja durch die DB´s ersetzt.

Die ganze "Kiste" hat fast 50m länge mit:

1Abwickler Drehzahl über einen Hydraulik manuell geregelt (will der Kunde beibehalten)
1 Kleberolle über DC Motor
1 Bandmotor via Getriebe
1 Heiztunnel mit 5 Lüftermotoren auch weiter Konventionell und Öl Wärmetauscher
1 Kühltunnel mit 7 Lüftermotoren 
1 Kettenband via FU über Poti
1 Hydraulik Aufwickler Geschwindigkeit über Hydraulik
1 Kühlwasserventil
Jede in die Steuerung noch integrierbare Funktion wie z.B. Fu Drehzahl usw ist vom Kunden nicht gewünscht bzw. kein Bedarf.

Also einfach nur alle Abschnitte einzeln Ansteuerbar für Wartung Testlauf trallala, und dann noch eben eine Start/Stop für alles auf einmal. Notaus über ein Notausrelais.
Effektiv nichts besonderes, nur mit Ein/Aus über eine Taste um Platz und Eingänge zu sparen halt Stromstoßschalter für Einzelfunktionen. Motorschutz in Gruppen zusammen gefasst.
Also keine Analogwert, Fu, Zähler. Glaub da ist noch etwas Platz für die DB´s
 Hab ja noch etwas Zeit so neben der Normalen Arbeit wie Service und andere Spezialfällen das dig Zusammen zu Basteln. Da ja auch alles neu Verkabelt werden soll, kann ich erstmal gediegen zurück legen und das Programm so nebenbei aufbauen.

Ist auch nichts Zeitkritisches dabei. NotAus wird übern Sick den Ausgängen die Steuerspannung geklaut und im Programm alles Zurückgesetzt.


----------



## Paul (12 Februar 2020)

nade schrieb:


> Merker werden dann ja durch die DB´s ersetzt.


Du kannst natürlich auch weiterhin Merker verwenden. Die gibt es nach wie vor.
Auch wenn jetzt gleich wieder ein paar "Junge Wilde" aufschreien werden, dass solcher antiquierter Kram verboten gehört
und jeder der es benutzt, sich am besten gleich eingraben lassen sollte.

ACHTUNG, Wenn du DBs verwendest:
Bei TIA musst du es explizit anhaken  wenn ein DB *remanent *sein soll. 
War Anfangs sehr gewöhnungsbedürftig für mich.




nade schrieb:


> ......Jede in die Steuerung noch integrierbare Funktion wie z.B. Fu Drehzahl usw ist vom Kunden nicht gewünscht bzw. kein Bedarf......


Bei der Auftragsvergabe, wenn's um den Preis geht, dann Ja.
Wenn das Ding dann in Betrieb geht, dann geht's los. "Kannst du da mal schauen.... wär doch schön wenn wir das noch ..."



nade schrieb:


> ... so neben der Normalen Arbeit wie Service und andere Spezialfällen das dig Zusammen zu Basteln. .., kann ich erstmal gediegen zurück legen und das Programm so nebenbei aufbauen.....


Das wäre das Erste mal, dass das so läuft 
Sieh zu dass du da drüber bleiben kannst wenn du mal angefangen hast.
Mit "so nebenbei" fliegt dir das um die Ohren, zumal du ja sowas scheinbar noch nicht sooo oft gemacht hast.


----------



## nade (12 Februar 2020)

Das mit Remanent habe ich schon gesehn, hatte erst von Step 5.2 erst etwas schwierigkeiten gehabt, weil der "Call" Befehl etwas anderst angewendet wird. Ok, war mal etwas mit der 1200er zu beschäftigen privat gebastel, aber habs nun auch hin kriegt.

Ach ja, da wird kein anderer in der Firma rum Arbeiten, wir können uns Glücklich schätzen, dass unsere Firmenkunden fragen nur was geht bzw sagen was sie wollen, und ab dafür grobe kosten Richtung bei größeren Sachen, aber wird immer nach tatsächlicher zeit abgerechnet.
Der Auftrag ist unter anderem bereits frei mit was ich jetzt so schon an Material zusammen gefaßt habe, sehr großem Zeiteinsatz. Da alle Leitungen erneuert werden, wird das neue parallel errichten.
Das Konzept steht, das Programm auch bis eben auf die sich wiederholende Tastersache, also eben die Nachfrage nach FC oder FB für gleiche Blöcke.

Einfache Steuerungen sind das Problem nicht, ehr das jetzt mal ne Stufe weiter mit DB.

Aber dafür sind ja hier reichlich für und wieder mit Begrünung. :s1:


----------



## ducati (13 Februar 2020)

ms_gp schrieb:


> Da du mit einer neueren Steuerung (S7-1200) arbeitest, nimmst du auf jeden Fall einen FB. Dann bist du flexibler.
> Über Speicherplatz sollte man sich heutzutage ja wohl keine Gedanken mehr machen müssen.
> 
> Zur Historie, so wie ich es mit den FCs zusammenreime:
> ...



Das Problem beim TIA ist halt das Reinitialisieren der InstanzDBs. Wenn Du halt oft/immer Änderungen im laufenden Betrieb machen willst/musst. Ist man mit FCs deutlich besser aufgestellt... Lustigerweise werden die altmodischem Merker nicht reinitialusiert? Nicht alles war früher schlecht


----------



## Paul (13 Februar 2020)

Guten Morgen


ducati schrieb:


> Das Problem beim TIA ist halt das Reinitialisieren der InstanzDBs. *Wenn Du halt oft/immer Änderungen im laufenden Betrieb machen willst/musst. Ist man mit FCs deutlich besser aufgestellt.*.


Das ist natürlich ein Argument das nicht von der Hand zu weisen ist. 
Obwohl ich glaube dass das Reinitialisieren bei dieser speziellen Anlage kein sooo riesiges Problem sein würde.

Das Reinitialisieren ist der größte Schwachpunkt bei TIA. Eigentlich schon fast ein NO-GO.
Da haben wir ja schon oft darüber geredet.


----------



## nade (13 Februar 2020)

Deswegen stehts auch in Programmierstrategie. Wer was nutzt ist auf der einen Seite Firmenphilosophie, andererseits wie man am besten mit zurande kommt und dann eben noch der Nutzen, bzw wie die Software es her gibt.
Nun gut, mit Remanenz und Reinitialisieren hab ich hier keine Probleme. Die Anlage soll so einfach wie Möglich bleiben, wohl damit die "Schlappeflicker" Duduscha auch noch mit klar kommen.
<-- etwas OT bringt aber auf eine Ur Alte Frage neue Erkenntnisse.


----------

