Lectrice, lecteur, si vous avez suivi ce didacticiel jusqu’à ce chapitre, c’est soit parce que vous avez l’intention de créer une application de ce genre, soit que la programmation en C++ est votre loisir favoris, et que vous désirez en savoir plus sur les divers programmes. Comme le logiciel qui anime le poste de Pilotage n’est pas d’une simplicité évidente, quelques explications peuvent aider à comprendre les diverses fonctionnalités éparpillées dans le croquis. En ce qui vous concerne, vous allez téléverser des démonstrateurs qui sont, du moins je le crois, bien au point et fonctionnent correctement. Mais il faut savoir que leur gestation a été assez laborieuse, avec des changements de stratégie, des remises en cause et de nombreux tâtonnements. C’est que la mise en place d’un tel réseau n’a rien d’élémentaire. Aussi, dans le cadre de l’expérimentation qui est le notre, les comportements des démonstrateurs sont volontairement très bavard, c’est à dire qu’ils affichent une foule d’informations, tant sur la ligne série USB du Moniteur de l’IDE que sur les petits écrans OLED, ce qui ne serait pas le cas sur un produit commercial. Nous allons passer en revue ces divers affichages et surtout expérimenter le fonctionnement du réseau qui maintenant est complet.
Structure du démonstrateur du poste de Pilotage.
L’organigramme de la Fig.118 illustre le déroulement de la boucle de base et s’avère particulièrement simple, car matériellement le gros du travail se fait dans les diverses procédures. Du reste cette approche est assez générale dans mes programmes. Il est infiniment plus facile d’analyser le comportement d’un logiciel, lorsque la structure de base est élémentaire et que les divers traitements sont cloisonnés par des procédures elles même compartimentées en plusieurs sous-procédures. Il est alors relativement facile de placer des points de test à des endroits stratégiques, pour arriver à déterminer l’origine d’un problème quelconque.
Considérons l’organigramme de la Fig.118 qui commence par vérifier en (1) si l’on est actuellement en mode Developpement. C’est le cas sur RESET. C’est la commande ‘I’ qui force à false le booléen idoine. Si le mode manuel par défaut sur RESET est actif, le programme invite en (2) à frapper un JETON dans la ligne de saisie du Moniteur. Puis le logiciel patiente en (3) jusqu’à ce que l’on propose une consigne. En (4) le contenu intégral de cette dernière sera listé dans la fenêtre contextuelle du Moniteur quel que soit sa longueur. La longueur sera de 1 si on désire imposer une consigne, de 3 si c’est un JETON et jusqu’à 5 pour tester des formats non valides. Si en (5) la longueur est supérieure à 1, ce n’est pas une commande, et la saisie correspond à celle d’un JETON. Son contenu sera propagé en ligne puis le retour analysé en (6). Enfin, si Index = 1 en (5), c’est que la saisie est relative à une commande qui alors est traitée en (7). L’écran de service, que l’on soit en mode MANUEL ou en automatique est celui représenté sur les photographies de la Fig.119 et de la Fig.120 avec en 1 l’affichage du nombre de JETONs qui ont été transmis sur le réseau. En ligne 2 est affiché le contenu du JETON à sa mise en ligne, alors qu’en 3 le contenu de l’élément orphelin s’il y a retour et le texte Non si le TIME_OUT a été dépassé. La ligne du bas en 4 précise si l’on est en mode manuel ou en mode automatique. En 5 le programme précise avec ‘S‘ que l’unité est en mode SILENCIEUX car elle a reçu la consigne ‘S‘ qui est une bascule de type OUI/NON. Comme nous l’analyserons plus avant, en 6 le programme indique combien de postes de Travail sont actuellement à l’écoute. Enfin en 7 sera représenté graphiquement l’état du registre des JETONs en attente de la disponibilité de leur cible. Dans ces deux exemples, sur le premier la consigne est ‘N‘ et ne concerne que le poste de Pilotage. Si l’écran est affiché, ce ‘N‘ ce contente de l’éteindre. Sur la Fig.119, comme l’écran n’est pas noir, c’est que la commande vient de le rétablir. Sur la Fig.120, c’est le huitième JETON envoyé en début de ligne. Il concerne le poste de Travail n°1, et comme il est valide, il n’y a pas de retour, d’où le Non sur la ligne 3.
Le registre des JETONs orphelins en attente.
Avant de pouvoir « décortiquer » le fonctionnement des procédures principales, il est indispensable d’expliciter comment fonctionne le registre des JETONs qui ont été retournés car leurs postes de Travail étaient occupés. On ne peut exclure le cas ou les deux, voir les trois postes de Travail si c’est un réseau étendu, soient 
simultanément occupés et indisponibles. Si une telle configuration se présente, on se doute qu’il ne faut pas continuer à générer de nouvelles consignes, et qu’il importe alors d’attendre de pouvoir résorber la file d’attente. La file d’attente est un « empilement » de données du genre char PILE_Orphelins[9]. Comme le réseau peut être étendu à trois unités « de fabrication » et qu’un JETON est constitué de trois caractères de type char, avec un maximum possible de trois unités, avec 9 cellules le registre couvre tous les besoins. La Fig.121 illustre la logique d’une telle mémoire d’attente. Dans la ligne centrale, en violet sont les indices du tableau pour en manipuler les cellules. Le groupe [012] conservera une trace d’un orphelin du poste de Travail n°1. Pour le n°2 ce sera [345]. Et pour le n°3 si vous activez un réseau étendu, ce sera [678]. Un tel registre fonctionne exactement comme de la mémoire RAM utilisant des mots de trois caractères. L’accès que ce soit pour empiler ou dépiler est totalement libre contrairement à un registre à décalage de type LIFO ou FIFO.
Le registre de mémorisation des « indisponibles ».
Déterminer en mode automatique un JETON doit impérativement tenir compte de la disponibilité du poste de Travail concerné. En effet, si une cible est occupée et qu’elle a retourné sa consigne, il n’est plus question de générer de nouveaux JETONs la concernant. La séquence qui construit aléatoirement les JETONs devra donc 
puiser uniquement dans des adresses disponibles. C’est la raison pour laquelle il faut émuler un registre spécial comme celui de la Fig.122 qui mémorise en permanence la disponibilité de chaque poste de Travail. Ce tableau de booléens comporte quatre cellules. Deux cas sont possibles. Si le réseau est étendu, il compte trois individus matériels. Mais en automatique on va aussi générer une adresse supplémentaire aléatoirement, pour avoir à gérer des retours. Aussi, avec un réseau étendu on aura quatre adresses potentielles. Celle de l’indice 3 (Poste 4) dans le tableau sera toujours réputé disponible puisque le registre de la Fig.121 ne comporte que trois emplacements. Si le réseau est simplifié à deux postes de Travail, c’est le poste 3 qui sera « en débordement » et toujours disponible. Quand au poste quatre dans cette configuration, il sera tout simplement ignoré. Par exemple, sur la Fig.122 on se trouve dans le cas d’un réseau étendu avec deux unités, la n°2 et la n°3 qui sont indisponibles. Avant d’envisager des manipulations concrètes, il me semble important de clarifier le fonctionnement de la boucle de base, et détailler l’organisation de la procédure de service Verifier_le_retour, les deux effectuant un travail significatif.
– C’est qu’elle a raison la petite salamandre. Je vais suivre illico son conseil. On va commencer par tester toutes les fonctionnalités du poste de Pilotage et ensuite, éventuellement on complètera par des organigrammes et des commentaires sur le programme.
Se familiariser avec le poste de Pilotage et ses nombreuses fonctions.
Lors des manipulations décrites en page 59 et en page 61, nous avons vu comment rendre le réseau opérationnel et passé en revue les divers protocoles de démarrage en fonction de ce que l’on désire faire. Comme nous allons tester le comportement de P28_Poste_de_pilotage.ino, on désire se trouver en mode manuel, et en fonction de votre matériel, travailler sur un réseau « simple » ou un réseau étendu. Pour que ces exercices soient à la portée de tous, quelle que soit votre configuration matérielle, on va opter pour seulement deux postes de Travail. Notons au passage, que sur provocation d’un RESET avec l’option #define Developpement false, le programme se présente à l’écran par la page de la Fig.123 dans laquelle la version du logiciel défile de la droite vers la gauche durant quelques secondes. C’est un petit luxe que l’on peut se permettre vu que le croquis consomme à peine 72% de l’espace réservé au code objet. On a donc de la place à revendre.
Considérons la Fig.134 qui illustre le déroulement des événements. En 1 on a saisi la consigne BONJOUR, mais seulement cinq caractères sont mémorisés sur l’entrée USB, les autres sont purement et simplement ignorés. De toute façon en automatique il n’y aura que des JETONs à trois caractères. En 2, la consigne ne comportant qu’un seul caractère est alors interprétée comme une commande, et cette dernière étant valide, elle est immédiatement exécutée. Donc, dans la zone violette, la première action consiste à vérifier le dialogue correct avec le réseau. Le retour du 666 confirme, et en 3 il est ignoré car il n’y a plus de raison de l’envoyer encore en ligne. Puis en 4 il y a initialisation du registre d’attente et du tableau de booléens Disponibles[]. Puis en 5, les postes de Travail sont conditionnés pour devenir indisponibles. (Ainsi, la consigne envoyée en 19) est annulée.) En 6 et en 7 des consignes banales sont générées. Elles sont acceptées, car le nombre de JETONs envoyés est encore insuffisant sur les deux unités pour atteindre le comptage critique. En 8, la consigne générée aléatoirement est une erreur volontaire. Du coup il y a un retour 12E qui n’est pas le fait d’une machine occupée. Il n’y a donc aucune raison de le renvoyer sur le réseau, raison pour laquelle en 9 il est ignoré. Normalement, ce type d’incident ne peut provenir que d’une erreur opérateur, et ce dernier étant averti, il corrigerait alors le problème.
Noter au passage, que le S a été rétabli dans le petit encadré en haut à droite. Quand on active le mode Infini, le système passe automatiquement en mode Silencieux pour ne pas perturber l’environnement lorsque des JETONs volontairement avec erreur sont générés. Contrairement à nos exercices manuels, en automatique, la tentative de retransmettre un JETON en attente ne se fait qu’une consigne sur deux. En effet, il faut continuer à « alimenter » les autres machines qui elles sont disponibles. Avec si peu d’unités en ligne, il arrivera régulièrement que tous les postes soient simultanément indisponibles. Il faut impérativement parer cette éventualité. Quand c’est le cas, le programme ne fait qu’attendre la disponibilité d’au moins une unité pour générer de nouvelles actions.
Normalement, lorsque le mode INFINI est engagé, dans un domaine de loisir c’est uniquement pour tester la fiabilité du matériel et du logiciel sur une longue période. C’est la raison pour laquelle, il me semble toujours séduisant de passer les écrans en économie d’énergie. J’ai déjà exprimé mon point de vue sur cette approche, mais c’est si simple à programmer, (Là franchement je frime, car au contraire une foule de difficultés se sont présentées !) que ce serait dommage de ne pas le faire. Aussi, expérimentons cette possibilité :
32) Cliquer sur le bouton poussoir branché sur l’entrée A1. Attendre que la LED d’Arduino s’illumine pour attester de sa prise en compte puis le relâcher. L’onde se propage et tous les écrans vont s’éteindre. Naturellement avec le B.P. A1 on pourra à tout moment rallumer les afficheurs.
Commentons un peu ce qui se passe sur le réseau. Comme en général les JETONs générés sont valides, et que la majorité du temps un poste de Travail est disponible, globalement chaque consigne impose le TIME_OUT d’environ quatre secondes. Ce délai peut sembler un peu long, vu que la plupart du temps nos systèmes ont des cadences opératoires très élevées. Toutefois, pour un tel réseau c’est extrêmement rapide. En effet, sur une chaine de fabrication flexible, on ne change pas de production trois ou quatre fois par jour, sauf cas très particulier de création d’objets différenciés par la couleur par exemple. Et même dans de tels cas, on doit produire en masse une version de l’objet avant d’en changer, ce qui prend du temps. À quatre secondes par JETON, on en déduit qu’en moyenne il y en aura environ 900 par heure. Dans la pratique, on va constater qu’il en sera généré beaucoup plus, car le nombre de machines étant faible, on est souvent en indisponibilité sur l’une d’elle, et dans ce cas le retour est bien plus rapide. Par exemple sur la Fig.135, le réseau comporte trois machines dont actuellement deux sont occupées. En quelques heures le nombre de consignes envoyé en ligne dépasse les 35000 … et sans le moindre incident. Le matériel et le logiciel sont manifestement fiables et les démonstrateurs semblent tous très stables.
La Fig.136 est relative à un réseau à deux postes de Travail. L’unité n°1 était indisponible, mais la tentative de l’interroger ne retourne pas d’orphelin. Elle est donc à nouveau à l’écoute, mais il faut un JETON de plus pour rafraichir l’écran. Sur l’image de la Fig.137 c’est l’unité n°2 qui est occupée, elle continue à renvoyer l’orphelin. Enfin, sur la Fig.138 qui est relative à un réseau de trois machines supposées d’usinage, on constate que les trois postes de Travail sont simultanément occupés, d’où l’importance de prévoir ce cas de figure. Il se présentera encore plus souvent s’il n’y a que deux unités.
Nous arrivons ici, au terme de nos manipulations. Avant de se quitter, pour celles et ceux qui désirent en savoir plus, il reste à analyser l’agencement des séquences les plus délicates. Si un jour vous désirez établir un tel réseau, ces démonstrateurs simplifés apportent toutefois une architecture qui globalement a fait ses preuves. Il vous suffira de broder …
La suite est ICI.
