Step 7 PID-Regler außer Funktion

[Walter White]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tach,

für einen Kunden sollte ich eine Regelung neu einstellen. Aber die Regelstrecke reagiert nur mit 0% und 100% ausschlag.

Zum Rahmen :

- Regelung im FB41 geschrieben, DB250 als Instanz DB und im FC64 verarbeitet.
- Temperaturregelung eines Kühlers (Austritt soll, Sollwert halten)
- Produkteintrit Temp. bekannt, Austritt Temp. bekannt, Kühlkreislauf Temp. bekannt, Kühlkreislauf Poportionalventil gesteuert.
- Hardware und Ausgänge geprüft, Kühlleistung ausreichend.
- bisher wird versucht die Austritttemperatur zu halten in dem die Regelung auf die Austritttemperatur reagiert.
- Benötigte Tolleranz +- 0,3C°
- Nachlauf verhalten ca. 3 sec. bei 100% stellwertänderung
- Regelung läuft zwischen 40 und 50 % stabil (ermittelt durch Handbetrieb)

Daten aus dem Siemens PID-Control:
- Istwert intern
- Totzohne 0,1
- P- aktiv 10
- I- Aktiv 20s
- Stellwert Handbetrieb: OBg 1000%, UBG 0%, Norm.faktor 1, Norm.offset 0

Das Programm und die Einstellungen habe ich so vorgefunden, angeblich hat es mal funktioniert.

Ich vermute einen banalen Programm fehler, da es eine Modernisierung gab (S5 auf S7).

Wenn jamand das Bild kennt, würde ich mich über hinweise freuen...

-----------------------------
über PID Control habe ich diverse Einstellungen probiert. Ergebnis Katastrophal, die Regelung kommt mit dem Nachlauf der Temperatur nicht klar.

 

[IPC Bernhard]

Hallo

Ist es der Siemens Standard Regler Baustein?
Es ist ja ein Kühler muss da nicht der P Wert negiert sein?

Wo wird der Regler aufgerufen (OB 1, --- schlecht; OB 3x, --- gut)?
Welches Zeitintervall ist eingestellt?

Wenn es ein selbstgeschriebener Regler ist dann denke ich mal
kann ein "fremder Programmierer" nicht viel anfangen damit.

Was steht eignetlich im Kommentar "PV und Setpoint vertauscht"?

Gruß
Bernahrd

 

[Walter White]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

danke für deine Antwort.
- Es sieht nach einem Standardregler aus.
- P wert wurde vllt anderst negiert, deswegen glaube ich steht der Kommentar drin. (kann ich demnächst ausprobieren)
- Aufruf OB35, 100ms

Mein Verdacht ist momentan das der Regler nicht richtig "eingeschaltet" wird.
Der COM-RST wird über den DB205.DBX0.0 gesteuert, aber nirgends geschrieben...

Mit ein bisschen durch wühlen bekommt man die Reglerfunktion schon raus. Aber bevor ich dem seine
komplette Regelung zerpflücke, würde ich gerne die beschaltung und einfachen Grundparameter prüfen.

bisher habe ich beim beobachten nicht feststellen können das PV und Setpiont vertauscht sein sollen.
Habe ich versuchsweise getauscht, ergebnis =Regelung bleibt stehn.

 

[Onkel Dagobert]

Endlich hat mal einer den FB41 geknackt .

..Es ist ja ein Kühler muss da nicht der P Wert negiert sein?..
..Was steht eignetlich im Kommentar "PV und Setpoint vertauscht"?

Wenn dem so ist, dann kommt es unterm Strich auf dasselbe raus.

Was mir auffällt ist dass die Zeiten als S5-Zeiten vorgegeben werden. Der Umbau von S5 auf S7 ist doch noch ganz frisch, oder?
Wie wird das Stellsignal von 0 bis 1000% weiter verarbeitet? Warum eigentlich 1000%?

 

[Simon]

Zum kuehlen sollte der Gain negativ sein, die Cycle time vom FB41 ist auch falsch, es wird oben eine bcd codierte Zeit auf DB250.dbd2 geladen.
Bei einer Sekunde bcd stehen dann da aber 256ms im DB250 und nicht die 100ms vom OB35.

 

[Verpolt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein Verdacht ist momentan das der Regler nicht richtig "eingeschaltet" wird.
Der COM-RST wird über den DB205.DBX0.0 gesteuert, aber nirgends geschrieben...

vielleicht wird DB205.DBX0.0 über ein Display angesteuert.
Zum Testen kannst ja mal ein Hilfsbit=1 ranhängen

 

[Simon]

Wieso wird eigentlich der Instanz DB in den ersten Netzwerken beschrieben und unten nochmal an die Schnittstelle des FB41 gelegt?
Ich glaube der Com reset DB250.dbx0.0 ist nicht beschaltet, sonst währe das in den ersten Netzwerken passiert wie bei den anderen Werten.

 

[Walter White]

soweit ich da verstehe, wird der regler erst aktiv mit db250.dbx0.0 ... bei der Sprungmarke dazu wird auch die Cycle Time in Real gewandelt...
sollte die Zeit gleich der Zykluszeit im OB sein?

 

[Walter White]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diese Initialisierung sagt mir nichts, aber werde mal den DB250.dbx0.0 da mit setzen...
vllt war das schon das Ei das ich gesucht habe... Ergebnisreport dann am Donnerstag

 

[Simon]

FB41 makieren und F1 Taste drücken für die Bausteinbeschreibung.........
An Deiner Stelle würde ich:
- Netzwerke 1 bis 3 alle weg löschen
- schauen ob die Werte vom OP35 richtig auf Real erweitert werden. Im OP35 wurde bestimmt Integer mit Dezimalstelle verwendet.
- FB41 Schnittstelle direkt beschalten und nicht irgendwo im Programm den Instanz DB des FB41 beschreiben
- Hi_Lim vom FB41 auf 100.0 setzten,
- Cycle time vom FB41 mit 100ms beschalten
- Gain negativ beschalten
- schauen wo der Reglerausgang vom FB41 im Programm verwendet wird und entsprechend für den Ausgang des Prop. Ventil auf 0-100% umskalieren
- wenn Integralanteil an sollte auch eine Zeit vorgegeben werden...

 

[Walter White]

So, neues update...

- Im OB35 sind nur die Call befehle für den FC 64
- In der Hardwarekonfig konnt ich 100ms nachlesen für den OB35

nach dem ich nun den umfang der Verschachtelung kenne bin ich fast der Meinung, neu wäre besser....

der überblick als kurzform:
- FC 64 Regler aufruf mit Initialisierung
- FC 225 Reglerausgang
- FC 206 Routine für Analogwertscalierung
- FB 41 Regler
- OP35 Weckalarm
- DB 250 Instanz DB
zudem greift die Initialisierung auf folgendes zu:
- DB 64 -> Ladet und Wandelt in DB 250
- DB 32 -> Ladet und Wandelt in DB 250
- DB 140 -> Ladet Prozesswert in DB250

Die Frage wäre, ob ich den FB41 lassen kann und nur den DB250 raus nehme und den FB mit denrichtigen werten direkt ansteuer?!

letzte aussage des Bedieners:" Die alte Regelung hätte schon richtig rum geregelt, nur immer zu stark."

 

[ukofumo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Walter,

Also, was mir pauschal schonmal auffällt:
1.) dem FB41 ist der DB250 als Instanz-DB zugewiesen... dann braucht man die nicht nochmal an der Eingangs- Ausgangsbeschaltung des FB nochmal die gleichen Daten ranschreiben.
2.) wenn der OB35 einen Aufruf alle 100ms hat, sollte das auch so dem FB41 mitgeteilt werden... hier ist aber 1 sekunde angegeben (S5T#1s)
3.) zum Kühlen muss der Propotional-Gain Negativ sein (das Stellglied muss ja weiter öffnen wenn es kälter werden soll)
(zumal mir ein Proportional-Gain von +10 für eine Heiz/Kühl-Regelstrecke sehr hoch erscheint)

Der COM-RST wird über den DB205.DBX0.0 gesteuert... dieser "Eingang" dient normaler Weise zum Regler-Reset, wenn man ihn benutzt, dann üblicher weise beim Einschalten der SPS also aus dem Warmstart- Kaltstart- Wiederanlauf-OB heraus, sollte also nur für den ersten Zyklus bei Anlauf der SPS aktiv sein...
Man Kann Ihn Benutzen MUSS man aber nicht zwingend....

Das 0-1000(%) am Regler-Ausgang gesetzt sind macht u.U. durchaus Sinn man bekommt eine etwas feinere Regelung -> Auflösung 0,1%
die Skalierung des entsprechenden PAW muss dann natürlich auch dementsprechend angepasst sein...
Der Regler gibt 0-1000 (0,0-100,0%) die Skalierung des PAW muss dann auch 0-1000 = 4-20mA (oder 0-10V) ergeben
(macht natürlich nur Sinn wenn das entsprechende Stellglied auch solche "hohen" Auflösungen "feinfühlig" bearbeiten kann)
wenn hier am PAW die üblichen 0-100 (%) skaliert sind interpretiert dieser einen Reglerwert 10,0% als 100%...

Was auch sehr oft sehr gerne Falsch gemacht wird, Die Skalierung von Prozessvariable (PV-IN) bzw. Sollwert-Variable (SP_INT)
Wenn die nicht gleich Skaliert sind ---> kommt logischer weise nur Müll raus...

äußerst klassisches Beispiel:
- Eingangstemperatur wird über Thermoelemnt erfasst, die Analogkarte macht daraus für 50,0°C den Wert (INT) 500 -> nach Real gewandelt wird das zu 500.0 (5.0e+002)
- Der Sollwert 50°C wird im Panel als Integer-Variable "50" (ohne Komastelle) erfasst -> nach Real gewandelt 50.0 (5.0e+001)


Das sind so die "üblichen" Verdächtigen wenn ein Regler nicht richtig funktioniert.
und deine Beschreibung nach das der Regler entweder 0% oder 100% ausgibt, dazwischen aber nix kennt, deuten genau auf solche Skalierungsfehler hin.
oder eben audf einen viel zu hohen Proportional-Beiwert (GAIN)....

Gruß ukofumo

 

[Thomas_v2.1]

1.) dem FB41 ist der DB250 als Instanz-DB zugewiesen... dann braucht man die nicht nochmal an der Eingangs- Ausgangsbeschaltung des FB nochmal die gleichen Daten ranschreiben.

Braucht man nicht, stört aber auch nicht. Im Gegenteil lassen sich dadurch die Parameter im Online-Zustand beobeachten, und auch schnell über den Dialog (rechte Maustaste) steuern.

2.) wenn der OB35 einen Aufruf alle 100ms hat, sollte das auch so dem FB41 mitgeteilt werden... hier ist aber 1 sekunde angegeben (S5T#1s)

S5T ist sogar völlig falsch, weil das nur ein Wort und auch noch BCD codiert ist, also völlig falsches Bitmuster und Breite. Der Parameter verlangt den Datentyp TIME (das kommt davon wenn jemand in AWL rumfummelt und keine Ahnung hat, in FUP wäre so etwas gleich aufgefallen).
Wenn für den OB ein Aufrufzyklus von 100ms eingestellt ist, ist hier T#100ms einzustellen.

Wahrscheinlich ist das ein Hauptgrund warum der Regler nur Unfug berechnet. Bei den anderen Parametern steht ebenfalls fälschlicherweise S5T.

Das 0-1000(%) am Regler-Ausgang gesetzt sind macht u.U. durchaus Sinn man bekommt eine etwas feinere Regelung -> Auflösung 0,1%
die Skalierung des entsprechenden PAW muss dann natürlich auch dementsprechend angepasst sein...
Der Regler gibt 0-1000 (0,0-100,0%) die Skalierung des PAW muss dann auch 0-1000 = 4-20mA (oder 0-10V) ergeben
(macht natürlich nur Sinn wenn das entsprechende Stellglied auch solche "hohen" Auflösungen "feinfühlig" bearbeiten kann)
wenn hier am PAW die üblichen 0-100 (%) skaliert sind interpretiert dieser einen Reglerwert 10,0% als 100%...

Der Ausgang PV_PER skaliert immer von 0..27648. Ob du von 0..1000, 0..1 oder sonstwas skalierst wirkt sich nicht auf eine "feinere" Regelung aus, das ist Nonsense.
Wichtig ist nur, dass Istwert, Sollwert, Reglerparameter und Stellgrößenbereich zusammenpassen.

 

[Walter White]

Hallo und mal ein Danke an alle...

zur info, den regler habe ich in alle beschrieben richtungen gedreht und er wollte nicht das machen was er sollte.

Hab es nun selbst direkt in den Fc geschrieben... ist zwar nicht ganz so schön, funktioniert aber

Fazit: Löschen ist besser als reparieren

 

[ukofumo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Ausgang PV_PER skaliert immer von 0..27648. Ob du von 0..1000, 0..1 oder sonstwas skalierst wirkt sich nicht auf eine "feinere" Regelung aus, das ist Nonsense.
Wichtig ist nur, dass Istwert, Sollwert, Reglerparameter und Stellgrößenbereich zusammenpassen.

Also erst mal zur Klarstellung PV_PER ist ein Eingang! Hier kommt ein Pereferie-Eingangswort ran. Und wie der aufgelöst wird (0...27648.) muss mit entsprechenden Werten an PV_FAC und PV_OFF angegeben werden.
(es gibt schließlich auch Eingangsbaugruppen die anders auflösen... z.B. div. Wago-Module etc.) zusätzlich muss PVPER_ON auf TRUE gesetzt werden!

Wenn ich dann zur Ausgabe den Wert vom LMN abgreife der dann über einen Descale-Baustein auf den entsprechenden PAW gelegt wird, macht es schon Sinn über die Skallierung nachzudenken.
teile mal deine 27648 durch 1000 oder durch 100... wo hab ich dann wohl die feinere Auflösung (?)
Es sei denn man legt das PAW direkt auf LMN_PER, aber auch da muss die Auflösung mit LMN_FAC und LMN_OFF angegeben werden...

Beispiel: wir arbeiten mit Gasbrennern die durchaus bis zu 2000 KW Leistung haben können, da macht es sehr wohl Sinn die Skalierung 0-1000 anzusetzen.
bei Auflösung 0-100 (%) hätte 1 Punkt gleich 20 KW Leistungsdifferenz, bei 0-1000 wäre die Leistungsdifferenz aber nur 2 KW....

MfG ukofumo

 

[PN/DP]

Also erst mal zur Klarstellung PV_PER ist ein Eingang! Hier kommt ein Pereferie-Eingangswort ran. Und wie der aufgelöst wird (0...27648.) muss mit entsprechenden Werten an PV_FAC und PV_OFF angegeben werden.
(es gibt schließlich auch Eingangsbaugruppen die anders auflösen... z.B. div. Wago-Module etc.) zusätzlich muss PVPER_ON auf TRUE gesetzt werden!

Siemens unterstützt aber keine Wago-Module sondern nur Analogbaugruppen nach Siemens-Standard

PV_PER wird IMMER -27648 .. +27648 --> -100.0 .. +100.0 skaliert (*). PV_FAC und PV_OFF kommen erst danach ins Spiel. Da ist CRP_IN aber schon REAL und es kann keine bessere oder schlechtere Auflösung mehr erzeugt werden.

Genau so ist es auch in der Bausteinhilfe zum FB41 CONT_C dokumentiert.

(*) Skalierung PV_PER zu PV_NORM

CRP_IN  := INT_TO_REAL(PV_PER) * 100.0 / 27648.0 ;
PV_NORM := CRP_IN * PV_FAC + PV_OFF ;

Es sei denn man legt das PAW direkt auf LMN_PER, aber auch da muss die Auflösung mit LMN_FAC und LMN_OFF angegeben werden...

Diese Aussage kannst Du ebenso ins Reich der Legenden verbannen.


PS: Du meinst doch den FB41 CONT_C? Du weißt auch, daß der intern mit REAL und nicht mit Ganzzahlen rechnet?

Harald