Protocole optimisé relève d’un pléonasme, car par définition un protocole est constitué d’une suite d’actions établies par l’expérience en vue d’aboutir à un maximum d’efficacité dans le domaine concerné. En ce qui nous concerne, le but consiste à préparer un texte en vue de le pyrograver, puis à le compiler pour en faire un fichier.gco que pourra traiter la machine. Comme il faut ensuite charger ce fichier sur une carte mémoire SD, l’insérer dans le lecteur de la pyrograveuse puis déclencher le processus, l’idéal consiste à pouvoir vérifier sur l’ordinateur que ce qui sera obtenu corresponde exactement à ce que nous désirons avant d’engager toutes ces manipulations.
Rédiger rapidement un texte.
Indispensable, la fiche Protocole pour rédiger un texte a été imprimée et plastifiée. Outre les techniques optimisées pour préparer notre « verbiage », l’autre coté de la fiche nommé méthode pour tester les « images texte » sera particulièrement utile pour nous permettre de sélectionner la grandeur du texte en fonction du contexte souhaité, c’est à dire des options d’encadrement.
À titre d’exemple, on suppose que vous vous préparez à recevoir des amis à Noël et que pour la circonstance vous placerez une petite pancarte à la porte d’entrée. Vous prévoyez le texte suivant :
(Comme vous le constaterez rapidement, les caractères de substitution ne sont finalement pas très souvent rencontrés, d’où la dernière phrase pour y avoir recours dans cet exemple.)
Première étape, avec un traitement de texte banal comme le 
par exemple, rédiger le texte sans finesse. (Fig.29A.) On désire que la petite pancarte soit la plus grande possible avec un minimum de grandeur de caractère de 2. Avec « $g3« on se rend rapidement compte que le nombre de lignes dépassera la hauteur possible. On décide donc une grandeur double avec « $g2« qui imposera un maximum de 22 symboles en largeur. On recopie le texte A pour constituer en C des lignes les plus larges possibles, mais dont le nombre de caractères restera inférieur à 23, tout en évitant de couper des mots car un trait d’union est considéré personnellement comme peu esthétique. Pour faciliter le repérage en largeur on a tracé la ligne d’étoiles B qui évidemment comporte 22 symboles. L’étape suivante E commence par une approche « artistique », c’est à dire que l’on ajoute à gauche des espaces (Repérés en jaune sur la copie d’écran.) pour équilibrer le texte et lui donner un peu l’allure d’un générique de cinématographe. Avant cet artifice, on compte le nombre de caractères dans la ligne la plus large et en D on ajuste la ligne d’étoiles. La phase qui suit est primordiale, elle consiste à remplacer les symboles concernés par leurs caractères de substitution. Comme on peut être amenés à substituer l’élément par deux caractères comme pour le Å’ , il s’en suivrait une augmentation « artificielle » de la largeur de la ligne. C’est la raison pour laquelle, si l’on désire centrer les groupes de mots, il faut le faire avant la phase des substitutions.
La dernière étape en F sert à transformer le texte en une ligne unique acceptable dans la fenêtre d’édition du Moniteur pour laquelle le « retour de chariot » pour passer à la ligne n’est pas possible car il valide la ligne saisie. La technique la plus simple consiste à ajouter un ‘$‘ à la fin de chaque ligne située au dessus en partant du bas vers le haut, et de frapper la touche [Suppr] pour enlever le « retour de chariot » parasite. On aboutit à une ligne unique de 164 symboles.
Vérifier le résultat compilé avant de créer un fichier.
Difficile d’imaginer à l’avance ce que donnera un texte en fonction de ses particularités. L’aspect général sera influencé notamment par la largeur des caractères. Contrairement à la police utilisée sur le Moniteur, celle du compilateur génère des tracés dont la largeur sera affinée dans le but d’obtenir un résultat visuel le plus esthétique possible. Par exemple en largeur constante, le ‘i‘ majuscule engendrerait un écart trop important. Le ‘n‘ est plus étroit que les autres caractères, alors que ‘w‘ ou ‘W‘ sont plus larges. Ainsi ils sont moins « tassés ». Lorsque vous avez regardé la Fig.14 pour la première fois, je doute fort que vous ayez remarqué ces subtilités. On constate globalement un texte dont l’apparence des divers caractères semble homogène. Hors, manifestement la ligne des lettres minuscules est plus large que celle située au dessus, pourtant elles sont identiques au point de vue « grammatical ». Aussi, pouvoir vérifier l’impression finale d’une compilation peut amener à modifier légèrement les lignes pour mieux les équilibrer, évitant ainsi de nombreuses manipulations entre l’ordinateur et la pyrograveuse sans compter l’économie réalisée en matériaux à graver.
La technique va consister à utiliser Repetier-Host, peu importe sa version, pour visualiser les déplacements du LASER. Fiche Méthode pour tester les « images texte » en main on expérimente :
• Pour conserver sur le bureau le qui contiendra le texte initial, on ouvre une deuxième instance de ce traitement de texte. Puis comme indiqué sur la fiche on sauvegarde son contenu, c’est à dire « rien du tout » sous un nom tel que TEST.gco par exemple.
• On prépare le « vérificateur » en ouvrant 
et on charge une première fois TEST.gco pour qu’il enregistre « le chemin » sur le H.D. puis on valide les deux options et .
• Attention : Sur la fiche, il n’est pas précisé un point important. Pour que visualise les déplacements du LASER il faut impérativement cocher l’option Montrer les mouvements de déplacements. (Voir Fig.30)
• RESET sur le compilateur puis « $g2″ suivi de « $d« pour imposer nos préférences.
• Commande « $v« pour forcer un positionnement optimisé.
• Dans le premier on copie avec [Ctrl c] la longue ligne de 164 symboles.
• Dans la ligne de saisie du Moniteur on colle avec [Ctrl v] cette longue ligne et on la valide.
• Le futur résultat Fig.29 semble correct, donc on valide avec la réponse ‘o‘.
• Frouttttt, ça compile rapidement. L’ensemble de ce que liste le programme sera commenté dans un prochain chapitre. Le code objet.gco est contenu entre les deux lignes « ================ ». Surligner ces 1353 lignes de code et les copier avec [Ctrl c].
• Dans le traitant TEST.gco coller ce code avec [Ctrl v]. Si l’option Barre d’état dans l’onglet Affichage est cochée, en bas à droite on doit avoir 
.
• Avec [Ctrl s] on sauvegarde le contenu.
• Enfin, comme indiqué sur la fiche on active la fenêtre de puis on clique sur 
en 1, et un peu à gauche sur le nom du fichier en 2 pour voir le résultat qui ressemble à la copie d’écran de la Fig.31 sur laquelle on peut constater que le texte sera effectivement centré dans un cadre double. Globalement les lignes sont bien équilibrées. On peut noter que la dernière ligne (Repéré en bas en bleu.) comporte la lettre ‘p‘ avec une queue inférieure. Le cadrage en a tenu compte.
Graver : La finalité de tous ce processus.
Simulation encourageante avec , les manipulations ne sont pas terminées, car nous allons mener le processus à son terme, c’est à dire pyrograver. Ce n’est qu’à ce stade que sera révélée une pleine réussite, ou que des détails imprévus assombriront notre enthousiasme.
• Sauvegarder TEST.gco sur la carte mémoire SD et le renommer Img5.gco par exemple.
• Insérer la petite mémoire de masse sur le lecteur de la pyrograveuse et sélectionner le bon fichier. Cliquer sur la touche 
pour vérifier que c’est la bonne image. Le programme de la machine estime à environ dix minutes la durée exigée par le traitement.
• Déclencher le processus avec 
. Comme pour n’importe quel fichier le LASER est déplacé à l’Origine Image, c’est à dire dans l’angle inférieur gauche du cadre pour notre cas. Le LASER est en mode pointage et l’on doit placer la cible sur le plateau de la machine. (Dans la réalité le temps pour graver sera de 19 minutes.)
ATTENTION : Bien que la taille des caractères ne fait que deux fois celle de la plus petite police, l’encadrement occupe 212mm de large et 158mm de hauteur. Aussi, comme on peut le voir sur la Fig.32 prévoir une cible de surface suffisante avant de la positionner sur la machine.
À comparer avec la prédiction de la Fig.31 le résultat sur la machine montré en Fig.33 est très proche de ce que l’on pouvait imaginer à l’aide de la simulation de . Bien que ce logiciel soit conçu à la base pour piloter des imprimantes 3D et qu’il ne soit absolument pas prévu pour du gravage 2D à l’aide d’un LASER, on observe que pour cette application il soit très fiable, et constitue une aide précieuse pour s’assurer de l’aspect final que présentera le texte pyrogravé.
Certaines et certains vont certainement se demander si ce compilateur est vraiment pertinent. Pourquoi ne pas rédiger le texte dans PAINT.exe par exemple, puis le compiler avec LaserGRBL.exe comme explicité dans le didacticiel relatif à la pyrograveuse. C’est tout à fait possible bien entendu. Du reste le plus persuasif consiste à effectuer la manipulation. Vous charger 
dans LaserGRBL.exe et vous le compilez avec les paramètres conseillés dans le didacticiel sur la pyrograveuse. Pensez à imposer une largeur de 21,2cm.
Vous pouvez vérifier en chargeant le résultat 
dans que la taille du code objet fait maintenant 7049 lignes au lieu de 114. Il faudra donc 61 fois plus de temps pour le graver, soit environ 19 heures ! Aussi, en ce qui me concerne, pour les quelques euros que l’on investit dans la carte Arduino NANO et les bricoles qui vont autour, il n’y a pas à hésiter. La balance penche largement du coté du compilateur. Seule petite ombre au tableau, le caractère ‘n’ est un peu étriqué et nuit à mon sens à l’équilibre de l’ensemble, il faut le modifier.
La suite est ici.
