No I had not seen that update. I will update it. Thanks!!
Update:
Here’s a graph from a test I ran today with Heat PID Kp=0.5
It seems a bit better but I’ve noticed two main issues.
- The filter response time is around 20-30 minutes even though the setting was 3 minutes for this test. I feel this is a bug?
- The moment the filtered temperature drops below setting, the Heat PWM goes a little wild. It completely ignored my Maximum constraint of value 10. And it also cycles itself too many times although this is probably due to the filter not responding. But strangely it did not behave the same way in the beginning as you can see in the graph.
Additionally I would like to point out that there seems to be a problem with the PWM graphs. When I change the timespan for a PWM graph it does not work. It seems to be stuck at the default 10m. Changing this value does not seem to do anything even after refreshing, closing and opening Blox. Just an observation.
The PWM going over its constraints may be due to the interaction with the actuator constraints, specifically the minimum on time.
To confirm, add the PWM setting to the graph. If it’s markedly lower than the value, it’s likely caused by the minimum on time.
The filter response is indeed way too slow for a 3m setting. We’ll look into that.
Graphs settings not persisting for some blocks is a bug we found and fixed yesterday. The fix will be part of the next release. For now the workaround is to add the value to a standalone graph widget.
Got it. Thanks for clearing that up. I will try another test today and check the graphs tomorrow. I’d like to point out though that my actuator constraints are:
Fridge Cool Actuator:
Min On Time: 3m
Min Off Time: 5m
Fridge Heat Actuator
No constraints except Mutex.
Mutex Hold Time is 5m or 10m. Not sure will double check. But not more.
On the spark page, can you go to actions -> export blocks and share the file?
I’m trying to run a test here with the same settings to reproduce the behavior.
I was able to reproduce some of the behavior:
-
With the filter set to 3m, I get a blocky PID input. It raises much faster than a 3m fluctuation.
It is supposed to filter out fluctuations of 3 minutes or less. But after about 3 minutes it detects that it is not a fluctuation but a raising value and resets the filter. -
With the filter set 30 seconds and a threshold of 5 it is a lot better. Try with the threshold at 20 first to disable the reset behavior and a filter period of 30 seconds.
-
My threshold on the PWM seems to work just fine.
If you share your blocks, I’ll try your exact settings with a water cooker.
This is my water test. You really want the filter reset not to trigger on normal ramps.
I’ll have a look at adding a filter faster than 30s.
1 Like
Thanks for looking into this. Attaching my blocks that I used for the most recent test.
I will be running a new test now with your suggested settings.
Let me know what you observe. Thanks!
brewblox-blocks-spark-one.json (5.4 KB)
Updated to the hotfix. Running a test now with Filter settings at threshold 20C and 30s. Heat PWM still seems to ignore my max constraints. Let me know if you see the same effect with my settings.
Will post results tomorrow. Thank you so much.
The value displayed is the desired setting. We’ll update how it is displayed so it is clear. The PWM achieved value should be around the maximum constraint.
Yes I figured that, but from my graphs it is evident that the achieved value goes as high as 30% even with the constraint value set to 10. I hope this is how you set it? Anyways I guess it will be evident to you from my exported blocks.
Also, just curious, could you explain why for Filter settings I should start with a threshold of 20C and not smaller like 5C? Does this mean that within a 30s timespan it will ignore any fluctuations of 20C magnitude?
The filter averages values. So at the 30s setting, it introduces a 30s delay.
The threshold is an early detection mechanism to bypass the filter when the temperature changes a lot. This should not trigger during normal control, only for example when you put the sensor in a different bucket.
I think you should also set Ti to 10 minutes. If you have the behavior stable enough but have some overshoot, you can try a small time constant for Td, like 30s.
About the constraint not working, what is the setting of the PWM? Do you also see it exceeding the constraint?
About to head out for the day but this is the graph so far. It does seem like the filter is responding much faster. Any thoughts or changes I can do before I leave for the evening?
The PWM value exceeding the limit might be just a glitch of how we calculate it based on past toggle times. I agree it is a bit confusing and will probably add a simple filter in firmware.
Here is another graph with more Heat PWM metrics added. Meanwhile I will try with Ti = 10mins but I will leave Td as default for now?
Looks like it stopped heating around 18:08, but there is a large lag still, mostly in the filter causing it to overshoot.
I suspect that the controller is not updating every second and is overloaded for some reason. This might also explain why the output pin is sometimes on longer than needed.
Can you give me the output of this request?
https://[ip address here]/spark-one/objects/SystemTime
Sorry a bit confused, which IP address do I enter? I’m not too computer savvy 
Your pi’s address. Same address as the UI.
Really sorry but I dont know how to find it.
You are accessing the web interface. It is the same address, just something different after the slash.