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

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

Thema: Kaskadierte Temperaturregelung

  1. #1
    Registriert seit
    20.02.2014
    Beiträge
    75
    Danke
    13
    Erhielt 2 Danke für 2 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo zusammen,

    Zur Ausgangssituation:
    Ich habe ein bestehendes S7-classic Projekt für eine Hochregallagerlüftung. Diese ist mit einem Führungs-, Folge- und Motorregler ausgerüstet. Dabei sind diese 3 Regler mit dem CONT_C aufgebaut.
    Führungsregler = Raumtemperatur
    Folgeregler = Ablufttemperatur
    Die Solltemperatur im Lager beträgt 5°C.
    Nun soll ich für ein anderes Hochregallager dieses Funktionsprinzip anwenden, jedoch wird bei dieser Anlage eine S7-1500 eingesetzt.

    Dass ich das nun 1:1 mit diesen Reglern übernehmen kann ist klar, jedoch bietet mir das TIA-Portal zwei andere Regler an (PID_Compact, PID_Temp).
    Ist es nun besser den alten CONT_C weiter zu verwenden, der sich ja schon bewährt hat und die Parameter schon in etwa bekannt sind, oder sind die beiden anderen für so eine Aufgabe besser geeignet?
    Bereitet mir die Selbstoptimierung der Regler durch den kaskadierten Aufbau eventuell Probleme?

    Danke schon mal für die Antworten

    Mit freundlichen Grüßen

    Andreas
    Zitieren Zitieren Gelöst: Kaskadierte Temperaturregelung  

  2. "@ducati: war eher eine Zustimmung

    Für mich sind weitere Gründe für den CONT_C
    Simpel und leicht nachzuvollziehen
    Das Ding ist im Endeffekt ein einfaches Rechenwerk. Kann man leicht nachrechnen, somit weis man vorher was man am LMN bekommt.
    Die TOs sind (auf Grund der erweiterten Funktionen) natürlich deutlich komplizierter und haben ewig viel Parameter in den Instanzdaten
    Wenn man diese (siehe nächster Punkt) nicht über das grafische Interface parametrieren kann, wird's aufwändig.

    Multiinstanzfähigkeit
    Man kann einen CONT_C problemlos in eine Multiinstanz packen.
    Man muss ihn nicht mal in nem OB aufrufen. Sofern man ihn mit der korrekten Zeit seit dem letztem Aufruf (z.B. durch Zeitmessung) versorgt kann man den überall verwenden.

    Grad hier ist für mich eine große Schwäche der Technologieobjekte.
    Man kann zwar PIDTemp auch als Multiinstanz aufrufen, verliert dann aber die Möglichkeit den Regler mit dem grafischen Interface in TIA zu parametrieren.
    Das ist eigentlich das was die TOs ausmacht

    Einen TO-Regler außerhalb eines OBs aufzurufen macht möglicherweise auch Schwierigkeiten, der TO-Regler misst die vergangene Zeit des letzten Aufrufs selber und
    geht bei Abweichung zur Parametrierung in einen Fehlerzustand.

    Ganze Regelkreise in einen Baustein zu stecken und diese bequem per Multiinstanz irgendwo in einem Baustein zu erstellen ist mit den TOs eher schwierig.
    Manche TOs (z.B. High Speed Counter) können gar nicht als Multiinstanz angelegt werden.

    Keine Betriebsarten und Fehlerzustände die den Regler einfach stoppen
    Wenn beim CONT_C der COM_RST auf Low ist, dann arbeitet das Ding. Fertig aus.
    Bei den TO-Regler hat man Betriesarten die man per Befehl umschalten muss und Fehler die eventuell den Regler auf Stopp setzen

    Simulation
    Ursprünglich konnte man sowohl die TO-Regler als auch den CONT_C in PLCSIM nicht simulieren. Mittlerweile geht es anscheinend wieder... vorerst.
    Beim CONT_C musste ich mir damals den 300er-AWL-Code portieren. Nicht optimal, aber besser als gar nix.
    Wobei man sagen muss, wenn man beim CONT_C von "bewährt" spricht sollte man eventuell auch die 300er-Version portieren.
    Man sieht ja was die Flaschen verbrechen wenn sie Baustein portieren...

    Klar haben die TOs ihre Vorteile (Grafische Parametrierung, Selbstoptimierung,Trace) sind aber eben auch komplizierter und haben teilweise auch Nachteile.
    Wenn man mit den einzelnen DBs für jeden TO-Regler leben kann und die neuen Funktionen braucht (der PIDtemp hat bei Temperaturregelungen sicher seine Vorteile) dann ist das in Ordnung.

    Wenn man nen simplen Regler der Kategorie "ein und geht" will ist aber CONT_C sicher die bessere Wahl.
    Jedem das seine."


  3. #2
    Registriert seit
    09.08.2006
    Beiträge
    3.638
    Danke
    912
    Erhielt 661 Danke für 543 Beiträge

    Standard

    Behalte den alten cont_c ...

  4. Folgender Benutzer sagt Danke zu ducati für den nützlichen Beitrag:

    RONIN (28.04.2016)

  5. #3
    Registriert seit
    10.11.2013
    Ort
    Essen
    Beiträge
    119
    Danke
    39
    Erhielt 17 Danke für 14 Beiträge

    Standard

    Temp benutzen...

  6. #4
    Andi_ ist offline Benutzer
    Themenstarter
    Registriert seit
    20.02.2014
    Beiträge
    75
    Danke
    13
    Erhielt 2 Danke für 2 Beiträge

    Standard

    Danke für eure Antworten.
    Jedoch laufen diese genau in die entgegengesetzte Richtung. Könntet ihr eure Ansicht bitte erklären?

  7. #5
    Registriert seit
    09.08.2006
    Beiträge
    3.638
    Danke
    912
    Erhielt 661 Danke für 543 Beiträge

    Standard

    Zitat Zitat von Andi_ Beitrag anzeigen
    den alten CONT_C weiter zu verwenden, der sich ja schon bewährt hat und die Parameter schon in etwa bekannt sind,
    hast Dir die Antwort schon selbe gegeben Mit den "neuen" TIA-Reglern hatten schon einige eher Probleme...

    Gruß.

    PS: meine Antwort hat ein Danke erhalten

  8. #6
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.367
    Danke
    457
    Erhielt 696 Danke für 521 Beiträge

    Standard

    @ducati: war eher eine Zustimmung

    Für mich sind weitere Gründe für den CONT_C
    Simpel und leicht nachzuvollziehen
    Das Ding ist im Endeffekt ein einfaches Rechenwerk. Kann man leicht nachrechnen, somit weis man vorher was man am LMN bekommt.
    Die TOs sind (auf Grund der erweiterten Funktionen) natürlich deutlich komplizierter und haben ewig viel Parameter in den Instanzdaten
    Wenn man diese (siehe nächster Punkt) nicht über das grafische Interface parametrieren kann, wird's aufwändig.

    Multiinstanzfähigkeit
    Man kann einen CONT_C problemlos in eine Multiinstanz packen.
    Man muss ihn nicht mal in nem OB aufrufen. Sofern man ihn mit der korrekten Zeit seit dem letztem Aufruf (z.B. durch Zeitmessung) versorgt kann man den überall verwenden.

    Grad hier ist für mich eine große Schwäche der Technologieobjekte.
    Man kann zwar PIDTemp auch als Multiinstanz aufrufen, verliert dann aber die Möglichkeit den Regler mit dem grafischen Interface in TIA zu parametrieren.
    Das ist eigentlich das was die TOs ausmacht

    Einen TO-Regler außerhalb eines OBs aufzurufen macht möglicherweise auch Schwierigkeiten, der TO-Regler misst die vergangene Zeit des letzten Aufrufs selber und
    geht bei Abweichung zur Parametrierung in einen Fehlerzustand.

    Ganze Regelkreise in einen Baustein zu stecken und diese bequem per Multiinstanz irgendwo in einem Baustein zu erstellen ist mit den TOs eher schwierig.
    Manche TOs (z.B. High Speed Counter) können gar nicht als Multiinstanz angelegt werden.

    Keine Betriebsarten und Fehlerzustände die den Regler einfach stoppen
    Wenn beim CONT_C der COM_RST auf Low ist, dann arbeitet das Ding. Fertig aus.
    Bei den TO-Regler hat man Betriesarten die man per Befehl umschalten muss und Fehler die eventuell den Regler auf Stopp setzen

    Simulation
    Ursprünglich konnte man sowohl die TO-Regler als auch den CONT_C in PLCSIM nicht simulieren. Mittlerweile geht es anscheinend wieder... vorerst.
    Beim CONT_C musste ich mir damals den 300er-AWL-Code portieren. Nicht optimal, aber besser als gar nix.
    Wobei man sagen muss, wenn man beim CONT_C von "bewährt" spricht sollte man eventuell auch die 300er-Version portieren.
    Man sieht ja was die Flaschen verbrechen wenn sie Baustein portieren...

    Klar haben die TOs ihre Vorteile (Grafische Parametrierung, Selbstoptimierung,Trace) sind aber eben auch komplizierter und haben teilweise auch Nachteile.
    Wenn man mit den einzelnen DBs für jeden TO-Regler leben kann und die neuen Funktionen braucht (der PIDtemp hat bei Temperaturregelungen sicher seine Vorteile) dann ist das in Ordnung.

    Wenn man nen simplen Regler der Kategorie "ein und geht" will ist aber CONT_C sicher die bessere Wahl.
    Jedem das seine.
    Geändert von RONIN (29.04.2016 um 17:50 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  9. Folgende 2 Benutzer sagen Danke zu RONIN für den nützlichen Beitrag:

    Andi_ (29.04.2016),ducati (29.04.2016)

  10. #7
    Registriert seit
    10.11.2013
    Ort
    Essen
    Beiträge
    119
    Danke
    39
    Erhielt 17 Danke für 14 Beiträge

    Standard

    Ronin und Duc arbeitet Ihr mit TIA ? und mit der 1500er oder 1200er ? oder beide. Oder macht Ihr TIA unter 300er

  11. #8
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.367
    Danke
    457
    Erhielt 696 Danke für 521 Beiträge

    Standard

    Täglich.

    Neue Anlagen schon länger nur mehr 1500.
    1200er wenig, die kleinsten Anlagen liegen meistens am Punkt wo auf eine ET200SP kaum noch Aufpreis ist. Die ist nur für F oder Sub-Station interessant.
    Sonst auch noch viele Classic-Anlagen mit 300 (hin und wieder 400) an denen gewartet oder erweitert wird.
    Einige Misch-Projekte (SPS-Classic, HMI-TIA) zu Zeiten wo TIA noch ziemlich unbenutzbar war (<V13).
    Weiß also denke ich ganz gut was geht und was nicht bzw. wo Vor- und Nachteile liegen.

    300er in TIA (käm ich nicht aud die Idee) oder eine 1500 mit ner WinCCv7 hatte ich noch nicht.

    Im Endeffekt springe ich im Moment alle paar Wochen zwischen einem Classic-Projekt und einem TIA-Projekt.
    Insofern bemerke ich gerade extrem was an welchem der beiden Systeme besser/schlechter ist.
    Geändert von RONIN (29.04.2016 um 18:24 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  12. Folgender Benutzer sagt Danke zu RONIN für den nützlichen Beitrag:

    JaJa (29.04.2016)

  13. #9
    Registriert seit
    10.11.2013
    Ort
    Essen
    Beiträge
    119
    Danke
    39
    Erhielt 17 Danke für 14 Beiträge

    Standard

    Zitat Zitat von RONIN Beitrag anzeigen
    Täglich.

    Neue Anlagen schon länger nur mehr 1500.
    1200er wenig, die kleinsten Anlagen liegen meistens am Punkt wo auf eine ET200SP kaum noch Aufpreis ist. Die ist nur für F oder Sub-Station interessant.
    Sonst auch noch viele Classic-Anlagen mit 300 (hin und wieder 400) an denen gewartet oder erweitert wird.
    Einige Misch-Projekte (SPS-Classic, HMI-TIA) zu Zeiten wo TIA noch ziemlich unbenutzbar war (<V13).
    Weiß also denke ich ganz gut was geht und was nicht bzw. wo Vor- und Nachteile liegen.

    300er in TIA (käm ich nicht aud die Idee) oder eine 1500 mit ner WinCCv7 hatte ich noch nicht.

    Im Endeffekt springe ich im Moment alle paar Wochen zwischen einem Classic-Projekt und einem TIA-Projekt.
    Insofern bemerke ich gerade extrem was an welchem der beiden Systeme besser/schlechter ist.
    na dann haben wir schon etwas gemeinsam.
    Unserem Themenstarter kann ich nur empfehlen mal selber mit dem Temp zu arbeiten und sich eine eigene Meinung
    Über die neuen Technologieobjekte zu bilden.

    Mein Kollege spiel auch in der 1500er mit dem CONT_C was ich nicht machen würde.
    Ich finde die neuen TO einfach besser

  14. #10
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.367
    Danke
    457
    Erhielt 696 Danke für 521 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von JaJa Beitrag anzeigen
    Unserem Themenstarter kann ich nur empfehlen mal selber mit dem Temp zu arbeiten und sich eine eigene Meinung
    Über die neuen Technologieobjekte zu bilden.


    Wie gesagt, habe oben nur die Vor- und Nachteile der TOs gegenüber dem CONT_C aufgezählt.
    Der Einsatz von CONT_C bezieht auch mehr anstatt dem PIDcompact als dem PIDtemp und PID3Step.
    Für die letzteren sehe ich auch Vorteile gegenüber einem nackten CONT_C.

    Heißt auch nicht dass ich die TOs gar nicht einsetze, kommt für jeden auf den Anwendungsfall an.
    Ne kleine Anlage mit 4/5-Reglern die ich evtl. auch noch ausprogrammieren muss weil gerade keine Vorlage passt, bekommen eher nen TO-Regler
    und werden dann einzeln in per Grafik-Interface in Betrieb genommen.

    Ist das Mengengerüst groß so dass mit Multiinstanzen gearbeitet wird (Regelkreise oft nicht einzeln in Betrieb genommen werden) dann wird's eben ein CONT_C.
    Is es was Ur-simples ala "Regler rein, Parameter hingeschätzt und passt" ist dann wird's auch ein CONT_C.
    Manchmal auch weil er deutlich kompakter ist und besser in die Struktur/Instanz reinpasst.

    Ich verneine grundsätzlich wenig und suche mir eher für den jeweiligen Anwendungsfall das beste raus.
    Da ist auch mein finaler Rat an den TE

    Zitat Zitat von JaJa Beitrag anzeigen
    Mein Kollege spiel auch in der 1500er mit dem CONT_C was ich nicht machen würde.
    Weil konkret? Irgendwelche funktionelle Bedenken oder nur wegen der Zusatzfunktionen (Graf. Paramtrierung, Autom. Erst-IBN) und besser gefallen?
    Geändert von RONIN (29.04.2016 um 21:16 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

Ähnliche Themen

  1. Step 7 Temperaturregelung
    Von Hangasilly im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 11.06.2014, 07:48
  2. Kaskadierte Regelung
    Von zummi im Forum PC- und Netzwerktechnik
    Antworten: 21
    Letzter Beitrag: 29.03.2011, 18:00
  3. Temperaturregelung
    Von Phil im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 29.04.2008, 18:21
  4. Temperaturregelung
    Von ibinadabei im Forum Sonstige Steuerungen
    Antworten: 2
    Letzter Beitrag: 13.07.2006, 15:01
  5. Temperaturregelung
    Von Anonymous im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 19.09.2005, 08:57

Lesezeichen

Berechtigungen

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