Salut,
Bon, je n'ai pas noté d'anomalie dans tes réglages et si je simule ton GCode sous Mach3, il me donne un temps d'usinage totale de 3h31 ...
Effectivement les micro-segments en X sont dut à un arrondi, une fois arrondie, la valeur Z se retrouve être la même pour les différents mouvements, et le post pro ne réécrit pas la position d'un axe si elle n'a pas changée.
CamBam optimise les parcours AVANT de créer le Gcode, c'est au niveau des parcours qu'il supprime les points intermédiaires s'il n'y a pas de mouvement sur les autres axes, mais pour le calcul des parcours il utilise la précision maxi, ce n'est qu'au moment de créer le GCode que se fait l'arrondi et ça ce n'est pas optimisé, si ce n'est que si une coordonnée n'a pas changée, il ne la réécrit pas (ça dépend du formatage de la macro dans le PP) mais ce n'est pas grave, ça n’empêche pas le système de fonctionner et ça ne ralentis pas la machine.
un exemple d'un des parcours, tu a bien un point tous les 0.4mm (Ø outil * résolution) sur la zone ou il y a des variations en Z, mais sur les zones plates, les points intermédiaires inutiles sont supprimés.
Pour régler le nb de décimales, c'est aussi dans le post pro.
Il vaut mieux ne pas trop réduire le nb de décimales (4 c'est bien) sinon tu risque d'avoir des problèmes avec les arcs à cause des arrondis, et un message du genre "le rayon de début de l'arc ne correspond pas au rayon de fin de l'arc" .... je ne sais pas quel est la tolérance sur GRBL, mais par exemple Mach3 sort cette erreur s'il détecte une différence de plus de 0.002mm entre le rayon de départ et le rayon de fin d'un arc.
Je ne suis pas contre le fait de devoir essayer MACH3 si c'est nécessaire.
Mach3 ne peut pas piloter une machine arduino/GRBL
++
David