Is there any chance that a sequence block may contain opcodes cross controllers? or must all opcodes stay within the domain of one controller?
Is this also the case for nested sequence blocks?
Sequences are limited to the same controller right now. I’m working on a mechanism to directly share sensor values between controllers. Maybe we can extend this to other values, but we’d have to look at it in detail.
What instructions did you have in mind for cross-controller use?
First of all my objective is to work towards some loadbalancing on the controllers as well as to create some chines walls between the brewprocesses.
Eg i have 3 cotrollers in one cabinet, one has 4 spark4 boards (main controller controlling HLT, mash tun, Brew kettle, pumps, ballvalves, HE etc); one has 2 spark4 boards (in support to the main board for controlling extra temp sensores and valves); one has 3 spark4 boards (focus on controlling the unitanks).
Being able to spread the components in a more balanced way over the 2 controllers is very welcome.
Beside sharing values among controllers it would be nice that the balancer and mutex could work cross controller as well.
Basically i’m looking for sharing values of DigAct, FastPWM, Setpoints and let them be part of a sequence block (opcodes from different controllers). It looks like being able to select cross controller channels as input parameters on a block could be a solution. The behaviour of non-local parameters could behave like an external parameter.
I’m not expert in this matter but something like “federated” data could be nice.
Nested cross controller SEQUENCE block is welcome also.
Last but not least, i’m really looking forward that we the new gpio module you will be able to create a 4-20mA input board. There’are so many sensors available on the market that it would create immediately a high added value for your software.
While we really like the potential of federated / cooperative controllers, we’re unlikely to go all-in on the concept, as it runs into a fundamental problem: we don’t expect the network to be reliable. It’s a pretty common use case for a hobby brewer to be operating out of his/her shed, basement, garage, or outdoor patio - none of which are renowned for their excellent wifi reception.
Any networked value is a use-at-own-risk proposition that has to be purely optional.
In the things you mention, there’s a sliding scale of how demanding they are to implement.
- Temperature settings and values only change slowly and gradually. These are very easy.
- Analog actuator (PWM, Fast PWM, Setpoint Driver) settings are a bit more strict, but still very doable.
- Digital actuator settings are getting problematic. For a PWM with a 1s period (its minimum), we’re already measuring digital on/off times in milliseconds.
- Mutexes have the same timing requirements as Digital Actuators, but are conditional on their peers. The impact if you get the timing wrong can be immediate and unforgiving.
The first two are very likely to be implemented. The last two are not impossible, but would require some fundamental design choices that are likely incompatible with our stated use cases. Alternately, they could be implemented using direct controller-to-controller cables, but there a lot of other items in our hardware pipeline.
Inputs are on our radar, with switch/push/press being implemented first.
“none of which are renowned for their excellent wifi reception.” → i understand the situation but times are changing, coverage is by far much better
“Any networked value is a use-at-own-risk proposition that has to be purely optional.” → that’s the point with plenty of solutions, everything is at own risk. This is just my point that i brought to have configurations cross controllers otherwise the control of the installation becomes pretty digital. Solutions of course is to double the full control system.
"* Digital actuator settings are getting problematic. For a PWM with a 1s period (its minimum), we’re already measuring digital on/off times in milliseconds.
- Mutexes have the same timing requirements as Digital Actuators, but are conditional on their peers. The impact if you get the timing wrong can be immediate and unforgiving." → i understand the challenge. A wired connection between the controllers would be a possible solution as the controller are in the same cainet. The more i have on both controllers a lot of free RJ11 slots available (i need less temp sensors and more GPIO outputs). So creating a croos cable connection between controllers could do the job.
Inputs are on our radar, with switch/push/press being implemented first. → by curiosity, what will those inputs do from a functional point of view? Will those also be analog inputs?
thks for your feedback
Absolutely. I’m personally also watching Thread. Mesh networking done right would be amazing for these use cases.
I strongly suspect we’ll apply ADC to it, with configurable scaling. Software-wise, we’ll likely add support for declaring units per control chain. The PID doesn’t much care, but we don’t want to pretend externally that all values are temperatures.
Hardware-wise, I have no clue, and will refrain from blowing speculative hot air =)
“I strongly suspect we’ll apply ADC to it, with configurable scaling. Software-wise, we’ll likely add support for declaring units per control chain. The PID doesn’t much care, but we don’t want to pretend externally that all values are temperatures.”
I’m already happy that you make some reflections on the use of ADC → personnaly my needs are rather in water control (volume measurement, flow measurement) if I may dream an inline plato sensor
Beside the above, in my installation i have a HERMS with temp sensor → having a control block to manage the impeller pump speed based on the max delta temp = HERMS OUT - HERMS IN would be nice as well. Or is this already possible a possible combination with the actual blocks?
I suspect this can be done using the Setpoint Driver block. It depends somewhat on exactly what behavior you have in mind.
There’s also the caveat that variable HERMS pump speed may not even be a good idea, if it makes the input for the MT PID more instable.
The basic idea was to to control the speed in such a way the the delta between HERMSin and HERMSout is maximum → at that point we have maximum heat transfer.
Through that i didn’t reflect yet on what the impact is of MashTemp/HLTtemp Setpoint driver; i thought it would not have an impact on it as the setpoint driver is purely temp driven
Any feedback is welcome
You’re heating a closed system: all energy is applied to the MT content as a whole once the liquids are mixed. Pumping very slowly to increase diff(in, out) will not meaningfully increase energy transfer, but it will increase the temperature gradient in the MT, making sensor values less representative.
I suspect you’ll also be creating a control loop that will generally oppose the MT PID. If the MT temp is too low, the PID increases BK temperature. When BK temperature is increased, the pump will speed up to get desired diff(in, out) again. If the PID is decreasing BK temp because MT is close to setpoint, the pump will slow down to increase diff.
I’m not confident predicting exactly how this will interact, but I’m not seeing the upside.
Thanks for sharing your thoughts. You have convinced me that this idea is not crucial.