Commençant notre visite de courtoisie par la salle électronique S12, les techniciens ont bien travaillé et déjà plusieurs consoles d’exploitation sont presque terminées, tout au moins pour les boutons et les claviers. Ils sont en train de combler certains trous par de superbes gros boutons rotatifs dont l’utilisation n’est pas encore précisée, car les panneaux esthétiques comportant les inscriptions sont toujours bien emballés dans leurs caisses de livraison. Chaque composant est préalablement vérifié électriquement pour être validé avant sont installation sur la console. Ils avancent bien, ce n’est pas ce service qui va ralentir le projet et bousculer le planning.
Codeur rotatif incrémental.
Exclure le potentiomètre qui servait à pointer le LASER, à augmenter ou diminuer la puissance lumineuse ou diriger la TORSION, a été justifié pour des raisons techniques. Composant peu fiable par nature, le remplacer par des technologies plus robustes s’impose naturellement. Ce n’est toutefois pas la seule raison qui incite fortement à le remplacer pas un codeur rotatif incrémental. C’est surtout un critère de qualité opérationnelle d’utilisation de notre pupitre. En effet, le nombre de Consignes dépassait les cinquante dans l’ancienne version. (23 programmes et environ 31 consignes sous forme d’un seul caractère.) Il n’est pas question d’envisager un clavier qui comme celui d’un P.C. permet d’envoyer tous ces « textos ». Nous allons forcément procéder par des sélections sous formes de « MENUs Déroulants ». Hors la rotation d’un potentiomètre fait au maximum 270° et surtout on domine mal sa « progressivité ». Alors qu’avec un codeur incrémental on sait immédiatement que chaque clic d’indexation engendre un pas. Clic clic clic : On s’est déplacé de trois items dans la liste, en avant ou en arrière en fonction du sens de rotation. Coté convivialité on ne peut pas trouver mieux. Du coup, ce qui est très pratique pour déplacer un index sur un menu écran l’est aussi pour diriger un LASER ou doser un éclairage. Le pupitre de JEKERT sera donc muni d’un tel dispositif si agréable à employer, surtout sur un petit pupitre où il y a peu de place.
Mise en œuvre d’un codeur rotatif incrémental.
Qualifié d’incrémental car bien qu’il puisse tourner sans butée autant que désiré, il ne peut occuper de manière stable que des positions bien précises. Il y a quarante indexations par tour pour le modèle utilisé. Désolé chères lectrices et chers lecteurs, je me suis un tantinet fourvoyé. Le didacticiel est rédigé conjointement au développement du projet. Plusieurs semaines y sont englouties. Hors j’avais complètement oublié que la Fiche n°19 décrivait le composant utilisé. Je viens de m’en apercevoir, effectuant un contrôle d’informations sur les documents déjà publiés. Hors je me suis donné le mal d’en refaire une. Comme cette Fiche n°34 est plus complète et surtout documentée avec plus de rigueur, elle rend caduque la Fiche n°19 que vous pouvez ranger précieusement aux oubliettes. Refermons cette parenthèse.
Généralement les codeurs Angulaires fournissent l’information de position sur plusieurs sorties binaires. Pour résoudre le problème des fausses numérisations par décalages temporels subtils sur les changements d’états de plusieurs sorties, on utilise des codes binaires intelligents tel que le code Gray par exemple. Grosse différence, dans notre cas ce n’est pas une position angulaire que l’on désire prendre en compte, mais un incrément de rotation. Du coup deux sorties sont suffisantes pour pouvoir effectuer du « comptage » et déterminer le sens de rotation. La technologie de ces composants ainsi que le principe d’utilisation sont précisés sur la Fiche n°34.
Approche logicielle : Oublions les interruptions.
Souvent traité par interruptions, c’est la première technique qui avait été utilisée sur le démonstrateur initial P21B_Démonstrateur_Raquette.ino qui introduit la gestion du codeur incrémental et celle du gradateur des énergies lumineuses. Dans cette façon de traiter le bouton à encliquetage, nous sommes obligés d’utiliser les broches D2 et D3. Si pour une quelconque raison on désire changer cette affectation, ce sera possible car les interruptions ont été abandonnées. Cette approche qui semblait séduisante s’est avérée catastrophique. Son avantage théorique réside dans la prise en compte aléatoire d’une action sur le codeur incrémental même si le programme est en train de traiter une séquence quelconque. C’est avantage sur le papier n’en est finalement pas un puisque de toute façon le traitement se fait dans la boucle de base, les routines d’interruptions ne faisaient que détecter une rotation, de positionner un booléen pour prévenir la boucle de base, et d’indiquer le sens de rotation. En contrepartie, ce non bénéfice s’accompagnait d’une foule de gros problèmes. Déjà le fait de traiter directement les deux entrées D2 et D3 dans la boucle de base fait économiser plus de 320 octets ce qui n’est pas rien. Le deuxième problème réside dans la spontanéité des interruptions qui réagissent très rapidement. Les rebonds des contacts du codeur engendraient des fausses détections de transitoires binaires, l’antiparasitage se montrant particulièrement difficile à éradiquer, et ce d’autant plus que les codeurs approvisionnés sont de qualité médiocre.
Pour mémoire la Fig.238A redonne le schéma interne. Les contacts électriques X et Y étant de type fugitifs par conception de ce composant, on doit trouver sur les sorties DT et CLK des tensions correspondant à l’état logique « 1 » puisqu’au repos A et B ne sont pas en contact avec la masse GND. Faisons une expérience simple. Ajoutons sur les entrées D2 et D3 deux diodes électroluminescentes pour visualiser les contacts entre X et Y et GND. Le schéma électrique donné sur la Fig.238B est rapidement câblé sur une plaque à essais. La Fiche n°34 en main on déduit qu’au repos les sorties DT et CLK sont au +5Vcc par les résistances de 10kΩ internes au module. Les deux LED sont éteintes. Quand on réalise un pas en rotation, durant un court instant X et Y provoquent un niveau « zéro volt » sur D2 et D3 ces impulsions étant légèrement décalées. On observe un court éclairement des deux LEDs puis les composants optoélectroniques redeviennent noirs. Comme montré sur la Fig.238C les deux contacts X et Y peuvent parfois rester en liaison avec GND et ne n’isole pas. Quelquefois ce n’est qu’une sortie qui reste à la masse. Une LED allumée témoigne de ce type d’incident non conforme à la théorie. Entre les rebonds et les contacts erronés, il a été impossible de dominer les interruptions. Soit sur un seul clic elles déclenchaient plusieurs changements d’options, soit le système se bloquait carrément et le codeur rotatif devenait inerte. Les interruptions ont pour toutes ces raisons été abandonnées.
Gestion logicielle du codeur KY-040
C’est la technique décrite en bas de la Fiche n°34 qui sur le listage de la Fig.228D est mise en pratique sur P21B_Démonstrateur_Raquette.ino et les versions qui suivent. Les transitions montantes sont surveillées dans ce programme sur B soit l’entrée binaire D3. Dans ce but on commence en (1) par déterminer l’état de l’entrée Codeur_B. La variable Transition en (5) a recopié l’état précédent de Codeur_B. Dans le test de la ligne (2) s’il était à LOW et que maintenant il vaut HIGH c’est bien que 
nous détectons un front montant. Le test étant positif on exécute alors tout ce qui est dans le bloc d’instructions {…}. En lisant l’état actuel du Codeur_A en (3) on détermine de sens de rotation et on positionne le booléen Sens_positif. Dans la procédure Traite_Codeur_incremental() en (4) on effectue les instructions concernant le codeur incrémental.
La suite est ici.
