mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bringt ein STM32 mehr?


Autor: Paul W (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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#Allg...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Paul W (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: regler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Umständen würde ja ein absoluter Drehgeber das Reglerdesign 
erleichtern, und für ein besseres Regelverhalten sorgen.

Autor: Paul W (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: regler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem entfällt dann die beim Start notwendige Referenzfahrt für den 
Drehgeber, und je nach Anwendung kann diese mehrere Minuten dauern.

Autor: Paul W (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-/...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der STM32 bringt ihm immerhin den vermissten DAC ;-).

Autor: regler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: thorstendb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Paul W (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.