Le sujet de ce billet porte donc sur la mise en œuvre d'un PLC à base de PI 3 comportant de plus un module GSM. Le but en étant l'application à un cas concret.
La première chose à faire consiste donc à commander et à recevoir un PLC de type S103-G de chez UniPi :
 |
| Fraichement arrivé! |
 |
| Fraichement déballé... |
 |
| Sera-t-il aussi performant que le n°007? |
 |
| Carte SD avec OS validé. |
Jusqu'ici, les opérations effectuées sont totalement triviales. A titre d'information, une version plus 'amateur' de ce concept peut être trouvé à cette adresse :
 |
| http://alltwincat.com/codesys/raspberry-pi-plc/ |
 |
| Avec en prime l'adresse MAC de la bête, afin de la configurer en statique dans le DHCP. |
Pour programmer ce type d'automates il existe plusieurs possibilités. A la limite, des scripts en Python pourraient 'suffire'. Je pense néanmoins qu'il est plus judicieux d'utiliser l'environnement de programmation Mervis fourni par le constructeur, et compatible avec la norme 61131-3. Il y a deux années de cela, j'ai eu l'occasion de programmer des automates à base de processeurs ARM qui utilisent cette norme de programmation et d'en constater la facilité de mise en oeuvre :
 |
| Configuration quelque peu artisanale, mais efficace! |
Mervis fonctionne de la même façon que la solution Codesys. A savoir un runtime temps réel implémenté sur l'automate qui exécute le programme édité et 'compilé' sur un IDE fonctionnant dans mon cas sous Windows. Pour implémenter une solution Mervis, il convient donc de télécharger et d'installer sur la SDcard de l'automate, l'image du système contenant le runtime Mervis. Une fois fait, un ssh à l'adresse IP du PLC permet de se connecter au système Linux embarqué de la même façon que cela fût le cas avec le système Linux 'standard'.
La ou cela devient intéressant, c'est qu'une fois le logiciel de développement installé sur le PC, il devient possible de se connecter, via ce logiciel, directement au Neuron S103-G. Il 'suffit pour cela de demander l'ajout d'un contrôleur :
Et d'attendre que la recherche automatique ait eu lieu pour que l'automate soit reconnu depuis le réseau, wifi dans mon cas :
Une fois l'automate sélectionné et cette fenêtre validée, l'IDE Mervis est en mesure de montrer les détails du PLC nouvellement détecté :
 |
| Et voilà! |
Pour l'instant le logiciel, bien qu'ayant reconnu le type d'automate en ligne, ne connait absolument rien des périphériques disponibles dans ce S103-G. Or, tous les périphériques sont accessibles VIA le protocole ModBus. Il est donc nécessaire de déclarer ce type de bus au sein de l'environnement de développement afin qu'il puisse converser normalement avec l'automate. Cela se faire de la façon suivante :
Puis dans le panneau propriété, de sélectionner le protocol ModBus. J'en ai aussi profité pour modifier le nom du 'channel' en l'appelant TcpModbus. A remarquer que cette liaison ModBus se fera sur le réseau Ethernet de la Pi3.
Ça n'est pas fini. Alors que le type d'automate a été déclaré précédemment, cette déclaration ne concerne pas la définition de ses périphériques qui demeurent encore inconnus par le logiciel de développement. Une procédure 'purement administrative' doit donc avoir lieu, qui consiste à déclarer tous les périphériques sous forme de variables utilisables dans les futurs programmes. Pour cela, il faut déclarer le type de 'device' attaché au bus ModBus, ce qui aura pour effet de générer les variables d'entrées/sorties associées :
 |
| Dans mon cas, il s'agit d'un modèle S10x. |
Dans l'onglet 'View' du logiciel, il est possible de demander le panneau 'Variables Browser', pour obtenir comme on peut s'en douter, le panneau avec toutes les variables déclarées :
On est presque au bout. Je vais faire clignoter la LED 01 de l'automate, matérialisée par la variable $Neuron S10x_ULED_1.01$ dans le fichier des variables globales générées lors des opérations précédentes dans la rubrique 'generated' du type de variables 'Globals' du programme que j'ai nommé 'Mervis-Test' dans la partie 'Executable projects' de mon premier projet 'Mervis-Test'. L'esprit humain adore la hiérarchie ;-) ...
Dans ce projet, j'ai donc créé un source principal nommé 'Main'. Pour un début, je n'ai pas cherché l'originalité. Cela se fait facilement de la façon suivante :
Dès lors, il est possible de commencer à rentrer du code dans la partie d'édition dédiée. Le code est extrêmement 'complexe' puisqu'il s'agit de faire clignoter une seule LED à une fréquence d'à peu près le Hertz :
PROGRAM Main
VAR
Delay : TON;
END_VAR
Delay(IN:=TRUE, PT:=T#1S);
IF NOT(Delay.Q) THEN
RETURN;
END_IF;
Delay(IN:=FALSE);
IF(hw.$Neuron S10x_ULED_1.01$ = FALSE) THEN
hw.$Neuron S10x_ULED_1.01$ := TRUE;
ELSE
hw.$Neuron S10x_ULED_1.01$ := FALSE;
END_IF;
END_PROGRAM
Je ne rentre pas dans les détails, notamment de la variable de type TON. Tout ce qui est écrit ici se trouve sur le Net. C'est l'avantage du langage à la norme 61131-3. Et pour plus de référence, il 'suffit' de rechercher les informations disponibles sur la toile avec le mot-clé Codesys puisque c'est l'entreprise de 'référence' en ce qui concerne ce langage. La compilation de ce source se passe sans problème.
Est-ce suffisant pour que cela fonctionne? Et bien NON!
Il est encore nécessaire de déclarer cette tâche au sein de l'automate en lui affectant un temps de fonctionnement. Il serait possible de discuter sur les raisons de cela, Il faut juste prendre conscience que sur un bus de type ModBus c'est toujours le Maître qui demande des 'choses'. Un périphériques ne peut JAMAIS interrompre un programme maître. Du coup, pour savoir ce qui se passe sur des entrées, par exemple, la seule solution consiste à faire du pooling sur l'entrée surveillée. C'est tout simplement cette notion de pooling, ou de fausse interruptions, qui est implémentée de la sorte de façon généralisée dans les automates. Cela reste évidemment extrêmement moins efficace que de la vraie gestion d'interruption processeur, mais c'est ainsi...
Un double 'click' sur l'automate permet de changer les icônes du bandeau supérieur du logiciel pour voir apparaître celui des Tâches. Il convient dès lors d'en ajouter une, en renseignant le programme concerné et le temps machine alloué, même si ce programme ne gère absolument aucune entrée :
Un 'clik droit sur l'automate pour demander un 'Full run' dans la rubrique 'PLC Operation' permet, après avoir déployé la solution, de démarrer 'réellement' la tâche et de constater le clignotement de la LED X1 sur le joli boitier bleu: magique!
A noter que lors de la mise sous tension du PLC, le programme démarre automatiquement après seulement quelques secondes de boot de la carte Pi3. On s'en serait douté, mais autant le confirmer.
13/10/2017 Bon, une LED qui clignote sur la face avant de l'automate c'est bien, et quoi d'autre?
Un des intérêt de cet automate de chez UniPi, c'est qu'il possède en interne un module GSM. J'ai choisi cet automate aussi pour cette raison parce que l'application que je développe doit prévenir en cas de problème. Un moyen 'simple' de le faire est donc de profiter de l'infrastructure réseau du téléphone mobile.
Le problème (le monde technique n'est QUE problèmes. Mais les résoudre est un vrai challenge, n'est-ce pas, surtout quand la réflexion profite à soi même, et non pas à Micro-Logiciel!), c'est qu'il n'y a absolument aucune connexion entre ce moduler GSM et l'automate.
Impossible donc de disposer d'une sortie type relais de l'automate, propre à déclencher quelque chose sur le module téléphone. En fait, il existe une solution, simple dans l'idée, mais un peu compliquée à mettre en œuvre.
Comme l'automate est connecté avec la carte Pi3 par le biais d'un liaison de type TCPModBus, et bien il 'suffit' de la même façon, d'implémenter sur le système de la Pi3 un client ModBus en TCP qui déclenchera le contrôle du module téléphone, qui lui, est connecté par port série sur la carte Pi3.
L'idée est simple, reste à la mettre en pratique. Pour ce faire, je vais d'abord effectuer des tests à l'aide d'un client démarré sur le PC de développement, raccordé en WiFi au réseau sur lequel est connecté l'automate.
La première étape consiste donc à déclarer un client ModBus par liaison TCP dans l'environnement de l'automate en ajoutant en Device dans la liaison TCPModBus comme ceci :
Contrairement à ce qui a été fait précédemment, il ne faut pas installer quoi que ce soit à partir de la 'Library Device' parce que, forcément, mon client ModBus n'a jamais été déclaré ou que ce soit étant donné que je le crée quasiment en live.
Voici les propriété que j'ai configuré pour ce client ModBus :
Pas grand chose de vital mis à part l'adresse IP du client, ainsi que le port réseau d'écoute. Le reste des paramètres se comprend aisément, tellement, que je n'ai touché à rien d'autre, hormis le nom.
Ah oui, pourquoi installer un client ModBus et non pas un Serveur? Parce que c'est l'automate le patron, c'est lui qui VA lire ou écrire à l'extérieur.
Une fois le client déclaré, il faut maintenant déclarer les registres de ce client auxquels il va falloir accéder, parce qu'il n'existe aucun fichier de déclaration pré-établi.
Première chose à faire, il faut déclarer en fait le type de variables auxquelles l'automate devra accéder. J'ai choisi de déclarer un groupe de variables de type 'Single Coil', autrement dit, un pool de relais dont j'en déclencherai un pour indiquer une action à effectuer vers le module téléphone.
Un 'clic' droit sur le Client ModBus permet d'ouvrir l'éditeur et d'accéder à l'ensemble de ce qu'est 'censé' contenir le client en terme de registres, d'entrées/sorties etc etc...
Et la page des ressource matérielle du client :
Je triche un peu, normalement le contenu de cette page est vide à la création. Mais ici, on voit le Group de ressources qui a été créé, et quelle est la ressource utilisée dans ce groupe.
'Clic' droit sur cette fenêtre permet d'accéder à la création du groupe de ressources :
Puis la sélection du Groupe permet d'en configurer les paramètres :
Donc, je déclare un 'tas' de variables, en fait il y en aura une, mais de type Byte, qui commencera à l'index n°1 et qui sera considérée comme un 'paquet' de relais qui accepteront simplement d'être 'écrits', toutes les 100ms. Le choix de la fréquence est important parce que pour mon test, je vais évidemment insérer la mise en ON puis OFF de la variable à l'endroit du code ou je mets la LED du panneau avant de l'automate en ON puis en OFF. Et comme je le fais toutes les secondes, une écriture toutes les 100ms me donnera donc au maximum un retard d'un dixième de secondes à l'actualisation de la variable du client ModBus par rapport à l'actualisation de la LED de l'automate. Vous suivez toujours?...
Ceci fait, la même manipulation permet de déclarer... la variable finale, cette fois ci en déclarant un 'Data Point' :
Il reste encore à positionner les propriétés de cette variable pour pouvoir l'utiliser :
Les paramètres les plus importants sont le groupe auquel appartient cette variable, ici le groupe 'Group' (comme c'est original!), le type de variable, j'ai choisi une sortie de type bit, donc 'bool'. Il est important de renseigner l'endroit ou se trouve la variable dans le paquet de huit 'bool' déclarés, à savoir la première position, avec le paramètre Write Offset Gap, puis d'indiquer la taille totale de la variable à écrire lors du changement d'état de la variable booléenne, ici un octet. Parce-que ModBus ne sait pas traiter des données de 1 bit, mais à minima des octets. Il suffira donc d'envoyer l'octet ou se trouve la variable à modifier vers le client.
Et ça n'est pas fini. Il faut maintenant générer la variable globale associée à cette variable pseudo physique. Simple, il suffit de demander l'auto-génération de la variable :
pour se retrouver avec la nouvelle variable globale de l'application :
C'est fait, nous voici avec une bien jolie variable. Qu'il suffit maintenant d'utiliser dans le programme initial :
J'utilise toujours le même programme qui consiste à faire clignoter une LED de la face avant de l'automate. Cette fois, je fais aussi clignoter la sortie virtuelle associée à la nouvelle variable. Bien évidemment, au redémarrage il ne se passe pas grand chose sur l'automate. Et pour cause, je suis censé faire clignoter une sortie sur un automate quelque part sur le réseau.
Or donc, il reste encore à démarrer un client sur le PC portable relié en WiFi au réseau. J'utilise l'esclave pyModSlave :
Après avoir configuré cet esclave ModBus pour fonctionner en TCP à l'adresse IP et au PORT adéquat, je peux constater qu'effectivement la première variable de type 'Coil' c'est à dire de type relais, ou tout simplement de type 'tout ou rien', clignote en rythme avec la LED de l'automate, à quelques dixièmes de secondes près :
Bien que l'image soit statique par essence, le seul bit à '1' correspond bien à la variable positionnée toutes les secondes par l'automate qui se situe... à l'autre bout de l'habitation : cool, voir carrément fun! (chacun ses plaisirs). A remarquer que l'adresse IP et le PORT correspondent à ce qui a été positionné sur le logiciel de l'automate pour créer le client virtuel. Les 'packets' indiquent en fait les trames ModBus valides qui ont été reçues. Par contre le client n'affiche pas un octet de variables, mais 10 bits. Je n'ai pas creusé la question parce que cela n'a aucun importance (pour le moment).
Et maintenant? Il ne s'agit la que d'un test de faisabilité. Il me faut maintenant implémenter un client ModBus directement sur l'automate, puis m'en servir pour déclencher un script de gestion du module GSM afin qu'il y ait bien émission d'un SMS lors d'un évènement surveillé. Je ne suis pas au bout de mes peines...
