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?
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.
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?
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?
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.
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.
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.
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.
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.
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.
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!
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.
