PWM setting and value mismatch

Troubleshooting
1

I’m new to BrewPI/Brewblox and I’m in the process of getting a fridge conversion and HLT, Boil kettle temperature control up and running. While working to tune the various PID loops I’ve noticed that there is a consistent mismatch between the PWM setting and PWM value when the PWM setting initially drops away from 100%. The PWM value drops very quickly to a value that is much lower than the PWM setting and remains there for a period of time that appears to be related in some way to the PID parameters. After this period of time has elapsed, the PWM value starts to closely track the PWM setting again.
The attached graph, which is for fridge heating, shows an example of the behavior I’m trying to describe. The same thing happening with the HLT and Boil kettle controllers.

graph (2)
graph (2)3000×1500 163 KB

I have a few questions:

  • Is this intended behavior? If it is, what is its purpose?
  • If it’s not intended, could it be having a negative impact on control loop performance?

Here’s a log file in case it’s of help:
https://termbin.com/hkkmw

Cheers,
John

2

PWMs and the Digital Actuators they drive have constraints: https://brewblox.netlify.com/user/all_blocks.html#analog-actuator-constraints.

Constraints typically act as safeguard, allowing you to do things like simultaneously use multiple heating elements that together draw more power than your fuses can handle. They also stabilize fermentation fridges by preventing the heater and cooler from rapidly alternating.

This does mean that there can be a temporary mismatch between the setting the PID wants, and the result that the constraints allow the PWM to deliver.

In the graph you posted, I’d say that the mutex is most likely the active constraint, but I’m not entirely sure. If you view the PWM/Digital Actuator blocks in the service page, they will show all constraints that are currently limiting.

To answer your questions: yes, this behavior is intentional, and yes, this will often negatively impact control loop performance.

3

Actually, I think this is a bug and I will look at it in more detail soon.

The PWM keeps a short history of when it toggled and uses that to calculate the actually achieved duty cycle. When it has a long history without toggles (for example due to constraints) the achieved value calculation is wrong. It is based on the past, but that very long pas has become irrelevant in the changed situation.

4

Thanks both for the quick replies.
It’s definitely not being caused by the direct action of constraints. There were none active and I’ve seen it happen with control chains that had no constraints configured at all.

@Elco, if there’s any further data or testing that would be helpful when you start looking into whether it’s a bug, let me know

5

From the spark page top right menu, export blocks

6

brewblox-blocks-spark-one.json (9.3 KB)