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

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 13 von 13

Thema: Frage zu meinem Baustein

  1. #11
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.480
    Danke
    1.141
    Erhielt 1.241 Danke für 973 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von eNDe Beitrag anzeigen
    Hallo Blockmove,
    Bausteine haben in FUP einen Eingang EN und einen Ausgang ENO. Damit können FUP-Bausteine "in Reihe" geschaltet werden. Ein Baustein in dieser Kette wird nur bearbeitet, wenn der Eingang EN ein 1-Signal führt, bei 0-Signal wird er nicht bearbeitet.
    Besten Dank für die Erklärung.
    Es ist doch das Schöne an unserem Job, dass es immer was Neues zu entdecken bzw. zu lernen gibt

    Gruß
    Dieter

  2. #12
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.186
    Danke
    923
    Erhielt 3.291 Danke für 2.660 Beiträge

    Standard

    Wissenswertes zum BIE-Bit (weil es hier gerade angesprochen wurde)

    Das BIE-Bit kann man beim Beobachten eines Bausteinaufrufs in FUP/KOP direkt sehen.
    Ist das BIE-Bit am Bausteinende 1, dann wird der Rahmen der Baustein-Box grün.

    Alle SFB und SFC zeigen über das BIE-Bit an, ob die Funktion fehlerfrei ausgeführt wurde.

    Das BIE-Bit nutze ich gern in eigenen Analogeingang-Skalierungsbausteinen für die Anzeige
    Drahtbruch/Überlauf --> BIE=0 / OK --> BIE=1
    Den ENO-Ausgang kann man platzsparend sofort weiterverknüpfen,
    z.B.(KOP): ENO|---|NOT|---(#Stoerung)


    Mit Hilfe des BIE-Bit kann man sich die in KOP nicht vorhandene XOR-Box selber als FC
    programmieren (auch mit mehr als 2 Eingängen):

    Code:
    FUNCTION FC102 : VOID
    TITLE =XOR-Box für KOP
    NAME : XOR2
    
    VAR_INPUT
      IN1 : BOOL ;	
      IN2 : BOOL ;	
    END_VAR
    
    BEGIN
    NETWORK
    TITLE =XOR-Verknüpfung auf ENO ausgeben
          X     #IN1; 
          X     #IN2; 
          SAVE  ; 
    END_FUNCTION
    Einsatz in KOP:
    Code:
                      +--------+
                      | FC102  |
                      | "XOR2" |  M10.3    M10.7
    ------------------|EN   ENO|---| |------( )
                      |        |
      M10.0    M10.1  |        |
    ---| |------| |---|IN1     |
                      |        |
      M10.2           |        |
    ---|/|------------|IN2     |
                      +--------+
    Gruß
    PN/DP
    Zitieren Zitieren BIE-Bit / XOR-Box für KOP  

  3. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    Cosman (30.08.2009)

  4. #13
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.186
    Danke
    923
    Erhielt 3.291 Danke für 2.660 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Gini Beitrag anzeigen
    Ich rufe den FC übrigens im OB35 (100ms) auf.
    Ich würde die KW-Berechnung nicht im OB35 machen, sondern normal irgendwo im OB1-Zyklus.
    Im OB35 wird das von vielen Kunden nicht gern gesehen, zumal es nicht zwingend im OB35 sein
    muß. Im OB35 erzeugt das schwankende Zykluszeiten.

    Ich würde wahrscheinlich die ganze KW-Berechnung nicht in so einer eleganten Schleife machen,
    sondern in einem FC die 160 oder weniger Addierungen stupide linear hintereinander schreiben,
    da kann man auch besser Sonderfälle berücksichtigen (gleicher Antrieb vorwärts oder rückwärts,
    Ausgang ist gar kein Antrieb und/oder soll nicht eingerechnet werden).

    Weiter würde ich eventuell die KW-Werte als Festwerte im linearen Programmcode und nicht in
    einem DB angeben, um dann wieder Speicherplatz zu sparen (DB mit 160 REAL = 160*4 = 640 Byte).

    Ich würde auch darüber nachdenken, ob ich in REAL rechnen muß. Hundertfache KW-INT auf DINT
    addieren und am Ende erst zu REAL wandeln und durch 100 teilen: 2 Nachkommastellen.

    Code:
    //lineares Addieren, KW-Werte aus DB100
          AUF   "KW-Werte"        //DB100
          L     0.000000e+000     //KW-Summe in AKKU1 mit 0.0kW initialisieren
    
          O     A      0.0        //Antrieb1 vor Ein?
          O     A      0.1        //Antrieb1 rück Ein?
          SPBN  M002
          L     DBD    0          //Antrieb1 KW
          +R
    
    M002: U     A      0.2        //Antrieb2 Ein?
          SPBN  M003
          L     DBD    4          //Antrieb2 KW
          +R
    
    M003: U     A      0.3        //Antrieb3 Ein?
          SPBN  M004
          L     DBD    8
          +R
    ...
    ...
    
    M197: U     A     19.7        //AntriebX Ein?
          SPBN  M200
          L     DBD  636          //AntriebX KW
          +R
    
    M200: T     #KW_OUT
    Benchmark

    Diese Vorschläge fallen mir spontan ein, weil ich schon seit 1996 S7-300 programmiere und die CPUs
    damals noch nicht so leistungsfähig waren wie heute.
    Ich denke, es wird mal Zeit, die Erfahrungen anhand aktueller CPUs zu überprüfen. Ich habe einen
    Benchmarktest der verschiedenen Programmlösungen mit einer CPU 315-2 PN/DP gemacht.

    Fazit: Das Ergebnis überrascht mich nun doch ein wenig. Die Rechenzeit-Unterschiede sind nicht
    mehr so gewaltig, wie sie noch vor 4 Jahren gewesen wären. Doch wenn es auf kurze und gleichmäßige
    Zykluszeit ankommt, ist es immer noch richtig, die lineare Programmierung in Betracht zu ziehen.
    Der Programmierer muß entscheiden, ob er lieber kurzen oder lieber schnellen Code will.

    Code:
    Befehlsausführungszeiten Festpunktarithmetik und Gleitpunktarithmetik (Angaben von Siemens)
    
    S7-300 CPU                Festpunkt Gleitpunkt
    alte Generation
      314/315/315-2DP (2001)    2,0µs     50,0µs
    neue Generation mit MMC
      314/315-2 (PN/)DP         2,0µs      3,0µs
      317-2 (PN/)DP             0,2µs      1,0µs
      319-2 PN/DP               0,02µs     0,04µs
    Code:
    Benchmark-Ergebnisse bei kein Ausgang Ein (0%), 50% Ausgänge Ein und alle Ausgänge Ein (100%)
    (getestet und gemessen auf CPU 315-2 PN/DP und dann für CPU alte Generation hochgerechnet)
    
                     MC7-Code + DB   Rechenzeit 0/50/100%   alte CPU 0/50/100%
                         Byte  Byte      ms (gemessen)         ms (berechnet)
    Schleife Gini         184 + 640    2,1 / 2,8 / 3,5       2,1 / 6,6 / 11,0
    Schleife eNDe          70 + 640    1,2 / 1,6 / 1,9       1,2 / 5,4 /  9,4
    linear aus DB        1734 + 640    0,4 / 0,5 / 0,6       0,4 / 4,3 /  8,1
    linear fest REAL     2012     -    0,4 / 0,4 / 0,5       0,4 / 4,2 /  8,0
    linear fest INT      1740     -    0,4 / 0,4 / 0,5       0,4 / 0,4 /  0,5
    Es ist zu sehen, daß die Bearbeitungszeiten der Gleitpunktarithmetik so stark verbessert wurden, daß
    es praktisch keinen Unterschied mehr macht, ob mit Festpunkt- oder Gleitpunkt-Befehlen gerechnet
    wird. (bei der 317 und entsprechend großem Programm könnte man noch drüber nachdenken)

    Gegenüber der reinen KW-Addition benötigen Schleifen ein vielfaches an Rechenzeit für die
    Adressberechnung, die indirekten Zugriffe und das zwischenspeichern.
    (Schleife von Gini: 7-fache Zeit, optimierte Schleife von eNDe: 4-fache Zeit)
    Der Programmcode als Schleife ist allerdings wesentlich kürzer und eleganter.

    Gerade bei Schleifen lohnt es sich, den Code zu optimieren, Befehle möglichst aus der Schleife
    herauszuhalten und/oder Befehle zusammenzufassen (z.B. SLD 5).

    Am Code von eNDe kann man fast nichts mehr optimieren.
    Nur das "L #Zeiger" vor dem "SLD 5" ist überflüssig, der Wert ist noch im AKKU1.
    Zur Ehrenrettung:
    Der Befehl erhöht die Verständlichkeit des Codes und macht bei 100% eingeschalteten Ausgängen
    gerade mal 0,032ms mehr Rechenzeit aus.
    (ich hätte den Befehl im Quelltext auch hingeschrieben, aber auskommentiert)

    Gruß
    PN/DP

    PS:
    In der Abschluß-Sequenz SET + SAVE + CLR von Gini ist CLR eigentlich überflüssig.
    Das VKE wird zwar an den aufrufenden Baustein zurückgegeben, kann da aber nicht weiter verknüpft
    werden (/ER ist 0), nur einer boolschen Variable zugewiesen werden, und das auch nur in AWL.
    Zitieren Zitieren Benchmark Rechenzeit vs. Codegröße  

  5. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    Gini (05.09.2009)

Ähnliche Themen

  1. Antworten: 54
    Letzter Beitrag: 12.06.2011, 11:04
  2. Frage zu Baustein vergleich
    Von Pockebrd im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 24.09.2010, 18:00
  3. Mega Problem bei meinem Programm
    Von COOLT im Forum CODESYS und IEC61131
    Antworten: 10
    Letzter Beitrag: 28.07.2009, 10:28
  4. FB Baustein . Frage?
    Von hank12 im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 07.05.2009, 16:45
  5. Auf meinem Schreibtisch herrscht Chaos
    Von pvbrowser im Forum Stammtisch
    Antworten: 11
    Letzter Beitrag: 12.07.2007, 12:50

Lesezeichen

Berechtigungen

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