Help making a event counter for beer fermentation

[Ben]

Hi CC,

you wrote

"And I would really appreciate some input/comments from other enthusiasts as well,"

Since you asked, here are my thoughts.

1) "What the he#$ it works!" So the rest of my comments can be ignored.

2) When I am just adding new readings to a set of prior readings, I will use a chart instead of a graph. The Chart is a lot smarter and efficient than a graph. Yes you loose the cursor option but that is not used in this example. I replaced your graphs with charts and tossed most of the shift registers.

3) Local variables are faster than property node >>> value so I switched over to locals.

4) Structure. I would have turned things inside out. Instead of using a user event that is triggered by the DAQ to update the display, I would have put that logic in the DAQ loop. Then I would have used a queue to pass a "reset" from the user loop to the DAQ loop. Flip a coin!

5) See point #1 above.

I hope this is what you were asking,

Ben

Re: Beer. I drank my life time quota before I was 25. We just do not get along well any more. My wife on the other hand always wanted to do home brewing and I live just south of Pittsburgh. "Library" is the end of the trolley line. Library BTW supplied the coal that was converted to coke to make the steal used durring WWII. So in a very convoluted way, my house looks out over the mine that helped save europe.

[trimixdiver]

Ben

Thanks! Im also a member of the PA trolley musuem. Ever been there?

[Ben]

Yes,

Its about 15 minutes from where I work in McMurray PA.

It has been along time. You had a "steet car named Desire" there if I rember correctly.

Please see Beer monitor2.VI in the llb I posted.

Sotrry,

Ben

[chilly_charly]

---

@Ben wrote:


...Since you asked, here are my thoughts.


1) "What the he#$ it works!" So the rest of my comments can be ignored.


2) When I am just adding new readings to a set of prior readings, I will use a chart instead of a graph. The Chart is a lot smarter and efficient than a graph. Yes you loose the cursor option but that is not used in this example. I replaced your graphs with charts and tossed most of the shift registers.


3) Local variables are faster than property node >>> value so I switched over to locals.


4) Structure. I would have turned things inside out. Instead of using a user event that is triggered by the DAQ to update the display, I would have put that logic in the DAQ loop. Then I would have used a queue to pass a "reset" from the user loop to the DAQ loop. Flip a coin!


5) See point #1 above.

---

Ben thanks for the comments. Good to have an external look.





1/I'm planning to develop this a bit further (personnal and professionnal interest : I teach fermentation technology to a gang of students that would better learn beer fermentation than baker's yeast production) so the point #1 can be ignored: even if it works, it has to evolve...





2/ I choose the graph because I want to be able to overlay reference fermentation curves over the running fermentation data. This will allows the detection of a problem at a glance. Otherwise you are perfectly right : with timed acquisitions a chart is enough...





3/ I hesitated, since I had the idea of combining most of the parameter management into a single sub-vi, passing the control refs to the sub. Of course globals could be fine also... Actually, the development version uses type-2 globals that have replaced all the shift registers.





4/ Have to think about... Do you think I could manage cleanly the overlayed curves ?

[chilly_charly]

Hi 3mix !

If you still feel that you are taking advantage of me, you can relax. This is going to become an independent project, used for teaching purpose. I'll even need your help to build progressivelly an home-brewing facility here ! You can start collecting ideas about what was great and what was wrong in your own setup..

I'm discovering that Ben and you are not far from each other. If you manage to share a beer, please don't forget the poor lonesome french LV programmer, far away from Detroit...

[Ben]

1/I'm planning to develop this a bit further (personnal and professionnal interest : I teach fermentation technology to a gang of students that would better learn beer fermentation than baker's yeast production) so the point #1 can be ignored: even if it works, it has to evolve...

Ah hah! I was guessing you were a PHD in in Chemical Eng, or Material Science, or Physics. Now I strongly suspect Chem E!





2/ I choose the graph because I want to be able to overlay reference fermentation curves over the running fermentation data. This will allows the detection of a problem at a glance. Otherwise you are perfectly right : with timed acquisitions a chart is enough...

If you have a multiplot chart using WDT's, the time stamps do not have to match up between the traces. You could plot 24 hours of expected data when the procces starts and on follow-up updates of the chart, make shre the "prediction" plot is all NaN (or was it an empty array?).





3/ I hesitated, since I had the idea of combining most of the parameter management into a single sub-vi, passing the control refs to the sub. Of course globals could be fine also... Actually, the development version uses type-2 globals that have replaced all the shift registers.

By moving the updates out of the user interface, you should be able to spawn off multiple fermenters as duplicates. Just let the UI start/stop/clear.





4/ Have to think about... Do you think I could manage cleanly the overlayed curves ?

See my previous. WDT and charts have the following restrictions;

1) If the oldest data point in a new data sets is older the the newest value already pltted FOR THAT PLOT the chart gets reset.

2) Changing the number of plots will reset the chart.

Have fun,

Ben

[chilly_charly]

---

Ben wrote:...Ah hah! I was guessing you were a PHD in in Chemical Eng, or Material Science, or Physics. Now I strongly suspect Chem E!

---

Add "Bio" before "Chem" and you'll get it. I got my PhD 25 years ago :(. Time is running...

[Ben]

I'm not far behind. CC.

Ben

[trimixdiver]

Chilly,

Let me know what you need and its yours.

BTW, Any way to do a burps per minute? Its just easier to look at this to get a idea of how slow its getting. The graph is great that you made and I want to keep it, but it has so much data that its hard to tell what the rate is.

Thanks

[trimixdiver]

Hey Chilly

Do you still want to continue with this? If so let me know. This might be featured in a brewing Magazine. So Id would like to get your info.

Thanks