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

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

Thema: Guter Programmierstil?

  1. #1
    Registriert seit
    07.09.2013
    Beiträge
    7
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi,
    um einen übersichtlichen (gut lesbaren) Quellcode zu erhalten, habe ich meinen AWL-Code als Zustandsautomaten programmiert.
    Sobald ich jedoch Timer verwende wird es schwierig.
    Mein erster Versuch (siehe Beispiel A) hat dann auch promt nicht funktioniert, weil der Timer so die steigenden und fallenden Flanken des Eingangssignals (#event bzw. #reset) nicht mehr mitbekommt.
    Code:
    // Example A:
             L    #state
             SPL  def           //    switch(state)
             SPA  z0            //    case: 0 (waiting for event)
             SPA  z1            //    case: 1 (timer started)
             SPA  z2            //    case: 2 (waiting for reset)
     def:    SPA  err           //    default:
     err:    NOP  0             //    Zustand invalid
             SPA     end
    
     z0:     U    #event        //    if(#event)
             L    ST5#10s        
             SS   T1            //    start timer
             L    1
             T    #state        //    switch to state=1
             SPA  end:
    
     z1:     U    T1
             =    #output       //    … doing something
             L    2
             T    #state        //    switch to state=2
             SPA  end:    
    
     z2:     U    #reset        //    if(#reset)
             R    T1
             L    0
             T    #state        //    switch to state=0
      
     end:    BEA
    Eine Lösung ist, die Timer aus der Zustandsmaschine wieder herrauszunehmen (siehe Beispiel B), ...
    Code:
    // Example B:
             L    #state
             SPL    def         //    switch(state)
             SPA    z0          //    case: 0 (waiting for event)
             SPA    z1          //    case: 1 (timer started)
             SPA    z2          //    case: 2 (waiting for reset)
     def:    SPA err            //    default:
     err:    NOP 0              //    Zustand invalid
             SPA     end
    
     z0:     U    #event        //    if(#event)
             S    #start_timer
             L    1
             T    #state        //    switch to state=1
             SPA    end:
      
     z1:     U    T1
             =    #output       //    … doing something
             L    2
             T    #state        //    switch to state=2
             SPA    end:    
    
     z2:     U    #reset        //    if(#reset)
             S    #reset_timer
             L    0
             T    #state        //    switch to state=0
      
     end:    U    #start_timer
             L    ST5#10s        
             SS    T1
             R    #start_timer
      
             U    #reset_timer
             R    T1
             R    #reset_timer
             BEA
    ... was jedoch zur Folge hat, dass die Lesbarzeit des Programms leidet (insbesondere wenn man viele Timer benutzen will/braucht).

    FRAGE:
    Ist es überhaupt sinnvoll einen Zustandautomaten und Timer gleichzeitig zu verwenden, oder ist das schlechter Programmierstil?
    Wie sonst könnte man dieses Problem lösen, damit auch große Programme noch gut lesbar bleiben?

    Viele Grüße,
    Truth
    Zitieren Zitieren Guter Programmierstil?  

  2. #2
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.708
    Danke
    398
    Erhielt 2.397 Danke für 1.997 Beiträge

    Standard

    Hallo,
    so wie ich das sehe läuft dein Zustandsautomat (Schrittkette) unabhängig vom Timer durch.
    Bedenke immer : Lade und Transfer-Operationen sind von vorgeschalteten Verknüpfungen unabhängig und werden immer und absolut ausgeführt.
    Ich würde eine Schrittkette so gar nicht erstellen.
    Benutz doch zu dem Thema mal die Forums-Suche. Das bringt dir massenhaft Beispiele ...

    Gruß
    Larry

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

    truth (09.09.2013)

  4. #3
    Registriert seit
    13.10.2007
    Beiträge
    12.024
    Danke
    2.784
    Erhielt 3.268 Danke für 2.156 Beiträge

    Standard

    Wenn doch der Sprungverteiler weiter genutzt werden sollte, ist
    es sinnvoller die Timer außerhalb des Sprungverteilers aufzurufen
    durch nutzen einer Hilfsvariablen.

  5. #4
    truth ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.09.2013
    Beiträge
    7
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Upps,
    ... ich hab die 'bedingten Sprunganweisungen' vergessen.
    Hier also das überarbeite Beispiel B2:
    Code:
    // Example B2:
             L    #state
             SPL  def           //    switch(state)
             SPA  z0            //    case: 0 (waiting for event)
             SPA  z1            //    case: 1 (timer started)
             SPA  z2            //    case: 2 (waiting for reset)
     def:    SPA  err           //    default:
     err:    NOP  0             //    Zustand invalid
             SPA  end
    
     z0:     U    #event       
             SPBN end
             S    #start_timer  //    if(#event)
             L    1
             T    #state        //    switch to state=1
             SPA  end
      
     z1:     U    T1
             SPBN end
             =    #output       //    … doing something
             L    2
             T    #state        //    switch to state=2
             SPA  end    
    
     z2:     U    #reset       
             SPBN end
             S    #reset_timer  //    if(#reset)
             L    0
             T    #state        //    switch to state=0
      
     end:    U    #start_timer
             L    ST5#10s        
             SS   T1
             R    #start_timer  
             U    #reset_timer
             R    T1
             R    #reset_timer
             BEA
    FRAGE:
    Wie könnte ich denn den Zustandautomat ohne Spungverteiler realisieren?

    Grüße Truth

  6. #5
    Registriert seit
    11.03.2011
    Beiträge
    384
    Danke
    32
    Erhielt 80 Danke für 69 Beiträge

    Standard

    Du könntest noch einen Schritt einfügen, so dass der Timer erstmal resettet wird (und false sieht).

    Da ich davon ausgehe, dass T1 true ist, so lange die Zeit läuft (habe grade nichts zum nachlesen da) habe ich im Schritt 2 habe ich die Aktion vor die Weiterschaltbedingung gezogen und diese auch in SPB geändert. Damit ist #output true, solange der Timer läuft.

    Das SPA end am Ende der Schritte könnte man hier auch weglassen. Ich vermute das NOT und SS T1 im Schritt 0 ist auch nicht wirklich notwendig, konnte ich aber nicht ausprobieren.

    Code:
             L    #state
             SPL  err          //    switch(state)
             SPA  z0            //
             SPA  z1            //    case: 1 (waiting for event)
             SPA  z2            //    case: 2 (timer started)
             SPA  z3            //    case: 3 (waiting for reset)
    
     err:   CALL SFC46         //     state invalid: Stop CPU
    
     z0:    SET 
            R T1               //    reset T1
            NOT
            SS   T1            //    make shure T1 sees false
            L    1
            T    #state        //    switch to state=1
            SPA  end
    		
    
     z1:    U    #event       
            SPBN end
            L    ST5#10s       //    if(#event)   
            SS   T1            
            L    2
            T    #state        //    switch to state=2
            SPA  end
      
     z2:    U    T1
            =    #output       //    … doing something
            SPB end
            L    3
            T    #state        //    switch to state=3
            SPA  end    
    
     z3:    U    #reset       
            SPBN end
            S    #reset_timer  //    if(#reset)
            L    0
            T    #state        //    switch to state=0
      
    end:    BEA

    Und noch besser Programmierstil wäre es nicht fest T1 zu verwenden, sondern TON oder TOF (Timerbausteine aus der IEC Bib)

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

    Semo (10.09.2013)

  8. #6
    Registriert seit
    27.06.2009
    Ort
    am Nordharz
    Beiträge
    3.713
    Danke
    443
    Erhielt 914 Danke für 739 Beiträge

    Standard

    Was mir überhaupt nicht einleuchtet - Warum soll der Code mit dem Sprungverteiler lesbarer sein als ohne?
    Code:
             U    #event        //    if(#event)
             L    ST5#10s        
             SS   T1            //    start timer
             
     
             U    T1
             =    #output       //    … doing something
    
              
             U    #reset        //    if(#reset)
             R    T1
    Das kann ich tausendmal schneller erfassen, als das ganze Gedöns mit dem Sprungverteiler.

    Und besserer Programmierstil ist es m.M.n. auch noch, denn er benötigt keine unnötigen Sprünge!
    In jeder anderen Sprache gibt's was auf die Mütze, wenn man überhaupt mit GOTO arbeitet.
    Und nebenbei erledigt es auch noch das Problem mit dem Timer.

  9. #7
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.476
    Danke
    1.138
    Erhielt 1.238 Danke für 971 Beiträge

    Standard

    Guter Programmierstil ist - meines Erachtens - Schrittketten in S7Graph zu erstellen

    @Hucki
    Bitte nicht wieder einen Flamewar um's GOTO beginnen

    Gruß
    Dieter

  10. Folgender Benutzer sagt Danke zu Blockmove für den nützlichen Beitrag:

    UniMog (10.09.2013)

  11. #8
    Registriert seit
    27.06.2009
    Ort
    am Nordharz
    Beiträge
    3.713
    Danke
    443
    Erhielt 914 Danke für 739 Beiträge

    Standard

    Zitat Zitat von Blockmove Beitrag anzeigen
    @Hucki
    Bitte nicht wieder einen Flamewar um's GOTO beginnen
    Oh, das war ganz und gar nicht meine Absicht.

    Ich würde nur gerne verstehen, warum jemand der Meinung ist, ein Programm mit Sprungliste wäre lesbarer als ohne.
    Gibt's ja sicher Gründe für.

  12. #9
    Registriert seit
    17.06.2003
    Beiträge
    1.269
    Danke
    478
    Erhielt 65 Danke für 57 Beiträge

    Standard

    Zitat Zitat von Blockmove Beitrag anzeigen
    Guter Programmierstil ist - meines Erachtens - Schrittketten in S7Graph zu erstellen
    Warum S7Graph ?? Aus Gewohnheit oder gibt es gewichtige Argumente. Geht das nicht auf die Zykluszeit ?

  13. #10
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.725
    Danke
    314
    Erhielt 1.519 Danke für 1.282 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Rudi Beitrag anzeigen
    Warum S7Graph ?? Aus Gewohnheit oder gibt es gewichtige Argumente. Geht das nicht auf die Zykluszeit ?
    Das gewichtigste:
    Es ist graphisch, und aktive Schritte sind relativ leicht zu erfassen.
    Zykluszeit ist jetzt kein gewichtiges Problem, da das Endergebnis (MC7) im Enteffekt ein Sprungsammelsurium ist.

    Das für mich nachteiligste:
    Die Art und Weise, wie die Schnittstelle von Graph funktioniert muss man irgendwie mögen ... was auf mich persönlich nicht zutrifft.
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

Ähnliche Themen

  1. TIA Programmierstil
    Von kuti im Forum Simatic
    Antworten: 29
    Letzter Beitrag: 05.07.2013, 20:37
  2. Programmierstil / schöner programmieren?
    Von D4K!ZZ4 im Forum Programmierstrategien
    Antworten: 35
    Letzter Beitrag: 31.10.2011, 10:56
  3. Guter Messtaster ?
    Von Unisardo im Forum Antriebstechnik
    Antworten: 8
    Letzter Beitrag: 27.06.2011, 09:43
  4. programmierstil s7
    Von Anonymous im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 01.11.2005, 19:04
  5. Programmierstil - Richtlinien - S7
    Von eloboy im Forum Simatic
    Antworten: 14
    Letzter Beitrag: 13.10.2004, 09:13

Stichworte

Lesezeichen

Berechtigungen

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