Temperature Overshoot, PID Control and Filtering Help - Release 02/07/2019

#57

If you need a Kp of 0.2, it is probably best to get a lower power heater.

Also, change the PWM period to something larger than 10s, because 0.2% of 10 seconds is 0.02 seconds. A larger PWM period will work better, because then a small duty cycle will still be active long enough to spin up the fan.

Can you also give me the output of these two URLs so I can check your filter config?

https://brewpi/spark-one/objects/Ferment%20Fridge%20Setting

https://brewpi/spark-one/objects/Ferment%20Beer%20Setting

I still don’t understand why you would have such a long delay with a 30s filter.

#58

Yes that is a good idea. I’ll look into getting a smaller heater.
More observations: I timed the actuator for the heater with a stop watch and noted that it remains on for about 17-18s when Kp was at 0.5/c and heat actuator PWM duration was 10s. Isn’t this a fault? Shouldn’t the actuator pin remain on only for a max of 10s for 100% duty? Yet I’m seeing long duration on-times even with the duty at much less than 100% (maybe around 30%). How is this so?

Here are the outputs you requested. Just FYI, currently I had disabled control when taking the output. Let me know if it matters and I can run a new test and give you the output when it is running.

Fridge setting: {"id": "Ferment Fridge Setting", "nid": 102, "groups": [0], "type": "SetpointSensorPair", "data": {"settingEnabled": false, "filter": 0, "resetFilter": false, "value[degC]": 27.8125, "filterThreshold[delta_degC]": 5.0, "sensorId<TempSensorInterface>": "Ferment Fridge Sensor", "setting[degC]": null, "valueUnfiltered[degC]": 27.8125, "storedSetting[degC]": 35.0}}

Beer Setting
{"id": "Ferment Beer Setting", "nid": 103, "groups": [0], "type": "SetpointSensorPair", "data": {"filter": 3, "settingEnabled": false, "resetFilter": false, "value[degC]": null, "filterThreshold[delta_degC]": 1.0, "sensorId<TempSensorInterface>": "Ferment Beer Sensor", "setting[degC]": null, "valueUnfiltered[degC]": null, "storedSetting[degC]": 20.0}}

Here’s the graph from last night’s test at Kp=0.2
It seems to be a lot better but still needs tweaking I think. I have no idea why it went idle around 0300h. though. Any idea?

#59

Quick question:
I noticed that the Beer Setting and Beer Sensor Blocks are not connected to the Ferment Profile anymore. How do I set this up if I want to apply a temperature profile on my heated water (for testing) using the beer sensor in the water container and the fridge air temperature as the driver?

#60

I see that you beer setting still has the slower filter.

The profile can drive the fridge setting or beer setting when enabled. I would not do cascaded control with a dynamic fridge setting and setpoint driver yet. Just click the action to switch to beer constant and then enable the profile.

1 Like
#61

Some Observations : I’m noticing some real delays in the system as a whole.
I timed the actuator for the heater with a stop watch and noted that it remains on for about 17-18s when Kp was at 0.5/c and heat actuator PWM duration was 10s. Isn’t this a fault? Shouldn’t the actuator pin remain on only for a max of 10s for 100% duty? Yet I’m seeing long duration on-times even with the duty at much less than 100% (maybe around 30%). This seems strange.
Secondly, I timed the graph UI and it only updates every 20s. Is this normal?

Thirdly I noted the Heat PIN curve in the graph. It has 3 points per cycle as expected, one for zero, then 1 and then back to zero. There are no data points on this curve between the first zero and the on state and then between the on state and the last zero which could mean that the minimum time taken by an update is being represented by the Heat PIN cycle which is about 43 seconds. This seems quite slow to me because the actual stopwatch timer said 20s duration of the actuator on-off cycle but the graph shows that it took 43s. Isn’t the pin actuator just a binary 0 or 1?
I hope this makes sense.
I have a strong feeling that there is an overall slowness in the response time between the spark service and the hardware sensors/actuators and UI.

#62

I wasn’t using beer setting so far, just the fridge so I hadn’t changed the beer filter yet.

#63

You can time UI - service calls to check them being slow.

Open the dev window in your browser (ctrl + shift + i), and go the network tab. If you then make changes to a block, you should see new requests pop up to /spark-one/objects/(block name).

You can also export your current network tab as HAR. In Chrome you do this by right clicking the network tab window. Firefox has a button in the top right.

#64

If you look at the LED on the SSR, is it also toggling this slowly?

It does indeed seem that the control loop runs slowly, but I haven’t seen this anywhere else. What color and pattern is the LED of the spark?

Do the temperatures on the LCD display also update really slow?

If you unplug your heater, is it still slow? To test interference caused by it.

If you could take the spark to a place where you have WiFi, I would love to get remote access.

#65

That would not explain the PWM toggling to be slower than expected. But if the whole update loop on the Spark runs slow, that could also slow down service calls that communicate directly with the Spark.

#66

Yes this is correct. That is exactly how I noted the response time. By looking at the SSR LED.

If you can work with just the spark without the fridge and heater then yes on Monday I can take it to my place with WiFi.

I will check the response time without the heater connected.

The LED pattern on the spark - green but quick flashes with a time interval of perhaps 0.5s between flashes.

I didn’t note the response time of LCD display. Will do that and let you know.
Hope this helps.

#67

Do you need the SSRs for remote access testing? If it’s just the spark you need I can just take the spark and pi with me back home later on today where there’s WiFi.

#68

Green flashes means it is trying to connect to WiFi.
It should do this in the background, but it might not be working as it should.

I believe you are using USB, not WiFi, so try this erasing the WiFi settings to see if that makes a difference:

https://docs.particle.io/tutorials/device-os/led/photon/#wi-fi-network-reset

If that doesn’t help, yes please take it home without the SSR and heater and I’ll have a look.

#69

I did edit the config and set discovery=usb and also set the device to hardcoded serial number.
I’ll try what you suggested on Monday and hopefully will also be able to find some time to take it home for WiFi.
I’m going to be on vacation for a month after Monday so in any case I’ll return next month.

#70

The problem might be that it still continues to look for wifi, not that you are actually using it.

Wiping the WiFi credentials will stop it from trying to connect.

#71

That actually makes sense because even after I did change the config to usb, everytime I toggled the WiFi on my Pi to connect to my phone hotspot, Brewblox used to say that it lost connection to spark. I was wondering why that was happening.

I’m away from my setup so I have to wait till Monday to test this. Thank you!

#72

I have confirmed WiFi credentials not working to cause this behavior and found a fix.
Will be fixed in next release:

Clearing your WiFi credentials will also work in the meantime.

#73

Thanks for looking into this! That’s great to hear that you could confirm the root of the issue.
I went through the link you sent and only found a way to reset WiFi credentials by holding a setup button on the photon. Where is this button on the spark? Also, it only mentions resetting credentials, I’m assuming this is the same thing you asked me to do so I will try to do it today.

#74

Yes, for a spark V2, the buttons are under the holes in the bottom and require a small pin to press.

For a spark 3, they are on the side.

#75

I know you’re on holiday by now, but we have now released fixes for all the issues you had.

1 Like
#76

Yes I’m currently away from work but I’m glad it’s all addressed. Looking forward to it!
Thank you!