Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 409 views
  • Likes 5 likes
  • Comments 25 comments
Related
Recommended

PID temperature controller for the EasyL1105 MSPM0 board - Pt. 3: PWM

Jan Cumps
PID temperature controller for the EasyL1105 MSPM0 board - Pt. 3: PWM

  designed a development kit for the recent Texas Instruments MSPM0 microcontroller series. 
This 4 part blog series documents the steps to design a PID temperature controller. Part 3: add PWM to generate a PID controlled output.

image
(post that introduces the kit)

Goal of this 3nd post

not a goal of this post: have the PID regulation working 100%.

Set up PWM SysConfig

The code uses timer TIMG1, channel 0, to drive PA26. There's no interrupt involved. The duty cycle gets adjusted in the regulation loop.

At this point, I have set the PWM period count to 65535, in an attempt to have the output range identical (but 32768 offset) to the input. 

image

image

Code

note: this design doesn't regulate perfectly yet. At this point in the blog series, all modules are in place and they are tied to the PID. But finetuning PID parameters, input, output, ADC and PWM settings is for post 4.

void perform_pwm() {
    DL_TimerG_setCaptureCompareValue(PWM_0_INST, i32_Output_PID + 32768,
        DL_TIMER_CC_0_INDEX); // update ccr0 value  
}


int main(void) {
    SYSCFG_DL_init();

    // /* timer 5 interrupt ticks per second */ 
    // /* Enable Timer0 NVIC */
    NVIC_EnableIRQ(TIMER_0_INST_INT_IRQN);

    NVIC_EnableIRQ(ADC12_0_INST_INT_IRQN);
    gCheckADC = false;

	/* Initialize the parameters of PID */
	Initialize_PID_Parameter();

    /* Start PWM */
    DL_TimerG_startCounter(PWM_0_INST);

    /* Start Timer counting */
    DL_TimerG_startCounter(TIMER_0_INST);    

    while (1) {
        if (perform) {
            perform = false;
            DL_GPIO_setPins(GPIO_GRP_LEDS_PORT,
                GPIO_GRP_LEDS_PIN_LED_GREEN_PIN);

            perform_adc();
            
            perform_pid();

            perform_pwm();

            DL_GPIO_clearPins(GPIO_GRP_LEDS_PORT,
                GPIO_GRP_LEDS_PIN_LED_GREEN_PIN);
        }
    }
}


void perform_pid() {
    /* Execute PID control in every TM0 interrupt. */
    i32_Output_PID = PID(&PID_Var, i32_Target_Command, gAdcResult);
}

If you compare the perform_pid() with the one from the previous post, you 'll see that it now uses ADC as feedback, and output to drive the PWM.

Demo circuit

I used the same (random) low pass filter as in  MSP432 and TI-RTOS: PID Library Part 2 - Real World Example , to turn the PWM into a DC signal.

image

The filter sits between PWM out  (P26) and ADC in (PA25).

ccs project for EasyL1105: pid_EasyL1105_20251002_02.zip

Related posts

Parents

  • After a lot of tweaking, it's still not perfect, but I think acceptable.

    For the results in the chart below, I initially set a temperature of 70 degrees, and experimented with adding an aluminium thermal mass on top briefly to force the temperature down by a few degrees, and then removing it to see the response back to the set temperature.  I kept the mass on top at one stage (labeled Kept Mass), to see the temperature recover with the mass present too.

    Then, I reduced the set temperature by two degrees to 68 degC, then increased it back to 70 degrees, then set it to 150 degC, then again did the thermal mass test, then finally turned the set temperature down to 100 degC.

    From the chart, what can be determined is that there is overshoot, I struggled to tame that, and didn't succeed. The overshoot is usually under 1.5 degC, but under certain conditions (such as deliberately cooling the system by about 6-8 deg C by temporarily adding a thermal mass and then removing it), when it tries to recover, the overshoot can reach about 2.5 degC.

    The damping occurs reasonably well, the error is under 0.5 degC often within the first oscillation, before it dampens out. Maybe it would be better for the system to slowly approach the temperature so that it doesn't overshoot or undershoot at all.Or maybe I'm being too picky. Apparently 3D printer hot end control systems overshoot too, and even 5 degC is considered acceptable for that use-case.

    The undershoot shown in the chart below (when lowering the set temperature) is better than the overshoot; usually under 1 degC.

    The PID code is complicated now, it kicks in the 'I' portion only within a certain range for instance. I relied heavily on Chat GPT to handle that.

    In summary, although it functions, I'm sure performance could be improved a lot, by control system experts. But, for the actual end application (heating punches for leather), and probably a whole load of other applications, I think the current performance may be acceptable (it took an entire day of tests and tweaks to get it to this state: (

    I hope the control system doesn't have any unexpected behavior under certain conditions, but I'll find out over time, as it gets used. I need to move on to the PCB, to get the project into at least a usable state.

    image

  • in reply to shabaz

    for communication with the python software, it may be interesting to use TI's JSON lib for the MSPM0. 

    No added value if only sending two numbers one way. But if you'd like to send more - or more complex - data from the MSPM0, or if you want to send data/interface commands from Python to the MSPM0, then it's useful. Avoids the need to write a custom payload interpreter.

Comment
  • in reply to shabaz

    for communication with the python software, it may be interesting to use TI's JSON lib for the MSPM0. 

    No added value if only sending two numbers one way. But if you'd like to send more - or more complex - data from the MSPM0, or if you want to send data/interface commands from Python to the MSPM0, then it's useful. Avoids the need to write a custom payload interpreter.

Children
  • in reply to Jan Cumps

    Funnily enough, I used JSON for a similar thing a while back, I've not written a blog on it yet. I used JSON to send a whole variety of attributes values from the microcontroller (Pi Pico in that case) to the PC, and pull out particular attributes and send to particular charts (for instance, you may want occasional board temperature reports to go into a different chart than say a Voltage measurement. One major downside was that since JSON isn't traditionally streamed, a lot of JSON parsers are unhelpful if the complete content is not available, and so you either have the choice to wait till all the content arrives (and hard to know that! does one count braces for instance, or send non-standard character sequences), or start processing earlier with your own custom parser that accepts invalid partial content. I can't recall what I did on the Python end (currently traveling without PC). Although it functioned, my code could be improved a lot, but I have not really used that code much, since it turned out I was unlikely to require such rich functionality that can split to multiple charts. But I'm sure for a real solution, people may well have that need for debugging or performance monitoring more complex systems.

  • in reply to shabaz

    > a lot of JSON parsers are unhelpful if the complete content is not available, and so you either have the choice to wait till all the content arrives (and hard to know that! does one count braces for instance, or send non-standard character sequences),

    The one in the TI SDK acts whenever it gets a newline. 

  • in reply to Jan Cumps

    The handler:

    https://dev.ti.com/tirex/explore/node?node=A__ADJ0T9itsmRPt9nb8QQy9A__MSPM0-SDK__a3PaaoK__LATEST&placeholder=true

    It's called by UART rx interrupt for each byte received. It builds a buffer. 

    When a newline is detected, the handler sends the data to the JSON parser. If it's invalid json, or an attribute that we didn't register a callback for, the data is ignored. Else, the correct callback for that data point is called, with the string representation of the received data.

    Then, there are lib functions to retrieve bool, uint, ... that you can use in the callback to turn that into the data type you need.

    Example of registering a callback for a bool variable and a uint16

    // ...

extern volatile bool bEnableSwitch;
extern volatile _q qIncrement;

// ***** Application Callback Functions to Process data *****
void callback_boolEnable(char* string)
{
    // Example to receive a boolean
    bEnableSwitch = GUIComm_ReadBool(string);
}

void callback_QMathData(char* string)
{
    qIncrement = GUIComm_ReadUInt16(string);
}


const tGUI_RxCmd GUI_RXCommands[] = {
    {"bEnable", callback_boolEnable},
    {"u16Data", callback_QMathData},
};

int main() {

    // ...
    GUI_InitRxCmd(&GUI_RXCommands[0], (sizeof(GUI_RXCommands) / sizeof(GUI_RXCommands[0])));
    
    // ... 
}