Dans le démonstrateur avec trois postes de Travail, on a vérifié qu’ajouter une unité quelconque dans la ligne de fabrication ne pose pas vraiment de problème. Pour cette ultime expérience, nous allons revenir à un anneau qui n’inclut que deux entités adressées, car tout le monde n’aura pas forcément la chance de disposer d’autant de composants. Déjà avec trois Arduinos et six modules Bluetooth l’investissement n’est pas dérisoire du tout.
– Ben on l’a déjà vu l’anneau à trois unités, on va rabâcher dans ce chapitre !
– Et non Dudule, car tout ce qui a été proposé avant est une discrète tromperie.
– À bon, pourquoi ? Môamôa je vais porter plainte au Ministre des tromperies alors !
– Et bien nous avons trop simplifié car les démonstrateurs sont disponibles en permanence.
– Et alors ?
– Du coup on est loin de la réalité industrielle dans laquelle un poste peut recevoir un JETON le concernant, et étant occupé il ne peut pas le prendre en compte. Il doit en premier terminer le travail local en cours avant de se mettre en attente de la nouvelle consigne.
– Ben c’est comme Môamôa, je commence plein plein plein de choses et je ne les termine jamais.
Nous allons voir dans les chapitres qui vont suivre, que gérer un tel réseau est bien plus délicat, et ce autant pour un poste de Travail que sur le poste de Pilotage qui jusqu’à présent n’avait pas grand chose à faire lors de l’arrivée d’un JETON orphelin.
Traitement des JETONs sur un poste de Travail plus « réaliste ».
Pour ne pas trop pénaliser le nombre de consignes qui transitent dans le réseau en anneau, lors d’un test de fiabilité en mode automatique, statistiquement chaque poste de travail sera « occupé » d’une fois sur trois à une fois sur six, pour générer des files d’attente par effet « d’embouteillage » sur le poste de Pilotage. Nous serons ainsi en présence d’un joyeux « chassé/croisé ». Autant dire que nous avons fort intérêt à analyser finement les algorithmes à mettre en place, sans compter qu’il va falloir filtrer les retours « d’erreurs volontaires » qui ne doivent pas être réinjectées dans le réseau. Scongregneugneu … comme dirait Dudule !
Lorsqu’un poste de travail est engagé dans une séquence d’indisponibilité, il se contente de renvoyer en aval tout ce qu’il reçoit, sans effectuer d’analyse. Il restera dans cette configuration pendant une durée comprise entre vingt cinq et quarante secondes, pour générer des « embouteillages » aléatoires pouvant aller jusqu’à empiler trois JETONs. Chaque fois que dans un logiciel je dois générer un ou plusieurs nombres aléatoires, j’effectue comme sur la Fig.105 un test de fiabilité. On peut y observer une distribution assez équilibrée dans la fourchette des valeurs désirées qui vont de 3 à 6 pour 1 / N et de 25 à 40 pour la calibration des durées exprimées en secondes. On peut passer à l’ossature du programme résumé en Fig.106 par un organigramme.
La trame du programme animant l’un des postes de Travail.
Résumée sur l’organigramme de la Fig.106-A on remarque que la première action du démonstrateur dans la boucle de base consiste à tester en (1) si l’on est en mode Developpement. Si c’est le cas, logiquement on teste le programme manuellement. Aussi, il y aura un maximum d’informations affichées dans la fenêtre contextuelle du Moniteur de l’IDE. Dans ce cas, la valeur de 1/N sera listée en (2). Puis en (3) le système passe en attente de l’arrivée d’un JETON. Si c’est une consigne « banale », les deux tests en (4) et en (7) sont négatifs et l’on passe directement en (11). À ce stade le logiciel vérifie si le JETON est relatif au poste de Travail et si les indisponibilités sont possibles. Si c’est le cas, en (12) le compteur Un_sur_N est incrémenté : Chaque fois qu’un JETON relatif au poste de Travail sera reçu, il sera analysé, et le compteur progressera. Puis le déroulement des instructions se poursuit en (13) où l’on teste pour savoir si c’est le moment de déclencher une période d’indisponibilité. La majorité du temps le poste de Travail est disponible, et dans ce cas en (14) on traite le JETON de façon banale, c’est à dire qu’il est analysé s’il concerne le poste de Travail, ou renvoyé sans modification s’il est relatif à une autre unité. Si le poste de Travail est indisponible, alors le JETON sera purement et simplement retourné en aval sans modification. La procédure en (15) n’analyse pas le contenu du JETON mais effectue tout un travail de gestion de l’indisponibilité, avec gestion du chronométrage de cette dernière et des affichages sur OLED ou sur le Moniteur de l’IDE. Si le JETON en (4) contient DEB, il concerne tous les postes de Travail et aura le même effet sur ces derniers. Il les initialisera en configuration réaliste avec possibilité de se voir indisponibles. Puis sur chaque poste une valeur de Un_sur_N sera calculée. La première fois elle sera identique sur tous les postes. Mais la génération des adresses étant aléatoire, rapidement ces durées vont être différentes d’un poste à l’autre. Enfin, si le JETON en (7) contient la consigne spécifique FIN, tous les postes de Travail sont également concernés et aura un effet identique sur ces derniers. Il les conditionnera en disponibilité permanente en (8). Le compteur Un_sur_N sera remis à zéro en (9) (Et y restera.) et pour bien montrer que l’indisponibilité sur le poste de Travail ne risque plus de se produire, MAX_chrono est figé en (10) à la valeur particulière de 99. (Les manipulations vont clarifier ces derniers points.)
Vérification manuelle du programme.
Avant d’envisager l’étude du programme qui gère le poste de Pilotage, nous allons tester le comportement du (des) démonstrateur(s). Concrètement, quatre versions sont disponibles relatives aux postes de Travail. P24_Poste_de_travail_1.ino et P25_Poste_de_travail_1B.ino sont strictement équivalents. Ils effectuent exactement le même travail. Le premier utilise un afficheur OLED bicolore de 0,93 pouce de diagonale, alors que le deuxième utilise le grand frère monochrome de 1,3 pouce de diagonale. Dans les deux cas, on peut se passer totalement de ces composants, puisque les manipulations font appel au Moniteur de l’IDE. Enfin P26_Poste_de_travail_2.ino et P27_Poste_de_travail_3.ino utilisent une carte NANO étendue avec afficheur OLED intégré pour le n°2 et si vous avez le matériel nécessaire, une unité NANO classique avec afficheur de 1,3 pouce de diagonale pour le troisième poste de Travail éventuel. Tous seront à tester manuellement, seuls les affichages et l’éclairage des LEDs locales seront différents. Les vérifications et manipulations seront à faire sur tous les postes de Travail insérés dans votre réseau en anneau. Toutefois, étant identiques, seules celles relative au poste de Travail n°1 seront proposées dans ce qui suit. Toutefois, avant d’entreprendre l’expérimentation, il me semble utile d’expliciter les informations qui seront disponibles sur les différents écrans graphiques potentiels :
Comportement des différents écrans OLED.
Trois cas sont à envisager. Soit l’afficheur OLED indépendant de 1,3 pouce de diagonale, soit son petit frère bicolore de 0,96 pouce de diagonale, soit l’écran OLED à définition réduite intégré sur une carte Arduino NANO élargie. Il est évident que sur la dernière version, la page écran ne pourra pas monter autant d’informations.
Afficheur OLED de 1,3 pouce de diagonale.
C’est celui qui apporte le plus d’informations d’état. Sur la Fig.107 A en 1, un petit cadre précise par O ou par N si les indisponibilités sont effectives. Cette figure constitue un « film » sur le cas où les indisponibilités ont été validées avec DEB. Chaque fois que le poste de Travail recevra un JETON qui le concerne, le compteur Un_sur_N sera incrémenté en 2. Arrivé au maximum possible en 3 la LED triple va s’allumer (Si l’on est en mode manuel.) et surtout une puce en 4 précisera que la durée d’indisponibilité commence. La suite du film est montrée en Fig.108 avec en 5 l’affichage du temps qui reste à attendre avant que le poste ne redevienne disponible. Cette valeur n’est pas rafraichie en permanence, mais uniquement lorsqu’un JETON arrive sur le réseau. En mode automatique il faut compter sur un JETON toutes les quatre secondes en moyenne. En 6 il reste encore 23 secondes à patienter. À la cadence de fonctionnement du mode automatique, la consigne concernant le poste de Travail n°1 sera envoyée plusieurs fois en ligne. On voit sur les copies d’écran D et E qu’une erreur devrait être détectée par l’analyser syntaxique. Comme l’unité est occupée, elle se contente de propager sans le modifier le JETON en aval. Enfin en F le chronomètre affiche zéro en 7. Cette fois l’erreur est détectée et transmise en aval pour prévenir le poste de Travail. Toutefois, il faudra que l’unité reçoive encore une 
consigne pour que l’écran soit rafraichi et voir la puce s’éteindre. Bien que dans le cas d’un réseau opérationnel intégré dans une réalisation réelle toutes ces informations affichées ne serait pas vraiment utiles, le logiciel étant au point et entièrement validé, dans le cadre d’expérimentation en loisirs elles sont indispensables pour « voir » vraiment ce qui se passe sur tous les afficheurs des modules Arduino impliquées dans notre activité ludique. On a ainsi une vision globale de ce qui se passe à chaque JETON envoyé manuellement. Sur la Fig.109 la consigne FIN engendre la disponibilité permanente de tous les postes de travail. Dans le petit encadré en 1 le O a été remplacé par un N et maintenant la valeur de Un sur N de 0/99 va rester figée. La valeur particulière de 99 est choisie pour attirer l’attention de l’opérateur.
Pourquoi prévoir la suppression des indisponibilités ? Cette action va à contre-sens de l’objet motivant ce chapitre. Deux cas ont amené à ajouter cette action aux consignes possibles. Le premier concerne le long chemin sinueux qui a été laborieusement suivi pour arriver à « tortiller » un logiciel qui tient la route sur toutes les unités. Aussi, par moment il s’avérait utile de rendre disponibles toutes les machines simultanément, sans avoir pour autant à quitter l’ordinateur pour aller faire des RESETs sur les divers postes de Travail. Par ailleurs, on peut désirer passer en mode automatique à partir du mode manuel par la consigne ‘I‘. Dans ce cas les postes de Travail sont dans des états quelconques. Hors le début de la génération des JETONs aléatoires commence par la commande de diverses initialisations pour les entités du réseau. Si certaines sont indisponibles, le système n’amorcera pas son fonctionnement INFINI avec tous les postes dans un état initial correct. Aussi, avant d’envoyer ses instructions d’initialisation, le logiciel commence par envoyer FIN, puis ayant l’attention de toutes les unités il propage DEB suivi de quelques codes de conditionnement comme éteindre les LEDs par exemple.
Afficheur OLED bicolore de 0,96 pouce de diagonale.
Bien qu’il présente la même définition que celle de son grand frère, il n’affichera pas la valeur de Un_sur_N ni le chronomètre en période d’indisponibilité. Il serait tout à fait possible de visualiser quatre lignes de texte comme dans le cas précédent. Toutefois, sachant que pour conduire les essais du réseau complet j’allais opter pour l’écran le plus grand, je n’ai pas eu le courage d’introduire ces informations. Seul le O ou le N seront visualisés ainsi que la « puce ». Sur la Fig.110 dans l’encadré rouge le N signifie que les indisponibilités ne sont pas effectives. Sur la Fig.111 on les rétablit et le N est remplacé par un O. Sur la Fig.112, le poste de travail n’est pas occupé. De ce fait, le JETON 111 n’étant pas valide, le programme retourne un message d’erreur dans l’encadré vert. Par contre, sur la Fig.113 le petit cercle dans l’encadré rouge précise que l’unité est occupée et dans l’encadré vert le JETON avec erreur est retourné sans être modifié. Comme dans le chapitre précédent, une puce aurait été plus visible qu’un simple cercle. Pour tracer un disque complet, il aurait fallu ajouter un autre cercle, et un PIXEL. Je n’ai pas pris le temps de le faire, ayant à ce stade une foule de difficultés à résorber avant de peaufiner les affichages. Le temps a passé … et j’ai oublié d’y revenir ! (Plus la paresse comme dirait la petite salamandre.)
Afficheur OLED de 128 x 32 sur carte NANO étendue.
C’est la page qui contient le moins d’informations, car l’écran ne présentera pas plus d’informations que dans le cas de l’afficheur bicolore, et de plus ne précise plus le numéro du poste de Travail. L’idée d’indiquer par O ou par N l’état de l’indisponibilité en début de la ligne du haut a été reprise. Elle est mise en évidence sur la Fig.114 dans l’encadré rouge. Une puce placée en début de ligne du bas est également visible Fig.115 dans l’encadré rouge. Sur la Fig.114 l’unité n’est pas occupée, ce qui sera le cas la majorité du temps. Le JETON qui vient d’arriver la concerne, et est retourné en aval du réseau car l’analyseur syntaxique a détecté une erreur. Sur la Fig.115, le poste de Pilotage tente un fois de plus d’envoyer une consigne en attente. Elle est retournée sans modification car le poste de Travail est actuellement occupé.
Une procédure délicate à mettre au point.
L’organigramme de la Fig.106-A en Page 54 qui présente le travail effectué par la boucle de base ne semble pas très compliqué. C’est du reste souvent le cas dans mes programmes. Le plus gros du traitement s’effectue dans les procédure et les subroutines. L’avantage de « fracturer » au maximum le logiciel, c’est de n’utiliser que des séquences « presque » simples bien plus faciles à dominer qu’une suite considérable d’instructions où tout finit par se mélanger. Personnellement, j’évite au maximum les procédures dont le listage ne tient pas entièrement dans la fenêtre de l’éditeur de texte. Avec cette approche, la complexité d’un logiciel ne se loge pratiquement jamais dans void loop(), mais réside dans les fonctions et les procédures de servitude. Comme Traiter_un_sur_N() entre dans la lignée des séquences un peu denses, il m’a semblé utiles pour celles et ceux qui désirent en savoir plus, de commenter cette procédure de service, car à mon sens les nombreuses remarques qui émaillent le listage ne sont pas suffisantes à mon avis pour comprendre le fonctionnement de cette séquence bien « dodue ».
C’est dans la routine void setup() que la valeur de Un_sur_N est déterminée initialement à la mise sous tension ou sur un RESET. Cette variable sert à déterminer aléatoirement combien de JETONs vont être reçu sur le poste de Travail avant de déclencher sur ce dernier une indisponibilité. C’est précisément lorsque cette dernière se produit, que la procédure représentée sur l’organigramme de la Fig.106-B est invoquée. Elle commence en (1) par déterminer aléatoirement la durée pendant laquelle l’unité sera « occupée ». Si l’on est en mode Developpement la valeur de cette temporisation sera affichée en (2) sur le Moniteur de l’IDE. Puis l’écran du dialogue est affiché en (3) pour tracer la « puce » qui signale l’indisponibilité du poste. C’est en (4) que l’on déclenche un chronomètre qui va décompter. Son identificateur est Chrono_DUREE dans les croquis.
Puis commence en (5) une boucle dans laquelle le programme va « tourner » tant que le chronométrage ne sera pas arrivé à son terme. Si on est en mode Developpement et que l’on transmet les JETONs manuellement, en (6) la valeur du temps restant durant lequel l’unité sera occupée est affiché sur le Moniteur. En standard, en (7) le décomptage est également présenté sur l’afficheur OLED chaque fois que cette boucle sera réitérée. Le JETON « refusé » est renvoyé sur le réseau en (8), puis immédiatement le programme se met en attente d’un JETON en (9). Lorsque ce dernier arrive, en (10) il est affiché sur OLED puis il y a rebouclage en (5). Noter que le JETON sera renvoyé en aval y compris si le poste de Travail n’est pas concerné. (Rien ne se perd, rien ne se crée … tout se retourne !) Arrivera forcément un moment où le décomptage sera à zéro. Le logiciel passe alors en (11) où il recalcule Un_sur_N le nombre aléatoire de consigne qu’il faudra recevoir avant de déclencher une nouvelle indisponibilité. Cette valeur sera comprise entre trois et six pour que l’unité soit à l’écoute la majorité du temps. Puis en (12) on rafraichi l’écran graphique en vue d’effacer le décomptage si c’est un écran de 1,3 pouce de diagonale, et la « puce » d’avertissement visuel de l’occupation du poste de Travail. Le dernier JETON qui vient d’être intercepté est alors analysé de façon standard en (13) et ne sera pas envoyé en aval s’il concerne l’unité.
La suite est ICI.
