Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 29

Thema: Anzahl Ein / Ausgänge FC / FB

  1. #1
    Registriert seit
    23.03.2006
    Ort
    Thüringen
    Beiträge
    2.005
    Danke
    162
    Erhielt 278 Danke für 199 Beiträge

    Standard


    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
    Zitieren Zitieren Anzahl Ein / Ausgänge FC / FB  

  2. #2
    Registriert seit
    10.08.2008
    Ort
    Hamburg
    Beiträge
    45
    Danke
    10
    Erhielt 4 Danke für 4 Beiträge

    Standard

    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...
    if (ahnung == 0) {read Manuel; use SEARCH; use GOOGLE; } else { use brain; make post; }

  3. #3
    Registriert seit
    19.06.2005
    Ort
    in Bayern ganz oben
    Beiträge
    1.360
    Danke
    188
    Erhielt 372 Danke für 290 Beiträge

    Standard

    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
    Erfahrung ist eine nützliche Sache. Leider macht man sie immer erst kurz nachdem man sie brauchte...

    OSCAT.lib Step 7

    Open Source Community for Automation Technolgy

    SPS-Forum Chat (Mibbit) | SPS-Forum Chat (MIRC)

  4. #4
    Registriert seit
    23.04.2009
    Ort
    Allgäu
    Beiträge
    3.042
    Danke
    241
    Erhielt 863 Danke für 617 Beiträge

    Standard

    Zitat Zitat von dalbi Beitrag anzeigen
    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.
    Das sehe und mache ich genauso wie dalbi.
    Gruß
    Paule
    ----------------------------------------------------------------------------
    > manchmal verliert man und manchmal gewinnen die anderen <

  5. #5
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.712
    Danke
    398
    Erhielt 2.398 Danke für 1.998 Beiträge

    Standard

    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

  6. #6
    Registriert seit
    01.01.2009
    Ort
    Niedersachsen
    Beiträge
    813
    Danke
    180
    Erhielt 79 Danke für 75 Beiträge

    Standard

    Zitat Zitat von Pietpinguin Beitrag anzeigen
    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.
    Gruß Jan

    Wer fragt, bekommt Antworten.

  7. #7
    mariob ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    23.03.2006
    Ort
    Thüringen
    Beiträge
    2.005
    Danke
    162
    Erhielt 278 Danke für 199 Beiträge

    Standard

    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

  8. #8
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.712
    Danke
    398
    Erhielt 2.398 Danke für 1.998 Beiträge

    Standard

    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

  9. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    Shiva (11.10.2010)

  10. #9
    Registriert seit
    24.10.2010
    Beiträge
    9
    Danke
    6
    Erhielt 10 Danke für 9 Beiträge

    Standard

    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
    Zitieren Zitieren Anzahl der Ein- /Ausgänge eines FB, FC  

  11. Folgender Benutzer sagt Danke zu BFlat für den nützlichen Beitrag:

    M_o_t (13.11.2010)

  12. #10
    Registriert seit
    23.04.2009
    Ort
    Allgäu
    Beiträge
    3.042
    Danke
    241
    Erhielt 863 Danke für 617 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi BFlat,
    das hört sich ja nach einem Lastenheft für ein SPS-Programm an.
    Gruß
    Paule
    ----------------------------------------------------------------------------
    > manchmal verliert man und manchmal gewinnen die anderen <

Ähnliche Themen

  1. Antworten: 3
    Letzter Beitrag: 30.11.2013, 14:11
  2. Anzahl Flankenabfragen
    Von blue dun im Forum Simatic
    Antworten: 9
    Letzter Beitrag: 03.05.2009, 21:01
  3. Anzahl der Ein- und Ausgänge
    Von Farinin im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 07.06.2008, 01:32
  4. gerade oder Ungerade Anzahl der Ausgänge
    Von Otto im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 31.10.2006, 09:17

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •