Compte tenu de la complexité relative du travail effectué par le Poste de Pilotage, il m’a semblé judicieux d’ouvrir à son profit un nouveau chapitre. Sur une chaîne de fabrication flexible pilotée par un réseau en anneau, c’est l’opérateur qui sur sa console informatique se charge de donner les consignes à un ordinateur qui alors « travaille » pour générer les JETONs. Naturellement, nous allons effectivement jouer ce rôle et proposer manuellement des consignes au réseau. C’est nous qui devrons proposer des JETON valides ou volontairement avec erreur pour observer le comportement du système. Des manipulations seront proposées pour ces expérimentations.
Toutefois, pour tester la fiabilité du réseau, il est prévu pour les démonstrateurs de pilotage, un mode où le programme génère de façon INFINIE des JETONs pour faire dialoguer ces diverses unités durant des heures voir durant plusieurs jours. Pour le développement et l’analyse on va y aller progressivement et commencer par le démonstrateur élémentaire P18A_Poste_de_pilotage ino.
Premier démonstrateur pour le Poste de Pilotage.
Annoncé comme pouvant utiliser une carte Arduino UNO ou NANO, j’ai commencé par développer le croquis avec une UNO et des paquets de fils sur des plaques « Breadboard ». Et puis, au final « j’ai KRAAAAAkkkkkééééé ! Les manipulations étaient trop indigestes, surtout lorsque pour certaines vérifications il fallait changer les modules Bluetooth. Aussi, en quelques heures j’ai réalisé une deuxième carte « UNIVERSELLE » strictement identique à la première. C’est donc au final une carte NANO avec écran OLED 1,3 pouce qui sert à mettre au point les démonstrateurs du Poste de Pilotage. (Les programmes restent pour autant 100% compatibles avec une carte UNO.)
• Première difficulté : La saisie manuelle des JETONS.
Matériellement on se heurte à un obstacle. Pour que l’opérateur puisse soumettre des consignes, on va tout naturellement utiliser le Moniteur de l’IDE qui mobilise RX et TX en D0 et D1. On frappera les consignes dans la ligne de saisie du Moniteur et le programme va les lire sur D0. Pour envoyer des JETONs vers le module Maître n°1 on utilise la voie série secondaire gérée par <SoftwareSerial.h> ce qui ne pose aucun problème. Hors pour réceptionner les accusés de réception, c’est encore D0 qui est sollicitée et on ne peut pas les laisser branchées en parallèle le Moniteur et le Bluetooth. C’est du reste dans ce but qu’en Fig.63 on a intercalé un inverseur double pour pouvoir téléverser les croquis. On se doute que ce dernier est également impératif pour les mêmes raisons.
Concrètement, la difficulté réside dans l’alternance des lignes à chaque consigne. Lorsque l’on saisit une directive, elle est lue sur D0. et transmise avec Maître n°1. Puis immédiatement il faut surveiller le retour du réseau, et basculer la lecture de D0 sur la sortie du Bluetooth Esclave n°3. (Voir la Fig.73) On se doute que manuellement basculer l’inverseur à chaque fois serait trop indigeste, et de toute façon nous ne serions pas assez rapide. C’est la raison pour laquelle nous allons utiliser un petit relais de commutation rapide dont le contact repos sera en série avec l’inverseur. (Voir l’encadré en haut de la page 43.) Il est piloté par D9. Le schéma de commutation est proposé en Fig.80 où D est la diode « de roue-libre » absorbant les surtensions de coupure.
Sur le schéma de la Fig.80 la section coloriée en gris du relais n’est pas utilisée, seul le contact CR de la section de gauche est branché sur TXD du module Bluetooth. Quand l’INVerseur est sur UT, la sortie TXD sera reliée à D0 si le relais est au repos sur R. Il est en permanence sur T lorsqu’une consigne est attendue sur le Moniteur. (Le module Bluetooth est alors isolé de la ligne.) Dès que cette dernière est lue par le programme, lorsque l’opérateur la valide, le relais passe immédiatement au repos sur R et TXD est en liaison avec D0. Le programme va alors vérifier si un retour est disponible en fin de réseau, action qui engendre la Deuxième difficulté. Puis, le logiciel va repasser en attente d’une consigne issue de l’opérateur. Quand on bascule l’INVerseur sur la position PGM, TXD est isolée quel que soit l’état du relais et l’on peut téléverser. La LED rouge L n’est absolument pas nécessaire. Elle témoigne de l’état du relais ce qui n’est vraiment utile que durant la mise au point du démonstrateur.
• Deuxième difficulté : La capture des JETONS.
Résultant du fait qu’il peut ne pas y avoir de retour, ce qui du reste sera le cas pour la majorité des consignes envoyées sur le réseau, le programme ne peut pas se permettre d’attendre impérativement un accusé de réception qui risque de ne jamais arriver. Par ailleurs, il faut un certain temps de cheminement des JETONs dans le réseau. Aussi, on doit tester la ligne durant un laps de temps suffisant. L’expérience montre qu’il ne faut pas moins de 850mS d’attente pour s’assurer des captures de JETONs éventuels avec fiabilité. Nous allons donc mettre en œuvre un chronométrage de type « TIME_OUT ». La Fig.81 permet de détailler le fonctionnement logiciel de la séquence d’attente et de capture éventuelle d’un JETON retourné en fin de réseau. Il n’y a que trois cas d’une telle présence. Soit le jeton est 999 et a été généré par le test de vérification du dialogue effectif dans la boucle Hertzienne, autrement dit on s’assure régulièrement que le réseau n’est pas bloqué. Soit on a envoyé un JETON qui ne concerne ni le poste de Travail n°1 ni le poste de Travail n°2. Par exemple 3:B ou 444 etc. Soit on a volontairement envoyé un JETON invalide pour simuler une erreur de manipulation de l’opérateur et le poste de Travail concerné retourne un accusé de réception de type erreur. Par exemple 1:Y retournera 12E ou 2xB retournera 23E etc.
L‘entrée de la procédure commence par mettre à zéro en (1) le chronomètre du « TIME_OUT ». Puis en (2) on prépare la boucle d’attente pour n’en sortir que lorsque l’une des deux conditions attendues sera effective. C’est en (3) que la surveillance des retours éventuels commence. Dans ce processus on débute en (4) par l’analyse de la valeur du chronomètre. Tant qu’il n’arrive pas à 700mS la durée d’attente maximale prévue, on saute en (6) pour voir si un JETON est disponible dans le tampon du module Bluetooth. Si ce n’est pas le cas, on reboucle en (3) pour réitérer ces deux tests. Considérons le cas le plus probable, celui ou les JETONs ont été « conservés » par les postes de Travail car ils sont valides, les écrans des unités concernées affichant alors « ///« . Dans ce cas, suite à un certain nombre de rebouclages en (3) le chronomètre en (4) arrive à la fin du délai prévu. En (5) le booléen est forcé à vrai provoquant alors la sortie de (3) vers (8). Soit en (6) le programme détecte la présence d’un JETON avant la fin de la temporisation de surveillance. Il faut également en (7) comme c’était le cas en (5) engendrer une sortie de la boucle d’attente. Dans les deux cas, en (8) on teste à nouveau pour savoir si un JETON est en attente dans le tampon de registre mémoire du module Bluetooth. Si un JETON est présent, il est alors récupéré par lecture sur la broche TXD de E3. (Voir la Fig.73.) Puis il y a affichage sur OLED de « /// » si la variable Index = 1, c’est à dire pas de JETON, soit le contenu de ce dernier s’il y a eu capture, donc Index est supérieur à zéro. Éventuellement le JETON sera analysé par le démonstrateur s’il est particulier, comme 999 par exemple.
Tester le premier démonstrateur.
Avant d’envisager un fonctionnement automatique avec en mode INFINI la génération de JETONs aléatoires, tant pour les adresses que pour les actions spécifiques à chaque poste de Travail, nous allons expérimenter avec P18A_Poste_de_pilotage.ino le comportement du système, tant en mode manuel qu’en mode automatique. On suppose que les branchements stipulés en tête de programme ont été réalisés pour constituer le réseau, et que le relais de la Fig.80 a été installé. C’est impératif pour pouvoir proposer des JETONs par l’entremise du Moniteur de l’IDE.
Commentaires :
Comme à chaque fois, en 1 le programme commence par se présenter. Puis en 2 il donne un rappel du protocole global pour amorcer la boucle de dialogue. En 3 un petit rappel des trois commandes de base. Par choix logiciel, soit l’opérateur va saisir un JETON sous la forme de trois caractères, soit il imposera une commande sous forme d’une seule lettre. À tout moment le ‘H‘ ou le ‘?‘ fourniront un rappel des commandes possible sur l’écran OLED du poste de Travail. Si vous attendez un peu, le système en 4 va comme sur la Fig.85 vérifier le fonctionnement du réseau en envoyant 555, ou 666 en tête de boucle. Ces deux consignes alternent pour montrer que le système n’est pas figé mais actif. C’est un cas particulier où, comme le montre la Fig.85, les deux postes de Travail n’étant pas adressés retournent le JETON orphelin, mais que l’affichage est > Non car pas pris en compte. De plus, ils sont une invitation pour l’opérateur à saisir soit 555, soit 666. En 5 on a saisi 555 et validé. Immédiatement sur l’cran OLED et en 6 le programme signale qu’il passe en mode dialogue. La LED d’Arduino se met à clignoter invitant l’opérateur à proposer des JETONs. Puis en 7 le logiciel précise qu’il va éteindre toutes les LEDs sur les postes de Travail et activer leurs écrans OLED. Le but est de démarrer dans une configuration initiale même si on a déjà effectué des manipulations suivies d’un RESET. Pour effectuer ces initialisations il faut quatre JETONs en 8 dont aucun ne génère un retour puisque les consignes sont valides. Enfin, en 9 le programme nous invite à proposer des JETONs et se met en attente :
NOTE : Je précise toujours la version du compilateur utilisé. En effet, la taille du code est directement fonction de ce facteur. Avec des versions plus actuelles, la taille occupée par le code objet est significativement plus faible, car ils sont systématiquement optimisés.
Deuxième démonstrateur pour le Poste de Pilotage.
Strictement identique au logiciel déjà testé P18A_Poste_de_pilotage.ino, le démonstrateur P18B_Poste_de_pilotage.ino effectue exactement le même travail et vous pouvez intégralement reprendre avec lui les manipulations commencées en page 44. Vous ne constaterez aucune différence durant ces expérimentations. La seule différence réside dans le mode automatique quand vous le déclenchez par la commande ‘I‘. (Remarquez au passage que la lettre ‘I’ a été choisie comme commande pour « INFINI », mais il serait tout à fait envisageable d’utiliser ‘A’ pour « Automatique ».) Avec ce deuxième démonstrateur, en mode INFINI il y a génération des JETONs de façon aléatoire. L’adresse est aléatoire ainsi que l’Action à réaliser. Autre subtilité, on se contente de tester le bon fonctionnement du réseau environ une fois toutes les trente secondes. L’affichage de l’écran si le B.P. sur A3 n’a pas été cliqué pour avoir des écrans noirs est montré sur la Fig.91 avec sur la ligne du bas la précision du mode en cours. Sur la ligne du haut les échanges sont comptabilisés et surtout en haut à droite le ‘S‘ nous informe que la génération automatique impose le mode silencieux pour ne pas gêner l’entourage avec des BIPs réguliers.
Détermination de l’adresse aléatoire.
Deux phases sont nécessaires pour déterminer l’adresse du poste de Travail. La première consiste à générer un chiffre aléatoire compris entre 1 et 3. Le poste n°3 n’existe pas. Le JETON sera alors retourné comme étant orphelin. Toutefois, il ne faut pas qu’il soit généré aussi souvent que les consignes valides. C’est la raison pour laquelle on va diviser par cinq la probabilité qu’il se produise. L’adresse ainsi produite dans la variable Poste est un chiffre de type byte. Hors le tableau JETON[] est de type string. Pour pouvoir insérer ce chiffre dans JETON[0] il faut le transformer en équivalent de type char. La procédure complète Selectionne_un_poste() montrée en Fig.92 est la suivante :
Dans les initialisations du croquis, la variable Adresse_Poste est déclarée comme type char. Dans cette procédure, en (1) la variable locale Poste sera un chiffre que l’on désire compris entre 1 et 3. C’est exactement ce que fait l’instruction (2). Pour mémoire dans la fonction random le premier paramètre correspond au nombre généré le plus faible, mais le deuxième est relatif au nombre le plus grand moins un. Les trois chiffres 1, 2 et 3 seront donc créés aléatoirement avec une probabilité de se produire identique. Hors la valeur 3 doit être engendrée statistiquement quinze fois moins que les deux autres pour ne pas pénaliser les « actions valides ». Donc en (3) on surveille son apparition. En „ on gère le compteur « diviseur » par cinq. Si ce compteur arrive à la valeur cinq, on se contente de le remettre à zéro pour recommencer à diviser. La valeur de 3 pour l’Adresse_Poste sera donc conservée. Quatre fois sur cinq, Poste est recalculé en (5) pour privilégier les adresses affectées aux postes de Travail 1 et 2. La deuxième phase consiste à transformer en (6) le byte Poste en son équivalent alphabétique de type char pour compatibilité avec JETON[n]. Obtenue par génération en boucle avec affichage sur le Moniteur de l’IDE, la copie d’écran de la Fig.93 montre qu’effectivement l’apparition de l’adresse 3 est bien plus rare que celles des deux autres postes de Travail. Noter au passage que 3 est pris en compte qu’une fois sur 5. Mais la statistique de génération de 3 est aussi de 1/3. Du coup, la probabilité d’engendrer une Adresse_Poste de valeur 3 est bien de 1 divisé par (3 x 5), donc de 1/15.
Des JETONs avec erreur volontaire.
Deux cas qui ne se produiront pas très souvent sont prévu pour générer volontairement un JETON signalant une erreur. Le premier cas, c’est dans la génération des Actions. Pour les trois adresses, Selectionne_une_action() crée un nombre compris entre 1 et 11 qui convertit en lettre va de ‘A‘ à ‘K‘. Hors pour le postes de Travail n°1 la dernière lettre valide est le ‘J‘. (Voir le tableau de la Fig.72) Du coup, lorsque Genere_un_JETON_aleatoire() crée le JETON 1:K il n’est pas accepté et retourné sous la forme de l’ACR orphelin 12E qui provoque l’écran de la Fig.94 où l’on observe que le texte « >>> Mode INFINI <<< » de la ligne du bas est remplacé par la nature de l’erreur constatée.
Pour mettre en évidence la génération plus rare de l’adressage du postes de Travail n°3, le démonstrateur génère volontairement une erreur de type trois montré sur la Fig.95 où l’on observe le même comportement que celui de l’erreur précédente. La LED triple s’illumine en rouge. Le JETON suivant reprend les affichages « de routine ». Analysons maintenant Fig.96 la création des JETON.
L’instruction Index = 3 en (1) a pour but de faire afficher correctement la page sur l’écran OLED. Puis il y a création d’une adresse et d’une action. Adresse_Poste en (2) est directement inscrite dans le tableau JETON[0] car elle sera systématiquement correcte. Deux cas sont possibles. Le plus général en (3) correspond à des consignes pour les postes de Travail n°1 et n°2. L’action est directement validée et le séparateur inscrit dans JETON[1]. Le tableau est complet pour transmettre la consigne en ligne. Le deuxième cas en (4) ne se produit statistiquement que toutes les quinze consignes. Pour le mettre en évidence, en (4) on génère volontairement une erreur. Enfin, en (5) et en (6) les instructions repérées en rose servent à mémoriser le JETON transmis en vue d’en afficher le contenu sur la deuxième ligne de l’écran OLED.
À ce stade il ne reste plus qu’à tester la fiabilité du réseau. Après avoir téléversé le démonstrateur P18B_Poste_de_pilotage.ino, si le petit relais est installé je vous invite fortement à effectuer une deuxième fois les manipulations qui commencent en page 44. Puis vous terminez par la commande ‘I‘ pour observer le comportement du mode automatique. Si le relais n’est pas installé, vous passez directement au test de fiabilité du réseau à trois postes de Travail. Dans cette optique, vous commencez par mettre un peu de distance entre chaque module qui sera alimenté par la mini prise USB au moyen d’un petit bloc USB secteur 220V≈. Attendre que les six LEDs témoignant de la connexion entre les modules Bluetooth soient allumées. Faire alors un RESET sur le poste de Pilotage en maintenant activé le bouton poussoir branché sur A3. Immédiatement le réseau amorce une génération automatique en mode INFINI. Comme ce genre de test doit durer plusieurs heures si l’on veut qu’il soit crédible, autant ménager les trois écrans OLED. Cliquer sur le bouton poussoir branché sur A1. Ce capteur se comporte comme une touche de type OUI/NON. Il sera donc possible à tout moment de regarder combien d’échanges ont été effectués. Sauf incident qui ici ne s’est pas produit durant ce genre de test de fiabilité, si un problème de communication illumine la LED « Rouge/Vert », penser à cliquer sur A1 pour allumer l’écran et voir à combien d’échanges l’incident est survenu. Puis sur A3 pour relancer le processus sans pour autant annuler la valeur du compteur. Noter que ces deux boutons ne sont pas pris en compte immédiatement. Aussi, attendre la confirmation donnée par la LED d’Arduino qui doit s’illuminer, avant de les relâcher.
La suite est ICI.
