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

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 21

Thema: Schleife über FB

  1. #11
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    .

    Zitat Zitat von chomp Beitrag anzeigen
    Hallo Ihr zwei,

    nach genau so einer Lösung habe ich gesucht!
    Ich probie das mal!

    Vielen Dank!

    chomp
    @ Harald

    Bevor wir hier also noch aneinandergeraten,
    sollten wir einfach mal die Rückmeldung des TE
    abwarten, denn der scheint ja erstmal weiter zu
    kommen und probiert es aus.

    Gruss
    kind regards
    SoftMachine

  2. #12
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    .

    @ Harald

    Bevor ich es jetzt noch vergesse:

    Solche Betitelungen wie "eine saublöde Idee"
    oder "Schweinerei" haben mich jetzt schon
    überrascht, da sie ja vom gerade frisch gekürten
    "User des Jahres 2013" hier geäussert werden.

    Gruss



    P.S. Gern kannst du (statt bisher lediglich Kritik) deine eigene konstruktive Lösung präsentieren !
    kind regards
    SoftMachine

  3. #13
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    @SoftMachine
    Solche deutlichen "Betitelungen" gehörten schon immer zu meinem Fach-Wortschatz. Vielleicht wurde ich gerade deshalb zum dritten mal in Folge zum "User des Jahres" gewählt?
    Tip: versuche doch mal mehr fundierte Fachbeiträge zu schreiben statt Deinem sonst üblichen HIER- und DA-Blabla und halte Dich zurück bei Sachen wo Du keine Ahnung hast, dann wirst Du vielleicht auch mal nominiert ...

    Irgendwie scheinst Du das Thema dieses Threads absolut nicht zu verstehen. Anders kann ich mir Dein Beharren an Deinem unsinnigen "UC ..." nicht erklären. Auch wenn Du es vielleicht nicht begreifst, so habe ich doch in diesem Thread hier schon mehr konstruktiven Fachbeitrag geliefert als Du. Dir fallen allerdings nur meine "Betitelungen" auf - für eine Art zu programmieren, die ich ablehne, weil sie in Step7 nicht vorgesehen ist und daher nicht unterstützt wird.

    Wenn ich eine Lösung präsentieren wollte, dann würde sie wohl ähnlich wie die schon gleich am Anfang verlinkte Lösung von Thomas_V2.1 aussehen. Hast Du denn schon versucht diese Lösung zu verstehen?

    Naja, mal sehen wie weit der TE mit Deinem "UC ..." kommt ...

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  4. #14
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen
    .
    Code:
    ...
    
    UC FB  [#index]
    ...
    Der FB wird hier ohne Instanz-DB aufgerufen und
    darf damit auch keine Bausteinparameter und keine
    statischen Lokaldaten haben.
    So ein Schwachsinn...

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  5. #15
    chomp ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    04.11.2013
    Beiträge
    10
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo zusammen,

    es ist ja eine etwas hitzige Diskussion entfacht.
    Leider bin ich am WE nicht dazugekommen das zu testen, werde das aber baldmöglichst tun und dann auch Rückmeldung geben!
    Zum Thema:

    Der Lösungsvorschlag von SoftMachine scheint auch nicht das zu sein was ich brauche eher das verlinkte von Thomas_V2.1.

    Zum Sinn:
    Ich finde die Kritik von PN/DP ist durchaus gerechtfertigt, allerdings wenn es sich nicht nur um eine einmalige Tipparbeit handelt sondern um mehrfache und es sich nochdazu nicht nur um 5 - 10 Aufrufe der selben Instanz handelt, sondern das ganze sich im hohen zweistelligen Bereich bewegt, bin ich gerene Bereit über so eine "Schweinerei" nachzudenken!

    Schöne Grüße
    chomp

  6. #16
    Registriert seit
    06.10.2003
    Beiträge
    3.411
    Danke
    451
    Erhielt 506 Danke für 408 Beiträge

    Standard

    Zitat Zitat von chomp Beitrag anzeigen
    .. allerdings wenn es sich nicht nur um eine einmalige Tipparbeit handelt sondern um mehrfache und es sich nochdazu nicht nur um 5 - 10 Aufrufe der selben Instanz handelt, sondern das ganze sich im hohen zweistelligen Bereich bewegt, bin ich gerene Bereit über so eine "Schweinerei" nachzudenken! ..
    Wenn du schon einmal dabei bist, beim Nachdenken meine ich, dann käme vielleicht auch "meine" Lösung in Betracht. Ich hatte vor Jahren die selben Gedankengänge. Bei ähnlichen und wohl bemerkt über Jahre gut durchdachten Dingen lege ich einmalig einen UDT mit dem Inhalt der "Instanzdaten" an. Diesen UDT vereinbare ich x-fach in einem Global-DB und übergebe den DB an eine FC zur Bearbeitung. Ein zweiter Baustein-Parameter zeigt aus einem bestimmten Grund (bei mir HMI-Anbindung) auf eine weitere (einzelne) Variable von diesem Typ. Aus der DB-Größe und aus der UDT-Größe erkennt die FC die Anzahl der "Instanzen" und bearbeitet eine nach der anderen. In meinem Fall wird pro Zyklus immer nur eine Instanz bearbeitet. Grundlegend wichtig ist dass der UDT wirklich gut durchdacht ist. Nachträgliche Änderungen führen quasi zu einer neuen Generation der gesamten Bibliothek. Diese Schweinerei nenne ich "System" . Wenn man das System kennt, ist es selbst bei komplexen Sachen sehr effektiv und übersichtlich, resourcenschonend und auch leicht zu warten. Bausteinparameter wie Merker, Eingänge, Ausgänge usw. werden einfach durch die Variablen des DB ersetzt, bzw. direkt in den DB geschrieben bzw. gelesen. Vielleicht ist das noch mal ein weiterer Denkanstoß.
    Es gibt viel mehr Leute, die freiwillig aufgeben, als solche, die echt scheitern.
    Henry Ford

  7. #17
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.191
    Danke
    923
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Ich will mal meine Kritik etwas untermauern - die soll nicht wie unkonstruktives Meckern wirken

    Das größte Problem bei dem Wunsch zur Einsparung von Tipparbeit ist, daß auch noch verschiedene Aktualparameter an die Instanzaufrufe übergeben werden sollen. Ob diese Übergaben direkt am Bausteinaufruf gemacht werden oder vorher und nachher in/aus den Array-Instanzen, spart praktisch nichts. Das kann man imho doch schon so grob überschlagen. Oder man schaut es sich mal an:

    Das "klassisch" ausprogrammierte Beispiel vom TE (AWL/Pseudocode)
    (in Blau die Zeilen, die je Instanz unvermeidbar nötig sind)
    Code:
    VAR
        meinFB_1 : meinFB; //Ventil 12Y1 Presszylinder
        meinFB_2 : meinFB; //Ventil 12Y4 Schubzylinder horizontal
        meinFB_3 : meinFB; //Ventil 14Y3 Hubzylinder vorne
    END_VAR
    
    CALL #meinFB_1
      In := M0.0
      Out := M0.1
    
    CALL #meinFB_2
      In := M1.0
      Out := M1.1
    
    CALL #meinFB_3
      In := M2.0
      Out := M2.1
    
    U #meinFB_1.Wert
    U #meinFB_2.Wert
    U #meinFB_3.Wert
    = m5.0
    Nun die Tipparbeit "sparende" Variante mit Instanz-Array (SCL).
    (in Blau die Zeilen, die je Instanz unvermeidbar nötig sind)
    (Die Deklaration des TYPE meinFB_t laß ich hier mal weg, weil die mehr oder weniger eine nicht sehr aufwendige Kopie der Variablendeklaration des FB meinFB ist)
    Code:
    VAR
        FB_ARRAY : ARRAY[0..2] OF meinFB_t; //einzelnen Instanzen kann kein Kommentar und kein eigenes Symbol gegeben werden
        doInst : meinFB;
    END_VAR
    VAR_TEMP
        i : INT;
    END_VAR
    
    BEGIN        
    //Eingänge aller Instanzen mit ihren Aktualwerten versorgen:
        FB_ARRAY[0].In := M0.0;
        FB_ARRAY[1].In := M1.0;
        FB_ARRAY[2].In := M2.0;
    
    //alle Instanzen aufrufen
        FOR i := 0 TO 2 DO
            // Array-Instanz in Ausführ-Instanz kopieren
            doInst.In    := FB_ARRAY[i].In;
            doInst.Out   := FB_ARRAY[i].Out;
            doInst.Wert  := FB_ARRAY[i].Wert;
            doInst.Stat1 := FB_ARRAY[i].Stat1;
            doInst.Stat2 := FB_ARRAY[i].Stat2;
            doInst.Stat3 := FB_ARRAY[i].Stat3;
    
            // die Ausführ-Instanz aufrufen
            doInst();
    
            // Daten von Ausführ-Instanz in Array zurückkopieren
            FB_ARRAY[i].In    := doInst.In;
            FB_ARRAY[i].Out   := doInst.Out;
            FB_ARRAY[i].Wert  := doInst.Wert;
            FB_ARRAY[i].Stat1 := doInst.Stat1;
            FB_ARRAY[i].Stat2 := doInst.Stat2;
            FB_ARRAY[i].Stat3 := doInst.Stat3;
        END_FOR;
    
    //alle Instanz-Ausgänge auf die Ausgangsvariablen schreiben:
        M0.1 := FB_ARRAY[0].Out;
        M1.1 := FB_ARRAY[1].Out;
        M2.1 := FB_ARRAY[2].Out;
    
    //Beispiel-Verknüpfung
        M5.0 := FB_ARRAY[0].Wert AND FB_ARRAY[1].Wert AND FB_ARRAY[2].Wert;
    END_FUNCTION_BLOCK
    Also ich sehe hier kein nennenswertes Einsparpotenzial. Nur eine absolute Verschlechterung der Übersichtlichkeit.

    Man spart gerade mal die Zeile mit der Instanz-Deklaration und die Zeile mit dem "CALL Instanz..", hat dafür aber einmalig einen Schreib-Mehraufwand von hier > 15 Programmzeilen (was im realen Programm je nach Anzahl der Instanz-Variablen leicht mehr werden können).
    Nochmal: man spart je Instanz gerade mal 2 Programmzeilen, muß dafür aber Nachteile in Kauf nehmen, z.B. verliert man die Möglichkeit, jeder einzelnen Instanz ein eigenes Symbol und einen eigenen Kommentar zu geben.

    Falls man das in AWL schreiben will, dann benötigt diese Schreib-"Einsparung" sogar noch mehr Schreibaufwand.
    Dann benötigt jede Kopieraktion 2 Programmzeilen (L + T bzw. U + =). In AWL spart man also überhaupt keine Programmzeilen sondern muß sogar mehr schreiben!

    Da der meiste unvermeidliche Schreibaufwand in der Versorgung der Eingangs- und Ausgangs-Parameter liegt, ist es praktisch sogar unerheblich, wie aufwändig oder clever der CALL-Code innerhalb der FOR-Schleife gelöst wird, dieser Code fällt ja nur einmal an.

    Durch das mehrfache Kopieren der Instanzdaten hat diese Array-Variante eine deutlich schlechtere Performance als die klassisch übersichtlich ausprogrammierte Variante. Der Programmspeicherbedarf wird zudem erheblich größer.

    Übrigens kann man auf diese Art keine Variable im selben OB-Zyklus (bzw. beim selben Aufruf des Mutter-FB) von einer Instanz zur nächsten weitergeben, sondern immer erst im nächsten Zyklus, weil die Ausgangsvariablen erst beschrieben werden, nachdem alle Instanzen ausgeführt wurden.

    Selbst wenn man alle Übergabeparameter als Pointer deklarieren würde, um das Kopieren der Aktualwerte einzusparen, dann müßte man trotzdem einmal die Pointeradressen in das Instanz-Array schreiben - es spart also auch wieder keine Schreibarbeit.

    Es gibt bestimmt noch mehr Probleme, wenn man erstmal richtig drüber nachdenkt...

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

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

    vollmi (28.01.2014)

  9. #18
    chomp ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    04.11.2013
    Beiträge
    10
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ich möchte den vielen konstruktiven Beiträgen und Anregungen einmal Rechnung tragen und das ganze etwas näher beleuchten. Danke auch an Mr. Scrooge den Vorschlag finde ich auch sehr interessant!

    Konkret geht es darum. Ich habe meien Hütte automatisiert (Ja ich kenne Oscat) und das sieht im Moment so aus:
    Code:
    // Das findets jeweils in einem Multiinstanz FB statt den ich Pro Raum habe!
    //Für jeden Lichtschalter im Haus
          CALL  #Switch
           I_Enabled:=TRUE
           Input    :="E_Switch_Guest"
           Q_SC     :=
           Q_DC     :=
           Q_LC     :=
           Q_Sig    :=
    
    // -----------------------------------------
    // Lamp 1
    // -----------------------------------------
    
    // Toggle
          O     #Switch.Q_SC
          O     "GivenValueInterface".Lamps.Guest.Toggle
          =     #Toggle
    
    // TurnOn
          O     "GivenValueInterface".Lamps.Guest.TurnOn
          =     #TurnOn
    
    // TurnOff
          O     "StairsBasement".Switch_2.Q_SC
          O     "StairsFirstFloor".Switch_1.Q_DC
          O     "GivenValueInterface".Lamps.Guest.TurnOff
          =     #TurnOff
    
    // TimedOn
          O     #Switch.Q_DC
          O     "GivenValueInterface".Lamps.Guest.TimedOn
          =     #TimedOn
    
    
          CALL  #Light
           I_TimedOn:=#TimedOn
           I_Toggle :=#Toggle
           I_TurnOn :=#TurnOn
           I_TurnOff:=#TurnOff
           I_Enabled:="GlobalConfig".Lamps.Guest.Enabled
           I_Time   :="GlobalConfig".Lamps.Guest.TimeOnValue
           Q_On     :=
    
          U     #Light.Q_On
          =     "A_Li_Guest"
          =     "SystemState".Lamps.Guest
    Ich scheue also nicht die Tipparbeit, den es ist alles Fertig und funktioniert!
    Es ist nur so das ich mit dieser Lösung, wenn ich was am Verhalten ändern will, anfangen muss zu Programmieren. Ok, das geht schnell und einfach, aber noch schneller und einfacher ginge es über ein HMI über Parametrierung statt Programierung.
    Dazu hatte ich die Idee alle FB (hier #Switch) über ein Array zu durchlaufen. Dann prüfen welche Signale anliegen. Pro Consumer (hier #Light) gibt es eine Array mit allen Eingangssignalen (DC, SC, LC) und dann wird verglichen ob hierfür eine Aktion (und welche) ausgeführt werden soll. Konkret muss man jedes Eingangssignal (3 pro Taster) mit jedem Ausgangstreiber (4 pro Consumer) prüfen. Also: 3 * [AnzahlTaster] * 4 * [AnzahlConsumer] = (Bei mir >30k). Das das ganze nicht Performanter wird ist mir durchaus klar, mir geht es hier auch mehr am Spaß an der Freude .

    Das Problem mit den benamten Instanzen ist mir durchaus bewusst. Ist mir dann aber auch egal weil ich sowieso jedes Eingangssignal mit jeder Senke teste. Um das in der HMI übersichtlich zu halten Dachte ich an ein Weiteres Array aus UDTs, das die Bezeichnungen der Lichter, Schalter und Steckdosen hält!

    schöne Grüße
    chomp
    Geändert von chomp (28.01.2014 um 11:10 Uhr)

  10. #19
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.726
    Danke
    398
    Erhielt 2.401 Danke für 2.001 Beiträge

    Standard

    Hallo chomp,

    vielleicht ist nicht die Idee falsch sondern der Ansatz ...

    Es ist doch nur eine Frage, wen du nach vorne stellst. Du könntest z.B. einen Master-Baustein machen, der dein Array_of_UDT verwaltet. In dem läuft die Schleife, in der die Struktur-Ergebnisse[index] verknüpft werden. Das kann/könnte dann sogar (sofern es nicht eine Timer-Funktion ist) über einen eingelagerten FB abgewickelt werden.
    Falls du noch zusätzlich Zeiten brauchst so liesse sich das ja auch ganz gut "zu Fuß" lösen (Systemzeit mit verarbeiten).

    Gruß
    Larry

  11. #20
    chomp ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    04.11.2013
    Beiträge
    10
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Larry,

    ich bin mir nicht sicher ob ich deinen Vorschlag richtig verstanden habe.
    Du schlägst vor das was ich jetzt als FB gelöst habe (Switch und Light) anstatt als FB als FC löse.

    Wie gesagt bin ich mir nicht sicher ob du das so gemeint hast aber ich habe mal darüber nachgedacht und das sollte sich zu einer recht schmucken Lösung ausbauen lassen.

    Ich "füttere" den FC dann mit drei UDTs, einen für In, Out, und die Stat. Diese wiederum kann ich in einem Array UDT zusammenfassen welches mehrfach über ein Array instanziert wird.
    Das ganze sollte nicht allzu unleserlich werden.

    gruß chomp

Ähnliche Themen

  1. Step 7 Unterschied zwischen IF- Schleife und While-Schleife
    Von Vokal12 im Forum Simatic
    Antworten: 11
    Letzter Beitrag: 29.10.2013, 22:52
  2. Step 7 Schleife ?
    Von byfluffy im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 18.10.2013, 12:09
  3. Antworten: 23
    Letzter Beitrag: 12.06.2011, 07:30
  4. for-Schleife
    Von fai004 im Forum Simatic
    Antworten: 9
    Letzter Beitrag: 26.04.2009, 19:14
  5. For Schleife in VB 6
    Von godi im Forum Hochsprachen - OPC
    Antworten: 8
    Letzter Beitrag: 14.06.2007, 10:03

Lesezeichen

Berechtigungen

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