# Anzahl Ein / Ausgänge FC / FB



## mariob (8 Oktober 2010)

Hallo,
mal wieder ein Problem in Step 7 (eigentlich ist es keines), also wenn ich einen FB/FC mit Ein / Ausgängen parametriere, wo ist bei Euch die praktische Grenze der Anzahl solcher Variablen?
Praktisch sieht es gegenwärtig so aus das ich mächtige Monster mit Ein /Ausgängen produziere, irgendwie gefällt mir das alles nicht so recht....
Sicher, können kann man alles, ich denke der Mix aus den verschiedenen Zugriffsmöglichkeiten (Koppel DBs, Baustein E/A, direkte E/A im Baustein) macht die gute Programmierung aus.

Gruß
Mario


----------



## Pietpinguin (9 Oktober 2010)

Hallo!

Ich bin der Meinung, dass die In/Out Formlparameter im richtigen Verhältnis zu der Komplexität des Inhalts des entsprechenden FBs,FCs stehen muss. Je mehr innerhalb des Bausteins mit den Parametern gemacht wird, desto mehr rechtfertigt es die Anzahl der Eingänge/Ausgänge. 
Übrigens, direkte E/As sollte man innerhalb eines Bausteins natürlich nicht verwenden! 

sonnige Grüsse...


----------



## dalbi (10 Oktober 2010)

Hi,

ich bin ein grosser Freund von Structs und UDTs diese als Pointer an den FC/FB übergeben und Du kannst direkt auf den DB in dem sie abgelegt sind zugreifen und die Schnittstelle bleibt schön schlank. Direkte E/As in parametrierbaren Bausteinen gehört sich nicht.

Gruss Daniel


----------



## Paule (10 Oktober 2010)

dalbi schrieb:


> ich bin ein grosser Freund von Structs und UDTs diese als Pointer an den FC/FB übergeben und Du kannst direkt auf den DB in dem sie abgelegt sind zugreifen und die Schnittstelle bleibt schön schlank. Direkte E/As in parametrierbaren Bausteinen gehört sich nicht.


*ACK* Das sehe und mache ich genauso wie dalbi.


----------



## Larry Laffer (10 Oktober 2010)

Hallo Mario,
zu dem Thema fällt mir so pauschal nichts ein.
Wie du schon selber schreibst : "(fast) alles denkbare ist machbar".
Es wäre vielleicht hilfreich, wenn du die Funktionalität deines "Monster"-Bausteins mal ein bißchen ausführst - dann läßt sich ggf. etwas konkreteres dazu sagen.

Gruß
Larry


----------



## Jan (10 Oktober 2010)

Pietpinguin schrieb:


> Hallo!
> 
> Ich bin der Meinung, dass die In/Out Formlparameter im richtigen Verhältnis zu der Komplexität des Inhalts des entsprechenden FBs,FCs stehen muss. Je mehr innerhalb des Bausteins mit den Parametern gemacht wird, desto mehr rechtfertigt es die Anzahl der Eingänge/Ausgänge.
> Übrigens, direkte E/As sollte man innerhalb eines Bausteins natürlich nicht verwenden!
> ...


 
Dem kann ich nur zustimmen.

Ich würde zusätzlich auch darauf verzichten Merker, etc. in einem FC/FB zu verwenden, der mehrfach aufgerufen wird. Wenn hier z. B. im FC zwei Merker benötigt werden, dann würde ich einen FC mit INOUT draus machen. Wenn aber viele Zustände oder Werte innerhalb des Bausteins gespeichert werden müssen, dann würde ich einen FB verwenden, aber trotz dem evt. für den Rest des Programms erforderliche Signale, oder Werte als OUT / INOUT ausgeben.


----------



## mariob (10 Oktober 2010)

Hallo,
ich denke da schon genauso wie Ihr, ich präzisiere mal ein wenig meine Ausführungen, manchmal muß ich selbst auch erst einmal herausbekommen was ich möchte .
So also meine Probleme:
Zum Beispiel Notaus, keine Angst da ist auch Hardware dahinter, ich habe einen Baustein, der diese mit einsammelt, recht simpel auch für sich selbst auswertet und teilweise wieder ausgibt. 5 dieser Eingänge und ein einfaches Oder im FB, sowas kotzt mich an. Im OB ist das aber auch irgendwie nicht elegant.
Dann das Problem, wenn ich eine Variable übersehe, heißt das Schnittstellenänderung, jedesmal fliegt mir danach der Aufruf um die Ohren.
Ich möchte das ganze ein wenig effizienter gestalten und deswegen sind zumindest in der Entwicklungsphase direkte Zugriffe auf E/As im Gebrauch, für später (also wenn keine Änderungen mehr vonnöten sind) kommen die dann in die Schnittstelle.
Und hier kommt mir eben das Grausen, wenn ich sehe was ich da an Mengen bits und Bytes verbaue, die später nach draußen müssen.
Nochmal,auch meine Regel, globale Sachen außen an den FB/FC, Perfektionist schreibt dazu er behandelt soetwas wie eine virtuelle SPS, ich fand das sehr treffend.

Gruß
Mario


----------



## Larry Laffer (11 Oktober 2010)

Hallo Mario,
ich nehme aus deinem Beitrag jetzt mal mit, dass du gerne ein wenig objekt-orientierter mit der Programmierung deiner Bausteine (und im speziellen dieses einen Bausteins) werden möchtest.
Von deinem eigentlichen Problem habe ich noch nicht so viel verstanden - aber ... ich schreibe dir einfach mal, wie ich so etwas anpacke :

Ich habe einen Haupt-Baustein (Name FB450). Dieser FB stellt am Ablauf beteiligten Stationen einer Sektion Informationen (über eine definierte UDT-Schnittstelle) zur Verfügung und sammelt umgekehrt auf gleichem Weg Rückmeldungen wieder ein. Der Koppel-UDT ist hier für jede Station gleich - unabhängig davon, wie viele Informationen tatsächlich benötigt werden (er passt halt für den Max.-Ausbau). Am Ende des Zyklus werden die Stationsmeldungen dann zusammengefasst und an die Sektions-Steuerung weitergegeben. Das ist dann eine andere Schnittstelle mit einem anderem UDT.
Auch an dem ganzen Kuchen beteiligt ist der Baustein "Einschalten und Betriebsarten". Auch der kommuniziert mit dem "Super-FB" und versorgt diesen mit Info's bzw. erhält er auch welche zurück.
Damit ist die Schnittstelle dieses "Super-FB's" auf ca. 30 Parameter beschränkt und auch übersichtlich. Das, was ausgetauscht wird ist ein Code-Parameter der Schnittstelle - gleichfalls auch das, was gemacht wird.
Die Stationen kümmern sich dann um sich selbst und haben ggf. noch so ihre eigene Schnittstelle. Das gilt auch für den FB "Einschalten und Betriebsarten".

Ich weiß jetzt nicht, ob dir diese Ausführung wirklich weiter hilft - vielleicht ist sie aber für dich ein Denk-Anstoss oder eine Inspiration.

Gruß
Larry


----------



## BFlat (9 November 2010)

*Anzahl der Ein- /Ausgänge eines FB, FC*

Tatsächlich ist Deine Motivation, die Anzahl der E/A eines Bausteins niedrig zu halten nicht nur eine Frage der persönlichen Ästhetik. Denn prinzipiell schreibt man ein SPS Programm nicht für sich selbst, sondern für Andere. 


Für diejenigen, die die gesteuerte Maschine oder Anlage in Betrieb nehmen sollen,
Für diejenigen, die über das Programm den Grund finden wollen, warum die Maschine /Anlage nichtmehr tut was sie tun sollte,
Für diejenigen, die nach Jahren eine Funktionsanpassung machen sollen.
Schließlich für diejenigen, die einmal das Programm auf die nächste Steuerungsgeneration portieren sollen.
Um einen zügigen Onlinetest von weniger geübten SPS Anwendern zu ermöglichen, sollte der FB oder FC im KOP oder FUP darstellbar sein.

Die Größe des FB oder FC sollte auf einen Bildschirm passen ohne hinauf und hinunter zu rollen. So kann man den kompletten Baustein online beobachten.

Die Anzahl der Variablen, die zugleich online beobachtet werden können ist beschränkt. So kann es bei Bausteinen mit sehr vielen E/A passieren, dass Variable nichtmehr angezeigt werden, wenn man am Baustein entlang nach unten rollt. 
Leider kann ich jetzt nicht sagen, wo bei einer S7 die Grenze liegt.


Oft wird viel zu viel in einem Baustein versteckt. Manche Funktionen werden transparenter, wenn man vor den Bausteineingang KOP oder FUP Elemete schaltet um der Nachwelt die logischen Verriegelungen z.B. für eine Freigabe zu zeigen.

Des Weiteren sollte alles, was einmal angepasst werden könnte aus dem Baustein heraus vor den Baustein verlegt werden. Denn als Programmierer sieht man es gerne, wenn innerhalb eines einmal geschaffenen FBs oder FCs nichts mehr geändert wird.

Ein goldener Weg ist die Übergabe von Datenbausteinen oder Teilstrukturen eines DB mit Zeigern oder Pointer an eine Funktion. So kann man mit wenig Variablen (Ein - Aus - Automatik - Hand - Elementnummer) eine große Anzahl von Stellern steuern. 

Meine Bitte lautet nur, dass ALLE Variablen von außen erkennbar sein sollten.

Zum Beispiel DB-Nummer und Elementnummer per Bausteineingang übergeben und auch die Übergabesymbole lesbar gestalten. Wenn dann die Nachwelt am Baustein entdeckt, dass z.B. ein Ventil-DB aufgerufen wird, so kann man dort nachsehen und in der hoffentlich sauberen Kommentierung entdecken, dass es da noch Entprellungen, Stör- und Quittierungsmerker gibt, eine Timeout Funktion ..etc. ohne dass diese über die Baustein E/A gezogen worden sind.



BFlat


----------



## Paule (9 November 2010)

Hi BFlat,
das hört sich ja nach einem Lastenheft für ein SPS-Programm an. *ROFL*


----------



## rostiger Nagel (9 November 2010)

BFlat schrieb:


> Um einen zügigen Onlinetest von weniger geübten SPS Anwendern zu ermöglichen, sollte der FB oder FC im KOP oder FUP darstellbar sein.


 
muss das wirklich sein, warum darf jemand der kein AWL oder SCL kann 
überhaubt an den ding rumfummeln





BFlat schrieb:


> Die Größe des FB oder FC sollte auf einen Bildschirm passen ohne hinauf und hinunter zu rollen. So kann man den kompletten Baustein online beobachten.
> 
> 
> Die Anzahl der Variablen, die zugleich online beobachtet werden können ist beschränkt. So kann es bei Bausteinen mit sehr vielen E/A passieren, dass Variable nichtmehr angezeigt werden, wenn man am Baustein entlang nach unten rollt.
> Leider kann ich jetzt nicht sagen, wo bei einer S7 die Grenze liegt.


 
du kommst aber sehr....sehr schnell an grenzen des Nummerbandes der
S7 Steuerung wenn deine Bausteine komplett auf den Bildschirm passen
sollen, am besten stellt mann da die Schriftgröße auf sehr klein, etwa
auf 0,000048


----------



## bike (9 November 2010)

Helmut_von_der_Reparatur schrieb:


> muss das wirklich sein, warum darf jemand der kein AWL oder SCL kann
> überhaubt an den ding rumfummeln
> 
> 
> ...



Also lesen sollte auch ohne Lupe möglich sein.
Die Anforderungen von BFlat könnten aus dem Pflichtenheft von Renault oder VW sein. 
Und er hat absolut recht.
Wir schreiben nicht Programme für den Selbstzweck, sondern für unsere Kunden. 
Der Lieferant und Inbetriebnehmer gehen, doch die Anlage bleibt beim Kunden und der will bzw muss damit Geld verdienen. 
Und das über einen längeren Zeitraum und auch unabhängig, ob der Lieferant oder dessen Programmierer noch existieren.


bike


----------



## rostiger Nagel (9 November 2010)

bike schrieb:


> Also lesen sollte auch ohne Lupe möglich sein.
> Die Anforderungen von BFlat könnten aus dem Pflichtenheft von Renault oder VW sein.
> Und er hat absolut recht.
> Wir schreiben nicht Programme für den Selbstzweck, sondern für unsere Kunden.
> ...


 
es geht ja garnicht um den Selbstzweck, aber sei doch mal bitte 
realistisch. Nimm doch mal einen FB für eine einfache Stern Dreieck Schaltung,
mit min. 2 Zeitgliedern. Die bekommst doch nicht auf eine Bildschirmseite.
Soll ich das jetzt stückeln auf 3-4 FB's.

Wenn ein FB gut strukturiert, Dokumentiert und auf viele Netzwerke
verteilt ist, die kurz und bündig sind, darf der Baustein auch mal etwas
größer sein.


----------



## vierlagig (9 November 2010)

Helmut_von_der_Reparatur schrieb:


> es geht ja garnicht um den Selbstzweck, aber sei doch mal bitte
> realistisch. Nimm doch mal einen FB für eine einfache Stern Dreieck Schaltung,
> mit min. 2 Zeitgliedern. Die bekommst doch nicht auf eine Bildschirmseite.
> Soll ich das jetzt stückeln auf 3-4 FB's.



helmut, ich behaupte, du verstehst hier die anforderung falsch!
der aufruf des bausteins soll auf eine bildschirmseite passen, nicht der baustein an sich...


----------



## rostiger Nagel (9 November 2010)

vierlagig schrieb:


> helmut, ich behaupte, du verstehst hier die anforderung falsch!
> der aufruf des bausteins soll auf eine bildschirmseite passen, nicht der baustein an sich...


 
ich glaub ich komm gerade in ein alter


----------



## Thomas_v2.1 (9 November 2010)

BFlat schrieb:


> Zum Beispiel DB-Nummer und Elementnummer per Bausteineingang übergeben und auch die Übergabesymbole lesbar gestalten.



Also tut mit leid. Warum um alles in der Welt muss man bei einer S7 an einen Baustein eine DB-Nummer übergeben? Damit man im Baustein nicht-symbolische Schmierereien damit machen kann?

Vielleicht kannst du mal erläutern warum so ein Programmierstil übersichtlich und lesbar sein soll.


----------



## vierlagig (9 November 2010)

Thomas_v2.1 schrieb:


> Also tut mit leid. Warum um alles in der Welt muss man bei einer S7 an einen Baustein eine DB-Nummer übergeben? Damit man im Baustein nicht-symbolische Schmierereien damit machen kann?
> 
> Vielleicht kannst du mal erläutern warum so ein Programmierstil übersichtlich und lesbar sein soll.



och, nun hackt doch nicht alle auf irgendwelchen spitzfindigkeiten rum ...
übergibt man den datenbaustein als block_db kann man ihn wenigstens in den referenzdaten wieder finden ... übergibt man nur ne zahl, dann ist sense. in sofern kann ich diese forderung nachvollziehen und es wird immer in 3 aus 10 anlagen den fall geben, wo man "indirekt rumschweinern muss" ...


----------



## Andy79 (11 November 2010)

Aus aktuellem Anlass.
Das Monster aus dem Anhang ist mir vor kurzem untergekommen. Leider passt es selbst bei kleinster Schriftgröße nicht komplett auf den Bildschirm.
Schön ist was anderes :?
Innerhalb des FB´s werden dann nochmals solche Konstrukte aufgerufen.


----------



## Pietpinguin (11 November 2010)

Wer solche Bausteine programmiert gehört verbannt....
Und STEP7 straft einen mit einer super Ansicht .


----------



## Andy79 (11 November 2010)

Ach übrigens, das mag nun Zufall sein (oder nicht  ), aber die zugehörige Anlage ist abgebrannt.


----------



## bike (11 November 2010)

Also ob das allein am Baustein lag, dass es da gebrannt hat?
Heißt der Baustein: " Brandbeschleuniger" ? 

Ich kenne einige Bausteine, die im Editor nicht dargestellt werden können, da diese zu groß/lang sind.
Da hilft nur eine Quelle und dann darin Fehler suchen.
Ist aber der perfekte Kopierschutz, diese Bausteine beim Upload sind so verstümmelt, dass damit nichts angefangen werden kann.

bike


----------



## Question_mark (12 November 2010)

*Son Driss hau ich Dir um die Löffel ...*

Hallo,



			
				mariob schrieb:
			
		

> Praktisch sieht es gegenwärtig so aus das ich mächtige Monster mit Ein /Ausgängen produziere, irgendwie gefällt mir das alles nicht so recht....



Dieses Gefühl des Mißfallens mit solchen abenteuerlichen Konstrukten teile ich mit Dir. Wenn ich solche Monstren sehe, kommt mir das kalte Kotzen.

Zerlege einfach Deine Programmieraufgabe in kleine, überschaubare Teileinheiten, bei der S7 also FCs oder FBs. Das erleichtert den Funktionstest und die IBS. Diese Monsterbausteine sind der letzte Dreck und für den Endkunden eine Zumutung ...

Eine Funktion oder Prozedur sollte sich mit möglichst wenigen Parametern aufrufen lassen, so kann man ganz schnell sicher sein, das Fehlfunktionen 
leicht erkannt und beseitigt werden können.

Diese Monsterbausteine würde ich Dir um die Ohren hauen, aber bei vielen SPS-Programmierern sind wohl die Grundregeln der Informatik völlig unbekannt.

Und darum sehe ich wohl immer bei den Anlagen meiner Kunden die abenteuerlichsten Konstrukte von Fremdlieferanten. Wobei besonders die italienischen und französischen Anlagenbauer besonders erfindungsreich sind ...

Gruß

Question_mark


----------



## Perfektionist (13 November 2010)

nachdem Du mich und den Kollegen Kühner derneulich angepinkelt hast, kann ich Dir, lieber und werter Kollege QM, bescheinigen, dass Du mit dieser Art, die Leute anzugehen, zwar Beifall bei Deinen Freunden finden wirst, Deine allgemeine Reputation jedoch darunter leiden könnte.


----------



## BFlat (20 November 2010)

*E-/A für Bausteine*

Spät, spät, spät komme ich online um zu sehen, was ich durch eine unscharfe Formulierung angerichtet habe...

Ein findiger Forumsteilnehmer hat es durchblickt und mit wenigen Worten richtig gestellt:

Ich meinte den Baustein-*Aufruf!*

  Danke an 'Vierlagig'!  

Im Beispiel der Stern-Dreieckschaltung wäre das ein Kästchen mit vielleicht nur einem binären Eingang, ein Zeitglied als E/A Typ und drei Ausgängen. Das dahinterliegende Programm gestaltet sich selbstverständlich nach dem Gustus des Programmierers.



* * * * * *
DB im Bausteinaufruf erkennbar:

Ein sehr effizientes Mittel, Baustein E/A zu sparen ist das, lediglich einen Zeiger und einige wenige nicht strukturierte Variable (z.B. SPS E-A) zu übergeben.

z.B. ein pneumatisch betätigtes Ventil in einer Anlage mit Dutzenden von Ventilen: 

Ventilnummer,
Taster EIN,
Taster AUS,
Stellausgang ÖFFNEN.
All die anderen Variablen wie Zeitüberwachung, Stellzustand als mehrfarbige Anzeige, Störzustand, Alarm, Automatik EIN... gehen über einen Datenbaustein mit einem Array der Struktur der versteckten Ventilvariablen. Das Array wird über die Ventilnummer indiziert und direkt aus bem Bausteincode heraus angesprochen. Von "aussen" sind diese Variablen unsichtbar.

Es wäre nun fein, wenn zumindest die DB Nummer in dem Bausteinaufruf gewissermassen von "aussen" erkennbar wäre. So erhält man einen leisen Tipp.  Ansonsten muß der ahnungslose Fehlersucher in den Programmcode des Bausteins einsteigen, um irgendwann einmal zu entdecken, dass da ein DB ist...

Übrigens: freundliche Kommentierung bringt auch nicht all zu viel, da zunehmend Fehlersuche per upload nachgefragt wird: 
_Die Originalquelle (mit den Kommentaren) hat irgend ein Guru bei Lieferung der Anlage kassiert. Guru hat sich ins Ashram zurückgezogen, Quelle nichtmehr auffindbar. Herstellerfirma schon lange per Investor zerlegt.  Jetzt holt man Dich an die Anlage, weil Du SIEMENS buchstabieren kannst: "Nu kuck doch 'mal!"._​In solchen Fällen bewährt sich, dass die S7 die Mnemos der Bausteinaufrufe runter ladet und sie bei einem Upload wieder zu erkennen sind. Wenn ich nun entdecke dass Du, der mir unbekannte Programmierer, damals eine Übergabevariable 'DBNR' erzeugt hast, so werde ich Dir ein Extra-Räucherstäbchen spendieren, wenn auch ich mich dereinsten in ein Ashram zurückziehen werde...

Fairer Programmierstil an den Schnittstellen von Bausteinaufrufen!





BFlat
wieder auf Einsatz verschwindend


----------



## Jan (23 November 2010)

Andy79 schrieb:


> Aus aktuellem Anlass.
> Das Monster aus dem Anhang ist mir vor kurzem untergekommen. Leider passt es selbst bei kleinster Schriftgröße nicht komplett auf den Bildschirm.
> Schön ist was anderes :?
> Innerhalb des FB´s werden dann nochmals solche Konstrukte aufgerufen.


 
Den Baustein sollte man aus dem Programm herausnehmen und dem Programmierer ordendlich über den Schädel ziehen.

Groß genug ist er ja.

Bei uns muss ein Netzwerk in der Breite komplett auf eine Seite passen und ein Baustein sollte immer so kurz wie möglich sein. 
Und wehe da hält sich einer nicht dran....


----------



## Paule (23 November 2010)

Jan schrieb:


> ...und ein Baustein sollte immer so kurz wie möglich sein.



Aber dafür 800 Bausteine, oder wie soll ich das verstehen?
Für jede Ausgang eine separaten Baustein?


----------



## Jan (23 November 2010)

Paule schrieb:


> Aber dafür 800 Bausteine, oder wie soll ich das verstehen?
> Für jede Ausgang eine separaten Baustein?


 
Nein, meistens natürlich nicht.

Unter Umständen kann ein Programm insgesamt ein paar hundert Bausteinaufrufe haben. Auf jeden Fall strukturiert und übersichtlich.

Es gibt z. B. schon Bausteine mit ca. 8 IN, 5 INOUT, 6 OUT.

Wir nehmen aber auch nicht einen Baustein an den ALLE Eingänge und ALLE Ausgänge dranstehen. 

Es muss eben in einem vernünftigen Rahmen bleiben; wie es hier schon von einigen geschrieben wurde.


----------



## Paule (23 November 2010)

Jan schrieb:


> Es gibt z. B. schon Bausteine mit ca. 8 IN, 5 INOUT, 6 OUT.


Ach Du hast von einem parametrierbaren Baustein gesprochen.
Sorry, klar darum ging es ja.


----------



## Jan (23 November 2010)

Paule schrieb:


> Ach Du hast von einem parametrierbaren Baustein gesprochen.
> Sorry, klar darum ging es ja.


 
Habe meinen Text noch mal gelesen.

Das kann man auch anders verstehen; SORRY.


----------

