Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

practical PID ASM 16F

Status
Not open for further replies.

Mosaic

Well-Known Member
Regarding asm code for PID, there seems to be a real lack of samples around that work.
I tried the basic PID eq. implementation, which, while simple, failed in my app.

Due to my unique probs. with my sensors being unable to deliver signals an order of magnitude below my error correcting signals I had severe oscillation issues to deal with.
Basically my smallest permissible sensor signal change (being 1 bit in an 8bit ADC) was enough to warrant a response in the PID control! Therefore I had a case for integer math.

What I had to do is to dismantle the purpose of the P, I & D segments of the equation, and rebuild their functions with integer math. The result gives good control but does some magic when it comes to applying gain factors.


16 bit math won't help with an 8 bit ADC signal that requires action from a 1 bit change.

I chose not to use full 10 bit ADC because of electrical noise coming from the remote sensor, (induced on a 6' wire run in an electrically noisy env.). I just dropped the 2 lsb from the 10bit ADC as potential noise.

In order to add artificial resolution when u can't get it by direct signal resolution is sampling changes over a longer time period. Basically summing or integrating over a longer time for more resolution.

BUT u only want resolution when u are near the setpoint, if u go for resolution across the whole spectrum the controller will take long to update even when there is a large error.

Therefore u must scale the sampling time dynamically. U need a DIFFERENT timer for this than the PWM.
When the rate of change of your error signal is large u speed the sampling, when it is a small rate of change u slow the sampling. I found a max sampling speed of about half the PWM period. Slowest sampling was about 2xPWM period.

I also found it useful to separate the +ve going correction from the -ve going correction. Particularly as I had an emphasis to prevent a +ve spike over the setpoint.

This allowed me to include additional measures to control overshoot. These measures included a minimum PWM compensation of 1/16th PWMperiod and a second order derivative of the error signal. This d2e/dt2 derivative helped with Phaselead compensation as it told the code WHEN the error changed direction back to the control setpoint AND the speed of that change, thus permitting accurate predictive correction near the setpoint line.

Notably regular PID does not use second order derivatives for this, just a first order one.

When I completely flowchart and comment the solution I can share it.
Here is a graph of the result though: **broken link removed**
**broken link removed**
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top