Search |
 |
|
 |
| Author |
Message |
|
|
 Posted: Oct 23, 2006 - 01:06 PM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
|
Quote:
Actually, it is very simple, I do this a lot. Just
insert code such as the following into your 10ms interrupt service, and you are off and running.
Hi Tom,
Thanks for your post, I am not 100% conversant with c syntax, so please bear with me on this score. As far as I can make out, every 10mSEC interrupt, I give the ramp counter a tick which starts from 500 to 3500 this totals 3000 ticks, which will result in a ramp time of 30 Secs, correct?
Also, there will be a 11 tick delay between 1st PID loop and back to the 1st PID loop, there will be a 100mSec delay from 1st PID loop and back to 1st PID loop, in other words, my software ramp will have chunks of dead time embedded in it.
Another reason for using a 12bit d/a, is to make the entire setup flexible whereby the output analogue ramp/relay board can be exchanged for 10(of) 4..20mA outputs, in which case the d/a's would be justified and valid. Next, 30 secs for ramp time is too long, I am shooting for 4 Secs, given an analogue ramp, this time can easily be changed by a simple trimmer pot or it can be brought under MPU control.Flexibility is the name of the game here.
Lee, where are you, can someone please give his cage a rattle for me? What does Lee think about Tom's software ramp arrangement?
Best Regards
Darren |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 05:59 PM |
|
Joined: Dec 01, 2003
Posts: 1841
|
|
Hi Darren,
Basically this is how my example works:
"htrmod" is the "ramp" timer, incrementing at a 10ms
rate from 0 to 100 (for example). This establishes
1 second pwm rate for the heaters and a 1% resolution
for the settings (0-100%). The "top" count setting
for htrmod was not shown, but in this example would
be 100.
"htr(x)pwm" are the setpoints for the heater duty
cycles. These would be updated as needed by your
pid calculations with values from 0-100 for minimum
to maximum heat.
At each 10ms interrupt, the pwm setpoints are compared
with the counter and the conditionals determinine if
it is time for any heaters to turn off.
Each time the timer is rolled over to zero, all heaters
are turned on. This of course happens within a single
interrupt service call, so essentially they all turn
on at the same time. All conditionals are also tested
every 10ms.
There are no undesired "dead" times or delays. Operation is the same as if you had a bank of
hardware pwm timers.
By choice of interrupt interval and "top" count,
any pwm frequency and precision you need can be set up. Duplicate the lines of code for as many heaters as you need to control.
Hope this explains it a little better.
Tom Pappano
Tulsa, Oklahoma |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 06:13 PM |
|
Joined: Sep 04, 2002
Posts: 13373
Location: Orlando Florida
|
|
| Still trying to figure out if 10 single channel temp controllers would be cheaper/better/simpler/more reliable than one 10 channel controller. If the AVR costs a couple bucks and the relay costs 10x that, then, there is no clear winner. If the 10 ch controller has some additional smarts, because all the channels can see what the others are doing (tightly coupled), and this is a unique feature, then you just need an AVR with enough cpu and io to run the 10 channels. I'd still like to know the specs for the PID performance... what is the acceptable overshoot, response time, etc. Would regular old proportional control be good enough? If you buy the Maxim thermocouple preamps, the AVR a/d can read the temperatures. Doesnt one of the newer AVRs have a 10 ch a/d? |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 07:12 PM |
|
Joined: Dec 01, 2003
Posts: 1841
|
|
|
Quote:
Still trying to figure out if 10 single channel temp controllers would be cheaper/better/simpler/more reliable than one 10 channel controller.
One advantage of a multi-channel unit is savings from
not having to duplicate the human interface.
Tom Pappano
Tulsa, Oklahoma |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 07:31 PM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
|
Quote:
what is the acceptable overshoot, response time, etc.
Hi Bob,
Thats for the end user to decide, If the end user understands PID and enters the correct P.I.D. parameters then he will get a critical damped system, if he has trouble understanding PID for a particular loop then option is open for auto tune, where the MPU will test the heaterband or whatever its regulating, and calculate the required PID parameters.
The AVR64/128 does have a 10bit a/d 8 channel with 6 16 bit pwm channels, if you read the previous posts, I've been drooling over them as I am using Atmels other 1/3 namely AT89C51ED2.
Best Regards
Darren |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 07:48 PM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
|
Quote:
"htrmod" is the "ramp" timer, incrementing at a 10ms
rate from 0 to 100 (for example). This establishes
1 second pwm rate for the heaters and a 1% resolution
for the settings (0-100%).
Hi Tom,
You are using 7 bit resolution against my twelve, also my proposed 10 PID loops are going to be totaly independent of one another, each having it's own set of PID parameters, end user defined.The only common to all 10 PID loops will be the ramp.Your relays are all turning on together and all turning off together, right?, in effect thats only one loop.
Best Regards
Darren |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 08:03 PM |
|
Joined: Dec 01, 2003
Posts: 1841
|
|
|
Quote:
Hi Tom,
You are using 7 bit resolution against my twelve, also my proposed 10 PID loops are going to be totaly independent of one another, each having it's own set of PID parameters, end user defined.The only common to all 10 PID loops will be the ramp.Your relays are all turning on together and all turning off together, right?, in effect thats only one loop.
Best Regards
Darren
All the heater pwm channels are independent, and drive
each heater with the duty cycle written into each
individual setpoint variable. The pwm resolution
is not (and need not be) related at all to the
resolution of the a/d subsystem. The code I have
shown just takes the "Pouts" from your pid function(s)
and converts them to pwm signals to turn the heaters
on and off. FWIW, you can make the pwm resolution
and rate anything you want, within reason.
I could show you how to do the whole thing, but
that is how I make my living 
Tom Pappano
Tulsa, Oklahoma |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 10:18 PM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
|
Quote:
The pwm resolution
is not (and need not be) related at all to the
resolution of the a/d subsystem
Hi Tom,
Yes, I agree that the pwm is not related to the bit field of the a/d system, but the output d/a data converter does set the pwm resolution, I am proposing 12 bits, but you are using 7 bits or 0..100%, dont you find this resolution a little low. For example and assuming your PID loops are working, if I place my scope probe on your pwm signal then surely the quantization would be apparent?(descreet sudden changes).
That said, I am highly pleased that you consider the single or multi PID a trade secret, great stuff!
I assure you, you are not the first, on this thread, to post such a remark. However, I have to grant you 5 stars for your shear honesty, well done!, clearly PID embedded in a MCU has some value assigned to it.All the more reason for me to continue...
Keep well
Darren |
|
|
| |
|
|
|
|
|
|
Posted: Oct 23, 2006 - 11:58 PM |
|
Joined: Dec 01, 2003
Posts: 1841
|
|
|
Quote:
I am proposing 12 bits, but you are using 7 bits or 0..100%, dont you find this resolution a little low.
Not at all. We are after all, talking about closed
loop control. The pid loop will modulate the heater
to produce whatever average power is needed. For an
example, one of my products has a sensor maintained
at 1450 DegF, and that temp is held within 0.5 degree,
even with substantial variation in thermal load as
the process runs. In any case, as I have shown above,
you can set the pwm resolution up to be anything you
want. If this is to be a new design, I would dump
the whole d/a/ramp generator/comparator scheme because
it gets you nothing that can't be accomplished in
software, with a much lower overall component count,
cost, and better reliability.
Tom Pappano
Tulsa, Oklahoma |
|
|
| |
|
|
|
|
|
|
Posted: Oct 24, 2006 - 12:37 AM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
|
Quote:
If this is to be a new design, I would dump
the whole d/a/ramp generator/comparator scheme because
it gets you nothing that can't be accomplished in
software, with a much lower overall component count,
cost, and better reliability.
Hi Tom,
It is a new design, that said, a few years back, I developed an analogue controller whereby the PID parameters where calculated and the components hard wired or soldered into the controller, as such, the PID parameters were fixed, anyhow the entire exercise was to test my own understanding of PID. After this, I could compare my own findings with those who claim to understand PID and write books on the subject and by this I'm sure you are aware of what I mean.
With regard to the software ramp, your idea sounds good and I am in total agreement with you in regards to the benefits attained under software.
Just one question, does your PID allow PID parameter alteration whilst it is on the fly or busy regulating?
Look forward to your reply and best regards
Darren |
|
|
| |
|
|
|
|
|
|
Posted: Oct 24, 2006 - 01:01 AM |
|
Joined: Dec 01, 2003
Posts: 1841
|
|
|
Quote:
Just one question, does your PID allow PID parameter alteration whilst it is on the fly or busy regulating?
Yes, I generally keep the setpoints and pid parameters
in arrays. This is so that one process can adjust
another, as some of my systems need this capability.
Tom Pappano
Tulsa, Oklahoma |
|
|
| |
|
|
|
|
|
|
Posted: Oct 24, 2006 - 02:18 AM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
|
Quote:
Yes, I generally keep the setpoints and pid parameters
in arrays.
Hi Tom,
Thanks for your reply, with regard to arrays, I was just checking earlier on if Bascom 8051 supports multi dimentional arrays and it appears only 1 dimentional arrays are supported, Oh well..., I guess I can live with that. I am going to have a rethink about your software ramp and pwm resolution... and do some more pacing in my workroom. Thanks for the info. Tom
Best Regards
Darren |
|
|
| |
|
|
|
|
|
|
Posted: Oct 24, 2006 - 02:40 AM |
|
Joined: Dec 01, 2003
Posts: 1841
|
|
You are welcome!
I use single dimension arrays, one for each parameter
with the number of elements corresponding to the
number of channels. I also put the pid formula
into a form that accepts a channel index value,
then when pid(n) is called, channel n gets updated.
The index is incremented, and pid() called from the
interrupt service.
Tom Pappano
Tulsa, Oklahoma |
|
|
| |
|
|
|
|
|
|
Posted: Oct 24, 2006 - 11:15 AM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
Hi Tom,
I thought maybe c supports multi dimentional arrays, that said, yep, your thinking is right on track with mine, Bascom supports (one Dim.)array index increment/decrement as I checked this a few days ago.
This is one heck of a friendly/quality forum that has substance.
Keep well Tom and Others
Darren |
|
|
| |
|
|
|
|
|
|
Posted: Oct 26, 2006 - 04:33 PM |
|
Joined: Nov 04, 2004
Posts: 51
Location: N.Wales U.K.
|
|
|
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
