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

Ergebnis 1 bis 9 von 9

Thema: PID Regler unbedingt mit Interrupt?

  1. #1
    Registriert seit
    10.07.2014
    Beiträge
    376
    Danke
    137
    Erhielt 11 Danke für 11 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,

    ich habe einen Wert den ich etwas regeln möchte. Ich habe nun in den ganzen Tutorials gesehen, das der regler immer in einen Interupt gepackt wurde. Da mein Regler aber nur sehr selten einen Wert bekommt, bezogen auf die Zykluszeit, bin ich nicht sicher ob das mit dem Interupt dann nötig ist. Ich brauche ja keine Auswertung in jedem Zyklus.
    Ich habe einen Hydraulikzylinder und gebe die Schrittweite über den errechneten Durchfluss mit der Pumpendrehzahl vor. Das funktioniert bislang so leidlich und die Länge stimmt einigermaßen. Da ich aber weder einen Durchflusssensor noch ein richtiges Wegmesssystem habe, bleibt mir nur der Rückgriff über Hub und gezählte Schritte offen um die Schrittlänge zu regeln. Die Abweichung beträgt so ca. 10% nach unten. Das heist dann Leitungsverluste und Wirkungsgrad der Pumpe usw. nehme ich an.
    Nund die Fragen:
    1. macht das wirklich Sinn den regler in einen Interupt zu packen
    2. hättet ihr einen anderen Ansatz den ich verfolgen könnte?

    Ich weis, das es nicht wirklich genau werden kann, aber ich brauche wenigstens irgendwie wenigstens ansatzweise eine Möglichkeit der Regelung.
    Zitieren Zitieren PID Regler unbedingt mit Interrupt?  

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

    Standard

    Welchen Regler verwendest du?
    CONT_C, PID_Compact, etc....
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  3. #3
    Registriert seit
    21.02.2014
    Ort
    Sachsen-Anhalt
    Beiträge
    1.576
    Danke
    285
    Erhielt 261 Danke für 235 Beiträge

    Standard

    Für einen PID / PI / PD ist es notwendig, entweder die genaue Zeit zwischen den Regleraufrufen zu ermitteln oder den Regler zeitlich äqidistant aufzurufen.
    Aber ein Regler ist nur ein Regler mit einer Rückführung der Regelgröße. Ohne ein solches ist es nur ein Steuern.

  4. #4
    Registriert seit
    29.03.2004
    Beiträge
    5.801
    Danke
    144
    Erhielt 1.710 Danke für 1.240 Beiträge

    Standard

    Ich habe es bei sehr langsamen Regelstrecken schonmal so gemacht, dass ich den Regler mit einer z.B. 5 Sekunden Taktflanke getriggert im OB1 Zyklus aufgerufen habe.
    Beim Kunden hat sich dann jemand beschwert, dass man das doch so nicht machen würde, das gehört in den OB35. Ich habe ihm dann gesagt, wenn er mir belegen kann, dass meine Vorgehensweise einen signifikanten Einfluss auf die Regelgüte hat, dann programmiere ich ihm alle Regler um. Dann war Ruhe.
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  5. #5
    Credofire ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    10.07.2014
    Beiträge
    376
    Danke
    137
    Erhielt 11 Danke für 11 Beiträge

    Standard

    Ich bekomme ja den Trigger quasi von der vorderen Endlage. Wenn diese erreicht ist, errechnet das Programm den Vorschub, und diesen Wert will ich als Rückführung für den Regler nehmen.
    Bei den großen Maschinen die wir bauen ist es schöner, da haben wir ein Wegmessystem verbaut.

  6. #6
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.545
    Danke
    1.154
    Erhielt 1.254 Danke für 983 Beiträge

    Standard

    Wenn du eine konstante Zykluszeit und langsame Regelstrecken (z.B. Temperatur) hast, dann kannst den Regler auch in den OB1.
    Wie oft dein Regler einen Wert bekommt, ist eigentlich nicht das Thema, Wenn du aber z.B. Positionieren willst und vernünftige Rampen brauchst, dann ist der Aufruf über einen Alarm-OB deutlich besser.

    Gruß
    Dieter

  7. #7
    Registriert seit
    06.09.2010
    Ort
    Fulda
    Beiträge
    1
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    PID-Regler unbedingt mit Interrupt ? Eindeutig Ja !
    Einen PID-Regler sollte man immer in einem Zeit-OB aufrufen und diese Zeit auch am Parameter CYCLE angeben, sonst rechnet der Regelalgorithmus schlicht und einfach falsch (zumindest der I- und D-Anteil, da hier die Abtastzeit einfließt).
    Natürlich funktioniert ein langsamer Regler auch mit einer Taktflanke im OB1. Aber warum tut man sowas ? Richtig machen kostet doch nix. Man sollte auch nicht glauben, daß eine langsame Regelstrecke durch eine große Abtastzeit besser zu regeln wäre - siehe Abtasttheorem.


    Ein Kollege hat mal einen "langsamen" Niveauregler im OB1 platziert und auch noch 3 Sek. am Parameter CYCLE eingetragen. Der Regler hat dann komplett falsche Werte ausgespuckt, weil der Baustein nach wenigen Millisekunden wieder aufgerufen wurde, der Regelalgorithmus aber so gerechnet hat als wären schon 3 Sek. vergangen (d.h. bei einer Zykluszeit von 10ms wurde die Zeit mit dem Faktor 300 falsch gerechnet). Weil die Zykluszeit auch nicht konstant war (z.B. durch Kommunikationsaufträge) hat die Regelung dann komplett gesponnen.


    Gruß
    Reiner

  8. #8
    Registriert seit
    17.07.2009
    Ort
    Am Rande der Ostalb
    Beiträge
    5.545
    Danke
    1.154
    Erhielt 1.254 Danke für 983 Beiträge

    Standard

    Zitat Zitat von gress Beitrag anzeigen
    Aber warum tut man sowas ?
    Es gibt Programme die eine konstante Zykluszeit erfordern. Bei solchen Anwendungen sind Alarm-OBs überhaupt nicht gerne gesehen.

  9. #9
    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 gress Beitrag anzeigen
    PID-Regler unbedingt mit Interrupt ? Eindeutig Ja !
    Einen PID-Regler sollte man immer in einem Zeit-OB aufrufen und diese Zeit auch am Parameter CYCLE angeben, sonst rechnet der Regelalgorithmus schlicht und einfach falsch (zumindest der I- und D-Anteil, da hier die Abtastzeit einfließt).
    Zitat Zitat von gress Beitrag anzeigen
    Ein Kollege hat mal einen "langsamen" Niveauregler im OB1 platziert und auch noch 3 Sek. am Parameter CYCLE eingetragen. Der Regler hat dann komplett falsche Werte ausgespuckt, weil der Baustein nach wenigen Millisekunden wieder aufgerufen wurde,
    Was hat denn eine komplett fehlerhafte Anwendung des Bausteins damit zu tun ob der Aufruf außerhalb innerhalb eines Interrupts passieren muss oder nicht?

    Der Regler muss lediglich in möglichst konstanten und vor allem dem Regler bekannten Zeitintervallen aufgerufen werden.
    Das wir natürlich von einem Interrupt gefördert. Ein muss ist dieser deshalb aber noch lange nicht.
    Zitat Zitat von gress Beitrag anzeigen
    Natürlich funktioniert ein langsamer Regler auch mit einer Taktflanke im OB1. Aber warum tut man sowas ? Richtig machen kostet doch nix.
    Hängt oft vom Mengengerüst und der Regelstecke ab.
    Wenn man große Anzahlen (50+) von Reglern hat möchte man die oft nicht einzeln im OB35 programmieren und beschalten.
    Wir haben öfters ganze Regelkreise (mit mehreren Reglern - für z.B. Klimakammern) fertig in einer Multiinstanz verpackt, die dann nur mehr aufgerufen und parametriert werden.

    Des weiteren gibt es hier im Forum (von mir auch) oft den Wunsch, den Regler programm-strukturell an der entsprechenden Stelle (Anlage/Subablage/Zelle/etc.) im Code zu platzieren, zu der er auch gehört und diesen nicht in einen anderen Baustein auslagern zu müssen.
    Gründe für die Fragen gibt es also.

    Diese "einfachen" Regler können dann sehr wohl ohne Interrupt, aber eben per Timer und mit tatsächlich gemessener Aufrufzeit am CYCLE aufgerufen werden. Im Endeffekt kommt man, mit einem Regler und Intervall von T#1s, welcher dann aber eben wegen der Zykluszeit einmal mit T#1s5ms und einmal mit T#1s35ms aufgerufen wird, dafür aber die korrekte Zeit am CYLCE bekommt und somit seine I/D-Parameter durchaus korrekt berechnen kann, auch auf eine ausreichende Regelgüte. Im Endeffekt ist bei so einer Regelung oft von außen kein Unterschied zu einem T#1s-Interrupt-Aufruf zu erkennen.

    Wenn man ehrlich ist, hat der Regler im OB35 oft auch keine konstante Aufrufzeit mehr.
    Hab's zwar nie gemessen aber CONT_C wird bei Reset wahrscheinlich eine kürzere Code-Laufzeit als während des Beitriebs haben.
    Wenn man dann wieder 50+ Regler im OB35 rechnet, einmal sind 30 auf Reset und einmal laufen alle, inklusive eigenem Code dazwischen der oft noch viel weniger konstant ist, kann es sein dass dies für den der letzten Regler schon ein paar Millisekunden Schwankung bedeutet.

    Was für den CONT_C zählt ist ausschließlich das er ausreichend oft, ausreichend konstant aber eben mit bekannter Zeit zwischen den Aufrufen, aufgerufen wird. Wie man das erreicht ist jedem seine Sache.

    PS: Heißt nicht das ich selbst Regler niemals in Interrupts aufrufe, aber eben nicht immer...
    Geändert von RONIN (22.05.2016 um 10:42 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  10. Folgende 3 Benutzer sagen Danke zu RONIN für den nützlichen Beitrag:

    Credofire (23.05.2016),NikolausL (23.05.2016),weißnix_ (22.05.2016)

Ähnliche Themen

  1. druckregelung mit FU integrierten PID regler
    Von servus im Forum Antriebstechnik
    Antworten: 8
    Letzter Beitrag: 19.11.2012, 13:11
  2. Dosierbandwaagen mit PID Regler
    Von Jann im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 12.11.2012, 06:47
  3. PID-Regler mit Schalthysterese
    Von fossibear im Forum Simatic
    Antworten: 9
    Letzter Beitrag: 02.12.2010, 07:37
  4. Probleme mit PID Regler FB41
    Von LarsDD im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 29.06.2010, 21:15
  5. PID Regler mit CPU214
    Von hubert im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 05.01.2004, 13:20

Lesezeichen

Berechtigungen

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