Discussion :

[pascalCH]

comme promis, une architecture "tout premier jet" :



c'est la projection dans le logiciel à l'identique de l'existant :

le notion "Exclusif" dans ElementCommutables correspond à une règle de sécurité qui sera exploitée ultérieurement (la sole ne doit pas être active en même temps que la voute) et généralisée à tous les éléments constitutifs du four (exemple : pas de buée si l'éclairage est allumé - contrainte inexistante pour le moment ).

le schéma sous entend que la propriété Actif sera le reflet de l'état de l'élément physqiue correspondant.

J'attends vos remarques et questions.

ps: sans faire de bruit, je vous emmene sur une méthode de conception "xTrem programming", mais c'est comme ça qu'on avance ..

[GillesM57330]

Oui tout à fait pascalCH

Il s'agit de recréer le système de régulation sur un four .

Et par la suite je pense de refaire un système de régulation pour chambre de fermentation controlée, qui comprend une commande sur résistance de chauffe, et commande de groupe froid selon un processus délimitée dans le temps.

Ex 5 H en froid à 5 degrés, puis mise en route des résistances de chauffe pendant 3 H, avec une hygrométrie controlée.

C'est un peu prés tout ce que nous avons à automatiser en boulangerie, il peut exister des matériel nécessitant une commande sur moteur pas à pas, ce que l'on appelle une balancelle automatique, mais je n'en suis encore pas là..

Pour le reste il existe un application purement "bureautique" de gestion des matière premières et contrôle des produits fabriqué et vendus que je pense mettre en place avec un tableur de type Open Office.

Je suis sincèrement ravi que vous preniez mon projet en considération, je m'inquiétai un peu, n'ayant que fait du C++ à titre amateur, et serai attentif à vos suggestions, encore merci.

Ce four est assez ancien, le système d’arrêt d'urgence n'y est certainement pas installé, je vais voir ce point avec l’électricien avec qui je travaille sur ce projet.

Certes oui , je pense ne pas utiliser Microsoft, pour gérer ce système, et certainement utiliser un Linux en mode console, pour minimiser les risques.
Sur ce point il serait aisé d'avoir les deux versions, en mode console, et en mode graphique développé avec QT. et de tester.

Gilles

[ternel]

Si tu prévois deux versions, en général, il faut concevoir le système comme une bibliothèque que tu utilises dans les deux programmes.

Comme c'est un peu galère, tu peux procéder avec la version tricheur:
Tu code le premier programme en mettant tout ce qui serait la bibliothèque dans un sous-dossier.
Puis tu codes le second programme en ajoutant ce dossier dans la compilation (option -I de gcc, et en prenant les .o au passage)

Concrètement, ca équivaut (presque) à une bibliothèque statique

[GillesM57330]

Si Pascal CH, quand l'éclairage est alumé, on doit pouvoir mettre de la vapeur.

Mais je ne pensais pas intégrer le système de vapeur dans ce programme, je pense refaire le système de vapeur à l'existant, et fonctionner en commande manuelle

Dans le cas d'une gestion complète du four, particulièrement la vapeur , l’interfaçage du programme demanderait une application graphique, ou la présance physique d'une commande, via un bouton poussoir qui renverrait l'information au programme,
" la vapeur doit être gérée très rapidement"

L’application prendrait alors une dimension "supérieure ", chose que je conçoit aisément mettre en place.

[pascalCH]

Si tu prévois deux versions, en général, il faut concevoir le système comme une bibliothèque que tu utilises dans les deux programmes.

Comme c'est un peu galère, tu peux procéder avec la version tricheur:
Tu code le premier programme en mettant tout ce qui serait la bibliothèque dans un sous-dossier.
Puis tu codes le second programme en ajoutant ce dossier dans la compilation (option -I de gcc, et en prenant les .o au passage)

Concrètement, ca équivaut (presque) à une bibliothèque statique

100 % d'accord avec toi ! on est dans l'informatique industrielle et pas dans la gestion et recompiler le tout en fonction des infrastructures techniques est un choix souvent retenu, les "services", "dll" et autres sont souvent difficile à gérer dans des environnements un peu étriqués.

@GillesM57330 :

Je pense (à l'instant) à un truc, avez vous pensé à prendre un stagiaire pour vous épauler sur ce projet ?

[pascalCH]

Si Pascal CH, quand l'éclairage est alumé, on doit pouvoir mettre de la vapeur.

Mais je ne pensais pas intégrer le système de vapeur dans ce programme, je pense refaire le système de vapeur à l'existant, et fonctionner en commande manuelle

Dans le cas d'une gestion complète du four, particulièrement la vapeur , l’interfaçage du programme demanderait une application graphique, ou la présance physique d'une commande, via un bouton poussoir qui renverrait l'information au programme,
" la vapeur doit être gérée très rapidement"

L’application prendrait alors une dimension "supérieure ", chose que je conçoit aisément mettre en place.

l'exemple de vapeur vs eclairage n'etait qu'un exemple farfelu

étant assez copain avec mon boulanger préféré j'ai été surpris de voir qu'il avait une station météo sur le toit et qu'il modifiait ses programmes de cuissons (surtout pour les pains spéciaux) en fonction de la T° extérieure mais surtout l'humidité ambiante et qu'il pestait justement contre le fabriquant du four incapable de mettre un système de compensation automatique, comme quoi, vous tenez un filon !!

Pour ce qui est de l'application, on va s'atteler maintenant à la cinématique, je pense que la notion de "programmes" (au sens boulangerie) est un bon axe, chaque programme modélisant un cycle particulier (mise en chauffe, maintient de t°, programme de cuisson, pyrolyse ?, etc ...)
Dit autrement, après s'être inquiété de la modélisation du physique, on va s'occuper du modèle dynamique.

[GillesM57330]

Voici une photo du type de four que je m’apprête à réguler,

La flèche indique ou se trouve la commande de la vapeur, pour que vous vous fassiez une idée,.
Le boulanger appuie sur la vapeur,, enfourne avec le tapis, et remet un coup de vapeur, c'est selon, il y a des fois ou on en rajoute pas.

Le cycle de la vapeur ne fait pas partie du processus automatisé, il reste en commande manuelle.

[GillesM57330]

La température de cuisson est un secret professionnel en boulangerie, c'est elle qui détermine beaucoup de chose, en gros plus on cuit chaud, mieux c'est pour les baguettes,
Mais j'ai mis dans le programme la température à laquelle je cuit, c'est 260 Degrés au MINIMUM, en dessous le pain sèche, et sa conservation en prends un coup. Pour les masses plus compacte gros pains et spéciaux, c'est de l'ordre de 245 Degrés.

La règle c'est que quand le temps est humide on sèche légèrement plus, c'est à dire que l'on cuit moins chaud, le pain reste plus longtemps dans le four, on fait des cuisson à 22 Min au lieux de 20 Min par exemple.

Mais là nous sortons du C++ lol

[ternel]

Au contraire, on est dans le C++ dans ce qu'il a de mieux: une vraie utilisation concrète.

[pascalCH]

Au contraire, on est dans le C++ dans ce qu'il a de mieux: une vraie utilisation concrète.

Pour une fois qu'on a un sujet vraiment intéressant, on ne va pas se priver !! lol !!
parce que ce logiciel, qu'il soit en c++ java pascal c# cobol (non, là je rigole), il va faire quoi ?
reproduire méthodiquement les gestes et décisions du boulanger (le premier qui dit que le soft va pétrir la pâte et enfourner les baguettes prend 2 heures de colle ! )
la seule différence avec le boulanger, c'est qu'il (le logiciel) va être un petit esclave servile qui va permettre au boulanger (le vrai) d'être moins sous stress.
rien qu'une fonction à la noix : allumer le pré chauffage en automatique 1/2 heure avant la première cuisson, ben c'est 1/2 heure de sommeil de gagnée !

donc je reviens sur le logiciel : parler de "programmes" n'est peut etre pas le plus pertinent, peut etre que la notion de "Cycle" est plus adaptée ?

ps : intéressante la photo, il y a un écran devant la gueule du four, donc un échange thermique lors de l'enfournage, il fait plus chaud au fond qu'en façade, négligeable ? il y a une ventilation pour répartir la chaleur ? ( je dis ça parce que dans le four de cuisine, sur le poisson par exemple, il y avait un réel écart de cuisson entre la partie avant et la partie arrière, mais les temps de cuissons étaient mesurés à 10 secondes près et les T° au degré près).

oui, je sais , je suis chiant, mais comme le dit si bien leternel la question la plus idiote est celle que l'on ne pose pas

[ternel]

Pour le vocabulaire, je pense qu'on peut parler de script, de la même façon qu'on parle d'ennemi scripté dans un jeu.

[GillesM57330]

@PascalCH
J'en suis au stade du projet , je récupère un local en location ou un four est présent, seulement les thermostat régulateur n'y sont plus, et le système de temporisation alternant les régulateurs est à refaire, bref j'ai un devis à 8000 € établi par un professionnel,

Quand j'ai parlé de gérer la régulation du four avec un PC au " réparateur professionnel classique sur matériel de boulangerie ",
il a stoppé tout, m'a dit que lui ne faisait pas ce genre de travail, bref avec lui c'est tout ou rien.
Si vous voulez je vous envoie le devis. il comprend des éléments techniques.

Je me suis orienté vers un électricien industriel qui travaille en auto entrepreneur.

Il a accepté l'idée, mais lui également s’interroge sur la gestion par PC du four, d'autant que des régulateurs multi étages industriel sont disponibles pour pas excessivement cher.

Il existe un groupe de chambres de fermentation controlée en place, je dois voir si les platines de commandes fonctionnent, si le système de commande est HS, je dois réguler la fermentation controlée au moins cher, soit un accès USB PC

C'est pour ceci que je reste dans un schéma commande par PC, un platine de commande pour chambre de fermentation est hyper cher , et cela reste de l’électronique embarquée très fragile.
Les modules USB, sont particulièrement pratique, il permettent d'éloigner au maximum l’électronique du lieu de production

Tout ceci amène à l’interfaçage est à l'utilisation de bibliothèque QT, pour une création d'une application graphique, ou un système en mode console avec un minimum de graphique .

Un chambre de fermentation est un système critique qui ne peut pas planter, donc je me méfie assez d'un système graphique, sur la machine de commande.

Il faudrait faire tourner un serveur qui enverrait des info sur une plate forme de commande.


Retour à l'apli
Les modules Yocto, fonctionnent par une fonction Pulse
http://www.yoctopuce.com/FR/products...to-maxicoupler


Voici la réponse à une question que j'ai posé à la maison mère au sujet de leur produit

Je comprends bien le sens de votre requête.
Bien que nous utilisions en général des exemples "ludiques" pour illustrer les utilisations de nos produits dans notre blog, l'essentiel de notre clientèle est professionnelle.

Les bricoleurs du dimanche ne seraient pas un marché suffisant pour notre survie...

Nos produits sont robustes, mais comme toute utilisation connectée à des appareils présentant des risques physiques, il faut aussi prendre soin de les piloter par des méthodes robustes.

A titre d'exemple, lorsque vous pilotez votre four avec un relais,plutôt que de commander les changements d'état du relais (ON/OFF),
il vaut mieux utiliser la fonction "pulse" qui permet de demander au relais de commuter pour une durée prédéterminée (quitte à reprogrammer un pulse avant la fin du précédent).

Ainsi, en cas de plantage de l'application de commande, le four s'éteindra quand même.

Prenez aussi soin d'utiliser une machine de contrôle fiable, et non un board de développement "sans garantie" tel qu'un Raspberry Pi.

Ce qui se passe c'est qu'il existe d'autre producteur de ce type de produit, et le programme doit être capable de gérer rapidement, un replacement de type de module de sortie, en gros passer de ça : http://www.yoctopuce.com/FR/products...to-maxicoupler à ça : http://www.conrad.fr/ce/fr/product/3...s-relais-1-pcs
sans une re-compilation trop importante , mais je ne pense pas que ce soit possible "

Je reste dans les schéma de faire tourner ce four en mode console en C++, rapidement.

Mais je me demande si cette application ne devrait pas être au final directement être au final écrite en ligne de commande dans le shell et renvoyer tout vers un application C++ sur une machine externe.

C'est un serveur que je dois mettre en place, finalement.

[GillesM57330]

Oui mais non, parce-que si le serveur plante j'ai plus rien, donc c'est une application multi plate forme qu'il me faut...

[GillesM57330]

On sait plus où placer le noyau logique, sur un raspberry à 30 €, une tablette à 80 €, un PC serveur 250 €

[GillesM57330]

Sur le point de l'éloignement de la partie électronique de la chaleur, " le nerf de la guerre" c'est les module Thermocouple USB, http://www.yoctopuce.com/FR/products...o-thermocouple
Il sont en plusieurs parties selon le schéma:
Thermocouple > Module USB Le module USB peut être lui même séparé en deux.

Sur de l'existant les bloc thermostatique sont à coté des portes, et supportent la chaleur qui est limitée.

Je pense pouvoir aisément concevoir un système de fixation des modules sans danger, pouvant même m'extraire du schéma en façade, en piquant directement les thermocouple sur le coté, récupérant la longueur de celui ci pour éloigner les modules.

[white_tentacle]

Si tu prévois deux versions, en général, il faut concevoir le système comme une bibliothèque que tu utilises dans les deux programmes.

Ou alors, tu fais carrément deux processus séparés, ce que je recommande plutôt dans le cas présent. Avec un mécanisme d’IPC au milieu (dbus si on est en local, des sockets / soap / jsonrpc si on a besoin d’une transparence réseau). Le premier process contient l’intelligence et la régulation, sans interface aucun. Ensuite, tu peux fournir comme deuxième processus une interface en ligne de commande, une interface Qt, une interface web, etc.

Le principal avantage des processus séparés, c’est la robustesse : on réduit le code « critique » (régul du four, etc), et donc on réduit les risques qu’il plante / freeze etc. Par contre, ça demande un peu de boulot en plus.

[GillesM57330]

Sur le point du <chrono> , la fonction n'est pas intégrée dans mon compilateur gcc, ni dans ma version de QT.
J'ai réussi à la mettre sur Code Bock, mais Code Block, me "désempare" il recompile des truc non modifié.

Bref, je reste avec QT, et avec la fonction Time qui est une fonction Unix, Mais je pense devoir quand même l'intégrer pour gérer les modules, je verrai.

Je me soucie donc maintenant des relais, et de leur utilisation intensive, prés de 500 (pulse) changement d'état par jour de fonctionnement, j'ai envoyé un message dans ce sens à la maison mère Yocto.

Je clôture ce post version 2, en présenterai certainement un version 3 incluant les appel de fonction des modules, et la gestion erreur
Selon le manuel http://www.yoctopuce.com/FR/products...sermanual.html

Sur le point de l'algorithme, je pense qu'il est définitif ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
#include <QCoreApplication>
#include <unistd.h>   /* sleep() */
#include <iostream>
#include <time.h>
 
 
using namespace std;
 
 
int temperatureHaut ();  //-- Saisie de la Température sur Sonde du Haut
int temperatureBas ();    //-- Saisie de la Température sur Sonde du bas
 
int PulseBas (); //-- Fonction Pulse sur relais résistance haut
int PulseHaut (); //-- Fonction Pulse sur relais résistance bas
 
 
class Four
 
 {
     private:
          int consigneHaut;
          int consigneBas;
          int temps;
          time_t  depart;
 
     public:
          Four(int,int,int,time_t );
 
         void allumageminute ();
 
 
 
 
                                                                 };
// ----------  constructeur
 
 Four::Four(int regulHaut, int regulBas, int min, time_t  heure)
 
 {
           consigneHaut = regulHaut;
           consigneBas = regulBas;
           temps = min;
           depart = heure;
 
 
                                                          }
 
 
 
// -------- Fonction minutée
 
void Four::allumageminute()
 
{
      int a;
 
        sleep(1);
 
          time_t start;
          time (&start);
 
          a = difftime (start,depart);
 
 
    while ( a < temps)
 
 
{
      int ctr;
      int ctre;
 
 
            time (&start);
            a = difftime (start,depart);
 
 
            if ((temperatureHaut ()< ( consigneHaut)- 0.5 ) || (temperatureBas()< (consigneBas)- 0.5) )
 
                         PulseHaut() ;
                          cout<<"HAUT EN CHAUFFE";
                          cout <<  endl ;
 
 
                                for (ctr = 0; ctr < 3; ctr++)
 
                                    {
                                          sleep(2);
 
                                             if (temperatureHaut ()> consigneHaut)
 
                                                break;
                                                                                           }
 
 
                          PulseHaut() ;
                          cout <<  endl ;
 
 
                            PulseBas() ;
                           cout<<"BAS EN CHAUFFE";
                           cout <<  endl ;
 
                                for (ctre = 0; ctre < 3; ctre++)
 
                                   {
                                          sleep(3);
 
                                           if (temperatureBas()> consigneBas)
 
                                             break;
                                                                                            }
 
 
                                    PulseBas() ;
                                    cout <<  endl ;
 
 
                                                                                                         }
 
 
 
 
                                                                                                                               }
// --------------------------------------------------------------------------------------------------------------------------------------
 
int main()
 
         {
 
 
int dife;
    time_t temps;
 
       struct tm date;
 
       time(&temps);
 
       date=*localtime(&temps);
 cout <<  asctime(&date);
 cout<< "Il est:" << date.tm_hour << " H "<< date.tm_min << " Min " <<  date.tm_sec << " Sec ";
 cout <<  endl ;
 
 
             time_t a;
 
             struct tm as;
              time(&a);
                as = *localtime(&a);
 
 
             Four Baguettes(260,260,30,a); // (Températue demadée Haut,Température demandée Bas, temps de chauffe,"heure départ")
 
 
 
 
                      Baguettes.allumageminute();
                                cout <<  endl ;
 
                 time_t b;
                  struct tm bs;
                      time(&b);
                        bs = *localtime(&b);
 
                      cout<< " Il est :" << bs.tm_hour << " H "<< bs.tm_min << " Min " <<  bs.tm_sec << " Sec ";
                                                                                             cout <<  endl ;
 
 
                      dife = difftime (b,a);
 
                            cout<<"Vous avez cuit du pain pendant " << dife << " Secondes, ça sufit comme ça ";
                                                                                          cout <<  endl ;
 
                                                                                                                }
 
// --------Fin Main
 
 
 int temperatureHaut ()
          {
                 int a = 10;
                  return a;
                                 }
 
 
 
 int temperatureBas ()
      {
                  int a = 12;
                  return a;
                                    }
 
 
 
int PulseHaut ()
{
    int a  = 1;
  cout<<"Haut en Pulse" ;
     cout <<  endl ;
     return 1;
                               }
 
 
 
 
int PulseBas ()
{
  cout<<"Bas en Pulse" ;
   cout <<  endl ;
 
                             }

[GillesM57330]

Sur le point du système, je pense qu'au final, il faut trois points de commande possible.

1 PC
1 Tablette
1 Rasberry

1 PC en multi boot, avec un système double,
Un Linux mode graphique, avec les accès en mode graphique , et une version serveur qui envoie les info à une tablette.
La version serveur serait le mode normal

1 Tablette avec un aces au serveur en mode client normal.
Et posséder sur la tablette un programme capable d'interagir directement avec les modules et se passer du serveur.

1 Un Rapsberry configuré en secours.

Avec ce schéma, je pense être" sécurisé", pour pas trop cher.

[white_tentacle]

Sur le point du <chrono> , la fonction n'est pas intégrée dans mon compilateur gcc, ni dans ma version de Qt

Normalement <chrono> n’a rien à voir avec Qt : il fait partie de la lib standard. En revanche, pour ce qui concerne gcc, il est vraisemblable qu’il requiert l’option « --std=c++11 » pour que <chrono> soit disponible (et s’il ne supporte pas c++11, c’est mort…).

[ternel]

Sauf à utiliser boost, qui propose entre autre boost::chrono, identique (ou presque, je n'ai pas vérifié)