Anzahl Ein / Ausgänge FC / FB

mariob

Level-3
Beiträge
2.052
Reaktionspunkte
276
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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...

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.
 
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
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

  1. Für diejenigen, die die gesteuerte Maschine oder Anlage in Betrieb nehmen sollen,
  2. Für diejenigen, die über das Programm den Grund finden wollen, warum die Maschine /Anlage nichtmehr tut was sie tun sollte,
  3. Für diejenigen, die nach Jahren eine Funktionsanpassung machen sollen.
  4. 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
 
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



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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
muss das wirklich sein, warum darf jemand der kein AWL oder SCL kann
überhaubt an den ding rumfummeln





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

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

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.
 
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...
 
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.
 
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" ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 

Anhänge

  • fb.JPG
    fb.JPG
    40,1 KB · Aufrufe: 70
Zurück
Oben