[cyril13110]

C'est énorme ce sue tu es en train de créer, un soft complet concurrent de candle du déchire

Arrête d'écrire la bouche pleine Cyril

je suis repéré

[gwion]

Les briques s'assemblent...

2026-09-04 19_58_06-IHM.png

[paulfjujo]

bonjour à tous,

On voit que demander des déplacements au micron est illusoire, ce qui n'a rien d'étonnant pour une machine de cette nature... C'est ce que j'ai fait avec la commande console G0 X5.001 y-1.002 z0.005. Il suffit de regarder les coordonnées de travail sur l'écran pour en être convaincu.

Est-ce que tu en conclus d'utiliser un pas de commande JOG minimal de :
= Lead size (mm) / (200 * diviseur driver) :
dans mon cas 8 /( 200 *16))= 2.5µ pour le Z (avec $102=400)
et 8 /( 200 *8))= 5µ pour les axes X Y (avec $100=$101=200)
au lieu de 1µ
il faudrait alors aussi arrondir les valeurs issues du Homing des 3 axes (POM) pour rester modulo pas de commande

[gwion]

Je conclus simplement que vouloir se positionner au µm est impossible, ce qui semble cohérent pour une machine à 4 sous.
Par contre, ce qui est certain, c'est que malgré cela on peut faire x fois le passage de gravure avec des palanquées de décimales, et que la fraise retombe parfaitement sur le même tracé, d'où un certain mystère.
Et quand on regarde le nombre hallucinants de décimales générées par certains logiciels, on se demande bien quelle en est l'utilité.
D'autant que de ce que j'ai compris du fonctionnement de GRBL, il faut lui donner quelques commandes d'avance pour fluidifier les mouvements (au moins une dizaine), mais sans dépasser une taille de tampon de 127 octets. Il y a donc intérêt à ce que le gcode soit le plus concis possible, ce qui revient en pratique à ne pas envoyer les commentaires, les espaces, le signe "+", les zéros non significatifs, les batteries de décimales, ne pas répéter la vitesse si inchangée pour chaque commande G1...
L'épuration est d'ailleurs à l'étude ainsi que le maintient constant de la taille du tampon d'alimentation.