J’ai déjà vu ce soucis, les arc sont plus compliqués a interpréter que les lignes ce qui peux ralentir grbl et donner un delai.
Il faudrait convertir les arcs en ligne depuis le logiciel plutôt que de faire la traduction directement sur l’arduino.
Quels sont les logiciels que tu utilises ?

@benmaker j’utilise mon propre soft en c# , convertir des arcs en ligne n’est pas terrible, je converti déjà des courbes de beziers en arcs de cercle parce que grbl ne le supporte pas en natif (g-code G5)

Je récupère la position des moteurs toutes les 300 ou 400ms pour afficher la position actuelle de l’outil, et pendant plusieurs cycles la position ne change pas de l’origine, puis d’un coup ça se recale au bon endroit, c’est très bizarre, ca me parait bien long pour un pb de delai sachant que la trajectoire est correcte depuis le début.

Je n’ai pas d’autres idées pour l’instant. Je n’ai jamais créé de programme donc je ne pense pas que je pourrais t’aider beaucoup plus…
Y’a plus qu’a espérer que quelqu’un qui s’y connais mieux passe par la 😉

@benmaker En fait je pense que j’ai trouvé la solution. En analysant plus finement le retour des positions moteur, je m’aperçoit que je n’ai pas le « ok » que j’attendais précédemment dans mon contrôle de déplacement, mais j’ai quand même la position des moteurs. Il suffit donc de ne pas attendre le « ok » qui arrive très tard mais d’interpréter la position au fur et a mesure. Je l’ai mis en œuvre et ça a solutionné mon pb , donc on peut considérer que j’ai ma réponse, merci d’avoir passé du temps à me répondre

Ok ben tant mieux si ça fonctionne, la solution pourra peut-être aider quelqu’un d’autre 😉

sition des moteurs en permanence (500ms) pour vérifier que tout va bien

Avec le déplacement en ligne