Cher Vincent,
Encore une fois, quel boulot ! très beau dessin, je kiffe
/Bruno

Bruno,
Merci pour les compliments mais ils ne s'adressent pas à moi, c'est Alan mon gendre et son frère Maël qui montent ce projet et les dessins sont d'Alan qui en plus d'être maraîcher est illustrateur ! Oui en effet, que de boulot ! Moi je ne suis là que pour leur donner un coup de main sur la partie frigorifique...

Benoît,
Je te transmets ce fichier, peut-il être une sulution envisageable ? Merci.

Vincent

Salut Vincent,
Comme je l'avais suggéré dans mon précédent message, pour ton projet la meilleur solution pour raccorder les automates Raspberry sur le poste de supervision serait d'utiliser le protocole modbus tcp/ip.
Cette solution présente de nombreux avantages:
> facilité de mise en œuvre, notamment par rapport à une mise en réseau en QCombus (réseau propriétaire à Proview),
> performance/fiabilité adaptées aux constantes de temps de ton process (régulations température/hygrométrie),
> protocole ouvert et standard permettant l'évolution du système (ajout de futurs automates Rasberry ou autres périphériques modbus).

Les automates Raspberry géreront l'acquisition des entrées/sorties logique+analogique + l'automatisme et la régulation.
Les synoptiques (xttgraph) seront hébergés dans la station opérateur uniquement et seront animés à partir des infos en provenance des Raspberry (via modbus).
Il sera également possible de réaliser une fonction d'historisation des variables à partir de la station opérateur, les données seront enregistrées sur base de données MySql (open source, logiciel à installer sur la station opérateur).
Si tu souhaites récupérer ces informations pour des applications de bureautique (gestion de prod, rapports,..), il sera souhaitable d'avoir un 2eme PC ''bureautique'' connecté en réseau local avec la station opérateur.
On pourra également envisager de raccorder sur le réseau local un modem ADSL (Livebox,...) pour l'envoi de mail d'alarmes (surveillance température haute des chambres froides par exemple).

Tu trouveras ci-joint un exemple de ce qui peut ce faire.
Il y aura donc 2 architectures réseau:
> ethernet tcp/ip pour le réseau local entre les stations (PC opérateur et éventuellement PC bureautique + modem ADSL)
> modbus tcp/ip pour le réseau entre les automates Raspberry et la station opérateur.

Dans le fichier joint tu trouveras un exemple de structure de configuration qui te donne un peu le principe de la prog des Raspberry.
Dans l'arborescence $Node on trouvera 2 parties:
> une arborescence pour la gestion des entrées/sorties (GPIO et 1wire pour l'analogique si nécessaire),
> une deuxième partie pour le serveur modbus avec la table d'échange que le client viendra lire ou écrire. Dans l'exemple je n'ai représenté uniquement des objets ChanDo et ChanAo, cela veut dire que le client (PC opérateur) ne peut dans ce cas que lire. Si on veut que le client puisse écrire dans cette table il faudra utiliser des objets ChanDi ou ChanAi (pour des valeurs de consignes par exemple). Mais le principe reste le même.

Du coté du $Plant, on retrouvera l'arborescence des variables (Di, Do, Ai) correspondantes connectées aux IO et à la table d'échange Modbus.
Ensuite dans le programme automate (Raspberry), on réalisera les recopies des IO vers la table modbus. Dans l'exemple la table modbus récupère à la fois l'état des entrées et la recopie d'état des sorties. On pourra bien sur avoir des infos qui viennent du client vers les serveurs (par exemple: BP marche, consigne température,...).

Concernant le choix du métériel, comme l'évoquait Bruno, il sera souhaitable de prévoir une station opérateur fiable comme par exemple un PC station de travail. Ce type de PC est effectivement plus cher qu'un PC bureautique classique mais une station de travail est généralement taillée pour fonctionner 24h/24 (pour exemple, au boulot j'avais une station de travail Dell comme PC de supervision qui a fonctionné 24h/24 pendant 6-7ans et elle fonctionne encore).

Ce que je te propose ici n'est qu'un exemple et devra bien sur être adapté à ton cahier des charges.
A+
/Ben

Super, merci beaucoup Ben ! Je me mets au travail...
Bonne journée,
Vincent

bonjour vous,

je suis un tout nouveau dans l'utilisation de proview j'ai bien suivie les tutos de benoit il sont superbe bravo à lui .
je me suis tourné vers ce thème (déploiement d'un système raspberry) car je voudrais apprendre à faire aussi des application basé sur des station raspberry avec proview, en utilisant ces ports GPIO. et comme la tradition le voudrais c'est allumer tout d'abord une led (blink).

mon soucis est donc dans un premier temps de pouvoir allumer une leb brancher sur une pin GPIO de mon Raspi 3 PB+ avec un programme fait sous proview mais en optant votre logique précédentes à savoir: système à plusieurs stations , une station Opérateur qui jouera aussi le rôle de station de développement et une station process (RASPI) pour gérer mes actionneurs et acquérir le signal à travers mes capteurs.

pour ce faire j'ai essayer de suivre votre exemple précédent à savoir
1- j'ai déjà déployer pwrrt 5.6.1-1 sur mon raspberry PI 3 B+; et le pwr V5.6 sur umbutu 18.04.1 LTS
2- j'ai déjà configurer les fichier host avec les adresses ip des 2 stations pour la communication comme expliqué dans le tuto (Multistation) de benoît.

maintenant je voudrais s'il vous plait que vous me donner la conduite à tenir.

Merci d'avance.

Bonjour j91 (?)

Tout nouveau: un conseil, il faut lire (ou relire) la doc et faire tout les exemples pour comprendre la philosophie de Prowiewr, c'est long mais ça vaut le coup.
Pour essayer d'aider les francophones, Ben et moi avons effectivement réalisé des tutos vidéo (présents sur le site), il est indispensable de s'en imprégner; c'est bien que tu les ai visionnés. Pour ma part, j'ai mis à mes débuts trois semaines avant de faire quelque chose de parfaitement fonctionnel.

Dans les tutos, je crois qu'on ne parle pas spécifiquement du GPIO, une info précise est donnée page 69 à www.proview.se/doc/en_us/man_iog.pdf sur ce site.
Tu attaques d'emblée avec une configuration multistations, ce qui n'est pas forcément le plus simple.

Bon courage
/Bruno