Edge release 2019/07/10

[Trig]

Thanks Bob, do I re-run the update?

Ok all back to “normal”
Cheers!

[adempewolff]

This update is awesome. I’m not sure if I have time to migrate my existing dashboard over to the new arrangement, but I’ve been checking out all the new features through a dashboard created for my second chamber and there are so many new features that I had been hoping for.

Two questions:

First, can I have multiple dashboards and/or process views referring to the same widgets?

I’d like to have a master dashboard that shows the current state of both of my chambers (as well as the cold chamber that cold air comes from), then daughter dashboards for each of the chambers where I can have more detailed information for each process. My question is whether multiple dashboards (and process views) can link to the same widgets established for each process. I just want to make sure I’m not accidentally creating new conflicting widgets on the master page rather than linking to existing ones. Hopefully this description makes sense…

Second, will I need to worry about re-tuning my existing PIDs (which, to be fair, weren’t perfectly tuned in the first place) after this update? I know a number of changes were made to filtering and how Kp, Ti and Td are related to each other.

Thanks a ton for all this work. The active software development and rapid support alone make the price of the Spark 3 (and the wait for BrewBlox) completely worth it. The only downside is that all the work you two have done is now raising my expectations for a lot of the other software I use and I suspect I am setting myself up for disappointment!

[Bob_Steers]

Happy to hear you like the new features!

To answer your first question: you can have multiple widgets and process view parts linking to the same block on the controller. They behave like shortcuts: you can view and edit the block through them, but if you remove or copy the widget, you don’t change the block.
You can copy widgets through their action button (under Widget Actions).

The changes to filters are implemented in a way that leaves most people with sensible settings after the update. Depending on your setup, you may want to tune them further, but they shouldn’t be a cause for worry.

[adempewolff]

Thanks. I can already mock up a pretty decent overview dashboard:

The left and right chamber are a little inconsistent because the left is in active use and uses my own configuration while I’m using the right to try out the new default arrangement.

A couple questions/comments:

1. What is displayed for the PID block? It looks like output (but for the beer PID duty % doesn’t make much sense).
2. What is display for the PWM block? Is it target duty or achieved duty?
3. In the future will which value is displayed be configurable in the “edit settings” dialogue?
4. This is new variation of an old gripe of mine regarding how the mutex state is displayed, but why does the heating pin show a loading animation over the “on” side (as if it is waiting) when the target duty cycle for it is 0% and it will not turn on even once the mutex is released?

Thanks again for all the work on BrewBlox, it is starting to feel really polished and flexible!

[Bob_Steers]

The dashboard looks nice. At a guess, you’re using a setpoint driver in your left chamber?

In order:

1. The PID part displays the output (outputValue in graph)
2. The PWM part displays target duty (desiredSetting in graph).
3. Likely. We’re also still debating what value is most intuitive to display by default.
4. It’s displaying the loading animation when it wants to turn on. As with the mutex state, it doesn’t seem to be a display bug, but an issue with the PWM calculation.

[Elco]

The issue with the PWM/mutex behavior can be that you’re exactly at setpoint.
So the PWM heating value might varying between -0.5% and +0.5%.

If the cooler has a higher PWM value, the heater will never turn on, due to the minimum switch time in the mutex. It is a bit confusing. I’ll have to think about how to make the mutex behavior more intuitive.

Two independent PIDs for heating/cooling, only being kept in check by the mutex at digital pin level seems to work quite well, but has some downsides.
A mutex on a higher level (PIDs registers themselves instead of actuators) could take into account different scaling. Having a very different Kp for heating and cooling could have less effect.

I didn’t implement a single PID with a heater for positive and a cooler for negative values, because the heater and cooler cause a different system response and need other parameters.

[adempewolff]

Hmm. In the past I’m pretty sure I’ve noticed this while the heating PID output had been at 0.00 for a good deal of time, but could it be that it was actually 0.004 and that’s why it was in the mutex queue?

Functionally, the two PID and mutex setup has been working well for me in its current state. I just don’t like how the GUI presents visual cues about mutex queues with very low likelihoods of coming to fruition. Might it be possible to just only display all the GUI mutex visual cues if a target duty goes above a certain threshold for a certain period of time (ie. > 1% for at least 30 seconds)? I don’t really care if the actual mutex countdown starts earlier.