Aller au contenu

GO Print

Badour

Membres
  • Compteur de contenus

    61
  • Inscrit(e) le

  • Dernière visite

Information

  • Imprimantes
    Alfawise U20 "jackisée" : SKR 1.4, TMC2209, TFT 35 3.0, Marlin 2.0, renforcée avec des équerres, MOSFET, Octopi avec relais pour l'alim' et les LED, silent blocks et jantes alu 18".

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

Récompenses de Badour

Contributor

Contributor (5/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Badges récents

2

Réputation sur la communauté

  1. 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?
  2. 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.
  3. Mise à jour : J'ai remis les endstops au cas où, bah le problème reste le même...Sur une autre SKR 1.4 neuve reçue hier. Soit j'ai VRAIMENT, VRAIMENT pas de chance, soit le problème vient du firmware. Le matériel, j'ai interverti plusieurs les moteurs, les endstops et toujours pareil. Mais je comprends pas... Sérieux, j'en ai marre. Ca va finir sur un retour à une V0G cette affaire. 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 demain.
  4. Bonjour à tous, Les ennuis chez moi, faut croire que c'est jamais fini... J'ai créé un post à ce sujet, et ma question du moment c'est : est-ce que j'ai bien mis les drivers comme il faut? J'ai suivi le tutoriel de Chris Basement sur Youtube, donc j'ai coupé les pins pour les drivers Z et E et mis le jumper pour passer en UART sur tous les drivers. Mais est-ce que c'était ce qu'il faut faire? Résultat pour le moment, malgré 7 Marlin faits moi-même : dès que je fais un homing en Y celui du Z ne veut plus fonctionner. Tant que j'ai pas fait de homing en Y c'est bon mais dès que je le fais le Z bouge de quelques mm puis s'arrête, soit en considérant que le 0 est là où il s'est arrêté (ce qui souvent correspond à imprimer dans le vide), soit en me renvoyant un message "printer halted. kill canceled ()". Pas de problème avec le X par contre, sachant que X & Y sont en sensorless homing tandis que Z est avec l'endstop d'origine (2 fils). C'est à se taper la tête contre un mur ce problème
  5. 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).
  6. 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.
  7. 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...
  8. 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?
  9. 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!
  10. Une semaine (bien chargée) plus tard : - Le Z qui va trop vite et le moteur qui n'apprécie pas ça venait du réglage des steps/mm : au lieu de 400 il y avait 4000... Alors forcément le moteur se prenait pour une fusée! - Ventilateur 3010 changé, il tourne celui-là, aucun doute! "Yapluqua" comme on dit. - Octoprint fonctionne, même si ça m'a coûté une carte microSD : La première fois Octopi s'est mal mis dessus et en essayant de formater la carte ensuite ça me l'a flingué. Genre même pas récupérable via GParted. Sur la deuxième aucun souci même si j'ai dû le réinstaller parce que visiblement l'upgrade vers la v1.4 ne fonctionne pas avec mon install, sans que je sache pourquoi. Du coup j'ai laissé en v1.3 (et ajouté Astroprint, que je dois encore tester sur smartphone) : J'ai essayé rapidement, ça marche pas mal! - Par contre j'ai perdu beaucoup de temps (et copieusement insulté PlatformIO et VSCode) à trouver la solution au fait que lorsque je refaisais le firmware les valeurs ne changeaient pas (ex : le 4000 steps/mm qui ne bougeait pas). J'ai vu qu'à un moment du build PlatformIO me renvoyait un message d'erreur ("Unknown Folder Destination", un truc comme ça) donc je me suis focalisé là-dessus et pas moyen de le retirer. Et pourtant, j'ai testé BEAUCOUP de choses et de combinaisons. Ce n'est qu'hier soir (... 2 soirées à m'énerver dessus plus tard) que j'ai eu l'illumination : L'EEPROM du processeur est modifiée lors du premier flash parce qu'elle est vide, mais ensuite les flashs suivants ne la modifient plus! Ce que ça veut dire, c'est que les "valeurs-paramètres" ne sont pas écrasées à chaque flash. Et en soi c'est une super chose, mais ça m'a pris beaucoup de temps à comprendre que le problème venait de ce fonctionnement-là... Et depuis, même si le message d'erreur est toujours là le build se fait bien et fonctionne. J'ai testé en modifiant le nom de l'imprimante et nickel chrome. Plus que les serrages à revérifier, notamment l'axe Z, le sensorless homing à régler, les PID, le level du bed, le linear advance et normalement ce sera reparti!!! Enfin, j'espère
  11. Mise à jour du matin : Le problème de l'écran tactile venait d'une config' des ports série qui n'étaient pas bien définis dans Marlin (j'avais suivi le tuto de Chris Basement, mais c'est le tuto de ce forum sur l'installation de la SKR 1.4 qui m'a donné la solution dans le Marlin qui va avec). Les moteurs étaient à l'envers, ça c'est résolu, je vais ralentir le Z par contre parce qu'il se déplace super vite et j'entends que le moteur n'apprécie pas! Le ventilateur filament (le 4010) fonctionne très bien, par contre l'autre (3010) est visiblement mort. C'est ce que je soupçonnais depuis le début, et c'est confirmé : C'est ce p**** de ventilateur qui est la cause de tous mes problèmes (d'imprimante 3D, n'exagérons rien bien sûr). En fait, quand il a lâché la hotend chauffait trop donc bouchait, du coup j'ai changé la hotend en me disant que le problème venait de là, et c'est en changeant la résistance que j'ai cramé la CM... Grrr... Je positive en me disant que ça m'aura donné l'occasion de venir sur le forum et que j'ai une imprimante avec de meilleurs pièces et un Marlin propre, mais ça me fait d'autant plus rager que j'avais récupéré des 4020 pour faire le fang de Daemonscrack. Obligé de racheter un ventilo pour quelques impressions je trouve ça moche, mais bon. Petite question tant que j'y suis : Si je me base sur ce post, il faudrait rajouter un convertisseur PWM vers tension continue pour l'alimentation des ventilateurs pour ne pas les cramer prématurément. C'est toujours valable avec la SKR ou du coup je m'en fous maintenant?
  12. Bon, mon fils va mieux. Une grosse angine et un bouchon dans une oreille. Et une fin de semaine difficile. Bref. J'ai réessayé hier : Pas de feu, pas de fumée non plus, jusqu'ici tout va bien! J'ai fait mon Marlin tout bien en me basant sur des tutos croisés avec l'exemple pour l'U20 dispo sur le GitHub de Marlin. Le seul problème que je rencontre encore pour le moment c'est que sur le TFT 35 v3.0 l'imprimante est reconnue sur l'affichage Marlin mais pas l'autre. C'est con, il est joli l'autre. J'ai essayé avec deux baudrates différents (115200 et 250000 il me semble) à la fois sur l'écran et le Marlin mais jusqu'ici pas moyen. A voir, je vais le mettre à jour au cas où. Ce soir normalement je teste les moteurs, l'extrudeur, les chauffes, les ventilateurs et je règle le sensorless homing. "Y'a plus qu'à" comme on dit... Je croise les doigts mais jusqu'ici pas de casse!
  13. Du scotch autour des soudures des câbles donc pas d'échauffement à ce niveau, par contre Kapton au niveau de la hotend bien entendu Bien sûr, après si l'évolution nous a laissé la peur c'est peut-être bien que ça aide à survivre de temps en temps! Mais là en l'occurrence c'est surtout que j'enchaîne les "désagréments" avec cette imprimante, entre le plateau à revoir, la hotend, la CM... Sans compter mes échecs de print au début, j'ai mis du temps à bien trouver le niveau du bed! Je crois que l'imprimante a été maraboutée, j'en suis certain même! C'est un exorciste qu'il faut à ce niveau-là EDIT : Et là, au moment où je m'apprête à m'y mettre, mon fils se met à hurler de douleur... 39,8°. Quand je dis qu'elle est possédée! Bref, je remets à plus tard.
  14. Dis pas des choses comme ça, tu vas m'attirer la poisse! Faut que je remettre entre plus de scotch autour des fils thermistance/résistance hotend, histoire d'éviter un nouveau court-circuit... On sait jamais, par précaution.
×
×
  • Créer...