Hallo an Alle,
Ich hoffe, ihr könnt mir eine Fragen beantworten :-)...
Es geht um einen PD-Regler. Ich habe einen fertigen PD-Regler auf Basis
eines Atmega32 aufgebaut, der soweit auch funktioniert (läuft mit
16MHz). Das heißt konkret: Er bekommt vom PC Takt-/Richtungssignale und
gibt als Ausgang eine analoge Spannung von 0-5V aus (12bit DA-Wandler...
'manuell' gebaut mit Widerständen) + ein Richtungssignal, womit man auf
negative Spannung umschaltet. Der Ausgang ist also im Prinzip -10V bis
10V (Spannung zusätzlich durch Operationsverstärker verdoppelt). Als
Rückmeldung bekommt der Atmega Drehgeber-Signale. Funktioniert soweit
auch alles. Das Problem ist nur: Wenn ich schnell fahren will oder die
Auflösung des Drehgebers erhöhe (Parameter werden angepasst), dann läuft
er merkwürdig. Ich kann es nicht mit Worten beschreiben :-/...
Es ist aber auch einleuchtend:
Je schneller ich verfahre, desto mehr Signale kommen rein, die der
Atmega aktualisieren muss (Ist-/Soll-Position oder Differenz) und desto
seltener hat er Zeit den Ausgang zu berechnen und zu setzen. Im
Extremfall gibt der Drehgeber die Signale so schnell aus, dass der
Atmega nichts anderes mehr macht als zu zählen. Der Ausgang bleibt in
diesem Fall konstant, unabhängig vom Eingang.
Ich habe das Programm einmal in Assembler geschrieben und einmal in C.
Beide verhalten sich im niedrigen Drehzahlbereich korrekt. Im hohen
Drehzahlbereich kommt teilweise der Extremfall zustande.
Jetzt meine Frage: Lohnt sich der Umstieg auf einen STM32?
Meine bisherige Einschätzung (hatte noch nie im
32-Bit-Microcontroller-Bereich was zu tun, also korrigiert mich, wenn es
falsch ist):
- durch einen 32-Bitter würden sich die Rechenoperationen vereinfachen
- druch den höheren Takt (bis zu 72MHz) müsste es im allgemeinen
'schneller' laufen
Was denkt ihr? Sollte ich einen STM32 in Erwägung ziehen?
Danke fürs durchlesen :-) (und beantworten natürlich)
Paul W.
Ja.
Ich hatte einmal ein Ähnliches Problem. Ich musste aus einer
LVDT-Messung, die mit 10 KHz getaktet ist Messungen mit einem
Spitzenwertgleichrihter vornehmen.
- Messung alle 50 uS (20KHz)
- 5 uS nach der Messung den geladenen Kondesnsator für 7uS entladen.
Das war richtig kniffelig da mehrere Interrupts und Timer zusammen
arbeiten mussten. Das Timing war enorm wichtig.
Ausserdem tut der Cortex-M3 die Interrupts wesentlich besser/schneller
verarbeiten.
Siehe dazu mein (heute geschriebenen :) ) Artikel:
http://www.mikrocontroller.net/articles/STM32#Allgemeine_Infos
Paul W schrieb:> gibt als Ausgang eine analoge Spannung von 0-5V aus (12bit DA-Wandler...> 'manuell' gebaut mit Widerständen)
Wo kaufst Du denn die dafür nötigen teuren 0,02% Widerstände?
Außerdem ist ein fertiger 12Bit-DAC billiger.
> Je schneller ich verfahre, desto mehr Signale kommen rein, die der> Atmega aktualisieren muss (Ist-/Soll-Position oder Differenz) und desto> seltener hat er Zeit den Ausgang zu berechnen und zu setzen. Im> Extremfall gibt der Drehgeber die Signale so schnell aus, dass der> Atmega nichts anderes mehr macht als zu zählen. Der Ausgang bleibt in> diesem Fall konstant, unabhängig vom Eingang.
Du mußt doch nicht bei jedem Schritt neu anfangen zu rechnen.
Laß den MC rechnen und ein Interrupt liest nur den Encoder aus.
Und ist die Rechnung fertig, werden die zwischenzeitlich gezählten
Schritte übernommen.
Peter
> Je schneller ich verfahre, desto mehr Signale kommen rein, die der> Atmega aktualisieren muss (Ist-/Soll-Position oder Differenz) und desto> seltener hat er Zeit den Ausgang zu berechnen und zu setzen.
Somit ändert sich Deine Gesamtstrecke im Regler in Abhängigkeit von
irgendwelchen Umgebungsbedingungen. Das ist keine besonders gute Idee;
besser fährst Du mit einer von Anfang an konstanten Totzeit. Das
gesamte Reglerverhalten ist dann besser in den Griff zu bekommen, auch
wenn es zunächst widersinnig erscheint, vor der Ausgabe denjenigen Teil
der Zeit, der momentan nicht gebraucht wird, zu verheizen.
Mit einer festen Taktung fährst Du besser. Natürlich hast Du dann eine
harte Obergrenze, aber die hast Du jetzt implizit auch schon -- nur dass
sich das Reglerverhalten jetzt ändert, je näher Du ihr kommst.
Ok, ich muss wohl ein wenig genauer werden...
Zur Zeit ist das Programm so aufgebaut:
Die drei externen Interrupts überwachen beide Eingänge, das heißt das
Takt-Signal vom PC und die zwei (sind ja zwei Leitungen, inkrementeller
Drehgeber!) Drehgeber-Signale. In der While-Schleife der main wird nur
die Berechnung des Ausgangs berechnet.
Wer sagt, dass ich 0.02%-Widerstände nehme? Nehme zur Zeit die billigen
(später die genaueren), weil es auf diese Abweichung nicht sooo ankommt.
Ich nehme kein DA-Baustein, weil ich dann wieder Zeit verliere (I²C), es
sei denn ich verwende einen SPI-Baustein, aber das kann ich mir später
auch noch überlegen.
Paul W schrieb:> Wer sagt, dass ich 0.02%-Widerstände nehme?
Das sagt Deine Angabe: 12Bit.
2^12 = 4096
1/4096 = 0,0244%
Bei schlechter als 0,02% sind Deine 12Bit nur ne Lüge.
Peter
Ah, dann handelt es sich um ein Missverständnis: Mit 12bit meinte ich,
dass ich 12 Bits/Pins verwende. Dass die Toleranz bei den Widerständen
viel ausmacht weiß ich, aber das ist bisher nicht kritisch, da es sich
erstens um ein Hobbyprojekt handelt und zweitens es nur vorrübergehend
ist. Gemacht habe ich weil... ach... sagen wir einfach, ich wollte mir
ohne viel Arbeit Optionen frei halten ;-).
Absolute Drehgeber stehen mir leider nicht zur Verfügung, sind auch
erstens teuerer und zweitens schwerer anzusteuern. Mit Bussystem wollte
ich mich dafür nicht auseinandersetzen :-/...
Peter Dannegger schrieb:> Bei schlechter als 0,02% sind Deine 12Bit nur ne Lüge.
Auch bei 0,02% ist es garantiert gelogen, denn diese 0,02% bedeuten,
dass der Logikpegel des höchsten der Digitalausgänge auf 0,8mV genau
sein muss.
Paul W schrieb:> Die drei externen Interrupts überwachen beide Eingänge, das heißt das> Takt-Signal vom PC und die zwei (sind ja zwei Leitungen, inkrementeller> Drehgeber!) Drehgeber-Signale.
Das heißt also, nur Bits einlesen.
Da wird Dir ein 32Bitter nichts bringen.
Das schafft auch ein 8Bitter in wenigen µs pro Interrupt.
Wie schnell kommen denn die Interrupts?
Peter
OK, für ein Hobbyprojekt spielt es keine Rolle, aber eine mehrminütige
Referenzfahrt verursacht bei jedem Systemstart Kosten (Arbeitszeit), die
es bei einem absoluten Drehgeber nicht gibt.
Abgesehen davon gibt es mit dem SSI-Interface eine einfache digitale
Schnittstelle. Du gibts nur einen Takt vor, und bekommst in diesem Takt
die einzelnen Datenbits. Oder man verwendet einen Drehgeber mit einer
analogen (4-20)mA- oder (0-10)V-Schnittstelle.
> Siehe dazu mein (heute geschriebenen :) ) Artikel:> http://www.mikrocontroller.net/articles/STM32#Allg...
LOL, dein ists nimmer :-)
eher unser **g**
Bei Regelung sprechen mehrere Sachen für einen Cortex-M3, wenn die
Leistung des AVR nicht ausreicht:
- 32bit, d.h. Rechenoperationen auf 16, 32 bit werden gegenüber dem AVR
in einem Takt ausgeführt
- höhere Taktfrequenz erlaubt natürlich ein feineres Abtasten der
Messwerte, und eine feinere Ausgabe der Stellwerte
- durch Techniken wie z.B der DAM Controller können Aufgaben wie z.B.
das Auslesen des AD verlagert werden
- Cortex-M3 erlaubt non-invasive debugging, d.h. du kannst per debugger
in den laufenden core eingreifen, ohne dass er gestoppt werden muss
VG,
/th.
Paul W schrieb:> Mit 12bit meinte ich,> dass ich 12 Bits/Pins verwende. Dass die Toleranz bei den Widerständen> viel ausmacht weiß ich, aber das ist bisher nicht kritisch, da es sich> erstens um ein Hobbyprojekt handelt und zweitens es nur vorrübergehend> ist.
Vor allem wäre es besser, wenn Du die Bits, die Du nicht garantieren
kannst, einfach wegläßt. Um ein Beispiel zu nehmen: Angenommen, Dein
Regler sollte gerade etwas in der Gegend 1023/1024 ausgeben. Durch
Deine "dazubetrogenen" Bits ist aber 1024 kleiner als 1023. Ergebnis:
Egal aus welcher Richtung Du Dich dieser Grenze näherst: Du wirst übers
Ziel hinausschießen, denn der Schritt zwischen 1023 und 1024 tut genau
das Umgekehrte von dem was er soll. Du hast eine Schwingneigung
dazugebaut und es wäre besser, Du würdest auf diese falschen Bits ganz
verzichten.
EDIT: da die Regelverstärkung hier für kleine Änderungen ihr Vorzeichen
ändert, ist "Schwingneigung" ernst zu nehmen.
> Ich hoffe, ihr könnt mir eine Fragen beantworten :-)...
Eigntlich nicht da du es nicht fuer noetig haelst
einmal genau zu erzaehlen was du ueberhaubt machst.
Beschreibe also mal deine Regelstrecke!
> Je schneller ich verfahre, desto mehr Signale kommen rein, die der> Atmega aktualisieren muss (Ist-/Soll-Position oder Differenz)
Dann machst du etwas falsch. Dein Inkrementalgeber sollte in einem Timer
mit einer konstanten Abtastfrequenz abgetastet werden. Damit ist
die Auslastung unabhaengig von deiner Drehzahl.
> - durch einen 32-Bitter würden sich die Rechenoperationen vereinfachen
Sobald man etwas regelt, also mit entsprechend grossen Zahlen hantiert
wird man 16Bit oder 32bit zu schaetzen wissen.
Ich habe allerdings auch schon eine komplette Motorregelung fuer
Drehzahl und Position auf einem Mega8 ans laufen gebracht. Wuerde
ich mir heutzutage aber nicht mehr antun.
> Ich habe das Programm einmal in Assembler geschrieben und einmal in C.
Designfehler sind Implementationsunabhaengig und lassen sich auch nicht
durch einen fetten Microcontroller beheben.
> Ich nehme kein DA-Baustein, weil ich dann wieder Zeit verliere
Du weisst das es auch Microcontroller mit integriertem DA-Wandler gibt?
Ausserdem erklaer uns doch mal warum du glaubst 12Bit zu brauchen
und wo du schonmal dabei bist, wieso ein PWM-Ausgang nicht ausreicht.
:-)
Olaf
thorstendb schrieb:> Bei Regelung sprechen mehrere Sachen für einen Cortex-M3, wenn die>> Leistung des AVR nicht ausreicht:> - ...> - ...> - ...
...das reißt aber alles nichts, wenn der Algorithmus (in HW und SW)
nichts taugt - und darauf scheint mir das bisher geschilderte
hinzudeuten.
Ohne mich jetzt gross in die Sache hineinzudenken würde ich erst mal den
Encoder durch eine externe Hardware (z.B. kl. PLD) vom AVR und dessen
Antwortzeiten unabhängig machen. Dajnn kann der SW-Regelalgorithmus
immer dann, wenn er Zeit hat (bzw. das Taktraster es vorgibt) die
aufgelaufenen Schritte ermitteln. Damit dürfte schon viel gewonnen sein.
Wenn's unbedingt (auch aus anderen Gründen wie z.B. "ich will jetzt
endlich mal was mit 'nem Cortex-M3 machen" ;-) ) ein ARM-Derivat sein
soll, würde ich hier einen nehmen, der gleich einen Drehencoder-Eingang
hat (beim STM32 weiß ich's jetzt nicht, aber einige der von TI
aufgekauften Luminary/Stellaris Cortexe haben z.B. welche).
Ich hatte auf eine ausführliche Beschreibung verzichtet, da ich davon
ausging, dass eine grobe Erklärung ausreicht.
Es geht um einen Lageregler, genauer gesagt um einen PD-Regler.
Vom PC kommen zwei Signale, Takt und Richtung. Intern gibt es einen Wert
für die Soll-Position. Um genug Platz nach oben hin zu haben, habe ich
einen 32-bit Wert dafür gewählt (Alternative siehe weiter unten), d.h.
schon bei einem Taktsignal muss ich vier Bytes aus dem Ram in die
Register holen, mit einem fest eingestellten Wert addieren (Wert wird
per Software festgelegt) und wieder vier Register in den Ram schreiben
(hier würden sich 32 bit vermutlich bemerkbar machen). Das Takt-Signal
liegt an einem externen Interrupt-Pin und diese Rechnung wird in einer
Interrupt-Routine durchgeführt. Das Richtungssignal liegt an einem
normalen Pin.
Vom inkrementellen Drehgeber kommen ebenso zwei Signale die beide an
einem externen Interrupt-Pin liegen. Intern gibt es wieder einen
32-Bit-Wert für die Ist-Position. Beide Interrupts werden auf eine
Interrupt-Routine geleitet, es gibt also nur eine Interrupt-Routine für
die Drehgeber-Signale. Diese Routine holt sich die aktuelle Ist-Position
(32Bit), addiert um einen Wert (per Software festlegbar) und schreibt
wieder 4 Bytes in den Ram. Dazwischen werden noch Sachen erledigt, damit
das ganze funktioniert, Quadratur-Decoder eben.
In der While-Schleife der main passiert folgendes:
- Interrupts deaktivieren
- Ist- und Soll-Positionen in einer lokalen Variable speichern
- Interrupts aktivieren
- Differenz der beiden Werte bilden
- Stellwert berechnen mit eingestellen Parametern berechnen und setzen
- Ausgang setzen
Und mal ehrlich...
>> Eigntlich nicht da du es nicht fuer noetig haelst>> einmal genau zu erzaehlen was du ueberhaubt machst.
Das kann man auch freundlicher formulieren, wie z.B. "Wir bräuchten ein
wenig mehr Infos, was genau du machst und machen willst.". Wenn du nicht
antworten willst, dann lass es. Sorry, aber solche Antworten mag ich
nicht... wenn du was an meinen Posts zu kritisieren hast, dann sag es
bitte in einem vernünftigen / nicht überheblichen Ton.
Und ja, es ist mir durchaus bewusst, dass es Controller gibt mit
eingebautem DA-Wandler, aber die habe ich nicht zur Hand.
>> Dann machst du etwas falsch. Dein Inkrementalgeber sollte in einem Timer>> mit einer konstanten Abtastfrequenz abgetastet werden. Damit ist>> die Auslastung unabhaengig von deiner Drehzahl.
Ich habe die Interrupt-Routinen genommen, weil ein Verlust von Takten
unzulässiger ist als eine kleine Abweichung im Ausgang (nur ist diese
Abweichung in meinem Extremfall eben nicht mehr klein).
Etwas dabei gedacht habe ich mir schon, nur schien es erstens einfacher
zu implementieren und zweitens hatte ich diese Methode durch einen
kleinen Test (möglicherweise auch falsch durchgeführten) für die bessere
empfunden.
Im Test habe ich einen Drehgeber an den MC angehängt. Durch einen an den
Drehgeber angekoppelten Motor konnte ich gezielt Positionieren (Aufbau
ist nicht weiter wichtig, funktioniert aber einwandfrei). Ich hatte drei
unterschiedliche Methoden getestet: Interrupt-Betrieb, Timer-Betrieb und
ständiges Abfragen in der while-Schleife (fällt aber für den
Anwendungsfall in diesem Thread flach).
Ich konnte also exakt Positionieren und hatte gleichzeitig eine
Möglichkeit die aktuelle Position des Drehgeber auszugeben. Es stellte
sich heraus, dass der Interrupt-Betrieb zuverlässiger war, bzw.
schnellere Drehgeschwindigkeiten ermöglichte.
Jetzt der Anwendungsfall: Gesteuert wird damit ein Servoumrichter, der
einen Servo steuert. Der Servoumrichter akzeptiert nur -10 bis 10V. Die
Auflösung des Eingangs liegt bei 10-12Bit (laut Datenblatt, kann mich
nicht mehr genau daran erinnern).
Meine Ausgangsauflösung habe ich deswegen auf 12Bit gesetzt, mir war zu
dem Zeitpunkt nicht bewusst, dass sich das negativ auswirken wird /
auswirken kann. Der Servo dreht mit einer maximalen Geschwindigkeit von
3000 +- 200 Umdrehungen pro Minute, der Drehgeber hat eine Auflösung von
2048 vollen Drehgeber-Inkrementen pro Umdrehung. Das heißt, dass die
zuständige Interrupt-Routine 2048*4*3000/60 =~ 410.000 Mal pro Sekunde
aufgerufen wird. Wenn ich mich nicht verrechnet / keinen Denkfehler
habe, dann bedeutet das, dass für die Interrupt-Routine knapp 39 Takte
bleiben.
Auf einen PWM-Ausgang habe ich verzichtet, weil ich diese wieder glätten
müsste, da ich die Abtastrate des Servoumrichters nicht kenne. Das wäre
mir ein wenig zu riskant. Vor allem wenn ich bedenke, dass die sich auch
noch von Servoumrichter zu Servoumrichter unterscheiden kann. Ich gehe
hier allerdings davon aus, dass der Eingang ständig abgetastet wird und
nicht direkt auf den Servo geht (durch Umwege).
Über den Sinn-/Unsinn von 2048 Drehgeber-Inkrementen pro Umdrehung
brauchen wir hier nicht diskutieren ;-)...
Ich weiß ehrlich gesagt nicht direkt, was man an einem PD-Regler für
einen Algorithmus braucht?
http://www.rn-wissen.de/index.php/Regelungstechnik#PD-Regler
Ist quasi ein Einzeiler in C? Algorithmus kann man das ja schlecht
nennen?
Mit Logik-Bausteinen habe ich mich noch nicht wirklich auseinander
gesetzt... und würde es ehrlich gesagt eher vermeiden, wenn es auch
anders geht.
Also was ich bisher als Kritik an dem Aufbau sehe:
- "Genauigkeit" reduzieren auf 8-10 Bits
- von Interrupt-Betrieb auf Timer-Betrieb wechseln
39 Takte ist doch ein wenig arg knapp. Ähm, Push/Pop der Register
frisst davon schon mal das meiste weg.
Ich habe mal das RM0008 von STM32 mal an geschaut was der für
Timer-Funktionen hat. Hier gibt es ein Encoder-Eingangs-Modul. Aber die
Takte passen so mit Deiner Beschreibung (Clk/Direction) nicht zusammen.
Schaue mal selbst danach in dem STM32 Datenblatt. (Timer 1 & Timer 8 bei
12.3.16 oder 12.3.17)
Wegen 5V: Du hast ohnehin später einen Ausgang +/-10V, also musst Du
sowiso umskalieren mit einem OP.
Der STM32 kann auch 72 MHz und ist somit deutlich schneller. Der STM32
hat auch einen DA-Wandler drin. Für Dich würde dann der Chip STM32F103RC
in Frage kommen.
Ich könnte für Dich auch mal Testen ob es mit dem STM32-Timer klappen
könnte, schreibe mir dann ein Mail.
> 32-Bit-Wert für die Ist-Position. Beide Interrupts werden auf eine> Interrupt-Routine geleitet, es gibt also nur eine Interrupt-Routine für> die Drehgeber-Signale. Diese Routine holt sich die aktuelle Ist-Position> (32Bit), addiert um einen Wert (per Software festlegbar) und schreibt> wieder 4 Bytes in den Ram. Dazwischen werden noch Sachen erledigt, damit> das ganze funktioniert, Quadratur-Decoder eben.> Das heißt, dass die> zuständige Interrupt-Routine 2048*4*3000/60 =~ 410.000 Mal pro Sekunde> aufgerufen wird. Wenn ich mich nicht verrechnet / keinen Denkfehler> habe, dann bedeutet das, dass für die Interrupt-Routine knapp 39 Takte> bleiben.
Man könnte auch den Timer zählen lassen bzw. einen variablen Vorteiler
realisieren Stichwort CTC-Mode und so die Interrupt-Last drastisch
reduzieren...
> 3000 +- 200 Umdrehungen pro Minute, der Drehgeber hat eine> Auflösung von 2048 vollen Drehgeber-Inkrementen pro Umdrehung.
Ich habe eine Motor mit maximal 6000upm mit einem 512er Encoder
im Mega8 laufen. Drehzahlregelung, Lageregelung, Uebername neuer
Sollwerte ueber RS232, Regelausgang ist PWM und ein I2C-LCD fuer
Diagnosezwecke. Der Mega8 laeuft dabei mit 16Mhz.
Das ist jetzt zwar schon fast 10Jahre her das ich es gemacht habe,
aber ich hatte nicht den Eindruck das es von der Geschwindigkeit
her auf Kante genaeht wuerde. Und es ist alles in C programmiert!
Wenn es mit der Geschwindigkeit bei dir wirklich knapp wird dann
ist ein Controller der moeglichst schnell in den IRQ rein/raus kommt
von Vorteil. Wirklich schnell muss ja nur der TimerIRQ laufen wo der
Encoder abgetastet wird. Selbst wenn dabei 50% der Rechenleistung drauf
geht, fuer die Regler bleibt immer noch genug uebrig. Die koennen ja
erheblich langsamer laufen.
Was am Mega8 etwas schlecht ist, man hat nur wenig Flashrom. Das reicht
zwar fuer die Funktionalitaet, aber ich haette mir etwas mehr Platz fuer
Diagnosefunktionen gewuenscht.
Ich denke ein kleiner R8C wuerde das machen ohne auch nur ins schwitzen
zu kommen weil er als 16Bit CPU sich mit dem regeln leichter tut, und
man wegen den einstellbaren Interruptprioritaeten die Software besser
auslegen kann. Andererseits wenn man sieht wie billig ein Controller ist
dann wuerde ich fuer ein kleines Bastelprojekt mit ueberschaubarer
Stueckzahl vermutlich auch einen fetten Controller nehmen. Fuer 2Euro
mehr muss man sich ja nicht den Arsch unnoetig aufreissen.
Deine Angst vor PWM kann ich nicht verstehen weil ein einfaches RC
Filter reichen sollte. Was du dann da noch an Unsauberkeiten drauf hast
wird sowieso von deinem Regler erzeugt und von der Masse deiner Hardware
gefiltert.
> Vor allem wenn ich bedenke, dass die sich auch> noch von Servoumrichter zu Servoumrichter unterscheiden kann.
Du meinst deine Regelung soll mit unterschiedlicher Hardware
funktionieren? Ist dir klar das du damit vielleicht jedesmal andere
Regelparameter brauchst?
> Ist quasi ein Einzeiler in C? Algorithmus kann man das ja schlecht> nennen?
Klar. Ein PID Regleralgorythmus kann man wirklich in 3-Zeilen schreiben.
In einer Zeile schreibt man das nicht wegen der Uebersichtlichkeit und
vor allem weil du in den Algorythmus eingreifen musst. (z.B Antiwindup)
In der Praxis wirst du dann auf folgende Probleme treffen:
1. Ermittlung der Regelparameter. Da kann man theoretisch Doctorabeiten
drueber schreiben. Meist reicht fuers erste eine grobe Abschaetzung und
dann Ziegle&Nichols oder Chron-Renswick. (bestimmt falsch geschrieben
:-)
Die letzten Feinheiten macht man dann mit Bauch und Erfahrung.
2. Du wirst feststellen das deine Regelung nicht ueber den ganzen
Bereich
gleich ist. Es kann dann sein das du Drehzahlabhaengig unterschiedliche
Regelparameter brauchst.
3. Unangenehme Sonderfaelle. Wenn deine Servos ein Getriebe haben, dann
hat das wohlmoeglich Spiel. Wenn du nun im Bereich der
Drehrichtungsumkehr regelst so gibt es relativ grosse Zeiten wo dein
Motor keine Last/Masse sieht damit aendert sich natuerlich die
Regelstrecke extrem.
4. Falls du von 0 langsam hochfahren willst und dir dieser Bereich
wichtig ist so kaempfst du vielleicht mit dem Losbrechmoment.
5. Eine geschickte Skalierung finden. Du musst dir wirklich darueber im
klaren sein welchen Wertebereich deine Variablen annehmen koennen. Ich
hab das alles mit 16Bit Variablen gemacht die teilweise unterschiedlich
skaliert waren. An dem Punkt ist natuerlich ein 16Bit oder ein 32Bit
Controller einem 8Bit Controller ueberlegen. Ein weiterer Punkt ist
natuerlich das bei solchen Controllern dann 16Bit Variablen atomar sind.
Du also den IRQ nie sperren musst.
Wenn ich dir einen Tip geben darf, sieh in deiner Hardware eine
moeglichst schnelle RS232 Schnittstelle vor und gebe dort im Regler
immer die Parameter aus. Dann kannst du dir Drehzahl und
Einschwingverhalten ganz unbeschwert am PC als Kurve anschaut. Sowas
erleichtert Parametrierung und Fehlersuche ganz erheblich. Schliesslich
hast du ja den Nachteil das du einen laufenden Regler nicht mal eben mit
einem Debugger anhalten kannst.
Olaf
