TIA Temperatur Rampe

Zuviel Werbung?
-> Hier kostenlos registrieren
ich habe in OB 30 50 Regler. Jeder Regler entspricht eine Heizung

Bei einer solchen Anzahl mache ich mir gerne einen UDT, den ich als INOUT an einen FB oder FC hänge und gesammelt als Array of UDT in einen Global-DB packe.
Dann kann ich auch z.B. per Visu direkt auf die Parameter verweisen und alles bleibt sauber und wiederverwertbar.
Zudem kann ich sehr einfach etwas Reserve verplanen im Array und brauche bei Erweiterung keine Reinitialisierung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich habe mehrere Instanzen wie unterbringe ich sie. kannst du mir bitte hier erklären.
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
Das mit Multiinstanzen geht irgendwo ab Minute 18 los.
Du kannst übrigens die Instanzen auch als "Array [0..50] of FbRampe" anlegen.
Oder als Sahnehäubchen mit Konstanten anlegen => "Array [0..kUpperBound] of FbRampe".
Das geht zwar mit den Technologieobjekten nicht, dafür aber mit allem anderen was zu der Funktion gehört, womit du wieder recht simpel globale Infos per Schleife abfragen könntest.
Z.B. läuft irgendeine Rampe? laufen alle Rampen? Wie viele Rampen laufen?
 
Du kannst übrigens die Instanzen auch als "Array [0..50] of FbRampe" anlegen
heißt das ich muss wieder 50 Mal meinen Rampenbaustein in diesem FB-Multiinstanz einfügen und in Static-Speicher z.B ein Array [1..50] of Fb-Rampe deklarieren. Jeder Rampenbaustein mit der jeweiligen Instanz(Datenbaustein) zuweisen. Dann diese FB-Multinstanz in den Weckalarm OB30 aufrufen.
 
heißt das ich muss wieder 50 Mal meinen Rampenbaustein in diesem FB-Multiinstanz einfügen und in Static-Speicher z.B ein Array [1..50] of Fb-Rampe deklarieren.
Universalantwort: das kommt drauf an.......(✿◠‿◠)

Falls deine Rampe mit einem FB angewickelt wird, benötigst du natürlich auch eine Instanz. (Entfällt natürlich, falls du die Rampenlogik per FC machst)
Die Instanzen mit einem Array anzulegen hat verschiedene Vorteile bei der Verarbeitung durch Schleifen.
Du kannst natürlich jetzt für jede Rampe auch ein Netzwerk + Rampen-FB anlegen...
Du kannst aber auch einfach den kompletten Haufen per For-Schleife abhandeln.

Sagen wir du legst die Kernlogik deiner Heizung ebenfalls als Array an & übergibst dem Rampen-FB/FC die Logik-Instanz als Parameter:
For #i=0 to 50 do
instRampenFb[#i] := HeizungsDb.instHeizungslogik[#i];
End_For
Da kommt dann auch das Anlegen mit Konstanten zum tragen, wenn du die 50 durch eine entsprechende Konstante ersetzt.
Beziehen sich alle Beteiligten auf die gleichen Grenzen, kannst du mit dem Ändern von einer einzigen Konstante deine Anzahl an Heizzonen/Rampen beliebig skalieren.

Noch eine Bitte:
Array fangen bei 0 an. IMMER.
SCL akzeptiert auch ein 1..50, aber wenn du mit der Visu zugreifst macht diese das immer 0-Basiert.
Dann wird aus einem 1..50 ein 0..49.
Und dann fängt der Brainfuck an, dass du immer drauf achten musst ob du grade im HMI oder in der SPS bist.
Ich lass den 0er meistens einfach leer, benutze ihn bei UDTs als Quelle für ein Startwerte-Set oder NULL-Datensatz.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich lass den 0er meistens einfach leer, benutze ihn bei UDTs als Quelle für ein Startwerte-Set oder NULL-Datensatz.
Erstens das und man kann nachts den ruhigen Schlaf schlafen, ohne Angst zu haben dass vielleicht doch mal irgendwo ein Lesezugriff auf 0 erfolgt, ohne dass der definiert ist. Ein Fach mehr kostet keinen Platz und tut nur gutes.
 
Sagen wir du legst die Kernlogik deiner Heizung ebenfalls als Array an & übergibst dem Rampen-FB/FC die Logik-Instanz als Parameter
Unter Heizungslogik verstehe ich z.B einen selbst gebastelten PI-Regler, welcher ich in einem DB als Array [0...49] anlegen kann. Danach als Parameter dem Rampen-FB übergeben. Oder hast du was anderes gemeint
Code:
For #i:= 0 TO 49 DO
 #instRampe(rSollwert:=OPC-DB.Sollwerte_HB[#i],
 rRate:= 0,01666667;
 rAusgangswert => Heizung[#i].BH_Regler.Sollwert)



Ich verwende den PID Compact Baustein für meine Heizungsregelung davon habe ich 50 in OB30 eingefügt.(diese Flexibilität entfällt)
 
Unter Heizungslogik verstehe ich z.B einen selbst gebastelten PI-Regler, welcher ich in einem DB als Array [0...49] anlegen kann. Danach als Parameter dem Rampen-FB übergeben. Oder hast du was anderes gemeint
Das kommt drauf an wie du deine Heizung strukturierst.
Thema: objektorientierte Programmierung.
Gibt im Forenbereich "Programmierstrategien" ein paar Treads darüber.

Hab mal kurz was hin geschmiert wie ich so etwas aufziehen würde:
1696575502027.png

Input und Ausgabe sind Bausteine, die je nach vorhandener Hardware ausgewählt werden & sind mit standardisierten Schnittstellen an die Logik angebunden. Diese Aufbereitung brauche ich, da ich alles mögliche an Hardware für die gleiche Funktionslogik vorgesetzt bekomme.
Da diese beiden "Seiten" je Instanz auf andere Hardware adressieren müssen, werden diese nicht innerhalb von Schleifen verwendet.
=> Klassisches je Netzwerk ein Baustein.

Alles zwischen Input und Ausgabe wird in Arrays strukturiert; Die UDTs, Logik, Submodule...
Input/Logik/Output-Bausteine sind im zyklischen Programmteil angesiedelt.

Submodule können Teile der Funktion sein, die in einem Weckalarm laufen müssen oder nicht als Array angelegt werden können (Tech-Objekte) & bekommen per inOut die komplette Instanz der Logik-Baugruppe übergeben.
=>minimiert den Verschaltungsaufwand.
Die Strukturierung per Array macht die Logik sehr schnell skalierbar.
Eine Konstante ändern, die zusätzlichen Input/Ausgabe-Bausteine dran & du hast aufeinmal statt 10 Heizzonen 50, die alle identisch & wie definiert funktionieren.

In der Instanz haben die Submodule im Static-Bereich einen UDT oder Struktur für ihren jeweiligen Funktions-Slot indem diese sich im ersten Programmzyklus anmelden (in einen Int eine Nummer reinschreiben, die identifiziert wer/was sie sind & dass sie vorhanden sind) und auch alle Variablen zum Datenaustausch finden.

Einen PID-Regler kannst du bei so etwas z.B. per FC abhandeln.
Der FC bekommt per InOut die Instanz der Logik & das Technologieobjekt und kümmert sich intern nur um die Verschaltung zwischen der Logik & dem eigentlichen Siemens PID-Baustein.
Ein FC, zwei Variablen & fertig ist die Verschaltung.
=> minimiertes Fehlerpotenzial beim Anlegen.
Bei Verwendung der Technologieobjekte kannst du beim Regler-Submodul tatsächlich keine Schleifenbearbeitung verwenden, aber du kannst dir dein Leben einfacher machen.

Solche Konstrukte funktionieren natürlich nur so gut wie der Plan, den du dur gemacht hast BEVOR du auch nur eine Zeile Code geschrieben hast.
Und sie sind initial ein riesen f*cking Aufwand zum erstellen, können aber danach sehr viele Kopfschmerzen bei der IB einsparen.

Und nachdem ich jetzt antworttechnisch malwieder komplett eskaliert bin, ist mein Kaffee kalt & ich sollte nochwas arbeiten...
[]~( ̄▽ ̄)~*
 
Zuviel Werbung?
-> Hier kostenlos registrieren
sie sind initial ein riesen f*cking Aufwand zum erstellen, können aber danach sehr viele Kopfschmerzen bei der IB einsparen.
Oder sie könnten bei der IBN nen riesen Kopfschmerz erzeugen, wenn z.B. 2 Heizungen zufällig doch anders aufgebaut sind, als die restlichen 48... 🙈🤷‍♂️
Oder in 10 Jahren mal jemand was ändern will, und das Konstrukt mit der einen Konstante die dann automatisch neue Logik generiert dann doch nicht versteht/findet.
Sieht man doch hier im Thread, wie das schon nicht verstanden wird...
Oder in 8,5 Jahren am Sonntag Nachmittag mal eine defekte Heizung gegen nen neuen Typ ausgetauscht wird, der jetzt anders funktioniert...
Oder der Instandhalter am Feierttag mal online in der SPS schauen will, was mit Heizung 38 los ist... Da wird er dann sicherlich den OOP-Programmierer anrufen, und dieser auch hoffentlich ans Telefon gehen.
 
Zuletzt bearbeitet:
ich nehme gerade in Betrieb den Tank mit den 50 Reglern. Nach dem Anschalten der Heizungen über die SPS dauert es ca. 15 Minuten, bis diese wirklich auch am Tank angehen. Wie kann ich die Zeit optimieren. 15 Minuten ist echt viel.
ich kann zwar verstehen, dass bei der Aufheizrate von 1/60 K pro Minute dass es solange dauert bis der Sollwert erreicht wird aber ich hätte erwartet dass der Regler bzw. Heizer nach einer oder zwei Minuten aufzuheizen anfangen. Hat schon jemand eine Idee ?
 
Regler zackiger einstellen oder beim Start einen Startwert zur Vorsteuerung vorgeben (z.B. 10% bis 30%) und danach wieder frei laufen lassen.
Ich denke dein/e Regler fahren von 0 weg recht zögerlich weg.

Kannst Du einen Trace der Soll-, Ist- und Reglerausgangs-Werte machen?
 
Kommt drauf an mit welchem Wert deine Rampe startet.
Startet deine Rampe bei 0?
Am Anfang startet die Rampe bei 0?
Hast du dran gedacht beim Einschalten der Heizung den Rampen-Wert einmalig = Ist Temperatur zu setzen?
Nein. In meiner Rampenfunktion addiere ich mit Hilfe einer Temp-Variable von 0 mit einer Rate von 1/60 K bis der Sollwert erreicht wird.
Dieser Wert wird dann im Regler als Setpoint vorgegeben. Die IstWert-Temperatur wird nur als Input im Regler angegeben und von dort die Regelung getan wie es Bild zu entnehmen
 

Anhänge

  • PID-Compact.PNG
    PID-Compact.PNG
    62,7 KB · Aufrufe: 12
Zuviel Werbung?
-> Hier kostenlos registrieren
Dann halt mal beim Start deine Rampe auf die tatsächliche Ist-Temperatur setzen und dann erst loslegen.

Jetzt glaubt dein Regler ja er muss bei 0 (0°C oder 0°K) anfangen mit der Rampe, das ist aber wohl nicht sinnvoll :)
 
ich habe die Rampe auf die tatsächliche Ist-Temperatur gesezt und es läuft. Nun habe ich folgendes Problem wenn man die Heizungen ausschaltet bzw. Wenn die Sollwerte auf 0 gestellt werden, laufen die Heizungen einige Zeit (Halbe Stunde) weiter, bis die Temperatur abfällt. Es vermittelt das Gefühl Leistung wird weiter zugeführt. Warum verhalten sich die Regler so?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nun habe ich folgendes Problem wenn man die Heizungen ausschaltet bzw. Wenn die Sollwerte auf 0 gestellt werden, laufen die Heizungen einige Zeit (Halbe Stunde) weiter, bis die Temperatur abfällt. Es vermittelt das Gefühl Leistung wird weiter zugeführt. Warum verhalten sich die Regler so?
Der RegelKreis ist wahrscheinlich so träge, dass sich die Heizung erst stark verzögert auswirkt.

Aber:
ich würde auch den I-Anteil des Reglers verdächtigen. Mach doch mal probeweise den I-Anteil unwirksam und berichte, ob sich das positiv auswirkt!
 
Nun habe ich folgendes Problem wenn man die Heizungen ausschaltet bzw. Wenn die Sollwerte auf 0 gestellt werden, laufen die Heizungen einige Zeit (Halbe Stunde) weiter, bis die Temperatur abfällt. Es vermittelt das Gefühl Leistung wird weiter zugeführt. Warum verhalten sich die Regler so?
Naja...PID-Regler machen eben manchmal PID-Regler Sachen ¯\_(ツ)_/¯

Du wirst deine Regelparameter vermutlich sehr träge eingestellt haben (Tanks und so...).
Wenn du den Sollwert änderst, reagiert der Regler natürlich mit der Trägheit die du parametriert hast.
In deinem Fall braucht er eine halbe Stunde bis der Stellgrad auf "0%" fällt.

Du könntest den Regler-Mode bei ausgeschalteter Heizung auf inaktiv ändern.
Oder (quick&dirty) wenn Heizung aus, dann "ManualEnable" auf TRUE und "ManualValue" auf 0.0

ich würde auch den I-Anteil des Reglers verdächtigen.
Glaube ich nicht, zumindest nicht wenn @batindeko die Anti-Windup-Funktion nicht bewusst deaktiviert hat.
Zudem tritt sein Problem auf wenn er aus dem Normalbetrieb in "ausgeschaltet" wechselt.
I-Windups treten eigentlich (meistens) nur auf wenn der Regler im ausgeschalteten Zustand (Heizung) weiter lief und währenddessen den I-Anteil ins unendliche geschraubt hatte.
 
Zurück
Oben