Salut
Pour moi sur la version 2.4.0 la guillotine de 1200 en longueur et 500 de hauteur retour impeccable.
Tu à testé en GCode ?
Le problème est exactement aux mêmex endroitx ou plutôt aléatoire sur la guillotine.
Sa me fait vraiment croire à des perturbations, tu sais quand tu était en 41 Mghz....
A bientôt.
Eric

non les perturbations ne sont pas aléatoires, mais reproductibles, en mode guillotine , toujours les derniers mm avant les changements de sens

Salut,
J'ai vu la vidéo, tu a suivi la doc de Alain pour le montage ?
Tes popolux sont tous à la suite sur ta Ramps, Retour ou impultion croisement de pin?
A+
Eric

Salut,

La vidéo est excellente, belle astuce, merci Alain

Je n'ai pas vérifié dans tous les messages et je m'interroge sur un point : est ce que quelqu'un a une machine qui fonctionne bien, et qui a la même "résolution" (la même finesse) que Vincent et Bozzo 12 ?

Si le problème venait du nombre de pas à envoyer, un problème de buffer apparaitrait quelque soit la découpe. Là c'est lors du changement de sens de rotation, comme si il y avait un rebond sur le signal qui indique le sens de rotation...

Bonjour Jérôme,
Oui moi, même config
- driver DRV8825
- en full step 1/32eme
nema de 200 pas/tour
donc pas mal de steps/mm
Voir ma Vidéo coupe en guillotine en diagonal à la fin.
Ma vidéo est ici

A+

En fait c'est surtout sur les steppers qu'il faut regarder en faisant un repère sur la poulie et en faisant la guillotine le repère doit revenir exactement à la même position car le décalage peut être de seulement quelques degrés donc peu perceptible suivant le type de méca mais le test d'Alain me laisse penser que le problème n'est pas là...

Je ne comprends pas du tout, on est 3 à avoir le même problème, et pas vous alors qu'on a la même config, c'est absurde..
Les soudures j'y crois moyen vu que l'on a 3 cartes différentes qui posent le problème.

Il va falloir que j'essaye de prendre l'oscillo du boulot voir la forme des signaux au changement de sens mais en supposant que ce soit ça a quoi cela pourrais être dû ? Les signaux sortent directement de l'atmega...

Bonjour,
Avez- vous vérifié le câblage de vos moteurs, il m'est arrivé une fois en branchant la prise 4 broches sur la ramps 1.4 de l'avoir décalée d'une broche, une broche en l'air.
Le moteur tournait bien mais avait des problèmes à l'inversion. Si vous avez le même problème sur vos machines, le câblage est peut-être identique et une erreur s'est peut-être glissée, ce n'est pas toujours aussi simple qu'il n'en paraît. C'est pour cela que j'ai fait des circuits imprimés et que j'utilise des câbles tout fait.
Je vous encourage dans vos recherches.
Alain

Bonjour

Pour écarter définitivement la partie Hard, prend le sketch du test de la ramps modifie le nombre de pas à faire.

Normalement tu doit revenir au même point.

Vince

je teste ca et reviens vers vous

J'ai enfin trouvé !!!!!

Bon deja pour les tests avec les sketchs de test ca fonctionne sauf pour E3 qui fait des trucs bizarres, mais c'etait peut etre un fil qui avait laché.
Depuis j'ai refait a nouveau tous mes cablages et j'ai poursuivis mes essais sous alden 1.2.2 et 2.4.2.

Et en faisant du débug et en affichant sur l'ecran le nombre de pas je me suis rendu compte que ca fonctionnait...

La solution est en fait de ralentir la fonction HandleCommand lorsqu'elle traite la trame 'M', je n'ai pas compris pourquoi mais le simple fait de mettre un delay(1); à résolu le problème.

Et en plus ca ne ralentit pas le systteme (ou alors de facon totalement négligeable.

Alain ca peut peut etre etre (ca fait bizarre d'écrire ca comme ca) une modification a apporter.
Je pense que le probleme se pose car nous travaillons a des vitesses assez indecédentes (0.05mm/pas), en tout cas je ne vois pas trop ce qui pourrait jouer d'autre qui fait que l'on soit 3 a l'avoir constaté et pas vous.