Home Brew Forums

Home Brew Forums (http://www.homebrewtalk.com/forum.php)
-   Automated Brewing Forum (http://www.homebrewtalk.com/f235/)
-   -   Standalone, Plug and Play Raspberry Pi Headless Brewstand Controller-Server (http://www.homebrewtalk.com/f235/standalone-plug-play-raspberry-pi-headless-brewstand-controller-server-368332/)

Yorg 11-21-2012 03:04 AM

1 Attachment(s)

If the UI is intended as a Web Page, then the only one I know, and know reasonably well is the BCS460.
The other UI I've seen a little of is the Brewtroller, but the rotary encoder and smallish LCD display is frankly a big reason to go Web UI in the first place, and I wonder if referencing such systems is all that good a use of time or particularly instructive - since the limitations of the interface drive the process/programming approach considerably.
I'm happy to do some more research though - see a couple of links at bottom.

I would add that the BCS 460's general approach is quite easily understood, and readily configurable to one's equipment. Essentially:
- In 'manual' mode:
A 'state' is specified by the user, and the system adjusts outputs to achieve the 'state'. See the table titled "Manual Mode" in the attached pic.
Using the row for Output1 in the picture as an example, you can see that the temp probe named 'HLT Temp' is associated with Output1 - which, you guessed it, is controlling the HLT. The control method assigned is simple on/off, which will be used to get the temp up to - in this case - 80, and maintain it there. (The control method could also be PWM - handy for throttling back a boil for example, or PID rather than just on/off.)
- Auto mode:
Simply a bunch of manual mode configurations ('states') that are strung together, using 'exit conditions' to specify when to move from one state to another. Exit conditions can be a physical switch, a web UI button, a target temp, or a timer.


(Why not just get one of these? I have on, but as I've mentioned it doesn't suit my needs basically because of cost and klunky UI.)

Here's something else I've found - note the link to the manual:
http://gryphonbrewing.com.au/product...roducts_id=512

Here's Kladue's (on this forum). Way more scope, but also an example of a user interface that I think is more complicated as a consequence - at least for what I'd be looking for:


Brewmagic - note the video.
https://brewmagic.com/brew-magic-v350ms-system

Yorg 11-22-2012 03:59 AM

3 Attachment(s)

I agree about getting something up and going and not going for the ultimate controller. But I'd like to say:
Having worked in a para-it role, interfacing between business and IT to develop solutions, I have learned the hard way to have a vision and functional architecture to work to. Without it, a project starts wandering about, gathering functionality, and making additions to functionality difficult because it invariably leads to:

"Gee, if we knew that, then we would have taken a different approach, and it would have been easy to add what you want, but with the current architecture it would mean a big re-program".
On this note I've attached a couple of interface drawings as suggestions - with due credit to the bcs guy for similarities in approach.

How about:
If we comment on these, and arrive at something agreed, mindful to keep it do-able and not going for the big bang, then it would give good direction for you technical types with respect to development approach.
?

So to also respond to your question about the bcs interface - as i've said before, it is clunky, and hopefully the drawings move toward a simpler approach.

Regarding the bit banging question - I think you should collect the complete hardware set and develop from there - especially if we have established that without it the R PI can be 'wonky'.

Re the power sharing - another benefit of the 'step' / state machine approach is that it is probably easier to program, as each state is discrete and allows a % to be allocated per Output for that step.

Kladue - your knowledge and results on a number of things I've seen on this forum are awesome. I'm not sure you have the time to do your own thing as well as contribute here, but with the talent circling this thread, including brewman, adding you would make a great team.

Let me know what you think of the 'step' / state machine approach and the interface itself as suggested in the attached drawings.

Cheers.

edit: clearly not a complete set of 'pages', but not many more would do it.
edit2: Damn, these have been shrunk by the forum upload to be illegible - anyone know how to make them loadable in native resolution?
edit 3: Should I do a video and youtube it, demonstrating the bcs approach live, so you know what I'm talking about better?


Yorg 11-22-2012 03:59 AM

3 Attachment(s)

I agree about getting something up and going and not going for the ultimate controller. But I'd like to say:
Having worked in a para-it role, interfacing between business and IT to develop solutions, I have learned the hard way to have a vision and functional architecture to work to. Without it, a project starts wandering about, gathering functionality, and making additions to functionality difficult because it invariably leads to:

"Gee, if we knew that, then we would have taken a different approach, and it would have been easy to add what you want, but with the current architecture it would mean a big re-program".
On this note I've attached a couple of interface drawings as suggestions - with due credit to the bcs guy for similarities in approach.

How about:
If we comment on these, and arrive at something agreed, mindful to keep it do-able and not going for the big bang, then it would give good direction for you technical types with respect to development approach.
?

So to also respond to your question about the bcs interface - as i've said before, it is clunky, and hopefully the drawings move toward a simpler approach.

Regarding the bit banging question - I think you should collect the complete hardware set and develop from there - especially if we have established that without it the R PI can be 'wonky'.

Re the power sharing - another benefit of the 'step' / state machine approach is that it is probably easier to program, as each state is discrete and allows a % to be allocated per Output for that step.

Kladue - your knowledge and results on a number of things I've seen on this forum are awesome. I'm not sure you have the time to do your own thing as well as contribute here, but with the talent circling this thread, including brewman, adding you would make a great team.

Let me know what you think of the 'step' / state machine approach and the interface itself as suggested in the attached drawings.

Cheers.

edit: clearly not a complete set of 'pages', but not many more would do it.
edit2: Damn, these have been shrunk by the forum upload to be illegible - anyone know how to make them loadable in native resolution?
edit 3: Should I do a video and youtube it, demonstrating the bcs approach live, so you know what I'm talking about better?


Yorg 11-22-2012 03:59 AM

3 Attachment(s)

I agree about getting something up and going and not going for the ultimate controller. But I'd like to say:
Having worked in a para-it role, interfacing between business and IT to develop solutions, I have learned the hard way to have a vision and functional architecture to work to. Without it, a project starts wandering about, gathering functionality, and making additions to functionality difficult because it invariably leads to:

"Gee, if we knew that, then we would have taken a different approach, and it would have been easy to add what you want, but with the current architecture it would mean a big re-program".
On this note I've attached a couple of interface drawings as suggestions - with due credit to the bcs guy for similarities in approach.

How about:
If we comment on these, and arrive at something agreed, mindful to keep it do-able and not going for the big bang, then it would give good direction for you technical types with respect to development approach.
?

So to also respond to your question about the bcs interface - as i've said before, it is clunky, and hopefully the drawings move toward a simpler approach.

Regarding the bit banging question - I think you should collect the complete hardware set and develop from there - especially if we have established that without it the R PI can be 'wonky'.

Re the power sharing - another benefit of the 'step' / state machine approach is that it is probably easier to program, as each state is discrete and allows a % to be allocated per Output for that step.

Kladue - your knowledge and results on a number of things I've seen on this forum are awesome. I'm not sure you have the time to do your own thing as well as contribute here, but with the talent circling this thread, including brewman, adding you would make a great team.

Let me know what you think of the 'step' / state machine approach and the interface itself as suggested in the attached drawings.

Cheers.

edit: clearly not a complete set of 'pages', but not many more would do it.
edit2: Damn, these have been shrunk by the forum upload to be illegible - anyone know how to make them loadable in native resolution?
edit 3: Should I do a video and youtube it, demonstrating the bcs approach live, so you know what I'm talking about better?



All times are GMT. The time now is 09:32 PM.

Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.