L’interface
Mon système utilise des boutons et des interrupteurs physiques pour certaines opérations de base : allumer des pompes ou sélectionner lequel des corps de chauffe est actif. Tout le reste passe par l’interface graphique.
Le logiciel affiché est grandement inspiré du design d’un de ceux que j’utilise chez Cybelec (l’entreprise ou je travaille). Je rappelle qu’on vends des commandes numériques pour presses plieuses, et que je suis en fait edsan train de réaliser une commande numérique pour le brassage de la bière. C’est finalement assez similaire…
Le Raspberry Pi (le micro ordinateur qui est intégré dans mon système) affiche donc le logiciel que j’ai écrit en C#. Ce même logiciel, en réaction à des actions sur l’interface envoie des ordres à l’Arduino (le microcontrolleur qui actionne/vérifie les entrées-sorties sur mon système) Les deux communiquent ensemble par liaison série.
L’interface graphique affichée est relativement épurée. On peut éditer des recettes, et les exécuter. Un mode manuel permet de prendre directement contrôle des éléments de chauffe ou des pompes. Et enfin d’autres menus permettent de voir l’état du système (software, hardware et électronique), de le configurer ou de le tester. La plupart des éléments d’interface sont fait pour être touché.
Deux principaux modes de travail sont disponibles (directement empruntés au monde des commandes numériques pour machines industrielles) :
- Le mode manuel qui permet de commander tous les éléments individuellement
- Le mode automatique qui exécute un programme de brassage bien défini, et évite donc de rentrer des valeurs à la main.
Le mode manuel est parfaitement fonctionnel pour exécuter un brassage de A à Z. On peut choisir d’activer ou de désactiver les pompes, et sélectionner les modes des deux corps de chauffe. On a aussi accès à un compte à rebours qui permet de faire sonner l’alarme au bout d’un certain temps. Et le tout en gardant un œil sur les 5 sondes de températures.
Vous allez me dire : « mais pourquoi un mode automatique ??? »
Tout simplement parce que mon objectif est d’intervenir le minimum sur le processus de brassage. Mon rêve serait de programmer la recette, d’appuyer sur Start, et de revenir 6 heures plus tard pour mettre les levures et fermer la cuve de fermentation. Mais, çà c’est l’objectif à moyen terme (cet été ??)…
Pour l’instant, je voudrais au moins pouvoir programmer par exemple :
- Atteindre 55°C, faire sonner l’alarme (pour m’indiquer de transférer l’eau et le grain, puis de brancher les tuyaux correctement pour le brassage).
- Commencer à brasser en actionnant les deux pompes et en exécutant ces palier de températures:
- 20 minutes à 55°C
- 20 minutes à 62°C
- 30 minutes à 68°C
- 10 minutes à 74°C
- Puis sonner l’alarme pour m’indiquer de faire la phase de rinçage.
- etc.
Avoir un mode automatique permet donc de réaliser les paliers sans mon intervention. En mode manuel, il me faudrait choisir la température, programmer l’alarme, puis une fois que celle-ci sonne, il me faudrait alors revenir programmer la température suivante et le compte à rebours.
J’ai identifié 6 phases principales, et chacune aura son menu :
- La phase de remplissage de la cuve d’eau chaude avec de l’eau (froide) qui vient du robinet (quelques minutes)
- Le préchauffage de l’eau chaude dans cette même cuve (quelques minutes)
- Le transfert d’une partie de l’eau chaude dans la cuve de brassage (quelques minutes)
- Le brassage à proprement parler (de une à deux heures)
- Le rinçage des drêches (les restes des grains de malt qui doivent être lavés avec de l’eau très chaude pour en extraire le reste des sucre). Cette phase est lente et réalise le transfert du moût depuis la cuve de brassage vers la cuve d’ébullition.(de une à deux heures)
- Et enfin l’ébullition (de une à deux heures)
Actuellement l’interface graphique du mode automatique n’est pas encore complètement finalisée, mais en voici une ébauche pour la phase 2 et la phase 3:
Il me faudra encore quelques heures de travail pour finaliser cela correctement.
Le contrôle
Le contrôle est assuré par l’Arduino. Ce dernier est programmé en C++. Je ne vais pas rentrer trop dans les détails d’architecture logicielle, mais je vais tout de même présenter les aspects « régulation ». La régulation c’est par exemple, « faire chauffer » ou non le corps de chauffe pour maintenir une température mesurée par une sonde.
Un des avantages de programmer moi-même l’Arduino, c’est que je peux vraiment faire ce que je veux avec. Un Arduino ne coûte que quelques sous (5 environ), et me permet de remplacer trois éléments (2 PID + Chrono) dont le prix est bien plus élevé. En plus c’est plus marrant et plus gratifiant.
Le PID pour les corps de chauffe
Le PID, dans un langage d’automaticien, c’est (pour faire simple) un bloc qui prends en entrée une valeur X et qui fait varier une sortie Y. En principe, les variations sur Y sont supposées influer sur X. Le but du PID est de s’assurer que X prenne la valeur que l’on souhaite qu’elle prenne (le X visé). Y’a plein d’applications possibles. Voici des exemples:
- Dans mon cas, le X, c’est la température de la cuve en °C (entre 10°C et 100°C), et le Y, c’est la puissance à appliquer sur le corps de chauffe en Watts (entre 0 W et 6000 W). Je souhaite que la cuve soit à une température précise X visé, et le PID se charge de trouver la puissance Y pour atteindre rapidement ou maintenir précisément cette température. Le PID va automatiquement prendre en considération la dissipation thermique.
- L’exemple historique se trouve dans la marine, et dans les auto-pilotes. Un bateau doit généralement maintenir un cap précisément (c’est le X visé). Une boussole lui fournir le X. Le PID calcule la position du gouvernail pour maintenir le cap sur X visé. Le PID va automatiquement prendre en considération le vent ou les courant qui font dévier le cap.
Trois paramètres (gains) influencent le PID :
- Le gain proportionnel P, qui prends l’erreur et calcule un Y. Dans mon cas, c’est 1 kW par dizième de degré. (Si la température mesurée est trop basse par rapport à celle visée de 0.3°C, on applique 3 kW sur le corps de chauffe)
- Le gain intégral I, qui prends en compte le cumul des erreurs précédentes et le multiplie par I, puis l’ajoute au résultat des calculs précédents. Son but est de maintenir une certaine puissance de maintien lorsque l’erreur est nulle.
- Enfin, le gain dérivé D, qui prends en compte la pente des erreurs précédentes. Son but est de tenir compte de la dynamique du système dans les phase ou l’on minimise cherche à atteindre une nouvelle température visée.
Le PID est principalement utilisé pour chauffer l’eau de la cuve d’eau chaude. Dans la cuve d’ébullition mes premiers tests ont montré que le manque de brassage d’eau faisait que la température n’était pas homogène au sein de la cuve. Donc réguler sur une température arbitraire n’aurait pas vraiment de sens. C’est pour cette raison que je contrôle la cuve d’ébullition directement en puissance, en appliquant directement la valeur qui maintient une ébullition constante et suffisante (autour de 4 kW selon mes premiers tests).
Les pompes
Je ne régule pas les pompes à proprement parler, vu que je ne vérifie pas la quantité de liquide pompé (ceci viendra plus tard). Par contre, mon système me permet de calculer le débit dans des situations courantes, comme par exemple le passage de l’eau depuis la marmite d’eau chaude vers la marmite de brassage. A terme je souhaite que les volumes soient automatiquement gérés et que je n’aie pas à les mesurer systématiquement.
Conclusion
C’est vraiment cette partie qui me distingue de tout ce que les autres ont fait. Et y’a encore beaucoup de place pour des améliorations. Mais on verra surement ce qu’il faut faire en priorité après un ou deux brassages…