WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Mein MATLAB Forum - goMatlab.de

Mein MATLAB Forum

 
Gast > Registrieren       Autologin?   

Partner:




Forum
      Option
[Erweitert]
  • Diese Seite per Mail weiterempfehlen
     


Gehe zu:  
Neues Thema eröffnen Neue Antwort erstellen

Regelung macht Probleme

 

Simon26

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 28.07.2011, 12:26     Titel: Regelung macht Probleme
  Antworten mit Zitat      
Hallo,

ich habe ein Problem mit einer Regelung in Simulink. Mein Modell simuliert ein Thermoelektrischen Generator. Um zu schauen wieviel elektrischer Strom der Generator maximal erbringen kann, habe ich eine Regelung eingebaut. Diese Regelung soll den benötigten Wärmestrom (der vom elektrischen Strom abhängig ist) und den vorhandenen Wärmestrom vergleichen. Ist die Differenz der beiden Null, habe ich meinen maximalen Strom. Das Ganze hatte auch ganz gut bisher gekappt. Bis mir aufgefallen ist, das eine Konstante zur Berechnung des Wärmestroms falsch war (30 statt 30000). Nach der Änderung funktioniert die Regelung nicht mehr. Ich versteh auch nicht genau warum. Im Debugger kommt an der fehlerhaften Stelle (laut Simulink) ein Ein- und Ausgangswert von -1.#IND . Ich verstehe schon das das für Simulink ein NaN Fehler ist. Ich verstehe aber nicht, wieso er auf diesen Wert kommt und was er überhaupt bedeutet. Wisst ihr etwas darüber?

Die Fehlermneldung die Simulink immer ausgibt besagt das es sich um eine algebraische Schleife handelt und am fehlerhaften Block der Wert Inf oder Nan ist.

MfG
Simon26


_Peter_
Moderator

Moderator


Beiträge: 537
Anmeldedatum: 08.12.10
Wohnort: ---
Version: 7.10, 2010a
     Beitrag Verfasst am: 29.07.2011, 10:16     Titel:
  Antworten mit Zitat      
Hallo Simon,
das lässt sich schwer vorhersagen, wo der Fehler liegt ohne Einblick in das Modell, aber wie du schon selbst vermutest, läuft irgendwo eine Berechnung in den Himmel.

Als erstes würde ich die Datentypen mal prüfen, ob diese für die Zahlen die bei der Berechnung auftauchen geeignet sind.

Wenn das alles passt, dann hilft nur ein Blick ins Modell, da der Fehler so schwer zu finden sein dürfte.

Kannst du den Teil des Modells isolieren und hier hochladen? Bzw. ein kleines Modell erstellen, wo der Fehler auftaucht und hier hochladen? Das wäre einfacher für uns.
_________________

Gruß
Peter
_________________
goMatlab-Knigge - dran gehalten?!
Schon in den FAQ gesucht? Oder der MATLAB Hilfe?
Ist vielleicht bei den Skripten oder den Tutorials was für dich dabei?
Private Nachricht senden Benutzer-Profile anzeigen
 
Georg J
Forum-Century

Forum-Century



Beiträge: 113
Anmeldedatum: 22.06.11
Wohnort: ---
Version: R2008a
     Beitrag Verfasst am: 29.07.2011, 18:10     Titel:
  Antworten mit Zitat      
Hi Simon,

Welchen Solver verwendest du? Und welche Schrittgrösse? Hast du damit schon experimentiert?

Gruss, Georg
Private Nachricht senden Benutzer-Profile anzeigen
 
Simon26

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 29.07.2011, 19:39     Titel:
  Antworten mit Zitat      
Hallo,

erstmal Danke für die Antworten. Ich hab jetzt zwei Bilder hochgeladen. Es handelt sich bei beiden um die besagte Regelung mit der Fehlermeldung und einmal mit dem Debugger.

Die Datentypen werden nicht verändert (weil es nicht nötig ist). Die einzige Erklärung, wenn sich der Datentyp ändert, wäre der Regler. Aber das schließe ich eigentlich aus.

Ich habe schon einige variable Solver ausprobiert. Bis auf Discrete kam bei allen Solvern der gleiche Fehler. Mit konstanten Solvern habe ich es auch getestet. Da kommen auch die gleichen Fehler. Die Änderung der Toleranzen oder derZeitschritte bei konstanten Solvern haben nix gebracht (hab da jetzt aber auch nur ein paar mal versucht mit geänderten Werten zu rechnen).

MfG
Simon26

2.JPG
 Beschreibung:
Regelung mit Debugger

Download
 Dateiname:  2.JPG
 Dateigröße:  117.86 KB
 Heruntergeladen:  645 mal
1.JPG
 Beschreibung:
Regelung mit Fehlermeldung

Download
 Dateiname:  1.JPG
 Dateigröße:  82.84 KB
 Heruntergeladen:  565 mal
 
Georg J
Forum-Century

Forum-Century



Beiträge: 113
Anmeldedatum: 22.06.11
Wohnort: ---
Version: R2008a
     Beitrag Verfasst am: 30.07.2011, 11:32     Titel:
  Antworten mit Zitat      
Hi Simon,

Ich würde mal einen Scope vor den beiden Divide-Eingägnen und nach dem Divide einbauen. Ich vermute, dass durch einen Wert der (fast) Null ist geteilt wird.

Gruss, Georg
Private Nachricht senden Benutzer-Profile anzeigen
 
Simon26

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 30.07.2011, 12:52     Titel:
  Antworten mit Zitat      
Der Divide Block dort divididert nur Konstanten. Ich habe auch im Debugger nachgeschaut. Dort tritt das Problem nicht auf.

Mir ist aufgefallen, das wenn ich den PI Regler auf Werte von P=1 und I=1 dezimiere, die Regelung sogar für die angesetzten 10 Sekunden läuft, aber bei 14 Sekunden wieder abbricht wegen dem gleichen Fehler. Leider bringen mir die geringen I Werte nix. Um sinnvolle Ergebnisse zu bekommen brauch ich I Werte um die 1000. Was mir weiterhin auffällt ist, das der Fehler manchmal an anderen Blöcken auftritt. Meistens wenn ich die Eingangswerte oder die PI Werte geändert habe.
 
Georg J
Forum-Century

Forum-Century



Beiträge: 113
Anmeldedatum: 22.06.11
Wohnort: ---
Version: R2008a
     Beitrag Verfasst am: 30.07.2011, 13:30     Titel:
  Antworten mit Zitat      
Tritt der Fehler ohne PI-Regler bzw. nur mit P-Regler auch auf? Wie sehen denn die Signale vor und nach dem PI-Regler aus?
Wenn es nicht aus dem Divide kommt, dann wäre die nächste Fehlerquelle der PI-Regler. Wenn der Input des PI-Reglers allerdings schon verdächtig ist, ist es wohl eher die Berechnung des benötigten Wärmestroms. Es sei denn, der vorhandene Wäremestrom (Input 3) stimmt nicht.
Private Nachricht senden Benutzer-Profile anzeigen
 
Simon26

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 30.07.2011, 14:30     Titel:
  Antworten mit Zitat      
Der Fehler tritt auch bei nur I oder nur P Regler auf. Ich hab mittlerweile rausgefunden, das für 10 Sekunden der P Wert max. 7 sein darf und der I Wert max. 1 sein darf. Höhere Werte beim P Regler führen sofort zum Abbruch bei 0 Sekunden. Beim I regler tritt nach einem bruchteil von einer Sekunde ein unendlich hoher Wert auf. Allerdings ist aus dem Scope nicht ersichtlich, ob er vom Regler ausgelöst wird oder ob der Regler nur auf den unendlich hohen Wert reagiert. (Es sieht im Scope wie ein Sprung aus, nur das oben der verlauf abbricht). Beim PI Regler dagegen sieht das ganze wie eine Kurve aus. Deswegen ist mir der unendliche Wert beim nur I Regler nicht aufgefallen. Wie könnte ich genau ermitteln, welcher Block den unendlichen Wert berechnet?
 
Georg J
Forum-Century

Forum-Century



Beiträge: 113
Anmeldedatum: 22.06.11
Wohnort: ---
Version: R2008a
     Beitrag Verfasst am: 30.07.2011, 14:56     Titel:
  Antworten mit Zitat      
Für mich sieht das nach einem instabilen Regler aus.

Hast du den Regler schon getuned? Ich würde mal mit z.B. Ziegler-Nichols Tuning einen heuristischen Regler entwerfen.

http://de.wikipedia.org/wiki/Faustf.....utomatisierungstechnik%29
Private Nachricht senden Benutzer-Profile anzeigen
 
Simon26

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 31.07.2011, 09:10     Titel:
  Antworten mit Zitat      
Ich habe jetzt glaube ich den Fehler gefunden. Der Regler ist wenn überhaupt nur indirekt Schuld an der ganzen Sache. Das Hauptproblem liegt in der Berechnung der elektrischen Spannung. Das System produziert nur kleine Spannungen von ca. 1,5 Volt. Zusätzlich kommen noch ABzüge wegen Widerstände im System dazu. Diese sind wiederrum vom Strom abhängig. Der Regler hat den Strom nun so hoch geregelt, das meine Gesamtspannung aufeinmal negativ war und damit das gesamte Ergebniss negativ gemacht hat. Die Folge: Bim Differenzsignal werden die beiden Werte addiert (wegen-1*-1). Damit kam der Regler nicht klar.

Meine Frage ist jetzt, wie ich dem Regler sagen kann das er nicht über einen bestimmten Wert regeln darf? Unter "Data types" bei dem PI Regler habe ich das schon versucht, indem ich bei Maximum überall 25000 eingetragen habe. Das hat aber nicht geklappt. er hat beim Regler trozdem Werte über 100000 ausgegeben.
 
Georg J
Forum-Century

Forum-Century



Beiträge: 113
Anmeldedatum: 22.06.11
Wohnort: ---
Version: R2008a
     Beitrag Verfasst am: 31.07.2011, 21:34     Titel:
  Antworten mit Zitat      
Hi Simon,

Schön, dass du das Problem gefunden hast.

Kannst du nicht mit einem Saturation-Block vor oder nach dem Regler die Werte begrenzen?

Gruss, Georg
Private Nachricht senden Benutzer-Profile anzeigen
 
Idefix_1024
Forum-Century

Forum-Century


Beiträge: 230
Anmeldedatum: 16.10.08
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 01.08.2011, 08:56     Titel:
  Antworten mit Zitat      
Wenn Du einen PI Regler verwendest, solltest Du immer darauf achten, dass der nicht Stellgrößen berechnet, die Du im System nicht realisieren kannst. Ansonsten wird das gesamte System instabil!

Abhilfe schafft ein PI-Regler mit Stellgrößenbegrenzung!

Ganz so einfach ist es leider nicht, dass man nur einen Saturation Block an den Ausgang schaltet. Der I-Anteil im Regler integriert auch dann weiter und weiter und weiter...
Du musst einen Grenzwert definieren (ist durch das System vorgegeben) und dann muss, sobald der PI-Regler Ausgang diesen Wert überschreitet der Integrator auf seinem letzten Wert festgehalten werden. Zusätzlich muss man sicher stellen, dass der P Anteil nicht trotzdem für eine Überschreitung sorgt. Deshalb braucht man dann auch noch einen Saturation Block.

Ich hoffe das hilft soweit schonmal weiter!
Private Nachricht senden Benutzer-Profile anzeigen
 
Simon26

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 01.08.2011, 09:22     Titel:
  Antworten mit Zitat      
Danke für die Hilfestellung.

Also der Saturation Block hat nix gebracht.Es wird zwar berechnet, aber er bleibt die ganze Zeit an der Obergrenze. Der Limited Integrator sah dagegen wieder interessant aus. Leider fehlt mir dort jetzt die Einstellmöglichkeit für den P Regler.
Aber, das Problem kann man glaube ich nicht durch eine Reglerbegrenzung lösen. Denn mit der Regelung wollte ich ja eigentlich genau diese Obergrenze berechnen. Sie kann für andere Temperaturen/Widerstände nämlich kleiner bzw. größer sein.

Es ist glaube ich besser die Spannung so zu berechnen, das sie keine Werte annehmen kann, die kleiner als Null sind-> sprich sie bleibt immer größer gleich Null. Mit einem If Block geht das Ganze nicht, weil dieser in einer Schleife ist. (Warum sind If Blöcke so allergisch auf Schleifen zu sprechen?)
Wie würdet ihr vorgehen?
 
Simon26

Gast


Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
     Beitrag Verfasst am: 01.08.2011, 09:42     Titel:
  Antworten mit Zitat      
Sry für Doppelpost.
Aber anscheinend klappt es jetzt. Ich hab den Saturation Block einfach in den Block für die Spannungsberechnung gelegt und gesagt das er minimal 0 wird. Bis jetzt hat er wunderbar alle Ergebnisse ausgerechnet.

Danke für eure Hilfe
 
Neues Thema eröffnen Neue Antwort erstellen



Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:

Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
.





 Impressum  | Nutzungsbedingungen  | Datenschutz | FAQ | goMatlab RSS Button RSS

Hosted by:


Copyright © 2007 - 2024 goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks

MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.