PID-filter routine (2nd try).

[HenrikOlsson]

Hi,
1) That is indeed an issue with the example code which went unobserved for a very long time, someone noticed it and mentioned it a couple of posts back in the thread. Unfortunately the forum doesn't allow me to fix it in the original post. Anyway, you are 100% right, if you're using the HPWM command then you should set the output clamp to 255. With that said the standard CCP module creating the PWM output can provide resolution of up to 10bits depending on frequency, you just can't "access" it using the HPWM command.

2) Sounds like a good start. Getting the tuning values right can be tricky, especially so on slow systems since it takes so damn long to see if you got it right or not. I expect this particular "plant" to be extra tricky due to the somewhat unrepeatable/unpredictable "performance" of a charcoal bed - I imagine.

One thing you might consider is to run the heater/fan/furnace whatever "open loop" until the temperature starts to approach the setpoint and only then switch on the PID. A more elegant but also a bit more complicated way is to create a ramping action in a way that the setpoint, instead of being bumped from ambient to "working temp" is ramped up at a rate that the "plant" can actually follow.

If you're concerned that a dutycycle of 0% won't provide enough oxygen to keep the fire alive then simply don't allow it to go below a certain value to keep the fan running at all times.

/Henrik.

[andywpg]

Hi,

One thing you might consider is to run the heater/fan/furnace whatever "open loop" until the temperature starts to approach the setpoint and only then switch on the PID. A more elegant but also a bit more complicated way is to create a ramping action in a way that the setpoint, instead of being bumped from ambient to "working temp" is ramped up at a rate that the "plant" can actually follow.

I had actually planned to run the fan in manual mode until I am near the setpoint, then allow the PID loop to take over in auto mode.

The other question I had is on the reset. In the example, it is set to .5. What causes the integral ramp to get steeper? Would that be an increase in the number? What kind of range of numbers are you expecting on the reset .1 to 1 or even higher than that?

BTW, while running it in simulation last night, I discovered that a derivative of 0 causes unpredictable results - to remove the derivative, you have to set it to 1.

In my reading and conversations with people who deal with PID (one of which was an instructor at a local community college) I am told that temperature control only requires process and integral, not derivative.

Thanks again,

Andy

[andywpg]

If anyone is interested, here is what I used to run the simulation (my controller has an LCD)

#CONFIG
 __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_OFF & _MCLRE_OFF & _LVP_OFF & _CP_OFF 
#ENDCONFIG

DEFINE OSC 8  'LETS PBP KNOW THE OSCILLATOR IS RUNNING AT 8MHz
DEFINE NO_CLEARWDT 1 'NO WATCHDOG TIMER - FOR NOW - WILL DO OUR OWN CLRWDT


OSCCON = %01110001 '8 MHz INTERNAL OSCILLATOR, INTERNAL OSCILLATOR IS USED FOR SYSTEM CLOCK


DISABLE 'NO PBP INTERRUPTS NO PBP DEBUG

' Set LCD Data port
DEFINE LCD_DREG PORTB
' Set starting Data bit (0 or 4) if 4-bit bus
DEFINE LCD_DBIT 0
' Set LCD Register Select port
DEFINE LCD_RSREG PORTB
' Set LCD Register Select bit
DEFINE LCD_RSBIT 4
' Set LCD Enable port
DEFINE LCD_EREG PORTB
' Set LCD Enable bit
DEFINE LCD_EBIT 5
' Set LCD bus size (4 or 8 bits)
DEFINE LCD_BITS 4
' Set number of lines on LCD
DEFINE LCD_LINES 2
' Set command delay time in us
DEFINE LCD_COMMANDUS 1500
' Set data delay time in us
DEFINE LCD_DATAUS 44



  '// Set up hardware registers, ADC etc here (not shown) //

  ADValue VAR WORD                     '<---This is your variable.
  SetPoint VAR WORD                    '<---This is your variable.
  COUNTER VAR BYTE
  RUN_IND VAR BYTE




  INCLUDE "incPID.pbp"                 'Include the PID routine.

    'These variables are declared by the incPID routine but
    'the user needs to assign values to them.
    pid_Kp = $0700                     'Set Kp to 7.0 GAIN
    pid_Ki = $0080                     'Set Ki to 0.5 RESET
    pid_Kd = $0001                     'Set Kd to 0 (Derivative not necessary)
    pid_Ti = 8                         'Update I-term every 8th call to PID
    pid_I_Clamp = 100                  'Clamp I-term to max ±100
    pid_Out_Clamp = 255                'Clamp the final output to 0 to 255
	Setpoint = 230		               '<---Set desired position.
	RUN_IND = 1

START:
   	FOR ADVALUE = 225 TO 235 'TEST A BUNCH OF VALUES
		FOR COUNTER = 1 TO 10
   			pid_Error = Setpoint - ADValue     'Calculate the error
			Gosub PID                          'Result returned in pid_Drive
   			if pid_Out.15 then pid_out = 0     'IF NEGATIVE THEN SHUT OFF FAN
   			pid_Out = ABS pid_Out              'Convert from two's comp. to absolute
'  			HPWM 1, pid_Out, 10000             'Set PWM output

			LCDOUT $FE, 1, "AD=", DEC ADVALUE, " PO=", SDEC PID_OUT
			LCDOUT $FE, $C0, "RUN #", DEC COUNTER, " SETP ", DEC SETPOINT
			Pause 1000                           'Wait....
		NEXT COUNTER
	NEXT ADVALUE
	IF RUN_IND = 1 THEN
		RUN_IND = 0 
		GOTO START 'DO IT AGAIN SO THAT ITS AS IF THE TEMPERATURE DROPPED 
	ENDIF
	LCDOUT $FE, 1, "DONE!"
	DO
	LOOP 'ENDLESS LOOP
	
END

[HenrikOlsson]

Hi,
I'm sure you're correct that you don't need derivative. I'm surprised though that you get unpredictable results when you set it to zero, I'll have to look into that. What exactly is it doing?
Anyway setting it to 1 is pretty close to 0 (1/256 to be precise.) So it shouldn't have any effect on the actual control loop in your case.

The PID_Ki isn't the "reset time" (at least I don't think it's comparable to that), it's the integral gain. To get more integral action (steeper ramp) you increase the gain.

Here's how it works, basically:
Each time you GOSUB PID the integral term takes the error and adds it to an accumulator. It then increments a counter and compares the counter value to PID_Ti, if the counter value is less than PID_Ti it's done. If the counter is equal to PID_Ti it takes the (value in the accumulator) * (integral gain/256) / PID_Ti, it then adds the result to the output and resets the accumulator as to not overflow it. I think you can compare the PID_Ti value to what's sometimes called "reset time". (It does a couple of other things as well but lets not go into that right now).

As to a range of values for the integral gain..... all I can say really is that it's usually a lot less than the proportional gain, which in turn is usually a lot less than the derivative gain (which you don't use here).

Hope it helps.
/Henrik.

[andywpg]

Hi,
I'm sure you're correct that you don't need derivative. I'm surprised though that you get unpredictable results when you set it to zero, I'll have to look into that. What exactly is it doing?

All this was observed using the code I posted above.

With the derivative set to one, and the loop at 216 (degrees) it usually starts with an output to the PWM of 150 or so. As the sample gets closer to the setpoint (230) it ramps down - as it should.

With derivative set to 0, the PWM starts at about 20, and goes down from there - I can't remember exactly where, but at some point (long before its at the setpoint) its at ZERO - with a charcoal fire, that means its never getting to the setpoint. Strangely enough, on the SECOND run through the numbers, it starts working properly - not sure why. Maybe its my fault.

It seems to work great with the derivative set to 1, though, acts exactly as it should.

Hope it helps.

Very much so. Now, if only this damn snow would go away........

Thanks again,

Andy