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

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

Thema: Beschalten EN-Schnittstelle FC und FUP Bausteine

  1. #11
    Registriert seit
    29.03.2004
    Beiträge
    5.742
    Danke
    143
    Erhielt 1.688 Danke für 1.226 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Vor allem ist bei der Messerei bei der 1200/1500 zu beachten, dass der Compiler den Code mehr oder weniger gut optimiert. Das heißt, es wird nicht mehr alles genau so wie man es im Quellcode schreibt auch in der SPS abgearbeitet. Da wir noch nicht so weit sind uns den generierten Code komplett anzuschauen, kann man die realisierten Optimierungsschritte nur an Stichworten im TIA-Portal mutmaßen. Was es auf jeden Fall gibt ist, dass arithmetische Operationen mit Konstanten schon vorher ausgerechnet werden. Das beherrschte sogar der leidige Step7-SCL Compiler.

    Dann könnte es sein, dass man in seinem Testprogramm Berechnungen mit Temp-Variablen vornimmt deren Ergebnis aber nicht weiter verarbeitet oder gespeichert werden. Theoretisch könnte der Compiler den kompletten Codeblock entfernen weil er ihn als sinnlos erkennt. Sicherer ist hingegen (bezüglich Laufzeittests) wenn die Daten auf denen gearbeitet wird im Merker- oder Datenbausteinbereich abgelegt werden. Da diese Daten global sind kann der Compiler den Code nicht einfach entfernen, denn es könnte ja sein dass ein Zeitinterrupt oder eine Visualisierung auf diese Daten zugreift.

    Ich würde vermuten dass bei der 1200/1500 DB-Zugriffe weiterhin langsamer sind als Merkerzugriffe oder Zugriffe auf Temp-Variablen. Zumindest wenn man Operationen mit Variablen aus unterschiedlichen DBs vornimmt.

  2. #12
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hi Thomas

    Nein, da liegst du falsch. Optimierte DB sind schneller als Standard DB, Merker, Eingänge und Ausgänge.
    Es ist aber auch vom Datentyp abhängig. Dint zeigt größere Unterschiede als Int, Byte keine, und Bool die Größten.

    Nehmen wir eine REAL Addition:

    Am schnellsten gehen Zugriffe auf optimierte DB wenn die DB-Nummer bekannt ist.

    Auf Platz zwei liegen Zugriffe auf TEMP und STATIC wenn der Baustein optimiert ist.

    Dann kommen Zugriffe auf optimierte Daten die als Referenz rein kommen. Also auf die eigene Schnittstelle oder Elemente in UDT die im INOUT deklariert sind.

    Dann folgen Zugriffe auf optimierte Daten die per Value rein/raus kommen. Das liegt aber am kopieren, das durch meine Methode mit gemessen wird, was durchaus realistisch ist. Greift man auf einfache Typen in der In und Out eines FB zu, welche im Aufruf aber gar nicht versorgt sind, dann hast du den nackten Zugriff und der landet auf Platz zwei. Aber was soll ein unversorgter Input? Das ist ja dann STATIC

    Auf Platz fünf kommt E A M und Standard DB wenn die DB Nummer bekannt ist.

    Dann TEMP und STATIC wenn der Baustein nicht optimiert ist.

    Dann nicht optimierte Daten per Referenz.

    Den vorletzten Platz haben nicht optimierte Daten die per Value übergeben werden.

    Und einsam weit abgeschlagen liegen ungünstig versorgte UDT Parameter. Also an einen optimierten FC einen Standard DB verschalten, das kostet richtig böse viel Laufzeit. Der wird vermutlich erst kopiert und dann referenziert.


    Du hast recht, mit dem optimierenden Compiler kann man sehr irritierende Messwerte bekommen. Also einfach irgendwelchen Code verdoppeln führt total in die Irre. Aber wenn du.
    Code:
    t1 := i1 + i2;
    t2 := i3 + i4;
    o1 := t1 * t2;
    rechnen lässt, dann gibt es auch für den besten Optimierer der Welt wenig Potential.


    Seit neuestem kann man ja auch mit VariantPut und VariantGet indirekt ... aber das liegt auch nicht besser als Standard Speicher. Andererseits schein MOVE_BLK_VARIANT wieder einigermaßen schnell zu werden, wenn die Datenmenge größer wird. Das ist eine von den Ecken, wo ich noch nicht wirklich durch blicke. Die paar Messwerte die habe sind sehr unlogisch.

    'n schön' Tach auch
    HB
    Geändert von HelleBarde (15.05.2014 um 22:30 Uhr)

  3. #13
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 220 Danke für 174 Beiträge

    Standard

    Hier hab ich 2 PDF's mit die verarbeitungszeit einzelne aufrufen. Ist aber für die 300 und 400.

    Jetzt ist das für mir o.k. weil wir der 1200 und 1500 nicht im Einsatz haben.
    .
    Anhang 24213

    Anhang 24212

    Hab gerade ein erste versuch gemacht der Messmethode um zu setzen .
    Hänge gerade an der While schleife und ob der Weck OB eine feste 100ms cyclus hat.
    Sehe im Moment nur das ich der aufruf auf 100ms setzen kann.

    Morgen auf der Arbeit das Berger Buch mal dazu nehmen.

    Bram
    Wenn es nicht auf STRAVA ist, ist es nicht passiert !!

  4. #14
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.207
    Danke
    927
    Erhielt 3.293 Danke für 2.662 Beiträge

    Standard

    Zitat Zitat von HelleBarde Beitrag anzeigen
    es ist egal in welcher Sprache du den Call programmierst. Auf die Zykluszeit hat das keinen Einfluss.

    Aber du musst vorsichtig sein, dass du nicht Äpfel mit Birnen vergleichst. In deinem AWL verwendest du nur Merker. Während du in FUP auf DB zugreifst, manchen Eingang negierst und einmal sogar einen Vergleich an den Eingang legst. Das kostet alles zusätzliche AWL Befehle, die du in AWL je auch programmieren müsstest. Also wenn du die Sprachen miteinander vergleichst, dann müssen es auch wirklich semantisch gleich und von den Adressierungsarten her gleich sein. Wenn du das hast, dann gibt es zwischen KOP, FUP und AWL keinen Unterschied.
    Also ich sehe da schon einen Unterschied ob der CALL in AWL oder FUP/KOP programmiert wird.
    Ausführungszeiten habe ich nicht gemessen, denke aber, daß der längere Code auch länger braucht.

    AWL, benötigt 46 Byte
    Code:
          CALL  FC10
           IN_1:=M0.0
           IN_2:=M0.1
           IN_3:=M0.2
           IN_4:=M0.3
           IN_5:=M0.4
           IN_6:=M0.5
           IN_7:=M0.6
           IN_8:=M0.7
    KOP, benötigt 112 Byte, 66 Byte mehr als AWL
    Code:
                +----------+
                |   FC10   |
    ------------|EN     ENO|-
                |          |
           M0.0-|IN_1      |
                |          |
           M0.1-|IN_2      |
                |          |
           M0.2-|IN_3      |
                |          |
           M0.3-|IN_4      |
                |          |
           M0.4-|IN_5      |
                |          |
           M0.5-|IN_6      |
                |          |
           M0.6-|IN_7      |
                |          |
           M0.7-|IN_8      |
                +----------+
    AWL, benötigt 126 Byte
    Code:
          CALL  FC10
           IN_1:=DB1.DBX0.0
           IN_2:=DB1.DBX0.1
           IN_3:=DB1.DBX0.2
           IN_4:=DB1.DBX0.3
           IN_5:=DB1.DBX0.4
           IN_6:=DB1.DBX0.5
           IN_7:=DB1.DBX0.6
           IN_8:=DB1.DBX0.7
    KOP, benötigt 144 Byte, 18 Byte mehr als AWL
    Code:
                +----------+
                |   FC10   |
    ------------|EN     ENO|-
                |          |
     DB1.DBX0.0-|IN_1      |
                |          |
     DB1.DBX0.1-|IN_2      |
                |          |
     DB1.DBX0.2-|IN_3      |
                |          |
     DB1.DBX0.3-|IN_4      |
                |          |
     DB1.DBX0.4-|IN_5      |
                |          |
     DB1.DBX0.5-|IN_6      |
                |          |
     DB1.DBX0.6-|IN_7      |
                |          |
     DB1.DBX0.7-|IN_8      |
                +----------+
    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  5. #15
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 220 Danke für 174 Beiträge

    Standard

    Das mit optimierte und nicht optimierte Baustein muss ich mir auch mal anschauen.

    Ich hab viele FB's die (denke ich Standard sein)also nicht optimiert.
    Und auch eine menge an UDT's , aber nur im OUT Schnittstelle.
    Die UDT's werden dann OUT Schnittstelle wieder weiter gegeben an eine global (nicht optimierte ?) DB.

    Bram
    Wenn es nicht auf STRAVA ist, ist es nicht passiert !!

  6. #16
    Registriert seit
    29.03.2004
    Beiträge
    5.742
    Danke
    143
    Erhielt 1.688 Danke für 1.226 Beiträge

    Standard

    HB könnte ja mal sein Messprogramm einstellen. Am Besten vielleich in SCL, dann kann man das mal mit verschiedenen Steuerungen und TIA-Portal Versionen vergleichen.

  7. #17
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hallo Bram

    wenn du den TP auf 100ms stellst, dann solltest du den Zyklus auf 200ms stellen.
    Den TP auf 100ms und den Zyklus auf 100ms zu stellen muss schief gehen.
    Schließlich braucht der OB etwas mehr als 100ms, denn da kommen ja noch eine handvoll Befehle außen rum. Und damit verpasst der Zyklus sein Fenster und beim dritten mal bleibt die PLC stehen.

    Zyklus auf 200ms hat außerdem den Vorteil, dass dann noch reichlich Zeit für die Kommunikation bleibt, die durch die Beobachtungstabelle ausgelöst wird.

    HB

  8. #18
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 220 Danke für 174 Beiträge

    Standard

    @ PN/DP

    Ist der länge in BYTE der Machinencode MC7 die ich im Eigenschaften des Bausteins sehe ?

    Um bei mein Beispiel zu bleibenvon FC763 (nur mit merker beschaltet ohne Logik)

    AWL Aufruf MC7 code 86 BYTE

    FUP Aufruf MC7 code 216 BYTE

    Bram
    Geändert von de vliegende hollander (15.05.2014 um 22:54 Uhr) Grund: probiert
    Wenn es nicht auf STRAVA ist, ist es nicht passiert !!

  9. #19
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.207
    Danke
    927
    Erhielt 3.293 Danke für 2.662 Beiträge

    Standard

    Ja. Ist der MC7- bzw. Arbeitsspeicherbedarf.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  10. #20
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 220 Danke für 174 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Nach lange Zeit mal daran zugekommen.

    Erste Resultaten sind nicht schlecht mit diese Code

    Code:
     "Meettijdpuls".TP(IN:="START_IEC_Testtijd",
                        PT:=t#100ms,
                        Q=>#Testimpuls,
                        ET=>#Aktuele_Tijdwaarde);
    
    WHILE (#Testimpuls = true) DO
        // Te testen FB voor Cyclustijd
    "Berechnung_Sattdampf_DB"(P_Ist:=20.0,
                              Bara:="High",
                              T_Sattdampf=>#REAL);
    
    "TELWAARDE" := "TELWAARDE" + 1;
    RETURN;
    END_WHILE;
    Bram
    Wenn es nicht auf STRAVA ist, ist es nicht passiert !!

Ähnliche Themen

  1. Step 7 TON/TOF mit "MM:SS" beschalten und zurücklesen
    Von Waelder im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 22.01.2014, 10:22
  2. Step 7 Analoge Ein- und Ausgänge beschalten
    Von Zarewitsch im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 21.08.2013, 15:08
  3. FB mehrfach beschalten
    Von Dword im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 07.11.2012, 15:21
  4. STEP7: Bausteine von AWL in FUP wandeln
    Von Oeffi im Forum Simatic
    Antworten: 24
    Letzter Beitrag: 01.07.2008, 23:10
  5. Analogausgang beschalten...
    Von charlie im Forum Simatic
    Antworten: 29
    Letzter Beitrag: 21.06.2006, 08:57

Lesezeichen

Berechtigungen

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