incPID Routine - Help Needed

[Aussie Barry]

OK, now I am a little confused....
You said that Setpoint now becomes pulses per interrupt period but how is this referenced to the ADCin result of my speed set trimpot?
Shouldn't the setpoint always be derived from the setting of the speed set trimpot and the error be calculated from the pulses per interrupt period?

Cheers
Barry
VK2XBP

[HenrikOlsson]

Yes, what I mean is that if you previously had your setpoint scaled directly in Hz it now needs to be scaled in pulses/interrupt period.

/H.

[Aussie Barry]

OK. Now I understand.
Setpoint was previously read via ACDin (0-1023).
ADValue was scaled in pulses per 100ms (approx 0-550)

In the new setup, variable NewCount (replacing ADValue) can range from 0-255 so I propose to convert the ADCin result from 10-bit to 8-bit
Setpoint = Setpoint>>2
so that the error term does not get too large and gain terms can be kept to a manageable size.

I will let you know how things pan out after tonight's round of experimants.

Cheers
Barry
VK2XBP

[Aussie Barry]

Things have been going too well for too long. A crach and burn situation was iminent!
Things started falling apart once I pieces everything together.

For starters, should I be able to use the serial LCD (debug statements) on RA5 with the DT-interrupts and counters on TMR0 and TMR1?
The LCD screen is completely garbled.

I have modified the circuit so that the three ADCin pots for Kp, Kd and Ki terms are on AN4, AN5 and AN6 and the encoder wheel pulse train is fed to M0CKI (pin 11). Circuit diagram is attached here incPID_16F684_V6.pdf

I am in the process of cleaning up the program (making the PID routine as an included file as per Henrik's suggestion). I will post the code soon.

In the mean time, any comments regarding the use of the serial LCD with DT-interrupts happening in the background would be greatly appreciated.

Cheers
Barry
VK2XBP

[HenrikOlsson]

Hi Barry,
I touched this issue in a previous reply. The command you're using to communicate with the display (DEBUG) is a bit-banged command, it relies on software timing to generate the correct baudrate. When you add interrupts to the mix the interrupt code will "steal" time from the rest of the program. So if a DEBUG statement is executing when the interrupt fires the timing WILL be off.

The usual cure to this problem is to use HSEROUT instead of DEBUG but that requires a PIC with an USART which the '684 doesn't have :-(
The easiest thing to try is probably to split the messages to the LCD up in several pieces and send them one by one. Or even write the message to an array and use DEBUG to send one byte at the time from that array, disabling/enabling the interrupt system between each byte.

Something like this perhaps:

ArrayWrite myString,[$FE,1,"P: ", #pid_Kp, " I: ", #pid_Ki", "D: ", #pid_Kd"

For i = 0 to 16  'Or how many chars to send
  @ INT_DISABLE TMR1_INT
  DEBUG myString[i]
  @ INT_ENABLE TMR1_INT
NEXT

Now, I very rarely use DEBUG so I'm not sure it can handle arrays like this but I think it should. The "best" approach would probably be to switch to a PIC with an USART though.

/Henrik.

[Aussie Barry]

Thanks Henrik.

I thought this might be the case but thought it would be better to confirm my thoughts before pulling out what's left of my hair...
I had considered changing PIC's after one of your previous posts - I have been looking at 16F1825. What do you think of this as an alternative?
I would value your recommendations on other alternates.

For the time being I will just eliminate all display functions and "fly blind". I should at least be able to get the PID routine working, something yet to be achieved since introducing the interrupts!

Cheers
Barry
VK2XBP

[Ioannis]

Why not 16F1827?

I used it and think is a little monster.

Ioannis