05) Le tableau de maîtrise.

Avouez que ce titre fait bien plus sérieux que si l’on avait choisi : Le PUPITRE de commande. Ce vocable de frimeur nous place dans le poste de pilotage d’un avion de ligne, et avec une assurance d’acteur de cinéma on se voit déjà admiré par les personnes présentes dans le local. Bon, arrêtons immédiatement ce délire, et passons en revue les dispositifs qui sont à la disposition de l’opérateur pour utiliser la machine ou en assurer sa gestion technique. On sera en présence de l’indispensable, et aussi d’un superflu relativement secondaire. Commençons par le nécessaire, à savoir le « dialogue Homme/Machine« . La notion de dialogue suppose une entité qui parle, et une qui écoute. Puis les rôles s’inversent. Commençons par parler puisqu’en tant qu’utilisateur nous somme sensé donner des consignes.

Les organes sensoriels de la machine.

Outre les différentes broche configurées en Entrée binaire ou analogique, globalement le programme écoute l’utilisateur à travers deux « oreilles » qui sont le petit clavier à cinq touches et le codeur incrémental muni de son bouton poussoir central. Pour nous répondre et nous faire savoir ce qu’il a compris, sa « bouche » est matérialisée par l’afficheur OLED qui lui sert à rendre compte et répondre à nos questions. Sur un RESET, il affiche le Menu de base, (Voir Fig.13) qui nous précise ce qu’il peut faire pour nous satisfaire. Si on tourne le bouton ®  du codeur incrémental, en fonction du sens de rotation il déplace le curseur pour « accuser réception ». Quand on clique sur X+ → ou que l’on sollicite le B.P. central du C.I.↓  il en déduit que l’on désire qu’il invoque la fonction actuellement désignée par l’index. CLAVIER et ECRAN constituent la clef de voûte pour l’établissement du dialogue Homme/Machine, raison pour laquelle il faut en soigner l’ergonomie et la convivialité. Le premier critère pour satisfaire ces exigences consiste à placer les touches et le bouton du codeur rotatif dans une position et une orientation agréable à leur usage. Par ailleurs, l’écran doit lui aussi se trouver bien en vue sans obliger l’opérateur à des contorsions malcommodes.

Ergonomie matérielle, ergonomie logicielle.

Impactant directement la qualité opérationnelle, c’est à dire l’agrément d’utilisation de la machine et son efficacité, il est vital dans tout projet de consacrer beaucoup de temps à ces deux aspects qui conditionnent la convivialité de l’ensemble. L’ergonomie matérielle concerne le confort physique, alors que c’est le logiciel qui devra assurer l’agrément opérationnel, c’est à dire la facilité d’interprétation des données affichées, et induire les réactions de l’opérateur.
Pour atteindre ce but, après divers essais de validation, la solution retenue consiste en fin de compte à disposer d’un petit PUPITRE incliné à 36° par rapport au plateau de la machine. La disposition du clavier et du codeur rotatif situés de part et d’autre de l’afficheur OLED privilégie les manipulations par des droitiers. (Tourner un bouton est matériellement plus « compliqué » que se contenter d’appuyer sur un bouton. Donc le codeur rotatif est placé à droite et le clavier à gauche.) Si vous êtes gaucher, je vous suggère d’intervertir ces deux périphériques. Comme l’opérateur agit tout en surveillant les affichages sur OLED, c’est la raison pour laquelle ce dernier est situé entre les deux. La Fig.6 en page 4 du document PLANS.pdf présente clairement la zone relative au pupitre sur l’ensemble de la machine, ou plus particulièrement sur le statif. Il vous sera facile de constater sur les dessins cotés, que l’inclinaison par rapport à l’horizontale est de 36°. Cette pente a été choisie après divers essais sur des maquettes improvisées en carton rigide pour déduire la meilleure inclinaison pour optimiser l’ergonomie matérielle tout en satisfaisant les contraintes matérielles. (Pour loger les organes comme le galvanomètre 100µA par exemple et accéder au sectionneur de SÉCURITÉ …)

L’ergonomie logicielle résulte de plusieurs éléments auxquels il faut toujours consacrer du temps, je crois même qu’il faut commencer par établir un scénario d’utilisation de la machine avant d’écrire la moindre ligne de code pour Arduino et de percer des trous dans des profilés. On commence par définir tout ce que l’on aura envie de faire sur la machine, et on ajoute tout ce que l’on devra assumer, comme la maintenance par exemple. Puis on élabore des protocoles. On cogite, on simplifie,

on efface, et l’on remet en cause. Arrive le moment où l’on a élaboré une stratégie cohérente. Par exemple, les études initiales incitaient à utiliser un clavier à seize touches disponible dans mon « Mécano Truc Informatico Arduinesque ». Puis, les études de faisabilité ont consisté à assembler des modules électroniques, et à aligner les premières ligne de code. L’usage et l’expérimentation font alors émerger de bonnes idées et éliminent des solutions immédiates qui s’avèrent d’une convivialité médiocre. C’est dans ce cadre que le clavier a fondu à cinq touches auquel on peut ajouter le bouton central du codeur rotatif incrémental.

Typique de ce que peut être une machine virtuellement matérielle, oxymore qui traduit un dispositif démonstrateur visant à confirmer la faisabilité, la Fig.12 montre le bric à brac qui sur le bureau de l’ordinateur assemble petit à petit les différents organes de la future machine en gestation. En effet, il serait bien pénalisant de passer des heures à peaufiner l’affichage du contenu d’une carte SD si par la suite on n’arrive pas à gérer le lecteur de carte et d’en extraire les informations contenue dans un fichier image. Aussi, la faisabilité consiste à écrire des séquences de programme minimales pour s’assurer que nous serons capables d’afficher des textes sur l’écran, de décortiquer un fichier gcode, de faire tourner les moteurs, et d’allumer à notre convenance le LASER de puissance. Aussi, bien que la Fig.12 ne soit qu’une pyrograveuse virtuelle, car pour le moment les chariots n’existent que dans les octets de fichiers informatiques, sur le bureau sont déjà interconnectés tous les modules vitaux de la machine. Comme le développement du programme prend des semaines, vous pouvez constater en A le support de l’afficheur et du codeur incrémental … ergonomie minimale impérative !
En B des « bricolos » complémentaires permettent d’élaborer des stratégies, avec un peu caché en C un support avec des LEDs et autres composants. Sur cette photographie, on peut remarquer l’approche progressive des solutions adoptées. Par exemple sur l’écran OLED l’affichage du contenu d’une carte SD est en cours de développement pour en dégager l’ergonomie visuelle. Les protocoles d’exploitation commencent également à tenir la route, et pour en démontrer la pertinence, le clavier définitif qui sera intégré à la pyrograveuse est développé et mis en service. Prenez un peu de temps pour me rendre une petite visite et voir le bureau de l’ordinateur sur Image25.JPG qui se trouve dans le dossier <Galerie d’images\Les circuits électroniques>. L’espace « de confinement » pour programmer Arduino est très réduit. Pourtant, dans ce fatras de liaisons électriques et d’éléments hétéroclites, pratiquement l’intégralité des modules qui conditionneront la future machine est opérationnelle, et le logiciel déjà bien avancé. Ça tourne …

Une approche prudente et chronologique.

C’est durant cette phase primordiale où petit à petit les éléments s’ajoutent, tant mécaniques, électroniques, informatiques, et que se dégagent les besoins avec une ergonomie logicielle qui s’étoffe au fil des expérimentations. Développer un projet n’est pas un processus linéaire, mais une suite d’atermoiements avec des avancés et des reculs, des remises en cause fréquentes, pour lentement mais surement « faire émerger le futur ». On peut ainsi s’assurer que les protocoles envisagés sont réellement agréables lors de l’usage de la machine. C’est par exemple au cours de ces « démonstration » que la nécessité de prévenir l’opérateur que le programme P20_Programme_exploitation.ino attend une action sur le clavier, qui sur notre machine prend la forme d’une LED verte qui se met à clignoter. Parallèlement on développe les dessins, on commande les éléments mécaniques, mais surtout on ne commence pas à percer tous les trous dans les plaques qui vont constituer le statif, car à ce stade, nous ne savons pas encore quel sont tous les modules qui devront s’y voir assembler. La répartition de ces derniers ne sera raisonnable que lorsque électronique et informatiques seront pratiquement aboutis. Et surtout, lorsque l’on sera certain que l’on a pensé à tout, il faudra prévoir sur le statif dans toutes les zones encore « vierges », des emplacements pour des circuits imprimés supplémentaires et percer les trous pour leur fixation éventuelle. Le pire ennemi pour un concepteur réside dans la précipitation, ne pas résister et débuter trop prématurément les usinages.

La suite est ici.