??? 11/28/04 00:35 Read: times |
#82109 - in points... Responding to: ???'s previous message |
So, in points...
1) I'm assuming you know the theory behind the inner workings of PID. I mean the equations in numerical form (so you don't integrate over a hour of past data with each iteration, just multiply-and-add to get the new integral). If you don't, find them on the net. Check how you can read the 2) Either write or download library routines for basic float arithmetics. 3) For fixed time base best use timer interrupts for the loop. Using them write a simple P regulator, reading input, multiplying it then sending the result. That gets the bare bones to work - I/O tends to be a tricky part, clock stuff is easy but very prone to programmer mistakes. Before you start optimizations, check how much time it leaves after finishing work and before starting another iteration (just stick a simple 24bit counter at the end while waiting for the interrupt). The whole work shouldn't take more than 200-300 cycles unless you use RS232 to get/send the data or collect the data using very slow ADCs. Pay attention to make each task to finish its work in finite time - no deadlock-prone loops like JNB TI,$. If you're forced to wait for some event other than timer interrupt though (just like reading data from RS232), implement timeouts and generating/servicing exceptions if timeouts happen. Note sum of the timeouts plus all the rest shouldn't exceed your 20ms. 4) If the P regulator works as it's supposed to work, start modifying it - add I and D blocks, sum between them all, additional checks/limiters, other stuff you find in regular PIDs. Transforming equations into program is a pretty straightforward process. 5) Calculate PID parameters offline, apply them, test your system, if works as desired in all conditions, implement. As you noticed, part 3) (implementing the "generic" regulator) is probably the trickiest. Thing is it may take 200-300 cycles but these are pretty busy cycles, a lot of work not connected with regulation itself to do, and it's very error-prone. If you can apply -any- regulation to your device, getting to PID regulation from there is quite short and easy. Oh, of course getting to EFFICIENT PID regulation (that is getting the parameters right) is a bit longer but that's a different cup of tea, not really '51-related. |
Topic | Author | Date |
help about pid | 01/01/70 00:00 | |
Floating point? | 01/01/70 00:00 | |
Keil floating-point performance | 01/01/70 00:00 | |
Search the forum | 01/01/70 00:00 | |
Floating Point Vs Mixed point | 01/01/70 00:00 | |
You mean Fixed Point | 01/01/70 00:00 | |
Mixed not Fixed | 01/01/70 00:00 | |
Warnings about Floating Point | 01/01/70 00:00 | |
Shortcuts | 01/01/70 00:00 | |
Implied aka Fixed point | 01/01/70 00:00 | |
Another Shortcut | 01/01/70 00:00 | |
Answering the question | 01/01/70 00:00 | |
Autotunning? | 01/01/70 00:00 | |
PID Tricks and Tuning | 01/01/70 00:00 | |
Great Stuff ! | 01/01/70 00:00 | |
I followed your idea... | 01/01/70 00:00 | |
Another couple tricks | 01/01/70 00:00 | |
tests | 01/01/70 00:00 | |
limit cycle tuning![]() | 01/01/70 00:00 | |
PID to control a Peltier | 01/01/70 00:00 | |
An idea to try | 01/01/70 00:00 | |
very fast 20ms ??? | 01/01/70 00:00 | |
20.000, not 2000. | 01/01/70 00:00 | |
very fast 20ms ??? | 01/01/70 00:00 | |
in points... | 01/01/70 00:00 |