Taille du bed fausse + "Printer halted print canceled" sur SKR 1.4 + Marlin 2.0.6

[Badour]

Bonjour à tous,

 

Je fais suite à ce post sur le changement d'une CM. J'ai donc installé une SKR 1.4 avec TMC2209 sur une AlfaWise U20, fait un Marlin v2.0.6, réglé le sensorless homing, configuré Octoprint pour avoir un truc nickel chrome.

Sauf que voilà : au dernier moment de mes tests, une surprise : les moteurs vont dans le bon sens, le sensorless homing fonctionne et les steps de l'extrudeur sont calibrés mais... Quand j'appuie sur les boutons pour aller aux coins du bed pour faire le leveling, l'imprimante ne va pas aux coins, elle dessine un carré, certes, mais pas de la bonne dimension! Le "X0Y0" selon elle est en fait hors du plateau (Quelque chose comme -10 en X et 0 en Y). Et selon les positions le plateau devrait faire environ 220x200 au lieu de 300x300 en vérité. Pareil pour le Z qui est un peu plus bas que d'habitude.

Ce qui est étrange, c'est que quand je passe par le plugin "Bed Leveling" sur Octoprint, ça fonctionne tout bien, les points sont aux bons endroits... Jusqu'à ce que je lance une impression, rebelote, mon impression n'est pas au centre et le Z plus bas, ce qui a d'ailleurs au passage laissé une marque sur le bed

Bien entendu dans configuration.h du Marlin j'ai bien mis :

// The size of the print bed
#define X_BED_SIZE 300
#define Y_BED_SIZE 300
#define Z_MACHINE_MAX 400

// Travel limits (mm) after homing, corresponding to endstop positions.
#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS X_BED_SIZE
#define Y_MAX_POS Y_BED_SIZE
#define Z_MAX_POS Z_MACHINE_MAX

&

#define LEVEL_BED_CORNERS

#if ENABLED(LEVEL_BED_CORNERS)
  #define LEVEL_CORNERS_INSET_LFRB { 30, 30, 30, 30 } // (mm) Left, Front, Right, Back insets
  #define LEVEL_CORNERS_HEIGHT      0.2   // (mm) Z height of nozzle at leveling points
  #define LEVEL_CORNERS_Z_HOP       4.0   // (mm) Z height of nozzle between leveling points
  //#define LEVEL_CENTER_TOO              // Move to the center after the last corner
#endif

C'est à n'y rien comprendre... En plus de ça le z homing est parfois chiant, il ne va pas toujours jusqu'en bas, il descend un peu mais s'arrête ensuite sans avoir déclenché l'endstop. J'ai même déjà eu des "Printer halted. Kill canceled()" pendant certains homing en Z!

J'ai essayé de refaire un Marlin avec la 2.0.7 et la 2.0.x bugfix mais là c'est carrément "Printer halted. Kill canceled ()" qui s'affiche quand je fais un home sur un axe, n'importe lequel! Du coup l'imprimante ne fonctionne pas...

 

Est-ce que quelqu'un par hasard aurait déjà eu ce problème ou sait d'où ça peut venir? Le seul que j'ai vu sur le forum c'était avec une Anet A8 et la personne est finalement repassée sur Marlin 1.9, ce que je n'ai trop envie de faire, surtout que la SKR 1.4 est une 32 bits...

Merci!

[Badour]

Mise à jour à aujourd'hui : Après (beaucoup) de réflexion, j'ai compris d'où venait la mauvaise taille du bed : en fait, le TFT V3.0 que j'utilise a deux modes (Marlin + touch). Je pensais que le mode touch n'était qu'une apparence qui exécutait ce qu'il y avait dans Marlin mais en fait non, certains paramètres sont dans le firmware! Donc j'ai compilé le firmware moi-même plutôt que d'utiliser celui mis à dispo sur le GitHub de BTT, et là, surprise : le bed était déclaré comme faisant 235x235... La taille d'une Ender 3 en somme. Donc j'ai tout modifié, ce que je comprends c'est que les boutons pour faire le leveling à chaque coin du bed généraient un gcode influencé par le firmware de l'écran et pas le Marlin. Donc ça, ça fonctionne, c'était tordu, mais chouette.

 

Par contre, même si le "printer halted. Kill canceled ()" n'est plus apparu depuis quelques temps sur le Marlin 2.0.6 chargé sur la CM, le problème de Z continue.

Sans que je puisse expliquer pourquoi, lorsque je charge un firmware sur la CM ça fonctionne nickel, mais dès que j'éteins et que je rallume l'imprimante lorsque je fais un home en Z l'axe descend un peu, puis s'arrête et le 0 est défini à cet endroit. Dans le vide, j'entends, il s'arrête n'importe où mais pas sur l'endstop. Comme si il y a avit un sensorless homing hyper-sensible sur le Z et qu'il y avait un point de friction, alors que j'ai pas mal desserré les excentriques de l'axe au cas où ça générerait un effort. Et donc du coup ben... C'est embêtant. J'ai diminué les vitesses (3*60 mm/min en homing) et les accélérations, mais toujours rien même si forcément le déplacement est plus lent.

D’où est-ce que ça pourrait venir ce problème?

[legired]

Salut,

Tu a surement besoin de jouer avec la sensibilité du sensorless dans le config_adv

[Badour]

il y a 13 minutes, legired a dit :

Salut,

Tu a surement besoin de jouer avec la sensibilité du sensorless dans le config_adv

Salut,

Je n'ai pas activé le stallguard sur le Z, uniquement sur les axes X et Y. Le stallguard sur Z je trouve ça carrément dangereux... Même si dans l'absolu ça taperait sur l'endstop dans tous les cas.

La, à chaud dans mes réflexions, je me demande s'il ne faudrait pas inverser l'état de l'endstop. Peut-être que dans Marlin je l'ai déclaré comme NO au lieu de NC. Ou alors ce serait la ligne "ENDSTOP_PULLUP" à désactiver, j'avoue ne pas trop savoir à quoi elle sert celle-là. Mais ce qui est étrange c'est que ça n'explique pas pourquoi ça marche juste après un flash et pas après un redémarrage...

[legired]

Salut,

Alors si tu a un doute sur la logique de l'endstop, rien de plus simple  tu connecte ton imprimante a octoprint ou protnerface ou ce que tu veux, et tu execute la commande M119, cela te retourne l'état de tes endstop

Donc tu le fait avec le Z dans le vide (donc non appuyer sur l'endstop) si il te dit TRIGGER, c'est qu'il faut inversé la logique dans le fw, si il te dit OPEN c'est que la logique est bonne et dans ce cas faut chercher un autre truc 

[Badour]

il y a 1 minute, legired a dit :

Salut,

Alors si tu a un doute sur la logique de l'endstop, rien de plus simple  tu connecte ton imprimante a octoprint ou protnerface ou ce que tu veux, et tu execute la commande M119, cela te retourne l'état de tes endstop

Donc tu le fait avec le Z dans le vide (donc non appuyer sur l'endstop) si il te dit TRIGGER, c'est qu'il faut inversé la logique dans le fw, si il te dit OPEN c'est que la logique est bonne et dans ce cas faut chercher un autre truc 

Je vais tester ça ce soir!

Modifié (le) Octobre 8, 2020 par Badour

[Badour]

Il y a 7 heures, legired a dit :

Salut,

Alors si tu a un doute sur la logique de l'endstop, rien de plus simple  tu connecte ton imprimante a octoprint ou protnerface ou ce que tu veux, et tu execute la commande M119, cela te retourne l'état de tes endstop

Donc tu le fait avec le Z dans le vide (donc non appuyer sur l'endstop) si il te dit TRIGGER, c'est qu'il faut inversé la logique dans le fw, si il te dit OPEN c'est que la logique est bonne et dans ce cas faut chercher un autre truc 

M119 fait et RAS, l'endstop fonctionne bien.

J'ai remarqué quelque chose par contre : ce problème de homing en Z ne survient que SI ET SEULEMENT SI j'ai fait un homing en Y auparavant en fait. Donc le homing général est concerné. Curieux... Alors que le homing en X ne pose aucun problème.

J'ai essayé de désactiver ENDSTOP_PULLUP pour le Z_MIN, rien à faire, au contraire le "printer halted. Kill canceled ()" est revenu, en mode touch ou via Marlin.

[Badour]

7 Marlins différents plus tard (2.0.5.3, 2 x 2.0.6 de sources différentes, 2.0.7 "bugfix", 2.0.7 et 2.0.7.1 "bugfix du 11/10/2020), le bug y est toujours... Ce qui m'amène à reconsidérer la chose sous un angle hardware.

Est-ce que ça pourrait venir des drivers? Pour info j'ai mis le jumper pour passer en UART sur tous les drivers par contre je n'ai coupé les pins DIAG "que" sur les drivers du Z et de E. Peut-être que ça vient de là? Pour rappel je suis en sensorless homing en X et Y tandis que le Z a toujours son endstop d'origine (2 fils).

[Badour]

Des tests de drivers, moteurs et endstops plus tard, j'ai testé avec une autre SKR 1.4 neuve... Même problème. Donc soit j'ai une malchance pas possible (et ça, j'en suis à un point où je me pose des questions!) soit mon programme merde mais je vois même pas comment c'est possible!

 

EDIT du 12/10, tard : J'ai eu une illumination. Si le déplacement avant le bug du Z n'est jamais le même c'est peut-être que quelque chose déclenche l'endstop. Là j'ai gambergé, BEAUCOUP gambergé et je me suis soudain rappelé mes cours d'electronique en école d'ingé... Du bruit, bien sûr! De là, il faut mettre en place un noise gate, ou modifier le threshold sur le firmware. Bingo, la ligne existe :

#define ENDSTOP_NOISE_THRESHOLD 2

Et ça marche. J'y ai perdu un temps hallucinant, une CM en plus "pour rien" et beaucoup de santé mentale mais ça marche!

Enfin, ne parlons pas trop vite. Je testerai une impression demain.

Modifié (le) Octobre 24, 2020 par Badour

[fran6p]

@Badour

Content pour toi que ça fonctionne (on croise les doigts tout de même ).

Sinon tu aurais une photo de tes jantes alu 18"

[Badour]

Il y a 3 heures, fran6p a dit :

@Badour

Content pour toi que ça fonctionne (on croise les doigts tout de même ).

Sinon tu aurais une photo de tes jantes alu 18"

Merci!

Il reste encore un problème qui fait qu'en utilisant le mode tactile du TFT V3.0 les déplacements dans les coins pour faire le leveling va à Z0 et pas Z0.2, mais en passant par l'emulation de Marlin c'est bon.

Actuellement ça imprime le fang de Daemoncrack, je croise les doigts aussi mais ça a l'air de fonctionner depuis 3h...

J'ai voulu faire la blague par rapport au tuning si cher à ma région géographique, mais pourquoi pas lui faire un chariot de transport un jour, qui sait?

Modifié (le) Octobre 25, 2020 par Badour

[Tony007]

Le 08/10/2020 at 10:39, Badour a dit :

Mise à jour à aujourd'hui : Après (beaucoup) de réflexion, j'ai compris d'où venait la mauvaise taille du bed : en fait, le TFT V3.0 que j'utilise a deux modes (Marlin + touch). Je pensais que le mode touch n'était qu'une apparence qui exécutait ce qu'il y avait dans Marlin mais en fait non, certains paramètres sont dans le firmware! Donc j'ai compilé le firmware moi-même plutôt que d'utiliser celui mis à dispo sur le GitHub de BTT, et là, surprise : le bed était déclaré comme faisant 235x235... La taille d'une Ender 3 en somme. Donc j'ai tout modifié, ce que je comprends c'est que les boutons pour faire le leveling à chaque coin du bed généraient un gcode influencé par le firmware de l'écran et pas le Marlin. Donc ça, ça fonctionne, c'était tordu, mais chouette.

 

Par contre, même si le "printer halted. Kill canceled ()" n'est plus apparu depuis quelques temps sur le Marlin 2.0.6 chargé sur la CM, le problème de Z continue.

Sans que je puisse expliquer pourquoi, lorsque je charge un firmware sur la CM ça fonctionne nickel, mais dès que j'éteins et que je rallume l'imprimante lorsque je fais un home en Z l'axe descend un peu, puis s'arrête et le 0 est défini à cet endroit. Dans le vide, j'entends, il s'arrête n'importe où mais pas sur l'endstop. Comme si il y a avit un sensorless homing hyper-sensible sur le Z et qu'il y avait un point de friction, alors que j'ai pas mal desserré les excentriques de l'axe au cas où ça générerait un effort. Et donc du coup ben... C'est embêtant. J'ai diminué les vitesses (3*60 mm/min en homing) et les accélérations, mais toujours rien même si forcément le déplacement est plus lent.

D’où est-ce que ça pourrait venir ce problème?

Bonjour, j'ai le même problème sur le bed size et quasiment la même config U20/CRTouch/skr3/tft35 . Je n'arrive pas à flasher le tft35.

aurais-tu un firmaware ?

Merci

 

 

 

[pommeverte]

Salut @Tony007,

Si c'est juste pour la taille du plateau, il n'est pas nécessaire de flasher le firmware de l'écran. Tu n'as qu'à décommenter la ligne

  //#define M115_GEOMETRY_REPORT

dans le fichier configuration_adv.h pour que la taille soit mise à jour automatique en mode TFT.

Source: fichier config.ini de l'écran:

# The TFT will auto-detect the machine size (min and max) in Marlin firmware (requires

# enabling "M115_GEOMETRY_REPORT" in Configuration_adv.h in Marlin firmware).

[Tony007]

J'ai vérifié il est déjà décommenté.

Est-ce qu'on peut le modifier sur l'interface?

Merci.

#define EXTENDED_CAPABILITIES_REPORT

#if ENABLED(EXTENDED_CAPABILITIES_REPORT)

  //#define M115_GEOMETRY_REPORT

#endif

 

// @section security

[pommeverte]

il y a une heure, Tony007 a dit :

J'ai vérifié il est déjà décommenté.

dans ton aperçu écran, il ne l'est pas ... il faut enlever les //