HGR_14

Bonjour Merci pour ton retour duncan.. effectivement le serrage trop tendu de la courroie X entraine des points durs sur les déplacements.. c'est pour cela que j'ai grandement diminué les décrochage en diminuant la tension de la courroie.. De mon coté j'ai fait des essais en remettant une détection de fin de course classique avec un inter pour voir si la détection sur collision du PAP pouvait interférer en envoyant des signaux furtifs sur la ligne de fin de course... On peut éliminer cette piste car j'ai activé des fin de course durant une impression et il ne se passe rien.. Du coup il faut investiguer la piste d'une courroie X défectueuse (pourtant au touché les crans sont bien francs. pas de signe d'usure ou autre)... Sur la mienne la courroie Y est différente de la X car le coté cranté est orange.. (mais comme je l'ai décrit dans un précédent post en voulant tendre la courroie Y pendant une impression j'ai généré des pertes de pas en Y aussi.... ). CE que je comprend pas c'est que le système d'entrainement de l'axe X le swX4 et le même que celui de la sw X3 (j'ai même pu interchanger des pièces lors de mes premiers essais). C'est juste le guidage qui est différent. mais le X3 ne m'a jamais fait de décalage (j'ai d'autres soucis mais pas celui ci..) En dernier recours je vais essayer de changer le moteur PAP sur X par un modèle plus puissant.. mystère mystère!!.. ;)

Bonjour J'ai effectivement fait des essais de réglage en baissant la sensibilité du stallguard du driver... ca n'a pas éliminé les pertes de pas mais cela a rendu des "chocs" plus durs lors des homing... j'ai également augmenté légèrement le courant du moteur pap pour voir mais pareil : aucun résultat.... J'ai commencé les modifs pour faire des essais sans le virtual_EndStop : J'ai enlevé le cavalier de diag du Driver X et connecté un simple interrupteur sur le connecteur X-.. il faut juste changer une ligne dans le fichier de config et le homing se fait via l'interrupteur ( à la main ) pour les essais!! des que j'ai le temps je vais lancer des impressions en me mettant dans les conditions favorisant le décrochage/X. (impressions très lentes et déplacements à 300mm/s etc..).. Résultats au prochain post!!!

Bonjour Petit bilan avec une semaine d'impressions intensive : j'ai observé un seul décalage en X qui ne s'est pas reproduit quand j'ai repassé le même GCODE qq minutes après.. Bref c'est à mon sens pas satisfaisant de compter sur le réglage touchy de la tension de la courroie / X... Si l'on lance des impressions longues c'est trop risqué.. (pour l'instant je les confie à ma X2 qui est d'une fiabilité irréprochable)... Je vais donc explorer la faisabilité d'un retour à une détection de fin de course à l'ancienne avec un bon vieux capteur ou interrupteur!!!... la carte a bien une entrée X-.. l faut juste que je sache qu'elle est le numéro de la pinoche END X à indiquer à Klipper et désactiver la détection via blocage/collision du PAP que je soupçonne d'être à l'origine du problème !! Je vous tiens au courant de mes essais!...

Bonjour Petit bilan après une semaine non stop d'impression avec divers pla et des distances de retrait principalement à 1 mm et un peu à 3mm avec un PLA bois assez filandreux : pas un seul blocage de buse.. et une qualité des coutures bien meilleure et sans stringing...j'aurais du le faire bien avant (avec la SW X2!!)

Merci LilYoda pour cette info.. Sur les autres photos du site on voit que coté buse il y a des changements aussi. (heatbreak nouveau??).. Je vais en acheter une aussi pour voir.. Cordialement

Bonjour J'ai également eu ce soucis quasiment des le début et j'ai essayé plein de trucs Echanger le moteur X avec ma X3 (c'est exactement le même) : aucun effet Interchanger le driver des moteurs X et Y sur la carte mère avec tous les paramétrages Klipper qui vont bien... : le défaut est resté sur l'axe X!! Comme je pense que le problème vient du système de détection collision sur les PAP (pic de courant) j'ai diminué la sensibilité de contact quitte a avoir des chocs un plu plus violents lors des homes sur x : Aucun effet. J'ai finalement eu un peu la paix en diminuant la vitesse déplacement de 300m/s à 150m/s car j'imprime souvent assez lentement (50mm/sec sur les faces extérieures pour un beau fini) et il devait y avoir des transitions 50mm/s >300m/s peut être a l'origine des pertes de pas ou interprétées comme une collision par le driver.. bref ca m'a permis de reprendre des impressions sans risquer les fâcheux décalages... Par contre en changeant de tète (pour investiguer les soucis de blocage de buse) j'ai du démonté la courroie et la remettre.. et la j'ai constaté à nouveau qq décalages sur X... De plus pendant les essais à un moment je me suis aventuré à tendre la courroie de l'axe y qui me semblait lâche et la j'ai provoqué un décalage sur Y.. il y a donc un lien de cause à effet entre la tension des courrois et les décalages.. et il visiblement il faut les laisser un peu lâches.. c'est assez contre intuitif mais à priori ca marche chez moi.. Enfin comme j'ai la version S1 je lance des tests de fréquences car la tension des courroies doivent impacter ( vu comment elles vibrent pendant le test!!).. ensuite je touche plus à la tension!! Je vais essayer de faire des impressions avec des vitesses déplacements relevées à 300mm/s pour voir si ca tient.. je vous tient au courant.. Je te conseille donc de baisser la tension de la courroie du X pour voir ce que ca donne...

Bonjour comme indique dans le post précédent j'ai également eu le même problème. Apres avoir reçu une deuxième tète j'ai eu le même problème lors les première impression. J'ai finalement fait plein de réglages différents avec un PLA qui bloquait la buse à tout les coups... et j'ai réussi a ne plus avoir de blocage en abaissant la distance de rétractation à 1 mm... (et visiblement ca suffit pour éviter le stringing avec le PLA que j'utilise)... Avec d'autre PLA ca passe avec les 5-6 mm (voir plus mais ca dégrade la qualité) que je mettait dans les distances de rétractation mais pas avec le FiberLogy EasyPla !!.. Donc pour l'instant tout va bien avec 1 mm de rétractation

Bonjour Je confirme avoir également des soucis de "blocage" de la buse sur ma SW X+4.. Je dis blocage car à ce jour je n'ai pas eu de "vrai bouchage" nécessitant un démontage de la tête pour extraire le PLA coincé. Ce sont les rétractations qui finissent à un moment par bloquer l'extrusion mais je récupère toujours le fil par une simple manœuvre de retrait à partir du petit écran... Apres de multiples essais j'ai changé la distance d'extraction habituellement de 3-4 mm en direct drive par une distance de 10-12mm (plutôt d'usage avec la techno type bowden) et j'ai considérablement réduit les blocages.. c'est vraiment bizarre... Par contre si ca ne bloque plus j'ai toujours des artéfacts de sous extrusion qui sont très moches et fragilise les pièces qui nécessitent beaucoup de rétractations.. le problème n'est donc pas vraiment réglé... (sauf pour les pièces très compactes "monobloc" avec peu de rétractations).. Ce problème je l'avait déjà avec la X3 mais c'est normal car la X3 et X4 ont visiblement sous le capot le même extrudeur Dual Gear .. Sur la X2 (single Gear) ou avec mes vielles imprimantes maison avec Bowden je n'avais de tels blocages ( des vrais bouchages oui mais dus à de mauvaises manip ou réglage)... Je vais recevoir une deuxième tête pour la X4 je vais l'installer et étudier la première en la démontant intégralement... Je vous tiens au courant de mes investigations mais je pense que le système d'extrusion est le point faible des série X3 et 4 qui ont malgré tout pas mal d'atouts ailleurs mais qui sont un un peu gâchés car je n'arrive plus à bien imprimer des pièces "complexes" que j'imprimais avant

Bonjour Non non je confirme c'est bien un firmware X1 sur carte GD32 (qq icones différents et l'indication explicite dans un sous menu que c'est pour la X1) .. je pense que le STM doit être introuvable et ils passent visiblement tout sur le GD.. Hormis le fait que l'on ai pas encore la maitrise de µcontroleur pour sortir des firmwares TFT plus sympas que les versions officielles, le GD offre - a priori - de meilleurs performances que le STM ( Coeur M4 versus M3, 120 MHz vs 72 Mhz plus ram etc..).. Cela laisse imaginer des interfaces peut -être plus sophistiquées avec des animations, visu du STL etc.. Bon, il faut juste que l'on trouve le petit truc pour créer les bin qui vont bien... comme je l'ai indiqué dans le précédent post, pour flasher la carte GD les fichiers et répertoires à mettre sur la racine la SD ressemblent beaucoup à ceux que l'on met sur la racine de la SD pour flasher les cartes STM.. donc on croise les doigts!!! Cordialement

Bonjour Ok très bien, si ca marche j'en commanderai un aussi pour modifier celui que j'ai reçu!! Concernant la compilation du GD je vais essayer de trouver du temps pour creuser le truc.. mais je ne connais même pas environnement de compilation, IDE etc.. Cordialement

Bonjour Mauvaise nouvelle : j'ai reçu un TFT commandé chez AliExpress à cette adresse https://a.aliexpress.com/_EwCC2kZ mais visiblement ils livrent maintenant avec du GDGD32F305VCT6... en tout c'est ce modèle que j'ai reçu..:(.. Dommage, du coup j'ai essayé le dernier firmware de cet écran fourni par Artillery avec support de M600.. + la version firmware de MrMagounet pour cet écran et ca marche : Le M600 est dispo pour les impressions à partir de la carte SD ou USB (pas en via un PC qui fait tourner Cura par exemple).. Il faut juste trouver le bon réglage pour changer correctement le fil (sous cura dans mon cas).. Maintenant j'ai l'impression que l'on av bientôt pouvoir compiler le code pour les les GD.. la structure des fichiers et répertoires est très semblable à celle utilisée pour flasher les STM.. (par contre tous les icones sont en . bin et non en .bmp) Cordialement..

Pas de soucis... Pour l'instant je me fais la main avec X2 stock!! Je programme régulièrement en C et Python je ne sais pas si je peux aider!! Par contre sur le site SAV d'Artillery ils ne fournissent qu'un firmware de TFT et qui date de 6 mois mais pas pour le nouveau!.. du coup si on le plante c'est embêtant!! Cordialement

Bonjour Merci pour ce retour rapide!! Effectivement c'est bien un GD32 (il y a un gribouillis sur la puce pour cacher la ref mais on arrive à deviner quand même)!!! Cordialement

Bonjour, J'ai reçu ma SideWinder X2 il y a 15 jours. Si j'ai bien compris je ne peux pas mettre l'écran à jour avec le dernier Marlin puisque je risque d'avoir un écran TFT MKS équipé des Puces GD32F305? D'ailleurs il a-t-il une commande GCODE ou autre pour connaitre la config hard de la machine et éviter de l'ouvrir? Bien cordialement