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
Unter Umständen würde ja ein absoluter Drehgeber das Reglerdesign erleichtern, und für ein besseres Regelverhalten sorgen.
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 ;-).
Außerdem entfällt dann die beim Start notwendige Referenzfahrt für den Drehgeber, und je nach Anwendung kann diese mehrere Minuten dauern.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.