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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 20

Thema: Beschalten EN-Schnittstelle FC und FUP Bausteine

  1. #1
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 219 Danke für 173 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Alle,

    Wenn Mann die EN-Schnittstelle eines FC's oder z.b. im FUP eine MOVE Funktion nicht beschaltet werden die FC's und Funktion immer bearbeitet.

    So weit so gut.

    Wenn Mann jetzt der EN-Schnittstelle mit wert "Falsche" werden die nicht bearbeitet.

    Auch so weit so gut.

    Aber jetzt meine frage dazu:

    Hat es in die Programmbearbeitung (meine Einfluss auf Zycluszeit ) das gleiche Effekt als würde ich eine JUMP Funktion einsetzen um die FC's zu überspringen.
    bei der FUP Funktionen kommt in meinen fall auch etwas beisammen.

    Mir ist für Testzwecke online aufgefallen dass ich bei Beschaltung mit "falsch" die Bausteine als strich dargestellt sehe und bei JUMP seht man nichts (Als ob offline).

    Denke selbst ich muss zum JUMP Funktionen über gehen.

    Grund ist ein durch mir selbst geschriebene FB Zycluszeitmäßig zu optimieren.
    Zur Info : Natürlich ist das ein FB für alles wobei man jedes mal nur einzelne teilen braucht.

    Hat jemand von euch da Erfahrungen ?

    Bram
    Wenn es nicht auf STRAVA ist, ist es nicht passiert !!
    Zitieren Zitieren Beschalten EN-Schnittstelle FC und FUP Bausteine  

  2. #2
    Registriert seit
    29.03.2004
    Beiträge
    5.739
    Danke
    143
    Erhielt 1.686 Danke für 1.225 Beiträge

    Standard

    Bei einer S7300/400 kann man in der AWL sehen dass der Baustein ganz einfach übersprungen wird. Das Programm wird also um den Anteil des Bausteins schneller wenn dieser nicht aufgerufen wird.

    Bei der 1200/1500 sieht das ähnlich aus. Wobei man da nicht weiß wie die CPU die Anweisungen umsetzt.
    Bzw. konnte ich nur bei der 1200er den generierten Zwischencode entschlüsseln. Zumindest bei der 1200 wird die EN-/ENO-Mechanik nicht schon im Zwischencode mit Sprüngen umgesetzt, sondern die Anweisungen die im Zwischencode aufgerufen werden (z.B. MOVE) bekommen mitgeteilt ob EN/ENO beachtet werden soll. Was die CPU damit macht wird wohl für immer unklar bleiben, aber letztenendes wird es auch auf ein Überspringen der Anweisungen hinauslaufen, d.h. das Programm sollte schneller werden wenn Teile nicht bearbeitet werden.

  3. Folgender Benutzer sagt Danke zu Thomas_v2.1 für den nützlichen Beitrag:

    de vliegende hollander (09.05.2014)

  4. #3
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 219 Danke für 173 Beiträge

    Standard

    Tatsächlich,

    Man seht im AWL das das Programm ein Sprung darein macht wenn man de EN Schnittstelle beschaltet.

    Dann brauch ich mir um einige Netzwerke nicht zu kümmern.

    Mein FB wird in ein S7 414 CPU laufen später. Projektiert wird es mit TIA V13

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

  5. #4
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 219 Danke für 173 Beiträge

    Standard

    Ich hab eben weiter geprüft und fest gestellt wen man ein FC 3 mal aufruft im FUP das dann auch 3 Sprüngen entstehen. Nicht 1 Sprung so wie ich erwartet hab.

    Anhang 24154
    FUP

    Anhang 24155
    AWL

    Dann wäre es doch schneller für die CPU mit 1 Sprung zu schaffen ?

    Wobei das in der FUP ein riesen Darstellung und Netzwerkorgie wird

    Dann wäre de beste Wahl um zu schreiben im AWL. Oder natürlich gleich in der AWL.

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

  6. #5
    Registriert seit
    27.06.2009
    Ort
    am Nordharz
    Beiträge
    3.717
    Danke
    443
    Erhielt 919 Danke für 740 Beiträge

    Standard

    Oder Du erzeugst den Sprung selbst in FUP:





    PS: Dann sieht's übrigens auch so aus, wie Du's eigentlich erwartet hättest:

    Geändert von hucki (09.05.2014 um 18:24 Uhr)

  7. Folgender Benutzer sagt Danke zu hucki für den nützlichen Beitrag:

    de vliegende hollander (10.05.2014)

  8. #6
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 219 Danke für 173 Beiträge

    Standard

    Ich setze es um in AWL, So wie du es darstellst. Aber dann mach ich alles was zusammen gehört in 1 Netzwerk

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

  9. #7
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 219 Danke für 173 Beiträge

    Standard

    Hätte da noch mal eine frage die mir so bei der FUP zu AWL Umschaltung aufgefallen ist

    Anhang 24207

    Das mittlere Netzwerk ist der FC763 im Darstellung FUP
    Das rechter Netzwerk ist der FC763 in eine von FUP nach AWL umgeschaltete Darstellung
    Das linker Netzwerk ist der FC763 als reine AWL Aufruf.

    Jetzt sehe ich das er erst die Variablen auf lokal Daten schiebt , und dann die Lokal Daten auf der Baustein schaltet

    Wie seht dann die spätere Machinencode aus die aus dem FC generiert wird ?
    Die ist im FUP um 49 Zeilen länger als reine AWL Aufruf, so das es aus endlich (Denke ich) auch Einfluss hat auf der cycluszeit.

    Ist der Machinencode später gleich ??
    Es interessiert mir wirklich ob das schlecht ist für die Cycluszeit.

    Wen ich Quelle generier aus ein FC Aufruf. 1 mal als rein AWL andermal als reine FUP sehe ich das die 49 zeilen mitgenommen werden.

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

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

    Standard

    Hallo Bram

    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.

    Bei 300/400 wird letztendlich sowie so alles über AWL nach MC7 abgebildet. AWL kann etwas mehr als MC7. In AWL schreibst du L DB10.DBW12. Das kann MC7 gar nicht! MC7 kann nur AUF DB10; L DBW12, das sind zwei Befehle. Bei den CALL ist das ähnlich. MC7 kennt nur einen UC FCx. Dabei werden alle Parameter als 32Bit Pointer per Referenz übergeben. Deswegen muss du auch alles was nicht direkt adressiert werden kann, also die Negationen, die DB-Zugriffe und das Vergelichsergebnis zuerst nach L kopiert werden, damit im Hintergrund ein Zeiger auf L an den FC übergeben wird. Fazit: Es gibt keinen Geschwindigkeitsunterschied zwischen den Sprachen. Es gibt jedoch sehr wohl einen Unterschied im Komfort. Je komfortabler eine Sprache ist, desto schneller schreibt man langsame Programme
    SCL fällt ein wenig aus dem Rahmen, weil die andere Wege bei der Parameterübergabe gehen. Hier kann man in einer Zeile FC3( a + b ) schreiben. Letztendlich wird aber genau so wie bei FUP zuerst die Addition ausgeführt, das Ergebnis in einem LW abgelegt und ein Zeiger auf LW an den FC übergeben. Alles landet im MC7.

    Bei 1200 (und vermutlich auch bei 1500) wird alles nach MC7+ abgebildet. Aber wie in einem schönen Thread von Thomas_v2.1 erklärt wird, gehen hier die Compiler andere Wege. KOP/FUP wird nicht über den AWL Umweg abgebildet. Die 1200 hat kein AWL! Eher im Gegenteil, der KOP/FUP Code ist oft (aber nicht immer) kürzer als der AWL Code. Wir wissen zwar nicht wie der aussieht, aber allein an der Codegröße erkennt man, dass es AWL Konstrukte gibt, die die 1500 nicht mag. U >0 oder SPN mag sie überhaupt nicht. Bei meinen Laufzeitmessungen fallen solche Konstruktionen und das Gehampel mit Adressregistern total aus dem Rahmen. Der symbolische Zugriff auf ein Element eines DB geht rasend schnell. Ein AWL Programm, welches sich ein ANY Pointer zerlegt und über AUF DB und L W[AR1,p#0.0] auf das gleiche Element zugreift, braucht ungefähr 30 mal so lange. Das ist bei der AS400 nicht so.

    Fazit: Jede Sprache hat ihre Berechtigung. Keine ist im Prinzip schneller als die andere.

    'n schön' Tach auch
    HB

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

    de vliegende hollander (15.05.2014)

  12. #9
    Registriert seit
    12.12.2013
    Ort
    Kaiserslautern
    Beiträge
    1.339
    Danke
    388
    Erhielt 219 Danke für 173 Beiträge

    Standard

    Hallo Hellebarde,

    Danke für die Antwort

    Ich hab es mir gewünscht das es kein unterschied gibt .
    Bin so im Zweifel gekommen.
    Ja klar ist es 1000 mal angenehmer wenn noch Logik verschaltet wird um das im FUP zu machen.

    Hätte gleich noch mal eine frage an dir?

    PLC-Datentypen (UDT) als Aktualparameter IN_OUT einem FB übergeben

    In diese Tread hast du einige Cyclus Zeiten gemessen.

    Hat du dann der OB1 Cycluszeit dann jedes mal ausgelesen mit eine systemfunction ?

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

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

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Bram

    ich habe keine Zykluszeiten vermessen, ich habe Befehlslaufzeiten (versucht) zu messen. Das klingt jetzt rechthaberisch (vermutlich ist es das auch) und ist ein pingeliger aber (für mich) extrem wichtiger Unterschied.

    So ein Zyklus besteht aus:
    Peripherie lesen und Abbild der Eingänge erstellen
    Programm aus dem freien Zyklus ausführen
    Unterbrochen werden und was anderes tun
    weiter Programm aus dem freien Zyklus ausführen
    nochmal Unterbrochen werden
    weiter Programm aus dem freien Zyklus ausführen
    ...
    Abbild der Ausgänge auf die Peripherie schreiben
    Kommunikation mit dem ES und anderen Baugruppen durchführen


    Also man sieht, dass die Zykluszeit sehr viel mehr enthält als nur dein Programm. Das wird um so schlimmer je kürzer dein Programm ist. Aber wenn man nun messen will ob der eine Befehl oder der andere Befehl schneller ist, dann schreibt man ja ein kurzes Programm das eben nur den einen oder den anderen Befehl enthält. Und so lange da die Zykluszeit unter 1ms bleibt, hast du überhaupt keine Aussage.

    Weil man bei der Sache ja Information aus der CPU braucht, macht man eine Beobachtungstabelle und beobachtet Werte. Das schlägt sich als Kommunikation ebenfalls auf den Zyklus. Und Bausteinstatus kostet beim Beobachten von Schleifen richtig böse viel Zeit.

    Seit einiger Zeit gibt es für 1200/1500 einen Befehl RUNTIME, mit dem kann man Befehlsfolgen vermessen. Aber so richtig glücklich macht mich der auch nicht. Die Auflösung ist CPU abhängig und auch nicht so richtig toll.

    Inzwischen habe ich mir folgenden Trick ausgedacht. Geht in KOP/FUP/SCL (und AWL) und geht mit jeder CPU. (auch wenn die nicht von Siemens ist, z.B. von Beckhof)

    Man definiere ein oneloop : REAL im MD0 und erzeuge einen OB.
    Dort definiere ein cnt : DINT in der TEMP
    und setze diesen cnt auf 0
    dann starte einen TP für 100ms
    While-Schleife solange der TP true
    rufe einen Baustein ohne Parameter auf
    inkrementiere cnt
    while_end
    oneloop := 1e9 * ( 0.1 / DINT_TO_REAL( cnt ))

    Damit bekommst du in oneloop die Zeit für einen Schleifendurchgang in Nanosekunden.
    Für die 1200 kannst du auch 1e6 verwenden, dann sind das eben Mikrosekunden.
    Den onelopp kann man schön ein einer Beobachtungstabelle verfolgen (weil ja im MD0)

    Zuerst mal lässt du den aufgerufenen Baustein leer. Das ist sozusagen der Grundaufwand, die Basiszeit.
    Dann schreibst du in den aufgerufenen Baustein rein was dich gerade interessiert. Wenn du nun vom zweiten Versuch die Basiszeit abziehst, dann bleibt dir das was durch die zusätzlichen Zeilen, Boxen, Kontakte an Aufwand hinzugekommen ist.

    Die Zykluszeit ist dabei immer 100ms. Du musst also nie Angst haben, dass die CPU in Stop geht.

    Wenn du das im OB1 machst, wird du feststellen, dass die Zeiten sehr schwanken. Das liegt wie ich schon vermutet hatte an den Unterbrechungen. Also verwende am besten nicht den OB1 sondern einen zyklischen OB (bei der As400 einen 30er) und setze diesen auf höchste Priorität (findet sich in den Bausteineigenschaften des OB).

    Damit beruhigen sich die Werte, denn es gibt jetzt nicht mehr soviel, was die Messung unterbricht. Da der Baustein aber 100ms läuft, scheint die Kommunikation immer noch dazwischen zu funken. Also völlig stabil wird es nie. Aber man kann schon viel bessere Aussagen treffen als im OB1.


    viel Spaß beim Messen
    HB
    Geändert von HelleBarde (15.05.2014 um 21:30 Uhr)

  14. Folgender Benutzer sagt Danke zu HelleBarde für den nützlichen Beitrag:

    de vliegende hollander (15.05.2014)

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