How to convert PID output into meaningful result to feed into controller

Not making much sense !

This doesn't look like all your code !

You would do much better to have it all in one place either on the PIC or the Beagle.

Steps of only 0 to 9 is quite possibly not fine enough control for a PID to work correctly.

Suppose you only need a power setting of 3.5 to get the correct pressure, the actual, setting will need to oscillate between 3 and 4, this can work but its not  PID.

Also, the ONLY valid way to scale the output of the Beagle controller is by linearly scaling it, in your case multiplying by 9/1e7.

No one ever uses a straight PID controller in real life, you always need extras like integral wind up limiting.

If you describe the system in more detail and post the Beagle code it will be possible to help you (why do you need a Beagle and a PIC), how does the heater work ?

I've got code for two controllers in mind, one I did for a heater which is linear and another for a fridge which is not.  But I'd need to know a lot more about you system before suggesting code.

MK

Michael has some good points.

However If you just want to convert the big number, you might try taking a logarithm. It could radically change performance of the PID loop and there still may not be enough resolution in the result. The D factor (error derivative feedback) in that loop can easily cause instability. Sorting out the implications might be tougher than programming a PID loop from scratch.

Chris,

This is a little complex, but not in a good way.  Unless you need the PIC for other things, why not drive the heating coil switch directly from the pocketbeagle?  If the PIC has some other useful function, and you need to drive the heating coil switch from it, why not skip the UART ans communicate the PID output via something like a PWM signal (having a much greater range than 10 discrete levels).  The PIC could read the PWM signal as an analog input (passed through a low pass filter to convert the PWM to a DC signal).  This could allow the PID loop to be a bit more continuous and eliminate the need for the limited range of control.

Best of luck!

Gene

Thanks you all, the reason I have PIC an pocketbeagle is because, PIC handles ZeroCross detection and creates software PWM according to the value supplied by pocketbeagle, which handles PID. I need to have USB,WiFI n LCD display and embedded webserver functionality that's why I chose poketbeagle and since it can't handle zero cross detection or any real time processing (unless I dive into PRU codes, which is a bit of a learning curve that I would want like to avoid at this stage), I moved the ZCD code to PIC. Unfortunately I can't post all the code here because it belongs to the company.

I fought with the PIC code for it to accept a string and then change that string to integer, I am doing the same at the moment but just for a single character instead of a string. If I can get a string and then itoa(str) then, I can have a bigger resolution instead of just 0 to 9  and that may solve the problem. For some reason the PIC halts or at least it stops activating the tirac used to switch coil. It always stops the coil and never gets stuck in ON position. Here is my PIC code.

#include <xc.h>
 #include <stdlib.h>
#include <math.h>
#include <stdint.h>
#include "main.h"
#include "UART.h"


// BEGIN CONFIG
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF       // Power-up Timer Enable bit (PWRT enabled)
#pragma config BOREN = ON       // Brown-out Reset Enable bit (BOR enabled)
#pragma config LVP = OFF        // Low-Voltage (Single-Supply) In-Circuit Serial Programming Enable bit (RB3 is digital I/O, HV on MCLR must be used for programming)
#pragma config CP = OFF         // Flash Program Memory Code Protection bit (Code protection off)
#pragma config FEXTOSC = OFF    // External Oscillator mode selection bits (Oscillator not enabled)
#pragma config RSTOSC = HFINT1  // Power-up default value for COSC bits (HFINTOSC (1MHz))
//END CONFIG
int i=0;
int my_delay = 10000;
int t, value=0;
char zc;
char result[2];
char foo, buffer[3] ; // 10(0x0D))
char counter=0; 


void interrupt ISR(void)
{
    if(INTF) // check if RA2/INT interrupt is triggered.
        INTF=0;
         GIE=0;
        zc = 1;
        if(INTEDG)
            INTEDG =0;
        else
            INTEDG =1;
        GIE =1;
}


setup(void)
{
    TRISA4 = 0; //Set as output 
    TRISAbits.TRISA2 =1;
    ANSELAbits.ANSA2 =0;
    INLVLAbits.INLVLA2 = 1;
    INTPPS = 0x02;
    INTE =1;
    INTF = 0;
    INTEDG = 1;
    
    zc = 0; 


    PEIE =1;
    GIE=1;          //Enable Global Interrupt
    
   delay_ms(500);
}


delay_ms(unsigned int ms)
{
    while(ms > 0)
    {
        __delay_ms(1);
        ms--;
    }
}
void delay_10us(unsigned int us_count)
 {
    while(us_count!=0)
      {
        for(int i=0;i<11;i++)
        {
         __delay_us(1)  ;
us_count--;
        }
   }
   }






ser_process()
{
   char str[8];
   {
   UART_Read_Text(str,8);
   delay_ms(200);
   UART_send_string(str);
    }


#if 0 
    if(RC1IF)
    {


   foo = UART_get_char();
   buffer[counter]=foo;
   counter++;
   if(foo==0x0D)
   {
   buffer[counter]=0x00; // remove 0x0D
   my_delay = atoi(buffer);
   if(my_delay>9) // make sure not to overshoot
       my_delay=9;
   UART_send_string(buffer);
   itoa(result,my_delay,10);
   
   for(int i=0;i<3;i++)
   {
       buffer[i] =0x00;
      
   }
    counter = 0;
   
   }
             }


#endif
            
}
void main(void) 
{
  
    OSCCON1bits.NDIV = 0; // necessary 
    OSCFRQbits.HFFRQ = 0b011; // 8MHz
    
    Initialize_UART();
    setup();
    my_delay = 1;


        while(1)
            
        {


#if 1
            while(zc==0);
            
            {     
            delay_ms(0);  //THIS IS WHERE THE VALUE FROM PID SHOULD GO
            RA4 = 1;
            }
            __delay_us(500);
            RA4 = 0;
            zc = 0; 
#endif


          ser_process();
    
    

        }


    
    return;
}

I played around with it and found that even if I try to receive individual characters, it can't handle more than than three characters and then it gets stuck, the code still responds to UART but the heating coil stays off. In the above code I have hard coded for it to stay on (delay_ms(0)), and still it goes off, and  this is where I would want to use __delay_us instead, to get higher resolution, so I can send inputs e.g 34587, instead of just 3. So the question is why above code would suddenly turn the heating coil off ? while continue to respond to UART. Thanks

I get the feeling you are new to all this embedded stuff.

My first bit of advice is that you should never leave an unexplained observation to fester.

You say that the triac turns on and then turns off unexpectedly. You need to know why.  You haven't posted a circuit so I can't help you work that out.

You need to get a scope on it ( EXTREME CAUTION - IF YOU ARE CONNECTED TO MAINS POWER).

Start with the simplest of PIC code that just switches the triac on for a 20 cycles and then off, get that working.

Your UART code doesn't work but you are calling  functions like UART_Read_Rext() which we can't see - are they any good.

Which of the many PIC processors are you using and which debugger. All modern PICs support hardware debugging - you need to use it to see what is going on.

If your system is mains powered then for development I very strongly suggest that you use low voltage  AC (like 24V) from  a transformer.

If you are not using opto coupled drivers (possibly with built in zero crossing detection) - why not - unless you are going to build many thousands of this thing it is a totally false economy to direct drive a mains switching triac.

Do you actually need cycle by cycle control or could you use integral cycle "pwm" - if your thermal time constant is long enough (greater than about 20 seconds) then you can - then you could use a nice, safe, ready made solid state switch.

Finally, a point of ethics, if you are working on a commercial project you should say so and give a little detail (like the area of business) - many people on E14 will still help you if this is your paid work, but might not wish to do so or may have ethical reservations about some areas of work.

Hope some of this helps.

MK

Thanks Michael, I am not new to this embedded stuff, I have about 10 years of experience in electronics and maintain an RTOS product as part of my full time work, what I am not good at is explaining things on forums.

Yes I  am using optocouplers to drive triac and yes I have tested it with basic code etc.

The UART works fine, that's why I didn't add the code for UART.

The PIC is 16F15323. I am using PID because that is client requirement -- so yes this is a commercial project.

Finally I figured out what is causing the problem, I still haven't figured out how to solve it. -- The problem is by the time UART finishes receiving three or more char, a zero cross interrupt had already occurred, so the TRIAC misses the opportunity to get triggered, I think it's just about resetting the trigger flag at the right place. -- a little break and a fine cup of tea, that's all I needed to see things more clearly.

Thanks everyone for the help.  

Chris,

In looking at your interrupt function:

void interrupt ISR(void)  
{  
    if(INTF) // check if RA2/INT interrupt is triggered.  
        INTF=0;  
         GIE=0;  
        zc = 1;  
        if(INTEDG)  
            INTEDG =0;  
        else  
            INTEDG =1;  
        GIE =1;  
} 

I am not sure if the initial 'if(INTF) is intended to qualify all of the remaining code, or if the indention is unintentional.  Without braces '{}' the only statement that is dependent on the 'if(INTF) statement is 'INTF=0', all the remaining statements are executed on any interrupt, which might be causing your code to set zc to one unexpectedly.

Not sure if this is part of your problem, or just me getting confused by the indention.

Good luck!

Gene