Software PID für Geschwindigkeitsregelung

Sieh Dir einmal die Ziegler-Nichols Einstellmethode fuer die drei Parameter an:

Tim Wescott hat einiges zu PID geschrieben, ihn kann man in der s.e.d. NG finden:

Ich mache es bei etwas bockigem Verhalten oft "mit dem nassen Finger", so ganz beschreiben kann man das oft nicht. Ist vermutlich aehnlich wie das Einstellen des Vergasers eines alten Alfa Romeo, "nur Giuseppe kriegt das sauber hin". Uebung, Uebung ...

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Hallo,

ein wesentliches Problem welches Du vermutlich hast ist das OS. Windows & Co. sind keine Real Time OS. Es ist daher gar nicht möglich in definierter Zeit oder in definierten Intervallen zu arbeiten. Wenn Dir der Scheduler Rechenzeit weg nimmt, dann macht der das. Wenn Du dein Programm 40ms schlafen legts, können das auch mal 1000ms sein. Es gibt keine Garantie. Für diesen Zweck gibt es Real Time Kerne, die unter dem OS laufen und dort ein definiertes Zeitverhalten garantieren, das Windows läuft dann als ein Anwendung darauf mit und kann für die bunten Bilder sorgen. Google mal unter realtime und windows.

Viel Erfolg,

Hans

ntervallen zu arbeiten.

in.

rt ein definiertes Zeitverhalten

n f=FCr die bunten Bilder sorgen.

ntervallen zu arbeiten.

in.

rt ein definiertes Zeitverhalten

n f=FCr die bunten Bilder sorgen.

Hallo und zun=E4chst mal danke f=FCr eure Antworten. Ich habe mir eben mal das Ziegler-Nichols Einstellschema angeschaut und versuche das mal bei mir auszutesten. Danke f=FCr den Link.

@Hans: Siehst du hier irgendwelche M=F6glichkeiten, dennoch unter Windows eine saubere Regelung hinzubekommen (kann man eventuell die vage Echtzeitf=E4higkeit in irgendeiner Art und Weise in den Regler integrieren?).

Viele Gr=FC=DFe und einen sch=F6nen Abend,

Joachim

Intervallen zu arbeiten.

ein definiertes Zeitverhalten

die bunten Bilder sorgen.

Intervallen zu arbeiten.

ein definiertes Zeitverhalten

die bunten Bilder sorgen.

Ehrlich gesagt wuerde ich mich das nicht trauen, unter Windows laufen zu lassen. Zumindest nicht, wenn es bei Schieflauf ordentlich Rumms machen koennte.

Da wuerde ich ein Betriebssystem wie QNX nehmen, bei dem Interrupt-Latenz und solche Dinge determiniert sind.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Moin!

Du schreibst sehr wenig über das System. Was sind das für Motoren (DC? Schrittmotor?), was kannst Du vorgeben, was für Daten bekommst Du raus?

Möglicherweise wäre es zielführender, zwischen PC und Maschinen einen Mikrocontroller oder eine SPS zu hängen, die vom PC die neuen Koordinaten bekommt und dann beide Maschinen synchron dort hinbewegt. Für solche Hardware ist Echtzeit kein Problem.

Gruß, Michael.

Hallo Joachim,

Darf ich auch antworten?

Du kannst unter XP ein recht gutes Zeitverhalten hinbekommen, wenn Du die Auflösung der Timer eines Prozesses (also Dein Programm) mit

timeBeginPeriod(1);

bei Programmstart setzt und bei Programmende mit

timeEndPeriod(1);

wieder zurücksetzt. Dies beeinflusst auch die Genauigkeit von Sleeps und allen Wartefunktionen (WaitForSingleObject und Konsorten). Deine Gerätekommunikation solltest Du dann aber in einen eigenen Thread auslagern, dem Du dann Echtzeitpriorität gibst. Falls Du ein GUI in Deinem Programm hast, wird auch dies gleich damit entkoppelt, sonst kann es schon sein, dass sich Windows lieber mit dem Verschieben Deines Fensters beschäftigt, als mit Deiner Regelung. Wichtig ist dabei, dass Dein Kommunikationsthread die meiste Zeit schläft (also hier immer 40ms lang) und NIE in eine Busy-Loop gerät, da man sonst ganz Windows anhält (zumindest bei Single-Cores). Mit dieser Methode bekommt man schon ein recht zuverlässiges Zeitverhalten hin, die Sleeps halten sich dann meistens millisekundengenau an ihre Vorgaben. Sicherlich ist Windows dann immer noch kein Echtzeitbetriebssystem und ich würde dem auch keine sicherheitsrelevanten Funktionen anvertrauen, die zeitkritisch sind. Aber es funktioniert besser als man denkt, einfach mal ausprobieren.

Gruß, Oliver

n

Hallo, @Michael, J=F6rg: Das System welches dem Roboter folgen soll besteht aus

3-Servomotoren (f=FCr jede Achse einen) DC welche aktuell =FCber eine USB-

auch Windows, da die DLL zur Ansteuerung vom Hersteller nur f=FCr Windows zur Verf=FCgung gestellt wird. Ich habe mir schon mal =FCberlegt, ob ich eventuell Kithara verwende und damit dann Echtzeitf=E4hige Tasks unter Windows erstellen kann. Das mit dem Controller h=F6rt sich interessant an wobei es schwierig wird, den RS485 Treiber dort irgendwie unterzubringen (nehme ich mal an). Denn ohne den bekomme ich ja keine Daten zu der 3-Achs Maschine bzw. kann keine Befehle zum beschleunigen oder abbremsen an die Maschine schicken.

Ich denke ich werde den RS485 Treiber auf Linux umprogrammieren (vorausgesetzt der Hersteller gibt mir da die notwendigen Infos) und dann nehme ich RTAI und habe dann hoffentlich ein sauberes Echtzeit OS.

Viele Gr=FC=DFe,

Joachim

Hallo NG,

Joerg schrieb:

Hieß so nicht früher mal eine Mettwurst?

Z-N ist eine rein empirische Methode der Reglerdimensionierung, die für ein optimales Störverhalten ausgelegt ist. Für ein Führungsproblem wie hier ist meist die Phasenreserve zu gering.

Ganz so ist es zum Glück nicht, jedenfalls nicht, solange es um überschaubare, halbwegs lineare und zeitinvariante Strecken geht.

Grundsätzlich sollte vorher das Konzept geklärt sein: soll die zweite Regelung von der Regelgröße der ersten geführt werden oder ist es möglich, beide Regelungen parallel mit einem "Offset" von 1mm zu führen? Diese Festlegung hat Auswirkungen auf Dimensionierung und Performance des Gesamtsystems.

In jedem Falle ist zunächst eine saubere analytische Reglerdimensionierung auf der Basis eines hinreichend korrekten Modells zu empfehlen. Die Grundlagenliteratur der Regelungstechnik hat da jede Menge Ansätze parat. Wenn man nicht weiß, wie der Regler aussehen muss und was man mit welchem Reglertyp und Stellgrößenhub bei welchem Abtastintervall etc. an Performance schafft, braucht man garnicht erst mit der Implementierung anzufangen.

40ms Abtastintervall scheint mir spontan auch eher lang bemessen - wie schnell soll die Regelung denn sein?

Bei digitalen Verfahren muss immer beachtet werden, dass die Softwarekoeffizienten von I- und D-Anteilen eines Reglers von der Abtastrate abhängen. Also muss bei variabler Abtastrate dies 1. bekannt und 2. eingerechnet werden, was bei nicht hart echtzeitfähigen Systemen eher Probleme macht denn löst. Deshalb werden industrielle Lösungen meist auf einem gesonderten Echtzeitsystem aufgesetzt, der PC macht dann nur das GUI.

Viel Erfolg!

Gruß, Volker.

a

Hi Oliver,

das ist zumindest f=FCr eine schnelle L=F6sung sicher sehr hilfreich f=FCr mich. Die Frage ist halt, ob es reicht, dass ich einfach den Kommunikationsthread mit high-priority laufen lasse. Ich muss das mal an einem einfachen Beispiel testen. Besten Dank bis dahin, Joachim

nd

d

da

Hallo nochmals, bevor ich mich jetzt intensiver mit der Regelung auseinandersetze versuche ich gerade WinXP eine Pseudo Echtzeitf=E4higkeit zu entlocken. Aktuell habe ich folgenden Testcode verwendet:

#include #include "windows.h"

int main () { //mal schnell den Timer checken const int count =3D 64; LARGE_INTEGER f,last,cur; timeBeginPeriod(1); QueryPerformanceFrequency(&f);

QueryPerformanceCounter(&last); for (int n=3D0; n

jimbo schrieb:

Hallo,

gleich nach dem Starten wird der Rechner halt immer noch einiges vom Booten ausführen. Das lässt sich doch ganz einfach durch ein sleep(50) vor Beginn der Schleife beheben.

Bye

ch

Naja, ob das die Erkl=E4rung ist!! Schlie=DFlich ist die CPU ja nicht zu

100% ausgelastet sondern nur zu ca. 10%. Komischerweise ist es auch im laufenden Betrieb so,dass zumindest der erste Wert von den anderen abweicht. Keine Ahnung warum!!

Viele Gr=FC=DFe,

Joachim

jimbo schrieb:

Hallo,

dann sind es halt Sytemaktivitäten die beim Start des Programms noch notwendig sind.

Bye

Hmm,

dann m=FCsste ich irgendwie sicherstellen, dass mein Programm auch auf Systempriorit=E4t l=E4uft und das ist wohl nicht m=F6glich (bef=FCrchte ich)= . Denn was mache ich sonst wenn auf einmal w=E4hrend dem Betrieb meiner Maschinen genau sowas auftritt und die Zeiten dann nicht stimmen :(

Danke auf alle F=E4lle,

Joachim

jimbo schrieb:

Klar ist das möglich. Das willst du aber nicht. Du könntest dir freilich eine VXD basteln (Code im Ring 0), in der du die Interrupts sperrst. Prima. Hast du die Maschine für dich alleine. Allerdings hebelst du so halt auch den Scheduler aus - alles hängt. Besser kein so untaugliches System verwenden, deine Idee mit RTAI war doch gar nicht schlecht.

Viele Grüße, Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen."     -     Wolfgang Gerber
       in de.sci.electronics

Johannes Bauer schrieb:

USB ist ja auch echtzeittauglich. Irgendwie kann das also ein Windoof-Treiber hinkriegen.

Ich nix programmieren Win - Henry

--
www.ehydra.dyndns.info

Na das halte ich für ein Gerücht.

Gruß Henning

Hi Joachim,

[...]

Das ist in der Tat merkwürdig, denn laut MSDN wartet Sleep() MINDESTENS die eingestellte Zeit ab. Ich habe auch noch nie beobachtet, dass es weniger Zeit braucht. Ich habe übrigens mit VS2008 und dem C++Builder 5 das Verhalten Deines Programmes nicht nachvollziehen können (auf 'nem E6600 unter XP). Bei mir sind alle Werte recht gleichmäßig... Womit kompilierst Du denn? Ansonsten kannst Du aber auch die Priorität Deines Programms noch hochsetzen mit:

if(!SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL)) { printf("Failed to set priority (%d)\n", GetLastError()); }

Gruß, Oliver

Der Transport auf dem USB ! Also vermutlich mit FIFOs an Rechtzeitigkeit von Windoof angekoppelt.

Linux ist natürlich besser. Nicht das ich das vergesse zu erwähnen.

- Henry

--
www.ehydra.dyndns.info