autoleveling Souci avec le nivellement automatique Klipper

[_Edvin311_]

Bonjour à tous,

Je ne suis pas sûr d'être au bon endroit pour poster cela, auquel cas je m'en excuse.

Je vous écris car je commence à manquer d’idées .

Mon problème concerne une imprimante 3D entièrement faite maison, issue d’un mélange entre une Tevo Tornado et une CR-10 Pro, transformée en CoreXY fonctionnant sous Klipper. Elle est équipée d’une carte mère MKS Gen L v2.1 qui gère les trois axes Z, les axes X et Y, le plateau, un ventilateur et l’endstop Y. De l’autre côté, j’ai un EBB36 connecté en réseau CAN bus pour le reste, à savoir l’extrudeur avec son moteur et ses ventilateurs, l’endstop X et une sonde Eddy Coil pour l’endstop Z ainsi que le bed mesh.
Tous les drivers moteurs sont des TMC2209 en UART, et j’ai deux tailles de moteurs sur l’axe Z : un grand moteur central et deux plus petits à l’arrière. Klipper, quant à lui, tourne sous Linux Mint sur un PC OptiPlex 5060 équipé d’un i5-8500T et de 8 Go de RAM.

Le problème est que lors de l’impression, le bed mesh n’est pas pris en compte. J’en veux pour preuve que sur toutes mes pièces, un côté est trop écrasé tandis que l’autre se décolle du plateau (warping).
Je trouve déjà étrange d’avoir ce type de désalignement, sachant que j’effectue un Z-tilt juste avant le bed mesh. Cela devrait, en principe, corriger les écarts, mais passons, le souci est que le bed mesh ne compense absolument pas.

Lorsque j’imprime plusieurs rectangles de tailles différentes pour vérifier la planéité du plateau, je ne vois aucune correction effectuée par les axes Z. Or, sous Marlin, je me souviens que la compensation sur l'axe Z était visible à l’œil nu.

J’ai essayé énormément de choses, difficile de tout lister, mais dans les grandes lignes j’ai testé :

• Un bed mesh seul, puis son chargement dans le G-code de démarrage ;

• Une exécution du bed mesh directement dans le G-code de démarrage ;

• Une exécution du bed mesh suivie d’un chargement du mesh dans le G-code de démarrage ;

• Une exécution du bed mesh, une sauvegarde, puis un chargement du mesh dans le G-code de démarrage.

Malheureusement, rien n’a fonctionné…

Je ne suis pas un expert, plutôt un bricoleur passionné, c’est pourquoi je fais appel à votre aide.
Je joins à ce message ma configuration ainsi qu’une capture d’écran de mon bed mesh.
Ma configuration ayant été créée par mes soins, je vous demanderai d’être indulgent si vous constatez des incohérences ou des erreurs , et si possible, de me donner quelques conseils .

Merci à vous.

macroperso.cfg printer.cfg

Modifié (le) il y a 11 heures par _Edvin311_

[Savate]

il y a 18 minutes, _Edvin311_ a dit :

Malheureusement, rien n’a fonctionné…

Je vois que tu charge un SKEW_PROFILE à la fin de ton Gcode de démarrage (elle est si tordue que ça ?)

J'essayerai de charger le SKEW avant le bed mesh

ET surtout le ZTILT avant

et pour le bed mesh si tu as une version récente de klipper l'utilisation du adaptive est plus efficace

ce qui donnerait un print_start

[gcode_macro PRINT_START]
gcode:
    {% set BED = params.BED|default(60)|float %}
    {% set EXTRUDER = params.EXTRUDER|default(200)|float %}
    G28
    Z_TILT_ADJUST
    SKEW_PROFILE LOAD=Skew ; peut être avant le ztilt, je n'utilise pas le skew ...
    BED_MESH_CALIBRATE ADAPTIVE=1 : ne fait le bed mesh que sur la partie à imprimer
    M104 S{EXTRUDER}
    M190 S{BED}
    G28
    G92 E0;
    G90
    G0 X5 Y5 F6000
    G0 Z0.4
    G91
    G1 X120 E30 F1200;
    G1 Y1
    G1 X-120 E30 F1200;
    G92 E0;
    G90
    G1 Z15.0 F600 ;move the platform down 15mm
    G1 X125 Y125 F3000
    G92 E0 ;zero the extruded length again
    G1 F9000
    

Tu as quoi comme sonde ?

Modifié (le) il y a 11 heures par Savate

[_Edvin311_]

Bonjour Savate,
Merci pour ta réponse rapide.

Pour commencer, oui, elle est effectivement aussi tordue que ça, et même bien plus que tu ne peux l’imaginer .

J’avoue ne pas avoir pensé à placer la correction de skew avant le bed mesh, mais je ne pense pas que cela changera grand-chose, car la fonction de skew correction est arrivée récemment dans ma configuration et le problème de bed mesh existait déjà avant que je ne l'implémente.

Concernant le bed mesh adaptatif, je n’en ai pas vu l’utilité, car ma sonde, comme je l’ai mentionné plus haut, est une BTT Eddy Coil. C’est d’ailleurs la raison pour laquelle j’utilise la méthode de sondage rapid_scan pour le bed mesh.

[Savate]

il y a 58 minutes, _Edvin311_ a dit :

Concernant le bed mesh adaptatif, je n’en ai pas vu l’utilité, car ma sonde, comme je l’ai mentionné plus haut, est une BTT Eddy Coil. C’est d’ailleurs la raison pour laquelle j’utilise la méthode de sondage rapid_scan pour le bed mesh.

Attention, elle a tendance à dériver avec la t° la Eddy.
Mais effectivement dans ce cas tu peux enlever le adaptive=1
 

[_Edvin311_]

 

il y a 26 minutes, Savate a dit :

Attention, elle a tendance à dériver avec la t° la Eddy

Oui, je sais que la température de la sonde peut entraîner un drift, et malheureusement, le BTT Eddy Coil ne dispose pas de correction de drift.
C’est pour cette raison que, dans mon G-code de démarrage (old_PRINT_START, le PRINT_START simple viens de la séquence de lancement de la voron trident), je déplace la tête plus en hauteur du plateau afin qu’il puisse chauffer sans chauffer la sonde.

Cependant, même en partant du principe que la sonde dérive un peu, les résultats du bed mesh seraient peut-être faussés, mais comme tu peux le voir sur ma capture d’écran, j’ai presque 0,5 mm d’écart au maximum, et malgré cela, je ne constate toujours aucune compensation de l’axe Z…

Le drift du Eddy serra un problème pour plus tard .

Modifié (le) il y a 9 heures par _Edvin311_

[Savate]

il y a 10 minutes, _Edvin311_ a dit :

Cependant, même en partant du principe que la sonde dérive un peu, les résultats du bed mesh seraient peut-être faussés, mais comme tu peux le voir sur ma capture d’écran, j’ai presque 0,5 mm d’écart au maximum, et malgré cela, je ne constate toujours aucune compensation de l’axe Z…

il y a une limite de correction qui traine quelque part (il me semble que c'est 0.3mm max par défaut par rapport au zeroreferenceindex) et qui peut être la cause du problème.
 

 

[_Edvin311_]

Ce que tu me dit la m'intéresse énormément, dit moi s'en plus !
Comment modifier cette valeur ?

[Funboard29]

Bonjour,
Peut-être rajouter ceci au printer.cfg
 

Citation

[delayed_gcode bed_mesh_init]
initial_duration: .01
gcode:
  BED_MESH_PROFILE LOAD=default

 

[Savate]

il y a 43 minutes, _Edvin311_ a dit :

Comment modifier cette valeur ?

tu peux jouer avec zero_reference_index pour positionner la référence Z=0 à un endroit médian du lit comme indiqué dans cette partie

Maillage du Bed - Documentation Klipper

 

 

[_Edvin311_]

Peux-tu m’aider ? J’avoue ne pas être très à l’aise en anglais et je n’ai pas vraiment compris cette partie .

[Savate]

il y a une heure, _Edvin311_ a dit :

Peux-tu m’aider ? J’avoue ne pas être très à l’aise en anglais et je n’ai pas vraiment compris cette partie .

il faut rajouter dans la section mesh

zero_reference_index=les coordonées X, Y du centre du plateau

Comme tu as l'air d'avoir un plateau de 300x255

zero_reference_index=150,125
 

[bed_mesh]
speed: 200
mesh_min: 15,60  #35,-5
mesh_max: 285,275   #300,255
probe_count: 10,10
mesh_pps: 4,4
zero_reference_index=150,125
algorithm: bicubic
bicubic_tension: 0.2
horizontal_move_z : 5
split_delta_z: .025 # valeur par défaut 0.30 c'est beaucoup

Et vu que le scan va vite, tu peux augmenter le nombre de points

probe_count: 20,20 # par exemple au lieu de 10,10 ça donnera un meilleur apperçu de la surface.