TIA PID Regelung über HMI steuern

[paulg]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

ich muss im Rahmen meiner Weiterbildung zum staatlich geprüften Techniker für Elektrotechnik ein Programm für meine Projektarbeit erstellen.
Es handelt sich um eine Lüftungsanlage mit einem neuen Schaltschrank, in dem eine S7-1200 mit Erweiterungsmodulen verbaut wird. Ein HMI soll in der Schaltschranktür platz finden.

In dem Programm sollen zwei Temperatur- und Volumenstrom Regelungen mit PID Regelung programmiert werden. Die einzelnen Parameter der PID_Compacts sollen über die Visualisierung einstellbar sein.

Für die Regelungen habe ich schon 4 PID_Compact Technologieobjekte erstellt.

Nun zur Frage:

Wie kann ich am einfachsten die Parameter des Technologieobjektes der PID_Compacts über einen allein für den HMI erstellten DB Namens "DB_HMI_Schnittstelle" zum HMI bringen? In der Schule haben wir gelernt, dass man als Schnittstelle immer einen eigenen DB für das HMI erstellen sollte, damit man genau sieht welche Daten zum HMI gehen und zurück.

Mein erster Lösungsansatz ist folgender:

Ich habe einen FB erstellt, in dem ich den PID_Compact Baustein aufrufe und die Instanz des Bausteins über eine InOut Variable nach Außen führe, damit ich im OB Weckalarm nur von außen das TO anhängen muss. Die einzelnen Parameter habe ich dann über Inputs und Outputs über die Bausteinschnittstelle nach Außen geführt.


Wie würdet Ihr das ganze lösen?

Vielen Dank schonmal

 

[Januar]

An sich ist das schon so machbar. Du solltest bloß nicht deinen Baustein aufrufen bevor du die Inputs beschreibst. Also tausche doch besser Netzwerke 1 und 2. Sonst hast du während des Programmablaufs immer einen CPU-Zyklus Versatz und im ersten Programmzyklus einen undefinierten Zustand.

 

[sps_klassik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wieso hängen jetzt die Variabeln nicht mehr direkt am Regler?
In einem globalen Datenbaustein hättest du 4 Reglerdatensätze angelegt und dann direkt auf die Schnittstelle geschrieben.

 

[MFreiberger]

Moin paulg,

[..]In der Schule haben wir gelernt, dass man [..]

in der Schule lernt man Einiges. Manches ist brauchbar, manches praxisfern und manches sogar Unsinn (ein ehe. Kollege hat in der Schule "gelernt", dass man Adressierungen von Variablen bei 1 und nicht bei 0 beginnt).

Zu deinem Thema:
Ja, EIN HMI-DB bringt Vorteile. Aber auch Nachteile, denn man muss ggf. unsinnigerweise Variablen ummappen und benötigt dadurch mehr Speicher. Ich würde für das HMI nicht wild im Programm irgendwo irgendwelche Variablen abfragen, sondern die Informationen schon auf klar definierte DBs verteilen. Es gibt auch ein Für- und Wider zu dem HMI-Zugriff auf Instanz-DBs. Vieles muss man abschätzen und in der Praxis ist es sehr selten, dass wirklich nur ein Übergabe-DB verwendet wird.

Du greifst z.B. im Programm auf die Instanz-Variablen des FB zu. Für einige Programmierer ein NoGo. Manche haben damit kein Problem. Ich meine bei TC3 geht das gar nicht. IMHO ist das unsauber.

Nach meiner Auffassung sollte es absolut in Ordnung sein, für jeden PID die Variablen aus einem anderen DB zu nehmen. Dazu würde ich im HMI unter HMI-Variablen Unterordner schaffen, in denen die Variablen des jeweiligen PIDs abliegen.

Wenn es die Vorgabe ist, dass die Daten alle in einem DB abliegen sollen, auf die das HMI zugreift, würde ich eine UDT erstellen. Diese als INOUT in der FB-Schnittstelle verwenden und von außen den DB nutzen.

VG
MFreiberger

 

[paulg]

Okay vielen Dank schonmal für die Antworten.

in der Schule lernt man Einiges. Manches ist brauchbar, manches praxisfern und manches sogar Unsinn (ein ehe. Kollege hat in der Schule "gelernt", dass man Adressierungen von Variablen bei 1 und nicht bei 0 beginnt).

Das programmieren im TIA Portal was wir in der Weiterbildung lernen macht mir schon spaß und fällt mir auch echt leicht.
Nur mir fehlt halt leider der Bezug zur Praxis :/

Du greifst z.B. im Programm auf die Instanz-Variablen des FB zu. Für einige Programmierer ein NoGo. Manche haben damit kein Problem. Ich meine bei TC3 geht das gar nicht. IMHO ist das unsauber.

Nach meiner Auffassung sollte es absolut in Ordnung sein, für jeden PID die Variablen aus einem anderen DB zu nehmen. Dazu würde ich im HMI unter HMI-Variablen Unterordner schaffen, in denen die Variablen des jeweiligen PIDs abliegen.

Was meinst du genau mit TC3 und IMHO?

Also meinst du könnte ich auch mit dem HMI auf die Instanz DBs der Technologieobjekte der PID Regler zugreifen? Oder sollte ich evtl. einfach die PID Bausteine im Weckalarm OB aufrufen und dessen Instanz DBs für das HMI benutzen?

Ich weiß natürlich nun nicht was in meinem Fall sinnvoller ist. Unsere Lehrer die auch letztlich die Projektarbeit bewerten, sagen immer, man sollte einen eigenen DB nur fürs HMI erstellen. Aber wenn das in der Praxis sowieso nie der Fall ist, warum sollte man so machen.

Naja. Das sind nunmal Lehrer und keine Erfahrenen SPS-Programmierer.

 

[s_kraut]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein DB für Datenaustausch macht schon deswegen Sinn, weil die HMI-Kommunikation nicht über OB erfolgt.
Dann kriegst du im dümmsten Fall mal krumme Werte um die Ecke.

Aber gut, ich habe auch den Ansatz mal mit angeschaut, in dem alles über die Projektier-Software und die PID-Einstellungen über das TIA-Projekt gemacht worden ist. Mit dem Hintergedanken dass einmal eingestellt der Regler immer so bleibt und kein Fehler 50 über das HMI eingeschleust wird
Das ging auch ganz gut.

 

[PN/DP]

Was meinst du genau mit TC3 und IMHO?

TC3 = Beckhoff Automatisierungssoftware TwinCAT 3
IMHO = in my humble opinion = meiner bescheidenen Meinung nach

 

[Botimperator]

Also meinst du könnte ich auch mit dem HMI auf die Instanz DBs der Technologieobjekte der PID Regler zugreifen? Oder sollte ich evtl. einfach die PID Bausteine im Weckalarm OB aufrufen und dessen Instanz DBs für das HMI benutzen?

Könntest du.
Wir hatten die grundlegendes Diskussion darüber schon einige male, z.B. <hier>.
tldr: kommt ganz auf die Anwendung und das Umfeld an was geeigneter ist.

Ich weiß natürlich nun nicht was in meinem Fall sinnvoller ist. Unsere Lehrer die auch letztlich die Projektarbeit bewerten, sagen immer, man sollte einen eigenen DB nur fürs HMI erstellen. Aber wenn das in der Praxis sowieso nie der Fall ist, warum sollte man so machen.

In deinem Fall würde ich argumentieren, dass deine Lehrer-/Kundenanforderung ein Austausch über einen HMI-DB ist.
Du könntest in deiner Projekt-Doku erwähnen, dass es in der Praxis auch andere Möglichkeiten gibt.
Entgegen der Vorgabe dann in der Projektarbeit keinen HMI-DB zu nutzen wird aber sehr warscheinlich als "Thema verfehlt" gewertet werden.

Ich habe einen FB erstellt, in dem ich den PID_Compact Baustein aufrufe und die Instanz des Bausteins über eine InOut Variable nach Außen führe, damit ich im OB Weckalarm nur von außen das TO anhängen muss. Die einzelnen Parameter habe ich dann über Inputs und Outputs über die Bausteinschnittstelle nach Außen geführt.

Zu deinem Codeschnipsel würde ich noch gerne anmerken, dass es wenig Sinn macht die ".CtrlParamsBackup" vom HMI in die Instanz zu schieben.
Das sind interne Backup-Parameter, die eigentlich verwendeten Regelparameter stecken woanders.
Die Backup-Parameter würden maximal als Anzeige auf dem HMI Sinn ergeben.

Und ich würde empfehlen die PID-Parameter nur in die Instanz zu schreiben wenn sich die Werte im HMI-DB tatsächlich geändert haben.
Im Moment würdest du die Regelparameter des Reglers dauerhaft durch die Werte aus dem HMI überschreiben, was die Nutzung der Selbstoptimierung des Reglers effektiv unterbindet.

 

[sps_klassik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist die Selbstoptimierung nicht nur beim Start zum Finden der PID-Anteile?

 

[paulg]

So habe ich das ganze nun gelöst.

So gehe ich glaube ich einen guten Kompromiss ein, damit ich einen DB nur fürs HMI habe.
In dem HMI DB habe ich eigens erstellte Datentypen die ich dann im OB Weckalarm auf die FB Schnittstelle verschalte. So habe ich zwar viele Ein und Ausgänge am FB aber da ich noch nicht genau weiß welche Daten ich davon im HMI brauche ist das für mich so am einfachsten.

Ist vielleicht nicht die einfachste und schnellste Lösung, aber ich stehe ja noch am Anfang meiner SPS-Karriere.

Eine weitere Frage:

Wenn ich die
PID_CompactConfig und
PID_CompactControlParams über den FB auf das Technologieobjekt gebe..
Werden dann die Einstellungen in der Konfiguration des Technologieobjektes mit den Daten aus dem HMI DB überschrieben?
Also kann ich weiterhin die PID_Compact über das TO konfigurieren oder muss ich dass dann über die Startwerte im HMI DB machen.

 

[sps_klassik]

Ich hatte jetzt erwartet das du für die Aussenbschaltung vorab Regler1...Regler4 oder so was in der Art hast.
Das kann man mit udt's aber auch mit Structuren machen oder auch ohne Beides.
Da die Regler gleichartig sind, so vermute ich, würde ich einen UDT erstellen.

 

[Rabi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe auch einen ähnlichen Lösungsansatz für PID-Regler:


Dafür habe ich aber immer eine Schnittstelle zum HMI, separat davon eine Schnittstelle "Interface" diese mit meinem Programm für die Steuerung des Reglers "redet" und eine Konfiguration "CFG", diese die Parameter festlegt mit diesen geregelt werden soll, bzw. als Grundparameter dienen. Das HMI hat dann nur noch Korrekturwerte diese Einfluss haben auf die Grundparametrierung.

Für mich ist immer wichtig, dass die HMI Schnittstelle optional sein kann - bedeutet, dass der gesamte Regler auch ohne HMI eingaben selbst lauffähig ist - es gibt ja auch heutzutage noch Anlagen, diese mit mechanischen Knöpfen und Schaltern funktionieren.

 

[Botimperator]

Ist die Selbstoptimierung nicht nur beim Start zum Finden der PID-Anteile?

Schon.
Die funktioniert nur "nicht", wenn das neu berechnete Parameterset sofort wieder vom HMI überschrieben wird ¯\_(ツ)_/¯

Werden dann die Einstellungen in der Konfiguration des Technologieobjektes mit den Daten aus dem HMI DB überschrieben?

Jup.

Also kann ich weiterhin die PID_Compact über das TO konfigurieren oder muss ich dass dann über die Startwerte im HMI DB machen.

Wenn du die Config dauerhaft durch die HMI-Config überschreibst, wirst du dir Config auch auf der HMI-Seite machen müssen.

 

[sps_klassik]

Im Grunde bildest du ganz primitiv die Schnittstelle mit abgekürzten Variabelnnamen des Reglers in einem
udt ab.Das kann man direkt abschreiben.
Dann nimmst du einen Globalen DB und hast 4 reglerdatensätze vom Typ des udts.
Der Name des Reglers ist dann die UDT-variable.

 

[sps_klassik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schon.
Die funktioniert nur "nicht", wenn das neu berechnete Parameterset sofort wieder vom HMI überschrieben wird ¯\_(ツ)_/¯


Jup.


Wenn du die Config dauerhaft durch die HMI-Config überschreibst, wirst du dir Config auch auf der HMI-Seite machen müssen.

Da hast du jetzt auch wieder recht.

 

[sps_klassik]

Diese HMI-Variablen Problematik würde ich folgendermaßen angehen.
Grundsätzlich die Schnitstelle (in dem Bsp. die Regler) immer mit Globalvariablen versorgen.
Ob man da jetzt UDT's nimmt oder Strukturen oder keins von Beiden ist Geschmacksache.
Hinzu kämen dann die HMI-Variablen schreiben und Lesen., auch als jeweils eigener DB.
Die Variabeln haben dann immer den Zusatz HMI.
Der Sollwert vom HMI wird dann über dem Regleraufruf auf die Schnittstellenvariable vom Regler geschrieben.
Aber auch das kann man anderst machen und ist nicht in Stein gemeißelt.