Participant de manière importante à la qualité opérationnelle du pupitre de la pyrograveuse, le codeur rotatif constitue un composant tout compte fait important. En vérifiant dans la liste des fournisseurs qui figure en fin de ce document, je m’aperçois que je n’ai pas précisé de lien, ni pour le codeur, ni pour le buzzer qui impérativement doit être de type actif. Aussi, pour réparer cet oublie voici deux adresses possibles :
Cinq encodeurs incrémentaux :
https://www.amazon.fr/DollaTek-Panneau-d%C3%A9veloppement-dencodeur-rotatoire/dp/B07DK7QRLJ/ref=sr_1_3?dchild=1&keywords=KY040&qid=1591891909&sr=8-3
Dix buzzers actifs. Par exemple chez :
https://www.amazon.fr/Buzzer-Actif-continu-Arduino-Domotique/product-reviews/B00GX6YCBI
Sur le schéma de la Fig.1 du MANUEL.pdf le buzzer est branché sur D4 avec en série une résistance R dont je ne donne pas la valeur. Initialement j’avais placé une 220Ω pour atténuer le bruit car en expérimentation, dans le silence du bureau, un certain « calme » était assez agréable. Mais lorsque la machine ronronne dans la pièce voisine, il n’est plus du tout avantageux de brider ce petit transducteur. Sur le démonstrateur P06_Indexer_le_contenu_carte_SD.ino les broches D2, D3 et D4 sont conforme à l’implantation définitive. En revanche, la LED verte pour informer d’une action sur le clavier n’est que provisoirement branchée sur A3. En version d’exploitation du logiciel cette broche pilotera les petits LASERs rouges de capture d’Origine Machine. La LED verte de diamètre 5mm transitera sur la sortie S0 du MULTIPLEXEUR. Ici aussi il sera avantageux de déterminer la valeur de la résistance de limitation du courant. Vous remarquerez que sur le schéma de la Fig.1 elle semble bien plus faible que pour les autres témoins lumineux, c’est à dire 470Ω. Cette valeur a été retenue sur le prototype, car le rendement lumineux de la candidate employée n’était pas fabuleux, et que de plus je désirais une illumination relativement importante. Le croquis étant téléversé, les branchements effectués, la manipulation de validation est aisée. On suppose que la carte SD avec les neuf images est toujours dans le lecteur. En tournant le bouton ® du codeur incrémental on doit voir le curseur se « déplacer » dans les deux sens et balayer les deux colonnes de l’afficheur. Comme indiqué dans le programme, si le sens de déplacement n’est pas le bon, il suffit d’inverses les deux lignes électriques qui vont sur D2 et sur D3. Si vous cliquez sur le B.P. central du C.I.↓ alors qu’un « oui » est indexé, il ne se passe rien. (Qui ne dit mot … consent !) Si au contraire vous tentez un clic sur la ligne « Img5 — » alors un BIP doit vous interpeller. Tant que le B.P. central du C.I.↓ est appuyé, la LEDs verte du clavier doit éclairer. Encore deux périphériques opérationnels …
Explorer ligne à ligne un fichier image.gco valide.
Avec le démonstrateur P07_Utiliser_le_fichier_indexe.ino, nous n’en sommes pas encore à mettre en œuvre la complexité d’un analyseur syntaxique. Toutefois, démontrer que nous serons capables par la suite de lire ligne à ligne un fichier image de type gco reste fondamental pour démontrer la faisabilité de notre projet. Comme chaque fois que l’on dialogue avec le Moniteur de l’IDE, il importe d’accorder la vitesse de transmission des informations pour les échanges sur la ligne série USB. Soit vous imposez au Moniteur une vitesse de 115200baud, soit vous modifiez l’instruction spécifique dans void setup() {Serial.begin(115200) …
Le croquis effectue alors la lecture du contenu du fichier gco indexé. Si à ce stade le comportement observé est celui attendu, le plus délicat concernant le lecteur de carte SD est résolu. L’analyse du contenu des lignes ne relève plus que du logiciel, ce n’est alors plus qu’une question de patience. Pour la gestion des périphériques, il nous reste encore à intégrer un maillon essentiel de notre chaîne électronique : Le MULTIPLEXEUR dont la présence va faciliter considérablement le pilotage du LASER de puissance basé sur de la PWM. ACTION !
La suite est ici.
