TIA Temperatur Rampe

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich nehme mal an, dass das UND in deinem Code ein Schreibfehler ist - AND wäre hier dann schon zielführender ...
Du solltest am Ende überprüfen ob du mit deinem Vorgabe-Sollwert nicht den max.- bzw. min.-Sollwert über- bzw. unterschreitest ...

 

[Holzmichl]

der defaultwert ist null

Das kann problematisch sein.
Was machst Du mit dem Fall, dass ein Bediener kurz stoppt/ausschaltet/Sicherheitskette fällt/auf Handbetrieb nimmt?

Wenn Du bei z.B. Rampe 300°C bist = 5 Stunden und blöderweise für 3 Sekunden der Strom weg ist oder der Not-Aus gedrückt wird - soll dann bei z.B. Ist-Temp von 295°C weitergefahren oder wieder bei 0 gestartet werden?

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn das in einem FC funktionieren soll muss der vorherige Ausgangs Wert gespeichert werden, also InOut

 

[batindeko]

Wenn Du bei z.B. Rampe 300°C bist = 5 Stunden und blöderweise für 3 Sekunden der Strom weg ist oder der Not-Aus gedrückt wird - soll dann bei z.B. Ist-Temp von 295°C weitergefahren oder wieder bei 0 gestartet werden?

die ausgangswert_temp ist eine static variable

 

[leo]

ich habe ein Taktmerker eingesetzt der soll hier bei positive und negative flanke addieren bzw. subtrahieren

Der Taktmerker ist aber eine halbe Sekunde lang true. Während der Zeit addierst Du zyklisch auf deine Rampe.

rampe_hoch := sollwert > ausgangswert_temp;
rampe_runter := sollwert < ausgangswert_temp;

Das wird so auch nicht funktionieren.

 

[batindeko]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Taktmerker ist aber eine halbe Sekunde lang true. Während der Zeit addierst Du zyklisch auf deine Rampe.


Das wird so auch nicht funktionieren.

Deswegen setze ich sowohl auf die positive als auch auf die negative Flanke rechne.

 

[Mrtain]

Deswegen setze ich sowohl auf die positive als auch auf die negative Flanke rechne.

Die positive Flanke oder negative Flanke reicht völlig

 

[Heinileini]

rampe_rauf/runter müssen noch irgendwo zurückgesetzt werden.

Ja hast du recht.

Echt? Wer hat denn für "runter" eine Rampe gefordert?
Sollte für "runter" tatsächlich eine Rampe gefordert sein, wie steil soll sie sein? Ebenfalls 1 K / 60 s?
Ist überhaupt klar, wie schnell der Krempel abkühlen kann, ohne dass aktiv gekühlt wird?
Oder ist eine aktive Kühlung auch noch geplant?

Müssen wirklich 'rampe_rauf' und/oder 'rampe_runter' gesetzt und rückgesetzt werden?
Das Vorzeichen der Änderung bzw. Richtung sollte doch identisch sein mit dem Vorzeichen der Differenz aus endgültigem SollWert und dem IstWert.

Er meint sicherlich, dass du dir einen Baustein baust, der den Vorgabe-Sollwert für deinen Regler im Minuten-Takt erhöht.
Damit das allerdings funktioniert, muss der Regler dem auch folgen können - da sehe ich ggf. ein Problem ...

Es könnte zwar theoretisch ein Problem sein, dass die RegelStrecke in der Praxis nicht der geforderten AnstiegsGeschwindigkeit von 1 K / 60 s folgen kann. Das wäre dann aber auf eine zu sparsam dimensionierte HeizLeistung zurückzuführen.
Auf das Thema RampenBildung hat das m.E. keinen Einfluss.

Wie soll eigentlich der AusgangsWert des Reglers in eine entsprechende HeizLeistung umgesetzt werden? Ich sehe bisher lediglich, dass Oliver das Thema "PWM" angeschnitten hat.
Wird das HeizElement digital ein-/aus-geschaltet? Per Schütz oder Elektronik?

Ich glaube, über solche Dinge und auch über das Thema 'Hysterese' und evtl. das Thema 'Glättung des IstWertes' sollte man sich zunächst Klarheit verschaffen, ehe man sich Gedanken über RampenBildung macht.
Die RampenBildung kann doch eigentlich immer mit der IstTemperatur als aktuellem Startwert des Sollwertes berechnet werden, ohne berücksichtigen zu müssen, ob eine Rampe schon länger am wirken ist oder gerade erst gestartet wird?
Durch die RampenBildung soll doch kein Regler ersetzt werden. Lediglich die AnstiegsGeschwindigkeit des Sollwertes am Regler soll begrenzt werden.
Wird allerdings die AnstiegsGeschwindigkeit des Sollwertes begrenzt, so nimmt man sich die Möglichkeit, eine "SprungAntwort" zu testen/messen, wodurch es schwieriger wird, die ReglerParameter zu ermitteln. Egal, ob der Regler automatisch seine Parameter ermitteln soll oder, ob man dies "zu Fuss" tun will, wäre es gleichermassen hilfreich die RampenBildung ausschalten zu können.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Echt? Wer hat denn für "runter" eine Rampe gefordert?
Sollte für "runter" tatsächlich eine Rampe gefordert sein, wie steil soll sie sein? Ebenfalls 1 K / 60 s?
Ist überhaupt klar, wie schnell der Krempel abkühlen kann, ohne dass aktiv gekühlt wird?
Oder ist eine aktive Kühlung auch noch geplant?

Bezogen auf Härtereitechnik (mein Spielplatz) geht es bei "rampe runter" eher darum die Anlage mit z.B. maximal 60°C/h abzukühlen.
Wenn die Anlage langsamer abkühlt, greift halt irgendwann der Code-Teil, der beim Weglaufen der Sollwertrampe diese irgendwann einfängt.
Zudem kannst du auch Systeme zur Restaustenitbeseitigung haben; da hast du den ganzen Spaß dann bei Betriebstemperaturen von -100°C
Ich würde für beide Rampenrichungen jeweils ein "enable"-Bit vorsehen, um die Rampen nach Bedarf auch abschalten zu können.

Wie soll eigentlich der AusgangsWert des Reglers in eine entsprechende HeizLeistung umgesetzt werden? Ich sehe bisher lediglich, dass Oliver das Thema "PWM" angeschnitten hat.
Wird das HeizElement digital ein-/aus-geschaltet? Per Schütz oder Elektronik?

Bei elektrischen Systemen wären SSRs oder Thyristoren üblich. Schütze zum Pulsen gibt es selbst in Bestandsanlagen praktisch nicht mehr.
Der PID-Baustein hat ja bereits einen PWM-Ausgang, sollte also passen.
Bei Brennern müsste man den PWM-output noch im Bezug auf mindest Brenn-Pausenzeiten aufbereiten.
=>ist nochmal eine Angelegenheit für sich.

Wird allerdings die AnstiegsGeschwindigkeit des Sollwertes begrenzt, so nimmt man sich die Möglichkeit, eine "SprungAntwort" zu testen/messen, wodurch es schwieriger wird, die ReglerParameter zu ermitteln. Egal, ob der Regler automatisch seine Parameter ermitteln soll oder, ob man dies "zu Fuss" tun will, wäre es gleichermassen hilfreich die RampenBildung ausschalten zu können.

Bei solchen Systemen mit begrenzter Heizrate wirst du in der Praxis niemals eine Optimierung per Sprungantwort (Erstoptimierung in Siemens-PID) sehen, da du nicht weit genug springen kannst ohne die Anlage zu beschädigen.
Zudem ändert sich die Regelstrecken-Charakteristik von Raumtemperatur zu 700°C so extrem, dass du sowieso keine brauchbaren Werte bekommen würdest.
Meine Vorgehensweise ist immer, den Regler Pi mal Daumen mit PID-Startwerten zu versorgen & dann auf Betriebstemperatur einen Schnwingversuch (Nachoptimierung) zu machen.
Da muss man teilweise mit den Tuning-Vorgaben im Siemens-Baustein spielen (TuneRule), hat sich in der Praxis aber bisher gut gemacht.

 

[batindeko]

Meine Vorgehensweise ist immer, den Regler Pi mal Daumen mit PID-Startwerten zu versorgen & dann auf Betriebstemperatur einen Schnwingversuch (Nachoptimierung) zu machen.

ich benutze einen PI-Regler wobei ich auch feste PI Parameterwerte festgelegt dann über den PID Compact Baustein starte ich eine Nachoptimierung. @TJ_Aichelin : ist es etwa was du gemeint hast?

 

[Botimperator]

ich benutze einen PI-Regler wobei ich auch feste PI Parameterwerte festgelegt dann über den PID Compact Baustein starte ich eine Nachoptimierung. @TJ_Aichelin : ist es etwa was du gemeint hast?

Prinzipiell ja.
Parameter vorgeben => hochheizen => optimieren => fertig
Ob du nen PI oder PID benutzt ist ja am ende eine Frage deines Prozesses.
Wobei ich den PID_Temp für Temperaturregelungen bevorzuge.
Der hat schon Heizen/kühlen integriert & Vorbereitung für Kaskadenschaltung.

 

[batindeko]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich hätte noch eine Frage: die Heizungen und die Rampe kommen in dem OB35 rein, wobei die Rampe mit einem Taktgeber von 1 s versehen ist und den Weckalrm OB 35 mit 4ms eingestellt wird. Wird es gut gehen?

 

[Botimperator]

Universalantwort: das kommt drauf an.......(✿◠‿◠)
(Ja, ich bin gerne hilfreich)

Wenn du den Takt über einen Hardware-Taktmerker (die laufen unabhängig vom Anwenderprogramm) bekommst oder in dem 4ms Wekckalarm einfach bis 250 zählst, sollte das funktionieren.
Wenn der Takt aus deinem zyklischen Programm generiert wird...wirds wieder eher eine "so etwa" Rampe.

Mich irritieren grade nur die 4ms etwas
Ist dein Prozess wirklich so schnell?
Ich hab meine eigentlich nie schneller als 500ms laufen

 

[Botimperator]

Nachtrag, da ich das grade für ein anderes Projekt ausrechnen musste: (Garrrrrrstige Temperaturregelung)

Modul 6ES7134-6JD00-0CA1, AI 4xRTD/TC 2-/3-/4-wire HF
3 aktive Kanäle (einer deaktiviert), TC Typ S, Störspannungsunterdrückung 50Hz + Drahtbruchprüfung.

Macht eine Wandlungszeit von 62ms je Kanal => 186ms fürs Modul
Datenblatt:

Heißt: alle 186ms gibts neue Temperaturwerte, zzgl Verzögerung durch aktivierte Glättung.
Glättung hatte ich auf "mittel" => 8 Modulzyklen => 1488ms bis 63% einer Wertänderung anliegen.




Theoretisch wäre es am effizientesten die Regler, also den Weckalarm, alle 186ms aufzurufen & das TPE der Temperaturwerte ebenfalls an den Weckalarm zu koppeln (sonst werden die Werte der Variablen nicht aktualisiert).
Praktisch habe ich noch keine Temperaturregel-Anwendung gefunden bei der ein Weckalarm <500ms irgendwelche praktischen Effekte gehabt hätte.

Ähnliches gilt natürlich auch für die Rampe.
Die Rampe brauchst du nicht verändern, wenn dein Regler sowieso keine neuen Daten hat auf die er reagieren könnte.

Lesestoff zu dem Thema:
https://support.industry.siemens.com/cs/document/109761283/-wie-berechnen-sie-die-zykluszeit-des-s7-1500-analogeingabemoduls-ai-8xu-i-r-rtd-ba-in-abhängigkeit-von-der-anzahl-und-art-der-genutzten-kanäle-?dti=0&lc=de-WW

edit:
Tippfehler bei Prozenten

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich hätte noch eine Frage: die Heizungen und die Rampe kommen in dem OB35 rein, wobei die Rampe mit einem Taktgeber von 1 s versehen ist und den Weckalrm OB 35 mit 4ms eingestellt wird. Wird es gut gehen?

Wenn es keinen Grund für die 4ms gibt, würd ich da auch bei den 100ms für den OB35 bleiben.
Wenn Du den Rampenbaustein im Weckalarm aufrufst, brauchst Du den Takteingang garnicht, da der Rampenbaustein ja schon durch den OB35 gleichmässig aufgerufen wird.

Ich glaub, da fehlt noch ziemlich viel Hintergrundwissen bei Dir...

Ist das ne wichtige Anlage?

PS, warum jetzt auf einmal OB35? Im Betrag #18 schreibst Du, die Regler sind im OB30?

 

[batindeko]

PS, warum jetzt auf einmal OB35? Im Betrag #18 schreibst Du, die Regler sind im OB30

@ducati Es war ein Scahreibfehler. Der Rampenbaustein und die Régler werden in OB30 aufgerufen.

 

[batindeko]

Wenn du den Takt über einen Hardware-Taktmerker (die laufen unabhängig vom Anwenderprogramm) bekommst

Wenn ich es richtig verstanden habe, koennte ich den Rampenbaustein in OB30 ueber einen Hardware-Taktmerker laufen lassen.

 

[leo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, Du brauchst gar keinen Taktmerker. Wenn Du den OB z.B. alle 100ms aufrufst, brauchst Du im OB nur jedesmal deine Rampen um 0.1s zu Vergrößern/verkleinern (wenn die Bedingung erfüllt ist).

 

[Botimperator]

Wenn ich es richtig verstanden habe, koennte ich den Rampenbaustein in OB30 ueber einen Hardware-Taktmerker laufen lassen.

ja, könntest du.

Du könntest dich aber auch, wie von @leo vorgeschlagen, mit der Änderungsgröße deiner Rampe an den Weckalarm-Takt anpassen.
Oder du zählst intern im Weckalarm-Code die Zyklen hoch & löst nur alle paar Zyklen den "Takt" aus.
Sowas z.B.; das wäre in einem 100ms Weck-OB dann ein 1s Takt.



Wenn du "static" Speicher benötigst, kannst du dir einen FB für den eigentlichen Code schreiben & diesen dann im Weckalarm-OB aufrufen.
Da kannst du dann auch die ggf. anfallenden Instanzen unterbringen, um die Anzahl an eigenständigen DBs klein zu halten.

Zudem bin ich persönlich eher kein Fan davon code an globalen Kram dran zu hängen.
Ich verwende einmal geschriebenen Code gerne wieder & wenn du deinen Baustein kopierst und im Zielprojekt die Taktmerker anders benannt sind oder gar nicht existieren....¯\(°_o)/¯
Aber das sind schonwieder Details...funktionieren würden alle drei Vorschläge.

 

[batindeko]

Oder du zählst intern im Weckalarm-Code die Zyklen hoch & löst nur alle paar Zyklen den "Takt" aus.
Sowas z.B.; das wäre in einem 100ms Weck-OB dann ein 1s Takt.

jetzt verstehe ich was du meinst. Im Endeffekt kommt es auf das gleiche . Danke für den Vorschlag

Da kannst du dann auch die ggf. anfallenden Instanzen unterbringen, um die Anzahl an eigenständigen DBs klein zu halten.

ich habe mehrere Instanzen wie unterbringe ich sie. kannst du mir bitte hier erklären.