Graphtec CE6000-60 sous Linux

Piloter le traceur de découpe Graphtec CE6000-60 depuis Linux, sans aucun driver, et convertir un SVG en HP-GL prêt à couper.

Le CE6000 n'est pas une imprimante à pilote propriétaire : c'est un traceur qui lit des commandes texte. Le « driver » Windows (Cutting Master / Graphtec Studio) ne fait que traduire des courbes en HP-GL et pousser le résultat sur le port. Tout ce travail se refait en Python.

Au bout : une application, pupitre.py, qui ouvre un SVG, le place, le découpe en panneaux, le perfore, règle la machine et l'envoie. Le reste du dépôt est ce qu'il a fallu comprendre pour l'écrire — y compris le protocole propriétaire de Graphtec, relevé en capturant le flux USB de son propre logiciel.

• Par où commencer
• Le pupitre
• Vérifier qu'on n'a rien cassé
• Les outils
• Les réglages de l'établi
• La force d'offset déchirait le papier
• La machine mesure sa propre lame
• Le débordement à zéro déchirait chaque coin de départ
• Les repères ARMS, mesurés au pixel
• Les pièges
• Ce qui a été mesuré sur la machine
• Tracer une planche TechDraw au stylo
• Dessiner et couper au quotidien : Inkscape
• Le protocole propriétaire TC, et l'enquête qui l'a percé
• Quand utiliser quoi
• L'état des lieux au 11/08/2026
• Ce qui n'est PAS fait ici
• Licence

Par où commencer

./installer.sh          # une fois : « Pupitre de tracé » apparaît dans le menu

Ensuite on clique l'icône, et rien d'autre. Le pupitre ouvre un SVG, le place sur le média, le découpe en panneaux s'il est trop grand, règle la machine et l'envoie — feuille par feuille s'il le faut.

Le dépôt s'organise en trois étages, du quotidien vers l'archéologie :

pupitre.py	l'application — c'est le seul fichier à lancer
svg2hpgl.py, envoyer_hpgl.py, gabarit_traceur.py, nuancier_force.py, preparer_planche.py	les mêmes traitements en ligne de commande, pour le lot et les scripts
conditions.py, materiaux.py, mosaique.py, etat_machine.py, theme.py, icones.py	le moteur, importé par les précédents
sondes/	les huit programmes qui ont servi à comprendre la machine, pas à s'en servir. On n'y touche que pour reprendre l'enquête
tests/	trois suites, dont une qui vérifie que les deux autres savent échouer

Le pupitre

C'est l'application, et le seul fichier à lancer. Trois onglets.

Dessin — ouvrir un SVG, le placer sur le média (origine, rotation, miroirs, échelle, « ajuster au média »), le découper en panneaux quand il est plus grand que la feuille, le perforer en pointillé pour un gabarit détachable. L'aperçu montre le média, la zone utile, le tracé et les tuiles numérotées ; molette pour zoomer, glisser pour déplacer, double-clic pour recadrer.

Outil — le carnet d'établi en tête : choisir « papier 300 g » pose d'un coup le type de lame, la vitesse, la force, l'accélération, les passages et les cotes de perforation, puis rappelle ce qui ne se pilote pas (la sortie de lame se règle à la main). En dessous, les huit conditions de la machine avec leur contenu affiché — la condition active marquée d'un point — qu'on peut lire et écrire une par une. Et le nuancier de force, une grille de carrés à lever pour trouver le bon réglage sur un papier neuf.

Machine — les huit réglages du menu de la machine, lus à la demande et écrits un par un avec relecture : passe-pas, force et angle d'offset, tri des chemins, vitesse de l'outil relevé, priorité de condition, position de lame initiale, déplacement relevé.

Tout ce qui est écrit dans la machine est relu derrière, et l'envoi est annulé si un réglage n'a pas été retenu : tracer avec des réglages qu'on croit posés et qui ne le sont pas gâche le média.

Vérifier qu'on n'a rien cassé

python3 tests/lancer.py     # les trois suites

tests/test_traceur.py vérifie dix propriétés sans la machine. tests/verifier_les_tests.py casse chacune et exige que le test la voie. tests/test_pupitre.py inspecte l'interface elle-même.

Chaque test rejoue une faute RÉELLE de la mise au point, pas une faute imaginable : coordonnées décimales, croix de raccord unique, repassage qui coûte un trajet de retour, rainage « corrigé » en découpe, réglage hors des bornes que la machine écrête en silence.

Le second programme est le plus important. Une suite qui passe ne prouve rien — elle peut ne rien surveiller. Cette journée a produit cinq détecteurs successifs qui annonçaient « aucune erreur » sur des séquences qui en produisaient : l'un comptait un journal vide comme zéro, l'autre comptait les entrées d'un tampon circulaire dont le total ne peut pas bouger, un troisième polluait ce qu'il mesurait. Aucun n'avait été éprouvé avant de servir.

tests/verifier_les_tests.py introduit chaque faute en mémoire et exige que le test correspondant échoue. Un test qui passe malgré la faute est signalé comme aveugle.

tests/test_pupitre.py vient d'une faute que seule une capture d'écran avait vue : la liste « outil » avait DISPARU de l'interface, une renumérotation des lignes s'étant appliquée en cascade — 1 devient 3, puis 3 devient 5, puis 5 devient 7 — jusqu'à ce que le champ occupe la case d'un autre. Rien n'avait protesté : le fichier compilait, le champ existait, il répondait aux réglages. Il n'était plus visible, voilà tout. Qt empile deux widgets rangés dans la même case sans un mot. Le test le dit maintenant, et il a été éprouvé en remettant la faute.

Les outils

sondes/sonde_ce6000.py — interroger la machine

N'envoie que des requêtes de lecture : aucun mouvement.

python3 sondes/sonde_ce6000.py

Rend l'émulation active, la zone utile, la position, le statut et la résolution. C'est le premier réflexe quand quelque chose ne répond plus.

sondes/trace_controle.py — un F dans un rectangle de 100 × 50 mm

Fait bouger le chariot. À n'exécuter qu'avec un stylo monté.

python3 sondes/trace_controle.py --simuler   # affiche le HP-GL, n'envoie rien
python3 sondes/trace_controle.py             # trace

Le F n'est pas décoratif : c'est la seule lettre qui trahit d'un coup d'œil une rotation et un miroir, là où un rectangle seul ne dit rien. Le rectangle se contrôle au pied à coulisse — un écart de 2 % ne se voit pas à l'œil et se retrouve ensuite sur chaque pièce.

svg2hpgl.py — convertir un SVG

python3 svg2hpgl.py dessin.svg                    # écrit dessin.hpgl
python3 svg2hpgl.py dessin.svg --envoyer          # + envoie à la machine
python3 svg2hpgl.py dessin.svg --pivoter --marge 5,5

Option	Effet
--sortie	fichier .hpgl (défaut : à côté du SVG)
--outil N	condition de coupe du panneau, 1 à 8
--vitesse N	vitesse en cm/s (défaut : celle de la condition)
--force N	force 1 à 38 (défaut : celle de la condition)
--marge X,Y	décalage du dessin en mm
--pivoter	rotation 90°, met le grand côté dans l'avance
--brut	garde l'ordre du SVG au lieu d'optimiser le trajet
--envoyer	envoi réel — sans cette option, rien ne part

Il réutilise parse_svg_file() de LaserAtelier (~/.local/share/FreeCAD/v1-1/Mod/LaserAtelier/svg_import.py) : ses points sortent déjà en millimètres, déjà en Y-vers-le-haut, déjà ramenés à l'origine du viewBox — c'est-à-dire déjà dans la convention HP-GL. Le retournement d'axe écrit pour FreeCAD sert ici tel quel.

Attention : svg_import.py (de LaserAtelier) ne convertit que les <path>. Un <rect>, <circle> ou <polygon> serait traversé sans géométrie et sans avertissement — le SVG sortirait vide, en silence. svg2hpgl.py les détecte et le dit. Dans Inkscape : Chemin → Objet en chemin.

L'optimisation de trajet est un plus-proche-voisin, donc glouton : il ne voit pas le retour final et peut sortir un ordre pire que celui du SVG. Le script mesure les deux et ne garde le sien que s'il gagne — sur 3 chemins il déclare forfait, sur 40 pastilles dispersées il économise 70 % du déplacement à vide.

Les réglages de l'établi

materiaux.py porte le carnet de Christophe — huit matériaux réglés à l'usage, sous Windows, avant tout ce travail. Ce ne sont pas des valeurs calculées : elles ont été trouvées en coupant du papier.

Matériau	Vitesse	Force	Épaisseur	Lame
ingres 80 g	40	10	0,10	0,17
vinyle 0,20 mm	20	12	0,10	0,13
papier 80-90 g	20	10	0,10-0,15	0,25
aquarelle 200 g	20	14	0,30	0,35
canson 224 g	20	2 ?	0,30	0,40
papier 300 g	7	25	0,40-0,45	0,55
feutre Staedtler	27	15	—	2 passages
stylo Bic	30	10	—	2 passages

Trois choses qu'on n'aurait pas devinées :

La hauteur de lame suit l'épaisseur — 0,10 mm de papier demande 0,17 de lame, 0,42 en demande 0,55. C'est un réglage physique sur le porte-lame, qu'aucune commande ne touche et qu'aucune force ne rattrape.

La perforation s'écrit 8 mm / 0,25 mm : longueur coupée, longueur laissée. Voilà ce que sont les « Style 1 à 9 » du logiciel Graphtec.

Les plumes se tracent en DEUX passages. La réponse au trait pâle de nos premiers essais était dans ce carnet.

Une valeur reste douteuse et n'est pas corrigée en douce : le canson 224 g à force 2, quand l'aquarelle de même épaisseur en demande 14 et le 300 g en demande 25. Probable faute de recopie pour 20 — à retrouver au nuancier.

La force d'offset déchirait le papier

Mesuré le 13/08/2026, deux carrés sur la même feuille. Même papier 80 g, même CB09U, même force de coupe 10, même vitesse — une seule chose différente :

	FORCE OFFSET	résultat
carré de gauche	4	quatre bords propres et droits
carré de droite	30	un bord déchiqueté sur toute sa longueur, fibres arrachées, une languette restée accrochée

FORCE OFFSET n'est pas la force de coupe : c'est celle de la découpe légère qui oriente la lame avant de partir. Le manuel le dit — « cette FORCE la plus faible possible est nécessaire par rapport à la découpe normale » — et sa valeur par défaut est 4, plage 1 à 38 sur le -60.

À 30, elle valait trois fois la force de coupe du 80 g. L'orientation de lame n'était plus une caresse mais une coupe à part entière : elle laboure au lieu de pivoter.

D'où venait le 30 ? De Graphtec Studio, qui l'affiche à 30 dans ses captures et l'écrit dans la machine. Il abîmait donc chaque départ de découpe depuis toujours, sans que rien ne le signale — ni le panneau, ni le logiciel, ni le journal d'erreurs.

Le réglage se pose depuis le pupitre, onglet Machine, champ force d'offset. Il sert aussi au contrôle de rotation de la lame en mode tangentiel : si un jour la condition n° 8 (CB15U, TANGENTIAL MODE = 1) sert pour du matériau épais, c'est le seul cas où il faudra le remonter.

Ce que cette planche rappelle : la question était « le petit crochet au départ vient-il de là ? », et un seul carré n'y aurait pas répondu — il aurait dit « ça marque » sans dire par rapport à quoi. Deux carrés, tout identique sauf une chose, et la réponse se lit sans instrument.

La machine mesure sa propre lame

Trouvé dans le manuel le 13/08/2026 (page 2-48), après treize ans d'usage de la machine. La sortie de lame est la seule cote de la chaîne qu'aucune commande ne règle — mais elle se mesure, et la machine dit elle-même de combien tourner la molette.

[COND/TEST] → flèche POSITION jusqu'à CONDITION (3/3) → [3] (AJUSTEMENT LAME).

1. molette rentrée à fond vers la gauche ;
2. porte-lame en position 1 (arrière) — ailleurs l'ajustement refuse ;
3. [ENTER], puis [1] pour poser la longueur cible ;
4. [2] (VÉRIFIER) : elle descend et remonte l'outil, affiche T la cible et H le réel, et le nombre de tours à faire ;
5. tourner, re-vérifier, jusqu'à ce que H rejoigne T. [3] pour finir.

Avertissement du manuel, qui compte sur du papier fin : « selon la matière chargée, la lame pourrait s'enfoncer dans le média, ce qui rend impossible une mesure précise ». Si H s'affole sur du 80 g, mesurer sur une chute ferme : la lame ne change pas de longueur selon le papier, seule la mesure en dépend.

Ce que ça change pour le carnet d'établi : les cotes de sortie de lame (0,17 pour du 0,10 mm, 0,55 pour du 0,42) cessent d'être des intentions pour devenir des réglages vérifiables. Jusque-là, rien n'attestait qu'une lame était bien où on croyait l'avoir mise.

Le débordement à zéro déchirait chaque coin de départ

Mesuré le 13/08/2026, et c'est le défaut le plus ancien du lot.

Symptôme : sur un nuancier de treize carrés, tous portaient une languette arrachée au même coin, et dès les forces les plus faibles. Un défaut qui revient à la même place et ne dépend pas de l'appui n'est pas une affaire de force : il est géométrique.

Cause : la pointe de la lame traîne derrière l'axe du porte-outil — c'est le principe même du déport. Quand le contour se referme et que l'outil se lève, la pointe n'a pas encore atteint le coin. Il reste une languette non coupée, qui se déchire quand on pousse la pièce.

Le remède est un réglage que la machine porte déjà, à zéro sur la condition de découpe :

[No.1]  OVERCUT S.E. = 0.0mm, 0.0mm     ← celle qu'on employait
[No.8]  OVERCUT S.E. = 0.2mm, 0.2mm     ← un préréglage Graphtec

Posé à 0,2 mm sur la condition 1, les carrés se détachent proprement.

Deux paramètres nommés au passage, cherchés parce qu'on en avait besoin — la meilleure façon de trouver :

	condition 1	condition 8
TC1002,9	0,0	40,40	débordement, début et fin, 200 par mm
TC1002,8	0	1	mode tangentiel

Et ça fausse toute lecture de nuancier. Un carré qui se déchire au lieu de se détacher ne permet pas de juger « est-ce qu'il se détache proprement ? ». Le seuil du 80 g, relevé à 8 tant que le débordement était nul, est tombé à 7 une fois corrigé — et la force retenue de 10 à 8.

Les repères ARMS, mesurés au pixel

Le manuel ne donne la forme des repères qu'en image, illisible par extraction de texte. Christophe a fait engendrer par Graphtec Studio les six variantes (2, 3 et 4 points, types 1 et 2) ; les PDF sont raster, donc sans géométrie vectorielle non plus.

Ils ont donc été rendus à 300 dpi et mesurés au pixel :

forme	un L, deux branches à angle droit
branches	20,0 mm — le MARK SIZE=20.0 du vidage
épaisseur	1,0 mm
aire	38 mm², qui recoupe 2 × 20 × 1 moins le coin

Les quatre repères portent les quatre orientations, chacun encadrant son coin de la zone utile. Sur l'A4 fourni, ceux de droite sont tronqués par le bord : Studio dessinait pour un média plus large.

gabarit_arms.py engendre le gabarit aux cotes relevées, que le traceur dessine lui-même — il n'y a pas toujours une imprimante sous la main, et la machine pose la géométrie au dixième.

python3 gabarit_arms.py --media 210x297 -o reperes.svg

Tracer au stylo, puis remplir au marqueur NOIR. Le capteur est réglé pour du noir franc sur du blanc ; un contour au stylo ne suffit pas, et le remplissage en hachures (--hachures) reste gris. Le manuel ajoute deux limites : matière de 0,3 mm au plus — donc le 80 g, pas le 300 g — et presse-papier activé, sans quoi la feuille se soulève pendant le balayage.

Les pièges

1. Hors de l'état READY, la machine ne lit pas son tampon d'interface. Elle avale les octets sans répondre ni bouger — le symptôme est identique à une panne de liaison. Après un redémarrage elle redemande le type de média ; tant qu'on n'a pas répondu, rien ne se passe. svg2hpgl.py refuse d'envoyer si OH; reste muet, précisément pour ça.

2. L'endpoint d'envoi fait 8 octets et refuse les données quand la machine sature (EAGAIN en O_NONBLOCK). Écrire sans attendre tronque les gros fichiers en silence. C'est le contrôle de flux du port série sous une autre forme — l'USB ne l'a pas supprimé.

3. « Charger le vinyle » qui ne part pas : la feuille est trop étroite. Les capteurs de média sont sur la table, et une feuille qui ne les couvre pas n'est jamais détectée — le levier descend, tout a l'air normal, et la machine réclame indéfiniment. Vérifier aussi que chaque galet presseur est à la fois sur le papier et au-dessus d'une bande d'entraînement granuleuse : un galet qui pince dans le vide donne le même symptôme.

4. Les réponses se terminent par \r et s'accumulent. Sans vider le tampon d'entrée avant chaque requête, elles se chevauchent. Et la toute première interrogation après ouverture revient décalée : conditions.instantane en jette une pour rien, sans quoi trois relevés identiques n'en donnent que sept paramètres sur onze, l'accélération lue à l'index d'un autre.

5. COMMANDE = AUTO fait IMPRIMER le fichier au lieu de le tracer. La machine devine le langage d'après ce qu'elle reçoit ; quand elle se trompe, elle écrit les octets en toutes lettres, à la plume, sur le média — puis affiche « hors surface » quand la ligne sort de la feuille. Une conséquence qu'on prend volontiers pour la cause. Mettre COMMANDE sur HP-GL au panneau. La machine met elle-même en garde, dans son journal : W06001 DANGER COMMANDE = AUTO.

6. Fermer et rouvrir /dev/usb/lp0 entre deux étapes rend la machine MUETTE, pour des dizaines de secondes. Une lecture du journal suivie d'un OH; répond du premier coup sur un même descripteur, et se tait plus de 44 secondes si l'on referme entre les deux. Toute la chasse aux « pannes intermittentes » d'une journée se réduit à ça. Chaque programme n'ouvre donc le périphérique qu'une fois, et passe son descripteur.

   Corollaire d'usage : ne pas lancer etat_machine.py juste avant un envoi.

Ce qui a été mesuré sur la machine

Relevé à l'établi le 10/08/2026, en interrogeant le traceur et au pied à coulisse — pas recopié d'une documentation.

Fait	Valeur
USB	0b4d:1122, classe imprimante, bidirectionnel
Périphérique	/dev/usb/lp0 (root:lp) — ni udev, ni libusb, ni pyusb
Endpoints	EP1 OUT 8 octets, EP2 IN 64 octets
Langage	INTERFACE → COMMANDE doit être sur HP-GL, PAS sur AUTO — voir ci-dessous
Émulation	7586 (OI; → 7586), et non 7550
Résolution	40 unités/mm sur les deux axes (OF; → 40,40)
Repère	origine coin bas-gauche, aucun miroir
Axes	X = avance du média, Y = course du chariot
Zone utile	OH;, dépend du média chargé (A4 → ~256,8 × 187,1 mm)

COMMANDE = AUTO fait imprimer le fichier au lieu de le tracer

Résolu le 11/08/2026, après une journée à chercher ailleurs.

En AUTO, la machine devine le langage d'après ce qu'elle reçoit. Quand elle ne reconnaît ni HP-GL ni GP-GL, elle écrit les octets reçus en toutes lettres, à la plume, sur le média : U572,2620; tracé au stylo. Puis la ligne court vers la droite et le panneau affiche « hors surface » — une conséquence, pas une cause, et qui envoie chercher du côté des cotes alors que le dessin tenait très bien.

C'était aussi la source de l'HP-GL ERREUR 1 INSTRUCTION INCONNUE qui accompagnait chaque envoi.

La machine le disait elle-même, dans son propre journal, depuis le début :

W06001 DANGER COMMANDE = AUTO

Lue trois fois sans être comprise. Ce README affirmait pendant ce temps qu'AUTO allait très bien « puisque la machine reconnaît les deux à la volée » — une commodité jamais vérifiée, contredite par un avertissement que la machine répétait dans ses logs.

Mesure : le même fichier de 163 Ko, envoyé plume levée, ajoute une entrée au journal en AUTO et aucune en HP-GL.

Pourquoi les petits fichiers passaient : la détection tombait juste assez souvent. Le porte-manteau (11 Ko) est sorti correctement — avec une erreur journalisée à chaque fois, qu'on prenait pour un défaut cosmétique.

Ce qu'il reste après le passage en HP-GL. Une erreur, une seule, au démarrage d'un envoi précédé de --materiau. Isolée avec le détecteur par horodatage : c'est la salve TC seule qui la produit, ni l'HP-GL ni la combinaison. Intermittente — un troisième essai contenant la même salve n'en a produit aucune — et sans effet : le tracé sort juste.

Elle s'évite sans rien corriger, parce que les réglages sont persistants dans la machine : --materiau n'a d'utilité qu'au changement de matériau, pas à chaque envoi. Deux tracés de suite sur le même papier ne demandent qu'un envoyer_hpgl.py fichier.hpgl tout court.

Réglages du panneau : COMMAND → HP-GL, MODEL EMULATED → 7586 (le 7550 est un traceur de bureau A3 dont l'espace de coordonnées est petit), HP-GL ORIGIN POINT → coin.

La machine dit TOUT d'elle-même, en clair, en une commande

Trouvé le 11/08/2026, et ça relativise la journée entière qui précède.

ESC . v : TC2009,5 ␃

rend quatre kilo-octets de configuration en texte lisible : les huit conditions de découpe, les réglages d'outil, l'ARMS, la surface, le média, l'interface, les commandes, l'avancé. Chaque ligne est nommée en clair.

[TOOLS]
STEP PASS=7
OFFSET FORCE=30
OFFSET ANGLE=30
DATA SORT=OFF
TOOL UP SPEED=40
CONDITION PRIORITY=PROGRAM
INITIAL BLADE=2mm BELOW
TOOL UP MOVE=DISABLED

etat_machine.py la lit, l'analyse, met les huit conditions en tableau, enregistre un vidage et compare deux états — donc nomme un réglage sans qu'on ait à deviner dans quelle famille numérique il se cache.

python3 etat_machine.py --conditions
python3 etat_machine.py --section TOOLS
python3 etat_machine.py --comparer etat_2026-08-11.txt

Et TC2010,9 rend le journal d'erreurs horodaté, nos propres bêtises comprises : HP-GL ERREUR 1 INSTRUCTION INCONNUE, DANGER COMMANDE = AUTO, ERREUR REPLACER GALETS. Les horodatages sont négatifs — des heures écoulées depuis maintenant.

Ce que le vidage confirme d'un coup, après qu'on l'eut établi péniblement : HP-GL MODEL EMULATED=7586, HP-GL ORIGIN=LOWER LEFT, COMMAND=AUTO, GP-GL STEP SIZE=0.100 mm, CONDITION PRIORITY=PROGRAM — ce dernier ayant coûté une soirée à comprendre. Toutes les mesures étaient justes. Toutes tenaient en une ligne que la machine savait dire.

Comment il a été trouvé, et pourquoi si tard. Un premier balayage des familles TC2000–TC2020 n'avait interrogé que leurs paramètres 1 à 3 et conclu que deux familles répondaient — alors qu'on savait déjà que TC2004 ne répond qu'au 6 et TC2006 au 13. Une sonde trop courte rend des absences qui ressemblent à des faits. Le balayage refait sur 1 à 25 a trouvé 60 paramètres et six familles, dont celle-ci.

Ce qu'il ne fait pas : il ne LIT que. L'écriture reste TC1002, et le relevé encadrant garde son usage — trouver comment écrire un réglage qu'on sait maintenant lire. Il ne dit rien non plus de l'état courant du chariot ni du média chargé.

La vitesse SE pilote — par le protocole propriétaire TC

Correction du 11/08/2026. Ce fichier a d'abord affirmé, en gras, que la vitesse ne se pilotait pas depuis le PC. C'était vrai des trois commandes essayées et faux comme conclusion : la bonne était introuvable par supposition, il fallait regarder ce que le logiciel d'origine envoie.

ESC . v : TC1002,3,<condition>,<vitesse en cm/s × 10> ␃

puis continuer d'interroger l'état — ESC.v:ESC.C1:, qui répond 8 tant que la machine traite et 0 quand c'est fini. C'est la partie qu'on oubliait : envoyée seule, la commande fait réagir la machine et ne règle rien. Menée à son terme, la valeur change sous les yeux, sur le panneau.

Relevé en capturant le flux USB de Graphtec Studio pendant qu'on tournait la molette de vitesse : trois crans, trois commandes, ,270 puis ,260 puis ,250. La valeur est lisible en clair, ce qui rend l'identification immédiate — d'où le choix d'une valeur inhabituelle (25) pour la chercher.

sonde_gpgl.py --tc 25 reproduit la transaction complète.

La même méthode nommera les autres réglages : une capture en changeant un champ, et la commande se désigne elle-même par sa valeur. TC1002,1,…, TC1002,6,…, TC2002, TC2006, TC2008, TC2009 sont déjà visibles dans les captures, sans qu'on sache encore ce qu'ils portent.

VS fonctionne AUSSI — mais un réglage de panneau le gouverne

Seconde correction du 11/08/2026. PARAM OUTIL → CONDITION PRIORITE décide qui l'emporte entre le panneau et le fichier. Il était sur MANUEL, et dans cet état VS est silencieusement ignoré. Basculé sur PROGRAMME, le même essai donne enfin deux durées distinctes :

	Demandé	Mesuré
VS5	50 mm/s	46,5 mm/s	93 % de la consigne
VS40	400 mm/s	85,3 mm/s	= la vitesse de la condition

D'où le modèle : VS ralentit sous la vitesse de la condition, il ne la dépasse jamais. Et il ne vaut que le temps d'un travail, là où TC modifie durablement la condition enregistrée — les deux sont donc complémentaires.

Curiosité constatée sans explication : FS (force) fonctionnait déjà sous MANUEL, quand VS ne fonctionnait pas. Le réglage ne filtre pas les deux de la même façon.

Ce que ça coûte de croire une mesure sans connaître ses conditions : les durées identiques mesurées la veille étaient exactes, et la conclusion qu'on en tirait était fausse. La machine n'était pas sourde, elle avait reçu l'ordre de ne pas écouter.

Ce qui a échoué avant, et pourquoi c'est instructif

Trois commandes essayées à l'aveugle, deux langages, aucune n'agit — avec CONDITION PRIORITE sur MANUEL, ce que nous ignorions alors. Le même parcours de 2 560 mm, chronométré à la montre :

Commande envoyée	Durée
HP-GL VS5 … VS40	30 s partout
GP-GL !5 … !40	30 s et 28 s
GP-GL S5 (la lettre du panneau)	21 s = inchangé

Seul le panneau commande, et sa courbe sature — parce que le vrai plafond est l'accélération, pas la vitesse :

Vitesse au panneau	Durée	Vitesse réelle	Rendement
S10	30 s	85 mm/s	85 %
S30	22 s	116 mm/s	39 %
S64 (max)	21 s	122 mm/s	19 %

Consigne multipliée par 6,4, temps gagné : 30 %. Au-delà de S30, monter la vitesse ne sert plus à rien sur un parcours à virages — c'est ACCEL qu'il faut regarder. Et Graphtec règle l'accélération à 2 pour son outil « Stylo feutre » : une plume qui repart brutalement bave dans les angles. Garder une condition « plan soigné » et une « rapide » est le bon usage des huit emplacements.

Le détour par le GP-GL n'aura donc rien donné sur la vitesse. Il aura prouvé que la machine l'accepte : rectangle de 60 × 30 mm exact, syntaxe M/D, séparateur retour-ligne, pas de 0,1 mm (sondes/sonde_gpgl.py).

C'est cette impasse qui a mené à la capture USB, et elle a tout débloqué en une heure là où trois suppositions avaient échoué. La leçon vaut au-delà du traceur : quand deux ou trois essais à l'aveugle échouent sur une question fermée, il est temps d'aller regarder ce que fait celui qui sait déjà.

Les quatre commandes GP-GL éprouvées, et ce qu'elles donnent

Un texte de conseils reçu le 13/08/2026 les présentait comme les pistes à suivre. Elles ont donc été essayées, machine sur COMMANDE = HP-GL et CONDITION PRIORITY = PROGRAM, chaque envoi encadré par un vidage complet et par le détecteur d'erreur à horodatage :

commande	annoncée comme	mesuré
*15,20	accélération et force	aucun effet, avec ou sans CR
FCp,q	déport de lame	agit — mais c'est le second paramètre qui pose OFFSET FORCE
FD30	rotation de lame, tangentiel	aucun effet
!20	vitesse	aucun effet

FC ne fait pas ce qu'on lui prête. Le texte annonçait « p est l'offset, q est lié à la surcharge » : c'est l'inverse. FC7,2 met OFFSET FORCE à 2, FC20,1 la met à 1, et faire varier le premier paramètre ne change rien. Elle marche d'ailleurs alors que la machine est en HP-GL, ce qui contredit l'idée que ces réglages exigeraient le mode GP-GL.

Et elle ne sert à rien : TC1004,4 pose déjà OFFSET FORCE, se relit, et refuse les valeurs hors bornes. FC ne se relit pas, et FC30,0 n'a rien fait sans dire pourquoi.

La mesure de vitesse a été rejouée honnêtement. L'ancien verdict (!5…!40 sans effet) était confondu : il tournait avec CONDITION PRIORITE sur MANUEL, le réglage qui rendait VS muet. Refait sur PROGRAMME, !20 reste sans effet. Le verdict tient, mais il repose désormais sur une mesure valide.

Une réserve, dite plutôt que tue : ces essais ont été faits avec COMMANDE sur HP-GL. Il se peut que de vraies commandes GP-GL n'y soient tout simplement pas analysées — les trancher demanderait de basculer le panneau sur GP-GL, ce qui n'a pas été fait. FC prouve seulement qu'au moins une commande de cette famille passe en mode HP-GL.

Enfin, FD n'a plus d'objet : le mode tangentiel est TC1002,8, nommé le 13/08/2026 en comparant la condition 1 (OFF) à la 8 (mode 1).

Les chiffres d'accélération ci-dessus restent valables : c'est bien elle qui plafonne les temps de tracé. Sa commande a été identifiée depuis (TC1002,5), mais elle n'a que trois crans — le levier existe et il est très court.

Récapitulatif : quatre voies, et quand prendre chacune

Réglage	Voie	Portée	Condition
vitesse	TC1002,3	durable	aucune
vitesse	HP-GL VS	le temps du travail	CONDITION PRIORITE = PROGRAMME, et jamais au-dessus de la condition
force	TC1002,4	durable	aucune
force	HP-GL FS	le temps du travail	fonctionne même sous MANUEL

TC est la voie sûre : il s'applique toujours, et se relit (TC2002). VS/FS sont plus élégants pour un travail ponctuel puisqu'ils ne touchent pas aux conditions enregistrées — mais VS dépend d'un réglage de panneau qui, mal placé, le rend muet sans le moindre signe.

Les scripts du dépôt utilisent TC par défaut, pour cette raison.

sondes/sonde_vitesse.py garde la trace de la méthode, et surtout des deux qui ont échoué avant : OA; rend la position logique, pas celle du chariot, donc il ne mesure aucun mouvement ; et le contrôle de flux ne mord pas — 15 ko partent en 3,8 s quelle que soit la vitesse, soit 4 ko/s, qui est le débit de l'USB avec ses paquets de 8 octets. Le tampon de la machine avale au moins 15 ko. La seule mesure qui a tranché est un chronomètre à la main.

Piège de raisonnement à ne pas refaire : la première version du verdict regardait l'étendue des durées, pas leur ordre — n'importe quel bruit la satisfaisait, et elle a annoncé un résultat faux avec aplomb. Un verdict doit exiger la croissance, et se taire quand les mesures ne sont ni constantes ni croissantes.

« HP-GL ERREUR 1 INSTRUCTION INCONNUE » : réelle, sans effet, sans cause connue

Le panneau l'affiche à chaque envoi, et le journal de la machine (etat_machine.py --journal) la confirme, horodatée à la seconde.

Elle ne bloque rien. Vérifié pas à pas le 11/08/2026 : après chacune, la machine reste sur READY, répond à OH;, aux lectures TC et au vidage. Les deux panneaux du porte-manteau ont été tracés avec.

Sa cause n'est PAS établie, et deux explications avancées ici ont été retirées après mesure :

• « elle sort la machine de READY, d'où les silences d'OH; » — faux, la machine répond après chacune ;
• « les commandes TC commencent par ESC. et l'analyseur HP-GL les refuse » — un détecteur par horodatage, celui-là fiable, ne trouve RIEN : ni OH;, ni IN;/SP/PU, ni l'état TC, ni une lecture TC2002, ni une écriture TC1002, ni un choix d'outil, ni le vidage, ni l'ouverture- fermeture du périphérique.

Ce qui en produit une, en revanche, c'est un envoi complet qui trace réellement. Reste donc une seule chose non éprouvée : le PD, plume baissée. L'essai du fichier entier avait été fait plume levée, tous les PD remplacés par des PU — sans erreur. Trancher coûte une feuille : envoyer un panneau SANS --materiau, puis regarder l'horodatage du haut.

Ce compteur s'est trompé deux fois, et la seconde est la plus instructive. D'abord un journal lu VIDE compté comme zéro erreur, d'où un verdict de +13 puis -13. Puis, une fois cette panne bouchée, il a encore conclu « aucune erreur » sur une séquence qui en produisait deux — visibles dans le journal six minutes plus tard, horodatées.

La raison : le journal est un tampon circulaire. Une entrée nouvelle en chasse une ancienne, donc le NOMBRE d'« instruction inconnue » ne bouge pas pendant qu'elles se renouvellent. Compter une grandeur qui ne peut pas varier, c'est mesurer avec certitude quelque chose qui n'existe pas.

La bonne mesure est l'horodatage du haut : une entrée plus jeune que l'action qu'on vient de faire est une entrée neuve. Ce détecteur-là a été validé avant de servir — 25 secondes d'attente sans rien envoyer, l'entrée du haut a vieilli de 26 secondes et aucune n'est née.

Et c'est Christophe qui l'a débusqué, en lançant simplement la commande qu'on lui avait donnée : la ligne du haut affichait 35 secondes là où mon compteur venait de jurer que rien ne s'était produit.

Pour savoir si un envoi vient d'en produire une, regarder l'horodatage du haut : négatif, il compte en arrière depuis maintenant.

python3 etat_machine.py --journal | head -3

Tracer une planche TechDraw au stylo

Le cas d'usage principal : sortir un plan FreeCAD au stylo, éventuellement à l'échelle 1 pour servir de gabarit sur la planche de bois. L'axe chariot accepte 600 mm, l'axe d'avance est illimité en rouleau.

Export depuis FreeCAD. Sélectionner la planche dans l'arbre, puis TechDraw → Page → Exporter la page en SVG. Pour plusieurs planches :

import FreeCAD, TechDrawGui, os
doc = FreeCAD.getDocument("Tonnelle")
dossier = os.path.join(os.path.dirname(doc.FileName), "planches_svg")
os.makedirs(dossier, exist_ok=True)
for p in doc.Objects:
    if p.isDerivedFrom("TechDraw::DrawPage"):
        TechDrawGui.exportPageAsSvg(p, os.path.join(dossier, p.Name + ".svg"))

L'échelle sort juste sans réglage : une planche A3 est lue à 420,0 × 297,0 mm.

Un gabarit de page taillé pour le traceur

Une planche A3 au 1:1 ne tient pas sur du A3 : les galets et les marges mangent 39 mm dans le sens d'avance et 11 mm en largeur. gabarit_traceur.py fabrique gabarits/A3_Traceur_TD.svg, une page de 375 × 280 mm qui laisse ~5 mm de garde pour les variations de chargement.

python3 gabarit_traceur.py            # -> gabarits/A3_Traceur_TD.svg

Dans FreeCAD, pointer le modèle de la planche dessus :

page.Template.Template = "<dossier du dépôt>/gabarits/A3_Traceur_TD.svg"
page.KeepUpdated = True

Il reprend les dix mêmes noms de champs que le gabarit A3 de l'atelier (FC-Title, AuthorName, scale…), donc les remplissages automatiques de TechDraw fonctionnent à l'identique. Vérifié : format lu 375,0 × 280,0 mm, 10 champs reconnus, date et titre remplis seuls.

Sa particularité : tous les textes fixes sont en monotrait, dessinés glyphe par glyphe depuis les polices de LaserAtelier. Un gabarit ordinaire écrit ses libellés en <text>, qu'il faut convertir en chemins — ce qui donne des lettres creuses, parcourues deux fois par la plume. Ici seuls les dix champs remplis par TechDraw restent du texte. Emprise mesurée sur une planche vide : 365 × 270 mm, 290 tracés.

Il ne convient pas aux planches A3 existantes : leurs vues sont placées en coordonnées absolues et leurs échelles choisies pour 420 × 297. Les y faire entrer changerait l'échelle, donc le cartouche mentirait. Pour celles-là, c'est l'A2 ou le rouleau.

Piège : une planche dont KeepUpdated est faux, ou qui n'a jamais été ouverte, s'exporte vide — 975 octets au lieu de 29 000, sans erreur.

Préparation — une seule commande, plus d'Inkscape (25/08/2026). Une planche exportée contient trois familles d'éléments qui ne se tracent pas telles quelles — sur Plan_Debit du meuble à balais : 430 <rect>, 2 <circle>, 10 <text>, soit les tableaux et le cartouche.

python3 preparer_planche.py planche.svg     # -> planche_propre.svg
python3 svg2hpgl.py planche_propre.svg …

preparer_planche.py fait désormais les trois traitements : il retire les commentaires XML, vectorise les <text> restants en osifont — la police même que TechDraw met dans ses cotes, embarquée dans le dépôt (resources/osifont-lgpl3fe.ttf, LGPL avec « font exception ») — et convertit les formes simples en <path>. La graisse est NORMALE partout, même pour les champs déclarés gras : au stylo, un titre gras sortait en lettres creuses. Mesuré sur les deux planches du meuble : 432 et 38 formes converties, 38 textes vectorisés, et svg2hpgl lit le résultat sans un avertissement.

Chaque remplacement se fait dans le repère local de l'élément remplacé, ce qui immunise contre le piège qui gouvernait l'ancien protocole Inkscape : les champs du cartouche vivent hors du groupe DrawingContent et de son transform, et l'extension Texte Hershey les rendait dix fois trop grands (elle plantait d'ailleurs sur les commentaires XML — raison d'être historique de ce script).

Limite assumée : osifont est une police à contours. Sur les textes courants (≤ 5 px) les deux bords d'un fût fusionnent sous un stylo de 0,5 mm — un trait net, comme les cotes ; sur les grands titres (8 px), le double contour se voit. C'est le même dessin de lettre partout, cotes comprises : c'était la demande.

Pour les planches à grands titres, --police hershey (ou toute clé de --liste-polices) vectorise plutôt en MONOTRAIT, avec les polices de LaserAtelier : une passe de plume par branche de lettre. Mesuré sur Plan_Debit : 4 015 polylignes, zéro glyphe manquant, accents compris. Éviter les variantes gothiques et Med/Bold, au fût contourné — elles gravent double, c'est étiqueté ainsi dans LaserAtelier.

Pourquoi passer par svg2hpgl.py plutôt que par l'export d'Inkscape, sur une planche réelle :

Planche	Trajet à vide	Après réordonnancement
Plan_Ensemble	38 418 mm	4 809 mm (−87 %)
Plan_Debit	24 413 mm	8 852 mm (−64 %)

33 mètres de déplacement à vide évités sur une seule planche : du temps de tracé et de l'usure de courroie. L'exporteur d'Inkscape ne réordonne pas.

Dessiner et couper au quotidien : Inkscape

Aucun plugin à installer. Inkscape 1.4 embarque déjà l'équivalent du Cutting Master de Graphtec : Extensions → Exporter → Tracer, qui envoie directement au port. Vérifié le 10/08/2026 — carré de 60 mm sorti à 60,0 mm, coins nets.

Champ	Valeur	Pourquoi
Type de port	Port parallèle
Port parallèle	/dev/usb/lp0	le défaut proposé est lp2
Langage	HPGL	ce que dit COMMAND au panneau
Résolution X et Y	1016 dpi	1016 ÷ 25,4 = 40 unités/mm, la valeur mesurée
Plume	1	sélectionne la CONDITION 1
Force / Vitesse	0 / 0	0 = ne rien envoyer, le panneau garde la main
Surcoupe	0	déjà fait par le firmware
Correction d'offset d'outil	0	déjà fait par le firmware
Précoupe	décochée
Rotation / miroirs / origine centrée	aucun	le repère est vérifié, ne pas le contrarier
Alignement automatique	décoché	sinon il pousse le dessin dans le coin

Deux réglages par défaut à corriger impérativement, et ce sont les deux plus dangereux :

• « Correction d'offset d'outil » vaut 0,25 mm et « Surcoupe » vaut 1,00 mm d'origine. Or la machine fait déjà ces deux corrections dans son firmware. Les laisser actifs compense deux fois : les coins sortent avec de petites cornes au lieu d'être nets. Le contrôle est visuel — un carré, puis on regarde les angles.
• « Alignement automatique » déplace le dessin dans le coin du média et jette la position du SVG. À décocher pour maîtriser la mise en page.

Ce que le logiciel natif faisait et qu'Inkscape ne fait pas : les marques de repérage ARMS (print & cut), les lignes de dégagement, le pavage des grands dessins et la duplication en série. Le pavage et la duplication sont couverts ici (mosaïque, copies matricielles) ; l'ARMS ne l'est pas.

Inkcut : essayé, mesuré, désinstallé

C'est l'alternative qu'on trouve en premier, et la question mérite une réponse chiffrée plutôt qu'un avis. Installé le 10/08/2026, retiré le lendemain — 402 Mo de dépendances pour ce qu'il apportait.

Il a piloté la machine, et uniquement en HP-GL. Vérifié dans sa propre configuration avant de la supprimer : zéro occurrence du protocole propriétaire (ESC.v / TC1002), huit de HP-GL, un « Inkcut Generic Driver » sur /dev/usb/lp0. Ce n'est pas un pilote Graphtec, c'est un pilote générique.

Ce que ça implique, et qu'on ne pouvait pas savoir avant d'avoir mesuré :

• son champ force partait en FS, et agissait ;
• son champ vitesse partait en VS, et ne faisait RIEN — le panneau était sur CONDITION PRIORITE = MANUEL, réglage d'usine, où la machine ignore VS en silence (voir plus bas). Un réglage qui tourne à vide sans le dire ;
• il ne déclare jamais le type d'outil. La machine appliquait donc la compensation de la condition active — et si celle-ci annonce une lame quand un stylo est monté, le firmware compense un déport qui n'existe pas. C'est le mécanisme des coins arrondis documenté plus loin, et l'explication la plus probable du décalage constaté à l'usage.

Le HP-GL sait envoyer ; il ne sait rien DEMANDER. Pas de relecture, pas de vérification qu'un réglage a pris, pas d'accès aux huit conditions ni à la configuration de la machine. C'est ce qui sépare ce dépôt d'un pilote générique — pas la qualité du tracé, qui était correcte.

Le protocole propriétaire TC, et l'enquête qui l'a percé

python3 pupitre.py

Le seul écran que le logiciel Graphtec avait vraiment en plus (sa fenêtre « Page »). Il interroge le média à la machine par OH; — comme le faisait l'original, dont la capture affiche « Automatique (CE6000-60 (Taille de la sonde)) 187,20 × 257,00 mm », exactement nos chiffres — puis montre le dessin dessus.

Réglages : origine X/Y, rotation par quarts de tour, miroirs, échelle libre ou ajustée au média, copies matricielles (rangées × colonnes, écarts), condition, type d'outil, vitesse, force et accélération.

Les icônes d'outil (icones.py) sont dessinées d'après ce qui distingue les lames : la largeur de la pointe suit le diamètre, son angle suit celui de la lame. Ce n'est pas décoratif — le type déclaré doit correspondre à l'outil monté, et un « Stylo feutre » oublié a arrondi tous les angles d'une découpe le 11/08/2026. La plume n'a pas de pointe triangulaire, parce qu'elle n'a pas de déport. L'envoi se refuse tant que le dessin déborde.

Vitesse, force et accélération passent par conditions.py et le protocole TC — elles modifient durablement la condition enregistrée dans la machine, exactement comme le fait Graphtec Studio, d'où la case « régler la machine à l'envoi » qu'on peut décocher.

Paramètre	Commande	Plage
vitesse	TC1002,3,<cond>,<cm/s × 10>	1 à 640, soit 64 cm/s
force	TC1002,4,<cond>,<n>	1 à 38
accélération	TC1002,5,<cond>,<n>	1 à 3 seulement
type d'outil + offset	TC1002,2,<cond>,<code>,<offset>	voir la table ci-dessous ; offset −5 à +5

Les codes d'outil ont été relevés en parcourant la liste du logiciel Graphtec deux fois de haut en bas — la même suite les deux fois, donc une mesure reproduite et non une déduction sur un seul passage :

Outil	Code		Outil	Code
CB09U	1		CB15UB	3
CB09U-K60	10		Autre	6
CB15U	2		Stylo feutre	9

Le second champ est l'offset — et il était visible depuis le début

Longtemps porté ici comme « inexpliqué ». Nommé le 11/08/2026 par un relevé encadrant : offset porté à 3 au panneau ([COND/TEST], [2] OUTIL, [3] OFFSET), et de onze paramètres relevés un seul bouge, TC2002,2, de [1, 0] à [1, 3]. Gamme lue sur l'écran : −5 à +5, conforme au manuel.

Il s'écrit depuis le PC, négatifs compris — −2, 5, 0 demandés, les trois relus conformes.

Deux tentatives avaient échoué avant, chacune pour sa raison. Changer CB15U → CB09U ne montre rien : la retouche vaut 0 pour les deux lames, et un paramètre identique avant et après ne se voit dans aucune différence. Et le relevé lui-même mentait tant qu'il ne jetait pas sa première interrogation.

Mais la leçon n'est pas là. Le champ se donnait à voir depuis le premier jour : dans la capture USB il passait de 0 à 1 pendant que le logiciel Graphtec parcourait sa liste d'outils, et les captures d'écran de ce même logiciel affichaient « Offset : 1 ». Deux indices concordants, écartés d'une phrase — « un état du logiciel, pas une propriété du réglage » — faute d'avoir cherché ce qu'ils avaient en commun. La mesure qui a fini par trancher n'a rien appris que ces deux indices ne disaient déjà.

Et ça cachait un bug. regler_outil envoyait ce champ à 0 en dur : comme la commande écrit les deux valeurs d'un coup, choisir un outil effaçait l'offset. Le réglage posé au panneau disparaissait au premier profil appliqué, sans rien afficher. Corrigé : offset=None relit la valeur en place et la conserve, regler_offset() fait la symétrique (changer l'offset sans toucher à la lame). Vérifié en posant 4, en choisissant un outil, et en relisant 4.

TC2002 est la LECTURE du même jeu : TC2002,<paramètre>,<condition>, et la machine répond <condition>, <valeur>…. On peut donc vérifier un réglage au lieu de le supposer appliqué — et conditions.appliquer relit systématiquement ce qu'il vient d'écrire. Toute cette enquête a buté sur l'absence de cette vérification : une soirée entière passée à croire la machine sourde parce que rien ne disait ce qu'elle avait retenu.

conditions.lire_condition(n) rend l'état complet d'une condition, et les huit se listent d'un coup — utile pour retrouver ses préréglages.

La machine ÉCRÊTE sans un mot : une accélération 4 demandée est appliquée à 3, ce qui ressemble d'abord à un décalage d'une unité. conditions.BORNES refuse la valeur plutôt que de laisser croire qu'on a réglé ce qu'on n'a pas.

Trois crans d'accélération seulement, c'est peu — et c'est pourtant elle qui plafonne les temps de tracé (voir plus bas). Attendre plus de ~12 cm/s effectifs sur un parcours à virages est illusoire.

Le réordonnancement du trajet ne tourne qu'à l'envoi : il est en n², donc trop lourd à rejouer à chaque mouvement d'un réglage, et il ne change rien à ce que l'aperçu montre.

theme.py porte les couleurs — celles du visualiseur G-code, recopiées plutôt qu'importées d'un dépôt à l'autre pour une question d'habillage. Sombre par défaut, clair pour les captures, accent #ff8a00, l'orange de l'atelier. Quand le dessin déborde, les tracés, l'emprise et le message passent au rouge et le bouton d'envoi se grise : un message d'alerte sous un style neutre ne se lit pas comme un refus.

La mosaïque est dans mosaique.py, et s'appelle depuis la ligne de commande :

python3 svg2hpgl.py gabarit.svg --mosaique 380x280 --recouvrement 15

Elle écrit un fichier par panneau, sans rien envoyer : entre deux panneaux il faut repositionner le média, et l'automatiser ferait tracer le second par-dessus le premier. envoyer_hpgl.py prend le relais :

python3 envoyer_hpgl.py gabarit_p??.hpgl     # s'arrête entre chaque panneau

Il reprend les deux garde-fous du dépôt — contrôle de flux, et refus d'envoyer si OH; reste muet — plus un troisième : il lit l'emprise du fichier HP-GL et refuse s'il déborde de la zone utile réellement mesurée. Le découpage est un Liang-Barsky par segment : une polyligne qui traverse la frontière est coupée EXACTEMENT dessus, et ce qui dépasse disparaît. Un contour fermé coupé devient ouvert — ce n'est plus un contour.

La propriété qui compte, c'est que rien ne se perde, et elle est vérifiée par deux mesures indépendantes du code testé : un dessin de 25 m découpé en 20 panneaux sans recouvrement redonne 25 563,307 mm, contre 25 563,307 mm à l'original — écart nul au millionième. Et la longueur retenue dans un panneau donné correspond, à 0,045 mm près sur 3 m, à ce que donne un échantillonnage du dessin tous les 0,05 mm.

Les repères en croix sont posés au MILIEU des bandes de recouvrement, donc au même endroit physique sur les deux voisins : on superpose, on colle, le trait est continu. Une croix posée sur le bord d'un panneau, elle, ne serait pas sur l'autre.

Ce que le logiciel d'origine faisait, et où on en est

Relevé sur 18 captures de Graphtec Studio v2.70. Christophe, le 11/08/2026 : « ça me paraît léger les réglages par rapport au logiciel officiel ». Il avait raison, et le compte exact suit.

Studio avait trois panneaux là où le pupitre n'en a qu'un.

Panneau « Condition » — celui qu'on couvre

Réglage de Studio	Chez nous
Type d'outil	oui, avec icônes dessinées d'après le diamètre et l'angle
Offset	oui depuis le 11/08/2026, −5 à +5, grisé pour un stylo
Vitesse	oui
Accélération	oui
Force de coupe	oui
Motif de ligne de découpe (styles 1-9 + 3 utilisateur)	autrement : perforation logicielle en longueurs exactes, --perforation 8,0.25. Studio lui-même offrait le choix entre « perforation du cutter » et « du logiciel »
Passages	non — présent dans materiaux.py (2 pour les plumes) mais pas branché dans la chaîne. C'est la réponse au trait pâle du premier essai

Panneau « Paramètres outil » — couvert depuis

Réglage de Studio	Valeur vue sur la capture	État
Passe-pas (Step Pass)	1	réglable : TC1004,3
Force d'offset	30	réglable : TC1004,4
Angle d'offset	30°	réglable : TC1004,5, stocké × 100
Position initiale de la lame	2 mm en-deçà / dehors	réglable : TC1004,10
Vitesse outil relevé	40 cm/s	réglable : TC1004,7, stocké × 10
Déplacer activé/désactivé	—	réglable : TC1004,11, où 1 vaut « désactivé »

Tous lisibles depuis etat_machine.py. Reste à trouver comment les écrire : le relevé encadrant sert encore à ça, et il est maintenant beaucoup plus rapide puisqu'on peut vérifier d'un coup d'œil que la manipulation a pris.

Panneau « Avancé » et média

Réglage	État
Mode média épais (tangentiel) : désactivé / mode 1 / mode 2	lu par condition : TANGENTIAL MODE, à 1 sur la n° 8
Ajustement de la distance X / Y	lu : D. ADJ.=OFF avec X=0.59, Y=0.00 sur la condition 1 — désactivé, la capture Studio disait vrai, et notre carré de 60 mm sort juste sans lui
Pré-alimentation automatique	lu : [MEDIA] AUTO PRE FEED=OFF, AUTO PRE FEED LENGTH=500.0mm
Langue, unité, taille du pas, ventilateur, capteurs, bip	réglages de machine, pas de travail — le panneau les porte très bien

Ce qu'on a en plus

Le compte serait malhonnête sans l'autre colonne : mosaïque avec repères d'assemblage, perforation aux longueurs voulues plutôt que neuf motifs figés, réordonnancement des chemins pour raccourcir les trajets à vide, relecture systématique de chaque réglage écrit, et un gabarit TechDraw à la taille utile du traceur.

Comment le reste a été comblé

Onze paramètres répondent sur la condition 1, cinq sont nommés. Les six autres sont très probablement dans les tableaux ci-dessus. sondes/chercher_parametre.py les nomme un par un, en trois minutes chacun :

python3 sondes/chercher_parametre.py --debut

changer UNE chose au panneau, revenir à READY, puis :

python3 sondes/chercher_parametre.py --fin "step pass"

--reste liste ce qui manque.

Ce que le Step Pass a appris en n'étant pas là où on le croyait

TC2002,15 valait 1 et le Step Pass a 1 pour défaut : la coïncidence était belle. Step Pass porté à 7 au panneau le 11/08/2026, relevé encadrant sur les quatre familles — aucun des onze paramètres ne bouge. L'hypothèse tombe, et elle apprend plus que si elle avait tenu.

Le chemin au panneau dit dans quelle famille chercher :

Réglage	Chemin au panneau	Famille
offset, vitesse, force, accélération, outil	[COND/TEST] — écran des conditions	TC1002/TC2002, indexés par condition
Step Pass	[PAUSE/MENU] → [1] TOOL → [2] PAS — menu machine	ailleurs

Les quatre familles balayées sont toutes indexées par condition. Un réglage qui ne dépend pas de la condition ne peut pas y être, quel que soit le soin du relevé. Autrement dit : la structure des menus de la machine est une carte du protocole, et on cherchait dans la mauvaise page.

Et le premier balayage de familles ne prouvait rien non plus : il interrogeait les paramètres 1 à 3 de chaque famille, alors qu'on savait déjà que TC2004 ne répond qu'au 6 et TC2006 au 13. Ses « familles muettes » étaient un artefact de son étroitesse — une sonde trop courte rend des absences qui ressemblent à des faits.

Déjà porté par la machine : les 8 conditions, que le fichier sélectionne par SP1..SP8. Elles s'écrivent aussi, chacune séparément — TC1002,<paramètre>,<condition>,<valeur> — vérifié le 11/08/2026 en modifiant la n° 5 et en constatant que ses voisines ne bougeaient pas, restauration comprise. Le pupitre affiche le contenu des huit dans sa liste déroulante, la condition active marquée d'un point : choisir « condition 5 » sans savoir ce qu'elle contient n'aide personne. La compensation d'offset de lame et la compensation d'offset de lame et son angle sont faits dans le firmware. Déjà mesuré comme exact chez nous : l'ajustement de distance X/Y (OF; donne 40,00 et le carré de 60 mm l'a confirmé sur papier).

Pas encore nécessaire, mais à reprendre le jour où on découpe — la découpe de gabarits papier est le besoin d'origine, elle est seulement remise à plus tard :

Nuancier de force jugé au décollement	fait : nuancier_force.py --carres, une grille de carrés à lever
Styles de perforation	fait en logiciel : --perforation 8,0.25
Test de découpe / de force	équivalents déjà couverts par le nuancier
Cadre d'échenillage	propre au vinyle, sans objet sur papier
Repères d'alignement (ARMS)	seulement pour découper au contour un motif imprimé ; commandes mal documentées hors SDK

Deux relevés utiles au passage : le logiciel a un type d'outil « Stylo feutre » dont les valeurs d'usine sont vitesse 10 cm/s, accélération 2, force 2. L'accélération se règle au panneau (CONDITION → ACCEL) et n'apparaît dans aucune commande HP-GL — une plume qui accélère fort dérape au départ de chaque segment.

Le gabarit en deux passes : l'origine tient

Vérifié le 11/08/2026 sur du 80 g A3 : contour tracé au stylo, changement d'outil sans décharger le média, puis le même contour coupé à la lame. La coupe tombe sur le trait. Changer d'outil ne déplace donc pas l'origine, et un gabarit peut porter ses repères à l'encre et son contour à la lame.

Le piège à éviter, sinon on conclut de travers : le type d'outil déclaré doit correspondre à ce qui est physiquement monté. Avec CB09U déclaré pendant qu'un stylo est en place, la machine applique une compensation d'offset à un outil qui n'en a pas et décale le tracé d'un demi-millimètre — ce qui ressemble exactement à une origine qui bouge.

Second piège, physique celui-là : la hauteur de lame ne suit pas le profil. Elle reste où on l'a laissée, et une lame sortie à 0,55 mm pour du 300 g laboure un 80 g quelle que soit la force. Aucune commande ne la corrige.

La perforation, faite en logiciel

python3 svg2hpgl.py gabarit.svg --perforation 8,0.25 --envoyer

8 mm coupés, 0,25 laissés — les cotes du carnet d'établi. C'est ce que le logiciel Graphtec appelle « Style 1 à 9 » ; le faire ici donne les longueurs exactes au lieu de neuf motifs figés, et Graphtec lui-même offrait le choix entre « perforation du cutter » et « du logiciel ».

Le découpage se fait en abscisse curviligne : un tiret enjambe plusieurs segments d'une courbe aplatie, et le motif franchit les angles sans se remettre à zéro. Vérifié sur une ligne de 100 mm — 97,000 mm coupés là où 8/8,25 en prédit 96,970.

Vérifié sur le papier le 11/08/2026 : un carré de 60 mm perforé tient dans la feuille et se détache à la main. La réserve annoncée — 0,25 mm paraissant trop court pour lever une lame — était infondée, et c'est le papier qui l'a tranché.

La perforation est appliquée après le réordonnancement : la faire avant multiplierait par vingt le nombre de chemins, et l'ordonnancement est en n².

La compensation d'offset, vérifiée sur des pointes

sondes/sonde_offset.py découpe quatre triangles dont le sommet se ferme — 90°, 60°, 45°, 30° — plus un carré témoin. Vérifié le 11/08/2026 sur du 300 g avec une CB09U : toutes les pointes sortent franches, jusqu'à 30°. La compensation du firmware fait son travail, et le type d'outil TC1002,2 est bien ce qui la commande.

La retouche d'offset — le second champ de cette même commande — valait 0 pendant cet essai, sa valeur d'usine. Des pointes franches à 30° avec une retouche nulle veulent dire qu'il n'y a rien à retoucher pour ce couple lame/papier. Si un jour une pointe bavait ou rentrait, c'est ce champ-là qu'il faudrait bouger, d'un cran à la fois, dans la gamme −5 à +5.

Le carré témoin ne prouve rien, et c'est pour ça qu'il est là : un angle droit pardonne tout, et sur 12 mm le défaut se devine à peine. Le même réglage jugé sur un carré donnait « difficile à dire ».

Ce qui avait causé les coins arrondis : nos propres essais du protocole TC avaient laissé le type d'outil sur « Stylo feutre ». Un feutre n'a pas de déport, donc la machine n'appliquait aucune compensation — sans erreur ni alerte, elle faisait exactement ce qu'on lui avait demandé plusieurs heures plus tôt.

Le petit crochet isolé près du départ n'est pas une bavure : la machine oriente sa lame par un court mouvement préalable avant d'attaquer (PARAM OUTIL → LAME INITIALE, « 2 mm en-deçà » ou « dehors »).

Quand utiliser quoi

• Le pupitre pour tout ce qui est ordinaire : ouvrir, placer, découper en panneaux, perforer, régler, envoyer. Il relit chaque réglage écrit et refuse de tracer si l'un n'a pas été retenu.
• envoyer_hpgl.py --materiau quand le fichier HP-GL existe déjà, ou pour enchaîner plusieurs envois depuis un script.
• svg2hpgl.py pour le traitement en lot d'un dossier de SVG.
• sondes/sonde_ce6000.py dès que la machine ne répond plus : c'est le premier réflexe, et il ne fait rien bouger.
• etat_machine.py --comparer quand un réglage semble avoir changé tout seul : il nomme ce qui diffère d'un état enregistré. Pas juste avant un envoi — voir le piège n° 6.
• Inkscape pour dessiner, réglé comme ci-dessus ; l'extension HP-GL sait aussi couper directement pour un travail rapide.
• vpype (write --format hpgl) si un traitement de chemins plus poussé devient nécessaire.

L'état des lieux au 11/08/2026

Ce qui marche et a été éprouvé sur du papier : tracé au stylo d'une planche TechDraw, mosaïque sur deux feuilles raccordées aux croix, découpe au nuancier sur 80 g et 300 g, perforation d'un carré de 60 mm qui se détache à la main, réglage complet de la machine depuis le PC, lecture de sa configuration entière en clair.

Ce qui reste ouvert, dit plutôt que caché :

• TC2004,1 accepte une écriture — 0 devient 1, relu 1 — sans qu'aucune ligne du vidage en clair ne bouge. Un réglage réel que la machine n'expose nulle part. Sondé deux fois, sans résultat.
• Une HP-GL ERREUR 1 INSTRUCTION INCONNUE naît par intermittence d'une salve TC. Sans effet sur le tracé, et évitable : les réglages étant persistants, --materiau ne sert qu'au changement de matériau.
• L'ARMS reste hors de portée, faute de documentation publique.

Ce qui n'est PAS fait ici

• La compensation d'offset de lame : le firmware s'en charge (réglage OFFSET de la condition de coupe). On lui envoie la polyligne nominale, il place la lame. Ne pas la recalculer côté PC.

• La force de coupe : elle se trouve sur une chute du vrai matériau, en montant jusqu'à ce que le film se détache sans entamer le support. Aucun calcul ne donne ce nombre. Par défaut le programme dit SP1..SP8 et la machine applique la condition réglée au panneau — c'est le choix recommandé. FS fonctionne néanmoins (voir nuancier_force.py), d'où l'option --force pour les cas où l'on veut piloter depuis le PC.

  La plage utile va de 1 à 38. Au stylo, la progression ne se voit que jusqu'à ~10 puis sature : un stylo dépose son encre dès qu'il touche, et appuyer plus fort n'y change rien. La force n'est vraiment un réglage continu qu'avec une lame, où elle fixe la profondeur de coupe — c'est donc sur du vinyle, à la lame, que le nuancier prend son sens.

• L'ARMS (détection des marques de repérage, print & cut) : commandes mal documentées hors SDK Graphtec.

Licence

GPL-3.0-or-later — voir LICENSE. Le même terrain que LinuxCNC et FreeCAD, dans lequel ce travail s'inscrit : qui reprend ce code publie ses modifications sous la même licence.

Ne sont PAS couverts, et ne sont pas redistribués ici :

• le manuel du CE6000, sous copyright Graphtec, à télécharger chez le constructeur ;
• les polices monotrait employées par gabarit_traceur.py, qui vivent dans LaserAtelier avec leurs propres licences ;
• les dessins d'essai issus de banques commerciales, qui n'ont jamais été versés au dépôt.