regelalgorithmus implementieren

Float ? Vergiss das, bringt nichts. Ich arbeite schon seit jahren mit 
Integern und hatte nie Probleme. Eine Longinteger hat einen dynamischen 
bereich von 9 dezimalstellen und auch soviele signifikanten stellen. 
Waehrend ein Float einen dynamischen Bereich von 308 dezimalstellen hat, 
sind es nur 6 signifikante digits, da 24bit mantisse und 8 bit exponent.
Zudem ist die Eingabe (ADC) und die Ausgabe(DAC) ja auch in Integer.
Die Geschwinikeit des Loops hat einen Zusammenhang mit der 
Systemgeschwinigkeit.

Kp = 7.8 was soll das ? Braucht man so nicht.

Ich habe den Sollwert als Integer, falls das System linear ist, gleich 
dem ADC wert [0..65536]. Der Istwert ist auch gleich [0..65536].
Fehler = Soll-Ist;
P-Teil = P_Faktor * Fehler;
..
..
PI = P-Teil + I-Teil;
..

Etwas kreativ muss man schon sein.

PI Regler schrieb:
> Oder habe ich dan was total falsch verstanden.

Ja.

Um mit ganzen Zahlen zu rechnen, musst du deine Werte skalieren.

Anstatt also mit 7.8 (z.B. V) zu rechnen, überlegst du wie genau es
sein soll und rechnest halt stattdessen mit 78 Zehntel (also z.B.
0.1V) oder 780 Hundertstel (also 0.01V) oder 7800 Tausendstel
(also mV).

PS: um solche Werte zu addieren oder zu subtrahieren, braucht
man nicht viel ändern (ggf. Überlauf berücksichtigen).

Bei Multpikationen, Divisionen etc. ergibt sich ein Fehler durch
die Skalierung, das muß man jeweils manuell korrigieren.

nö

wie auch? Keiner kennt das System, wahrscheinlich du selber nicht,
keiner kennt dein Program (du?).

Wie soll man da sagen, warum es mal geht und mal nicht?
Sei froh, wenn es geht.

Und der Luefter hat eine Bandbreite von 100Hz ? Eher unter 10Hz. Da 
muesste man eigentlich mit einer Abtastzeit von 100ms dabei sein.

Zum Code :
Das macht man ganz anders.
1) Eine Berechnung in einem Interrupt gibt es eh nicht.
2) Eine Berechnung in einem Interrupt gibt es eh nicht.
3) Eine Berechnung in einem Interrupt gibt es eh nicht.
4) Eine Berechnung in einem Interrupt gibt es eh nicht.
5) Eine Berechnung in einem Interrupt gibt es eh nicht.


interrupt Timer0() {
 timercame=1;
}


main() {
 ..
 while (1) {
 if (timercame==1){
  ReadADC();
  CalcRegler();
  OutputRegler();
  ..
  StartADC();
  timercame=0;
  {
 }
}

Außerdem macht es Sinn, jeweils die Zeit einer Berechnung
festzuhalten und mit der bei der nächsten zu vergleichen.

Die Differenz braucht man für den I- und ggf. den D-Anteil.
Theoretisch kann man auch vertrauen, immer im x-msec-Raster
zu rechnen und diesen Wert dafür nehmen, aber je nach
Programm kann man es nicht garantieren, deshalb lieber
messen.

Zur Zeitmessung könnte man in einem Interrupt, der
zuverlässig in einem bestimmten Zeitraster statt findet,
einen Zähler weitersetzen. Überlauf beachten!

Das könnte in deinem (leider unvollständigen) Quelltext
die Geschichte mit x und x_alt sein.
Ich habe jetzt aber nicht gefunden, wo x weitergezählt
wird.

PS: man darf auch gerne *.c-Dateien anhängen.
Wenn die dann auch nett formatiert sind, fällt das
Lesen leichter.
Noch schöner, wenn sie vollständig sind...

PPS: ich mache nie Witze.

@  Verschneiter Tag (Firma: vorgestern) (hacky)

>Zum Code :
>Das macht man ganz anders.
>1) Eine Berechnung in einem Interrupt gibt es eh nicht.
>2) Eine Berechnung in einem Interrupt gibt es eh nicht.
>3) Eine Berechnung in einem Interrupt gibt es eh nicht.
>4) Eine Berechnung in einem Interrupt gibt es eh nicht.
>5) Eine Berechnung in einem Interrupt gibt es eh nicht.

Warum nicht? Wenn man genau weiß, wie lange die Berechnung dauert, und 
man genau weiß, daß während dieser Zeit nix anderes stören kann (also 
auch kein anderer Interrupt z.B.), kannst Du doch rechnen, wie du lustig 
bist. Man muß es eben nur im "zeitlichen Überblick" behalten.
In seinen Code oben habe ich aber nicht reingeschaut - weiß also nicht, 
ob dies die Ursache für sein Phenomen sein könnte (denke aber eher 
nicht).

Di Pi schrieb:
> Jens G. schrieb:
>> Warum nicht?
>
> Ganz einfach: Zum Zwecke der Übersichtlichkeit (das hat was mit Stil zu
> tun, ähnlich wie Groß- und Kleinschreibung).

Nicht wirklich.
Wenn er seine Berechnung nicht in float macht sondern als skalierten 
int, hat er in einem ISR Durchlauf ziemlich viel Zeit übrig.

Stilmässig viel schlimmer finde ich
* dass die internen Variablen der Berechnung nicht in der timer.c sind
  sondern als globale Variablen angelegt wurden
* dass da ein 'volatile' Rundumschlag gemacht wurde
* von der 'saumässigen' Codeformatierung rede ich erst gar nicht

Berechnungen dort hin, wo sie hingehören. Zeitkritische Dinge dürfen 
ruhig in einer ISR sein, sofern man dadurch nicht das Zeitbudget der ISR 
sprengt. ISR klein und kurz bedeutet nicht zwangsläufig, dass man da nur 
ein Flag setzen darf, da muss man nicht päpstlicher als der Papst sein.

Weshalb keine (Float-) Berechnungen in einem Interrupt ?

Vielleicht moechte man auch nur zu Debugzwecken kommunizieren. Das Uart 
laeuft aber nicht wenn man mit floatrechnungen den Interrupt verstopft.

Was zu rechnen waere steht ja schon da. Man kann es vereinfachen, 
speziell die Konstanten.

Kd*(y-yalt) bedeutet eine Gegenkopplung. Ob die was bringt kann man ja 
schauen. Wenn ich was zu regeln habe, so hab ich meinen Regler 
kommunikationsfaehig, und falls ich nicht probieren kann, schreib ich 
erst eine Simulation fuer den PC. Wenn die simulation dann laeuft, muss 
zuerst ermittelt werden, ob die abgenommenen Paramter der Strecke auch 
hinkommen, dh lass ich den Regler parallel zur Simulation laufen und 
schau die Abweichungen an.
Waehrend des Betriebes schau ich mir das Verhalten an und schraub an den 
Parametern rum.
Im obigen Fall, kann man ja mit Kd=0 beginnen und dann waehrend des 
Betriebes den Wert fuer Kd setzen.