# FB oder FC für Standartbausteine



## Bitverbieger (23 August 2007)

Hallo SPS ler,

Ich möchte mir Standartfunktionsbausteine bauen für die klassischen 
Antriebsarten in Step7. Auch die Ansteuerung der Antriebe mittels Simocode sollten 
berücksichtigt werden, sowie über FU.Aber auch der klassische Weg für ältere Anlagen mit Schaltern am Schrank möchte ich berücksitigen.


Nun, die grundsätzliche Frage: 
Wo überwiegen die Vorteile, wo die Nachteile?
Das Erstellen der Bausteine wie, ist nicht das Problem. 
Ich möchte mich mur nicht in eine "Programmiersackgasse" begeben.


----------



## zotos (23 August 2007)

Ich halte es nicht mehr aus!

Wenn jemand den vor und nachteil von FB im Vergleich zu einem FC erklärt haben will ist für mich echt noch an den absoluten Grundlagen.

Hast Du denn bei der Aufgabe Daten die gespeichert werden müssen und die nur innerhalb des Bausteins bekannt sein sollen? Wenn ja das brauchst Du lokale Statische Variablen also FB um es sauber lösen zu können. Wenn Du die statischen Daten eh an die Umwelt weiter geben willst kannst Du bei der Step7 auch im IN_OUT bereich was tricksen. Wenn Du keine statischen Variablen braucht schäme Dich das Du die Frage gestellt hast und schnapp Dir ein Grundlagen Buch (Buchempfehlungen spar ich mir).


----------



## Bitverbieger (23 August 2007)

Ich wollte eigendlich  nur die Erfahrungen mit anderen Anwenden austauschen
Was ich nicht brauche, sich solche Belehrungen:twisted:


----------



## IBFS (23 August 2007)

Bitverbieger schrieb:


> Ich möchte mich mur nicht in eine "Programmiersackgasse" begeben.


 
mit FC anfangen - wennnde merkst das de STAT braucht - kannste jederzeit deinen FC-Code in einen FB implantieren. No "Sackgasse"

Ganz einfach!


----------



## zotos (23 August 2007)

Bitverbrecher schrieb:


> Ich wollte eigendlich  nur die Erfahrungen mit anderen Anwenden austauschen
> Was ich nicht brauche, sich solche Belehrungen:twisted:



Na also gut, machen wir halt ein Stuhlkreis (Gruppensitzung). Fang Du doch mal an deine Erfahrungen mit Standar*d*bausteinen zu schildern. Macht es Dir mehr Spaß mit FCs oder mit den FBs? Kennst Du den Unterschied?

Auch wenn Du glaubst keine Belehrungen zu brauchen. Denk daran das in dem Wort das Lehren drin Vorkommt. Sei froh das man hier keine guten Ratschläge bekommst.

PS: Ich lade hiermit auch die Moderatoren dazu ein an unserer Gruppensitzung teil zu nehmen.


----------



## repök (23 August 2007)

IBFS schrieb:


> mit FC anfangen - wennnde merkst das de STAT braucht - kannste jederzeit deinen FC-Code in einen FB implantieren. No "Sackgasse"
> 
> Ganz einfach!


 
Man kann natürlich mit einem FC anfangen.  
Wenn man dann trotzdem stats braucht, kann man dem fc eine nummer verpassen. Mit dieser Nummer kann man dann im FC eine Global-DB aufrufen (z.B: AUF DB[IN_NR]). Dann kann man mit dem DB im FC arbeiten. Allerdings geht das mit einem FB und Intanz sehr viel schöner. 

Was ich damit sagen will: Mach dir vorher gedanken für was das ding gut sein soll! Für einen Antrieb wie auch immer muss man ja verschiede Flanke und Verzögerungen auswerten. Und diese Gedanken, wenn man sie sich dann gemacht hat, sollten dann nur einen Schluss zulassen. Und wer dann nicht weiss, was man dafür hernimmt, hat an einem PG nichts verloren.


----------



## zotos (23 August 2007)

IBFS schrieb:


> mit FC anfangen - wennnde merkst das de STAT braucht - kannste jederzeit deinen FC-Code in einen FB implantieren. No "Sackgasse"
> 
> Ganz einfach!



Das ist immer so, man fängt mal an zu programmieren. Wenn man dann merkt was man da so alles macht und wie man es braucht dann wird mal hier mal da eine Variable hinzugefügt. Die Schnittstellen mehrfach überarbeitet. Dann kann man ja auch noch schöne Sprünge machen. Und am Schluss ist man dann stolz das der Spaghetticode so gut gelungen ist.

Ich meine mich daran erinnern zu können das ich mal gelernt habe das man bevor man eine Funktion programmiert  erst mal die Schnittstellen definiert die diese Funktion hat. Dabei ist es dann eigentlich auch nicht schwer zu erahnen ob man auch statische Variablen braucht. 

Also bei dem was hier in letzter Zeit so abgeht über lege ich mir ernsthaft eine Schulungsfirma zu gründen bevor das Rückgrat des deutschen Maschinen- und Anlagenbau (für das ich die Automatisierer halte) zu Grunde geht. ZOTOSeducation... hmmm... klingt gar nicht so schlecht ;o)


----------



## hugo (24 August 2007)

eine funktion wird aufgerufen und nach der abarbeitung aus dem speicher gelöscht. sie kann sich also nichts merken. ein flip flop kann also nicht mit einer funktion gelöst werden, genausowenig ein betriebsstundenzähler. eine funktion hat auch nur einen rückgabewert.
grundsätzlich solltest du das wa möglich ist in funktionen lösen damit du speicher sparst, den im gegensatz zur fuktion ist der funktionsbaustein immer im speicher wenn er einmal verwendet ist. jeder FB kann beliebig oft deklariert werden und belegt dann jedesmal speicher.
der funktionsbaustein kann sich zustände merken, weil er ja im speicher bleibt, hat also bei jedem aufruf einen anderen zustand. so werden zähler und soclche dinge gelöst. weiterhin kann ein funktionsbaustein mehrere ausgänge haben was eine funktion nicht kann. dies kann unter umständen auch ein grund sein einen funktionsbaustein zu verwenden obwohl man sich nichts merken muss. aber vorsicht er bleibt dann eben auch im speicher.


----------



## Larry Laffer (24 August 2007)

Ich kann leider nicht umhin - Zotos hat da vollkommen recht ...


----------



## Ralle (24 August 2007)

hugo schrieb:


> eine funktion wird aufgerufen und nach der abarbeitung aus dem speicher gelöscht. sie kann sich also nichts merken. *ein flip flop kann also nicht mit einer funktion gelöst werden, genausowenig ein betriebsstundenzähler*. eine funktion hat auch nur einen rückgabewert.
> grundsätzlich solltest du das wa möglich ist in funktionen lösen damit du speicher sparst, den im *gegensatz zur fuktion ist der funktionsbaustein immer im speicher wenn er einmal verwendet ist*. jeder FB kann beliebig oft deklariert werden und belegt dann jedesmal speicher.
> der *funktionsbaustein kann sich zustände merken, weil er ja im speicher bleibt*, hat also bei jedem aufruf einen anderen zustand. so werden zähler und soclche dinge gelöst. *weiterhin kann ein funktionsbaustein mehrere ausgänge haben was eine funktion nicht kann*. dies kann unter umständen auch ein grund sein einen funktionsbaustein zu verwenden obwohl man sich nichts merken muss. aber vorsicht er bleibt dann eben auch im speicher.



???????????????
Die Quelle würde mich nun doch mal interessieren.
Wir reden doch von S7, oder?


----------



## zotos (24 August 2007)

Der werte Kollege Hugo wohl in der IEC-Welt.

Aber bis auf das "weiterhin kann ein funktionsbaustein mehrere ausgänge haben was eine funktion nicht kann" sind diese Informationen auch auf die S7 zu münzen. Bei der S7 kann auch eine Funktion mehrere Ausgänge haben als nur retval.

"ein flip flop kann also nicht mit einer funktion gelöst werden, genausowenig ein betriebsstundenzähler" -> es sei den man verwendet globale variablen (sei es direkt oder per VAR_IN_OUT) aber mit den lokalen Speichermöglichkeiten des FC geht es nicht da keine statischen Variablen dabei sind.

"gegensatz zur fuktion ist der funktionsbaustein immer im speicher wenn er einmal verwendet ist" und "funktionsbaustein kann sich zustände merken, weil er ja im speicher bleibt" -> Der lokale statische Variablenbereich bleibt im "Speicher" (bei der S7 eben einem DB).


----------



## MSB (24 August 2007)

Mir wäre,
egal bei welcher SPS noch nie begegnet, das eine Funktion nur einen Ausgang haben kann.

Grundsätzlich wird bei einer Funktion (bei Siemens nur bei SCL) definiert welchen Rückgabewert diese haben soll.

Das können die bekannten Standard-Datentypen sein, also z.B. BOOL, INT ...
oder aber auch VOID, sein, also sozusagen nicht definiert.
Wenn man eine Funktion vom Rückgabetyp VOID definiert, kann diese auch wieder "fast" beliebig viele Ausgänge haben.


Das Argument mit den Speicher sparen, ist wohl so korrekt, weil eine Funktion im Gegensatz zu einem FB keine Instanz benötigt.
Also bei einem FB belegt in jedem Fall die Instanz bei jedem Aufruf Speicher.
Das dürfte dann, vom Speicher her betrachtet aber auch schon der einzige Unterschied sein.

Mfg
Manuel


----------



## Ralle (24 August 2007)

zotos schrieb:


> Der werte Kollege Hugo wohl in der IEC-Welt.
> 
> Aber bis auf das "weiterhin kann ein funktionsbaustein mehrere ausgänge haben was eine funktion nicht kann" sind diese Informationen auch auf die S7 zu münzen. Bei der S7 kann auch eine Funktion mehrere Ausgänge haben als nur retval.



Es muß doch nicht der Retval sein.



zotos schrieb:


> "ein flip flop kann also nicht mit einer funktion gelöst werden, genausowenig ein betriebsstundenzähler" -> es sei den man verwendet globale variablen (sei es direkt oder per VAR_IN_OUT) aber mit den lokalen Speichermöglichkeiten des FC geht es nicht da keine statischen Variablen dabei sind.



Na also, mit einer IN_OUT geht auch das, obwohl die "Funktion nicht im Speicher bleibt".



zotos schrieb:


> "gegensatz zur fuktion ist der funktionsbaustein immer im speicher wenn er einmal verwendet ist" und "funktionsbaustein kann sich zustände merken, weil er ja im speicher bleibt" -> Der lokale statische Variablenbereich bleibt im "Speicher" (bei der S7 eben einem DB).



Was bleibt nun im Speicher die Funktion, oder die Variablen und was bleibt bei der S7 im Speicher. Hier kommt einiges gehörig durcheinander.


----------



## Ralle (24 August 2007)

So nun hab ich den Salat, der zotos *heult* im Chat und ich muß mal klarstellen, daß meine Zitate von zotos mehr als Antwort an Hugo gedacht waren und nicht als Gegenrede zu den Argumenten von zotos.

Hat das wer verstanden?


----------



## zotos (24 August 2007)

Selbstverständlich bleibt beim FB im Gegensatz zum FC der statische lokale Variablenbereich im speicher. Das hat nichts mit der Funktion (dem Programmcode) an sich zu tun wie die SPS-Hersteller das gelöst haben sieht man als Anwendungsprogrammierer eh nicht. Also Ralle es geht um die statischen Variablen. 
Jemand der die Unterschiede von einem FB zu einem FC nicht richtig kennt und nach Vor- und Nachteilen fragt, die es gar nicht gibt da die beiden Funktionen unterschiedliche Aufgaben gebiete haben,  versteht auch nicht den Unterschied ob der Programmcode und/oder dessen  Variablen im Speicher bleiben. Ich vermute mal das die meisten Hersteller für die Variablen einer Funktion (FC) einen festen Speicher haben und was man ja weis das man bei einem Funktionsblock (FB) für jede Instanz einen eigenen auch festen Speicherbereich im Speicher hält. Aber diese Diskusion nützt an der Stelle nichts. Der 0815S7 Programmierer rafft das eh nie ;o)


----------



## kiestumpe (24 August 2007)

In der Regel werden die TEMP-Variablen auf dem STACK abgelegt, das Stack-Handling besitzt aber jeder Microcontroller und da in CPU ja letztlich auch die schwarzen Käfer eingebaut sind, wird's wohl analog sein.

Allg. kann ich nur sagen, dass man mit den IN-OUTs sparsam umgehen sollte. Zum einen wird die Lesbarkeit m.E. eher schlechter, zum anderen der Speicherverbrauch, besonders bei UDT's unverhältnismäßig höher.
Allerdings mal ein Flankenmerker, oder ne Zählvariable geht schon...

just my 0.02 €


----------



## Maxl (24 August 2007)

Bitverbieger schrieb:


> Ich möchte mir Standartfunktionsbausteine bauen für die klassischen Antriebsarten in Step7. Auch die Ansteuerung der Antriebe mittels Simocode sollten berücksichtigt werden, sowie über FU. Aber auch der klassische Weg für ältere Anlagen mit Schaltern am Schrank möchte ich berücksitigen.
> 
> Nun, die grundsätzliche Frage:
> Wo überwiegen die Vorteile, wo die Nachteile?
> ...


Ich denke, bevor Du Dir diese Frage stellst, ist viel wichtiger, dass Du Dir im Klaren bist, was Du in einen Standardbaustein überhaupt alles reinpacken willst. Meiner Meinung nach macht es wenig Sinn, ganze Abläufe in einen FB zu packen, oder eine komplette Motorsteuerung, welche per Visu und per Taster und vielleicht auch noch per Codierschalter bedient werden kann.

Bei uns werden Standardbausteine in der Regel als kleine Einheiten programmiert, welche sich bei Bedarf zusammenstöpseln lassen - und bei Bedarf auch erweitern.

Ein Beispiel:
Eine Gießanlage hat 50 Kühlkreise, welche im Prinzip gleich funktionieren. Man möchte natürlich nicht alles 50 mal Programmieren, da macht der Einsatz eines Standardbausteins sinn, welcher dann 50 mal aufgerufen wird.

Oder:
Zylinderansteuerung mit der ganzen Schalterüberwachungsgschichte dran. Hier macht es z.B. keinen Sinn, alle möglichkeiten (4/2-Wege-Ventil 5/2 Wege 5/3 Wege, 1 Schalter pro Seite, Schalter nur auf 1 Seite usw.) in einen FB reinzupacken. Spätestens wenn man dann einen Sonderzylinder hat und seinen FB daran anpasst wird man sich ärgern, dass man nun bei den FBs für 50 andere Zylinder einen Zeitstempelkonflikt hat. Hier ist sinnoll, 3 oder 4 Verschiebene Bausteine für verschiedene Zylinderkonstellationen zu machen.

Beispiele, wo wir Standardfunktionen als FC verwenden sind z.B.
- Berechnungen, Datenmanipulation (lineare Skalierung, Kennlinien verbiegen, Daten indiziert kopieren, ....)

Beispiele für FB
- Schnittstellenabwicklung eines FU oder eines Movimot. nur 1 FB, für jeden FU ein eigener Instanz-DB in dem die PE/PA-Daten und Soll/Istwerte liegen.
- Funktionen, welche intern viele Statische Daten brauchen (z.B. Steuerung eines Prop-Ventils, 2-Punkt Regler)
- Funktionen, welche Statistische Daten oder Diagnosedaten aufzeichnen (z.B. DP-Diagnose, Schrittkettendiagnose, Taktzeitmessung)

Die dritte Variante, welche wir immer wieder einsetzen, ist die Mischform. Das Programm ist in einem FC geschrieben, ihm ist fix ein DB zugeordnet (welcher indiziert per AUF DI[#...] aufgerufen wird.). Diese Variante ist von der Bearbeitungszeit auf der CPU her schneller als ein FB und hat natürlich auf diverse Vor- und Nachteile.
Vorteil sind
- dass man im Instanz-DB die Daten ab DBX0.0 nutzen kann, auch wenn am FC IN und OUT-Daten verwendet werden
- dass Adressregister 1 und 2 uneingeschränkt nutzbar sind
- werden im Instanz-DB strukturelle Änderungen gemacht, muss nur der Instanz-DB neu generiert werden - nicht der FC-Aufruf
Nachteile sind:
- das gesamte Programm muss per DIX/DIW usw auf den DB zugreifen - eine gewissenhafte Dokumentation ist absolut notwendig
Diese dritte Variante setzen wird in der Regel dann ein, wenn der Code im Standard-Baustein sehr Umfangreich ist. Der Instanz-DB wird als UDT deklariert - anschließend wird für jede Instanz ein DB vom Typ UDTxxx angelegt.

mfg
Maxl


----------



## Bitverbieger (27 August 2007)

Vielen Dank für eure vielen Anregungen.
Aufgrund des von Zotos gegründeten Stuhlkreis werde ich meinen, bereits
begonnen, FC weiterentwickeln.

Dank an alle Mitwirkenden, besonderer aber an Zotos


----------

