marlin Souci de vitesse de bump avec le TouchMi

[willy2406]

Bien le bonsoir,

Je me suis équipé du TouchMi, j'en suis très content, mon seul problème c'est que lors du homing de Z, le "rebond" se passe  à la même vitesse que le palpage initial, alors qu'il est censé se passer à une vitesse divisée par 4, si j'ai bien compris le principe de :

#define HOMING_BUMP_DIVISOR { 4, 4, 4 }

Du coup je jongle avec le Z-offset à chaque impression c'est un peu pénible et pas très précis.

Je parle bien du homing, car pour le palpage du bed sur 9, 16 ou 25 points, tout se passe comme prévu et c'est d'une précision redoutable.

 

Merci de votre aide !

[pommeverte]

Salut,

Lorsqu'on utilise un système de palpage, je dirais que c'est plutôt ici:

#define Z_PROBE_FEEDRATE_FAST (14*60)

#define Z_PROBE_FEEDRATE_SLOW (Z_PROBE_FEEDRATE_FAST / 2)

Le #define HOMING_BUMP_DIVISOR { 4, 4, 4 }, c'est pour les détecteurs de fin de course si je ne me trompe:

/**
 * Homing Procedure
 * Homing (G28) does an indefinite move towards the endstops to establish
 * the position of the toolhead relative to the workspace.
 */

//#define SENSORLESS_BACKOFF_MM  { 2, 2, 0 }  // (mm) Backoff from endstops before sensorless homing
#define HOMING_BUMP_MM      { 5, 5, 2 }       // (mm) Backoff from endstops after first bump
#define HOMING_BUMP_DIVISOR { 2, 2, 4 }       // Re-Bump Speed Divisor (Divides the Homing Feedrate)

Modifié (le) Juin 17, 2022 par pommeverte

[willy2406]

Yes, merci de ta réponse !

du coup pour moi les palpages du bed se passent super bien, le bump se fait à vitesse réduite :

#define Z_PROBE_FEEDRATE_SLOW (Z_PROBE_FEEDRATE_FAST / 4) 

et c'est ultra précis.

Mon TouchMi est branché sur le z-stop, et du coup j'ai défini :

/**
 * Enable this option for a probe connected to the Z-MIN pin.
 * The probe replaces the Z-MIN endstop and is used for Z homing.
 * (Automatically enables USE_PROBE_FOR_Z_HOMING.)
 */
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

Peut être que c'est pour ça qu'il ne prend pas en compte le HOMING_BUMP_DIVISOR ?

[pommeverte]

il y a 7 minutes, willy2406 a dit :

Peut être que c'est pour ça qu'il ne prend pas en compte le HOMING_BUMP_DIVISOR ?

je serais tenté de dire non... ... du coup, je sèche , il va falloir faire appel à un ami, parce que le 50-50 n'aidera pas

[willy2406]

Au temps pour moi, même pendant le palpage du bed la vitesse en Z n'est pas réduite pendant le bump.

Je vais continuer à fouiner 

[pommeverte]

Est-ce que tu peux fournir tes fichiers de config?

est ce que tu as MULTIPLE_PROBING > 1 ?

EDIT : si cette ligne est commentée
//#define MULTIPLE_PROBING 2
alors c'est normal puisque:
// Feedrate (mm/min) for the first approach when double-probing (MULTIPLE_PROBING == 2)
#define Z_PROBE_FEEDRATE_FAST (4*60)
// Feedrate (mm/min) for the "accurate" probe of each point
#define Z_PROBE_FEEDRATE_SLOW (Z_PROBE_FEEDRATE_FAST / 2)

Modifié (le) Juin 17, 2022 par pommeverte

[willy2406]

Re !

J'ai #define MULTIPLE_PROBING 3

Il fait bien 3 palpages par point de mesh, mais les 2 derniers se font à la même vitesse que le premier...

bon là je vais me coucher, et puis ce we je serais pas trop dispo, mais je reviens rapidement. Merci de ton aide !

[willy2406]

Je reviens vers vous, si quelqu'un a une idée du pourquoi du comment ? 

Donc, que ce soit lors du homing, ou lors du palpage du bed, le mouvement apres le "bump" se fait bien à la même vitesse que le premier

Je poste mes fichiers de config au cas ou... 

 

Configuration.h Configuration_adv.h

[willy2406]

Pour info, problème résolu en compilant Marlin 2.1.x et en repartant des 2 fichiers de config d'origine, maintenant tout tourne nickel. 

En passant, j'ai désactivé le 

//#define EXTRA_PROBING    1 

Je pense que c'était ça qui posait souci dans la 2.0.9.3 mais je ne suis pas certain.

Du coup la marge d'erreur est de 0.005 mm lors du palpage, c'est parfait