16-Bit PID

[mytekcontrols]

I downloaded the PID program given on the Example page of the Matrix site, and would like to make it work for another application that has a 16-Bit DAC utilizing the 2 PWM outputs of a PIC16F877a. The example code shows a PID loop that updates a single PWM channel in 8-Bit mode, and references an 8-Bit setpoint.

Presently I have PWM1 assigned as the LSB and PWM2 as MSB, both in 8-Bit mode. These are then sent through a hardware conditioning circuit to derive a 16-Bit to Analog output. This part works great!

The setpoint would be a number between 0-6200, and the feedback would be in the same range, as taken from a watt transducer. Essentially I will be inputting a wattage via a keypad, and controlling a phase-fired proportional control module to send a given number of watts to a heating element.

I have all the logic and hardware in place to do this except I am missing a decent closed-loop control aspect in my flowcode. It would seem like the PID approach would be suitable, but I must admit to being very stupid when it comes to implementing this method. I was hoping either someone could help me understand how to modify the example code to work, or perhaps take a whole new approach.

Below is an image of the PID Macro given in the Matrix example program + some notes on what I wish to do.

PID.gif (26.68 KiB) Viewed 7582 times

[Benj]

Hello

Firstly you will need a scaling factor to convert your input control signal into a 16-bit signal. This then creates the correct amount of error to plug into the equasions.

16-bit = 0:65535

65536 possible values / 6200 = 10.57

Reducing this to 10 will simplify the calculations and give us a range of 0:62000 on the PWM output.

So the control signal will be multiplied by a factor of 10 to give the range of control with the 16-bit PWM output.

You will also need a way of converting the error input into a number equivalent to the output PWM. This will probably require calibration to get this correct. Essentially you want a value of 62000 or 6200 x 10 or 620 x 100 etc to equal your output power of 6200 Watts. A analogue voltage of 3.027V would give you a value of 620 when using the 10-bit internal ADCs ( (5V / 1024) x 620 ) . Therefore if you can produce an analogue voltage that is linear with the output Wattage and that gives approx 3.027V when the Wattage is at 6200W then you have the error signal sorted.

Alternativly you can manipulate the maths if the error voltage or output Wattage is not that controllable.

It is then quite easy to fit the PID equasion in using the current control signal, the current error and one or two orders of previous errors.

If you need the full PID equasion then I can dig it out for you but I think it is included with the original PID example.

[mytekcontrols]

Thanks for the quick reply and suggestions Ben. I will give it a try over the next couple of days and report back in on my results (or perhaps with more questions).

[mytekcontrols]

Opps! just found a potential problem with your suggestions. That is representing various signals in 16-Bit format. Flowcode only has signed integers, which means that anything over 32767 will cause an overflow (or is that considered underflow?), and be considered a negative number. So I think I'd be better off to leave the following in an unscaled format for the equations, in order to keep everything at the correct polarity so-to-speak:

Wattage feedback from the transducer (yes it is linear: 0-2.5V = 0-6250): 0-6200
I am not allowing the full range... leaving a 50 watt buffer zone. The wattage transducer is being read from an external 16-Bit ADC and the reading is stored as a flowcode integer called watts (As you can see, I am only using 13-Bits of the ADC's full resolution range).

Setpoint is entered from a keypad: 0-6200
Stored as a flowcode integer called setpoint

So PID_p = setpoint - watts will yield a number from 0 to 6200 which is easily represented within a signed 16-Bit integer, and without it overflowing.

Seems like scaling of the error will have to be done at the end where it will need to be translated into its LSB and MSB aspects to drive the 2 8-Bit PWM's. Unlike the ADC used to derive the wattage feedback signal, I am using the full 16-Bit resolution to span the control voltage driving the phase-fired proportional control module (Crydom). Although the there is a bit of play before turn-on and topping out.

Below I have attached a schematic of my Dual PWM 16-Bit DAC.

16-Bit_DAC.gif (8.08 KiB) Viewed 7533 times

Currently I do have a very crude non-PID control loop implemented in flowcode that is being updated at a 1ms rate. It does work to some extent, and did require a nested delay loop once the setpoint was approached in order to not over or under shoot too terribly. But it's acuuracy is only about +/- 8 watts. I would like to get this to be much tighter, so that is why I am very interested in replacing my control loop with a PID.

I figured that I could just stick with the existing 1ms update, but have it point to a PID macro instead of my crude code. The actual update speed from the watt transducer is much slower, being on the order of 1-2 seconds due to heavy filtering of its output. This slow response of course makes it a bit trickier to hold a constant value without overshooting or undershooting the target.

[mytekcontrols]

Hmm... I tried fiddling around with various approaches on modifying the PID to work with my application, but with dismal results. It was either way too touchy, had major over shoots, or just sat there and did nothing. I gave up, and have decided to take an approach that I can better understand and execute.

Thanks for the pointers Ben, but PID's are still out of my league.

What I am now doing; is to utilize an up-counter and a down-counter routine which plugs into both of the PWM channels. I then call one of these routines from the 1ms loop, based on which way the error is (if the setpoint<watts: use DOWN routine, if setpoint>watts: use UP routine, if setpoint = watts: do nothing). I also factor in the amount of error to determine if the correction is done every iteration, or bypassed "X" number of times (controlled acceleration based on distance from setpoint). So far it is working fairly well, but I still have some tweaking to do to get it to stop overshooting initially when the setpoint is achieved (it does catch itself and back-up, afterwards holding fairly steady at setpoint).

Using the ramp UP and DOWN counters, also insures a gentle, instead abrupt change in wattage being transferred to the heating elements. This should yield a longer life.

[Benj]

Hello

Sorry to hear youve given up on PID it can be a little tricky to implement correctly Ive certainly spent hours banging my head against walls over it.
Sounds like your current control method is working well though. A little overshoot is generally acceptable and is seen to be better then a slower responce time that doesnt overshoot at all.