Murdock

Après je ne vois pas bien ce que cela peut être d'autre. Sur un hotend plus "old school" j'aurais dis une fuite au niveau du raccord buse/heatblock mais ici cela n'est pas possible. Donc il faut croire que c'est bien un décollement de la pièce qui s'est collée à la buse et à dévié le flux de filament ...

J'ai également commandé l'adaptateur de Fred en cas de pépin. Mais je cherchais également une solution un peu plus light et qui réhaussait moins le PTFE. (Et qui permet de remettre le capot sans le modifier) Perso j'aime beaucoup les pneufit "ECAS" et je n'ai jamais rencontré de pb avec ces derniers. (Je les utilise depuis pas mal de temps sur mes vorons et c'est par exemple une des solutions natives proposées sur l'extrudeur Galileo 2) De plus ces adapteur présentent l'avantage d'êtres moins imposants et bas. J'ai donc réalisé la pièce suivante qui permet d'être utilisée aussi bien en préventif que curatif. Désolé pour le montage photo fait à l'arrache ... (Quand j'aurais éprouvé le truc, je déposerai les fichiers sur Printable et/ou Creality Cloud si certains sont intéressés)

Désolé de cette réponse tardive mais début de semaine assez tendue au taf. Je vais tester avec le wifi mais ca risque d'être pire... Le revendeur à remonté le pb chez Creality mais bon je pense qu'il ne faut pas s'attendre à grand chose. A suivre ... Merci pour ces infos.

@Poisson21 Pas de soucis. En fait de ce que j'ai vu sur la machine e en regardant vite fait la tronche du flux vidéo, ils n'utilisent pas un streamer classique comme celui utilisé d'habitude sous klipper. (en tous cas à première vue) Ce qui m'inquiète, c'est ce soucis de lags que ce soit dans un navigateur, par créality print et même l'appli mobile. Je ne te caches pas que j'aurais préféré que cela lag à mort chez tout le monde lol. Rien que de penser que c'est peut être un pb de ma machine et qu'il va falloir expliquer cela au SAV qui comme bien souvent ne va comprendre qu'à la 252 eme tentative d'explication, j'en ai des palpitations. lol. Je vais regarder si @Guilouz à vu un truc sur pour la cam sous fluidd. J'ai déjà utilisé ses scripts sur la K1 et c'était super bien fait et propre. Encore merci pour ton aide.

@Poisson21 Alors je ne me suis pa sencore occupé de la cam sous fluide donc je ne peux pas comparer mais que ce soit dans Creality Print ou juste dans un onglet de mon navigateur, je peux dire que c'est chronique. laplus souvent c'est un lag d'une grosse seconde mais j'ai parfois carrémént des pauses de facilement 2,5 à 3 secondes. Donc soit c'est un pb de ressources cpu, ram (ce qui est possible le cpu de la k1 n'était pas avions de chasse non plus et je ne me suis pas renseigné sur ce qu'il y avait dans la K2), bus de com ... Soit c'est un bug software. Bon je n'ai regardé que vite fait comment klipper était installé et comment dire ... C'est cela oui ... (Désolé pour mon humour à 2€) Au passage je ne sais pas si c'est mon coté développeur ou une forme de curiausité morbide mais je suis toujours fasciné par l'énergie dépensée par certaines boites ou personnes pour utiliser d'une façon non standard et plus laborieuse un composant logiciel qui marche très bien quand on l'utilise de la façon préconisée par son créateur. Soit le chip ethernet et franchement mauvais et cela provoque des lags. (Il faudra que je test en Wifi.) Soit ma machine à un soucis. (Mais curieusement à part cela le reste semble fonctionner normalement. C'est dommage car bon a part cela, l'installation chelou de fluidd (et surement du reste), mon bed qui tient plus d'un tacos que d'une feuille d'alu, la vitre de la porte collée trop basse une des pins de mon connecteur 485 qui sort plus que les autres (cela n'empêche pas le fonctionnement), elle fonctionne plutôt bien. La qualité de print est bonne le bruit un peu moins présent que sur la K1 Max, non franchement on est pas loin du très très bon truc. (A voir comment cela va vieillir ...) Tant que c'est logiciel, on peut espérer des correctifs. Mais vu la lenteur du reboot ... Le cpu me faitun peu peur cela me rappel quand j'avais voulu utiliser plusieurs caméras sur un Orange Pi Zero 2... Pour la cam sous fluidd tu es passé par la réinstall de moonraker ? Merci pour ton aide.

Bonjour à tous, Possesseur d'un K2 Plus depuis le début de semaine et on va le dire assez maniaque, vous vous doutez bien que 2-3 (euphémise ... :p) m'ont titillées avec cette dernière. Mais il y a un truc qui me paraît curieux et je n'ai pas réussi à trouver de personnes qui se plaignent exactement du même. Si il y a bien des plaintes au sujet de la cam (absence de fonctionnement par exemple) la mienne fonctionne mais j'ai dezs gros lags dans la vidéo. si j'affiche le flux vidéo par le port 8000 j'ai un bon arrêt de pas loin d'une seconde toutes les 3-4 secondes. (Ma machine est reliée par ethernet en Gb) On dirait presque que c'est ce cpu du bousin qui n'a pas assez de pêche pour traiter le flux. Quelqu'un à t-il déjà remarqué ce pb ? Merci pour votre aide ! François.

Bonjour à tous. Non je ne suis pas encore mort ! (Ca va venir lol mais pas encore) Je me fais effectivement très rare ces deniers temps tant sur le forum que sur le Discord. Un très gros projet au boulot (qui plus est générateur de stress) ne me laisse pas beaucoup de temps libre en dehors de mes heures de sommeil pour pouvoir me consacrer à mes passions ces derniers mois. J'ai depuis fin Mai 2 Voron V2.4 et une V0.1 en cours et je ne trouve pas le temps de les terminer. (Enfin de terminer déjà la première 2.4, les autres ne sont pas encore commencées ...) Je vais essayer de faire un "saut" sur le Discord pour voir ou en est le projet pour vous faire un point car honnêtement je n'ai pas codé une ligne dedans depuis Juin et je n'ai pas trop toujours par faute de temps suivi l'évolution depuis Juillet. Perso je suis toujours sur une version un peu "marginale" du projet dérivée la version 2.0.8.x avec quelques modifs perso que j'avais commencé à tester avant ma pause forcée. L'imprimante tourne assez souvent sans problèmes particuliers. Pour rebondir sur ce que disait @vap38 l'interface est effectivement un peu particulière mais bon pour ce à quoi elle sert, elle est tout à fait fonctionnelle. Bon après c'est vrai que dans ce domaine c'est une histoire de goûts et l'ergonomie choisie dépend souvent de la façon dont le développeur imagine que l'utilisateur va utiliser le produit. De plus Richard m'avait dis que l'écran était un peu particulier avec un IDE uniquement dispo en chinois. (le truc qui aide !) Perso je préfère gérer la machine par Octoprint. Pour avoir travaillé dur la partie "system" de Luxuri. Je peux affirmer que les versions basées sur 2.0.7.x sont fiables. Pour les versions 2.0.8.x je dirais que je n'ai testé que la première beta et cette dernière me semble fiable à 95 %. (C'est celle que j'utilise.) Comme indiqué plus haut je vais essayer de me renseigner dans la semaine et si possible (mais là franchement je doute d'avoir le temps) de tester la dernière version pour vous faire un retour. Un autre truc sympa que j'aurais voulu tester mais qui demande un peu de temps et de tester klipper sur la D3 ... Bon prints à tous et à bientôt !

Hello ! Pour le moment c'est via les commande gcode (M92 ...) sans oublier un M500 pour stocker dans l'eeprom. Nous avons augmenté la vitesse du port série. Essaies avec 250000.

Peux-tu essayer ce lien : https://www.facebook.com/kLAcK107

Moi non plus mais parfois on doit faire avec. Nous en avons eu quelques une qui sont passées sur le groupe.

Hello @methylene67 ! Alors même si je ne suis pas des plus réactif ces derniers temps à cause du boulot je peux donner quelques nouvelles du projet. La version "d'origine" basée sur les version 2.0.7.x de Marlin fonctionne bien, actuellement avec l'équipe de dev, nous testons un portage de cette dernière basée sur les firmwares 2.0.8.x qui contient d'origine certaines des corrections que nous avions apporté sur les versions 2.0.7.x. Cette version fonctionne elle aussi plutôt bien et pour l'heure nous ne relevons pas encore de problème particuliers. Nous pensions au départ pouvoir proposer une fusion complète de nos modifications de façon a ce qu'elles soient toutes intégrées en "standard" dans marlin cependant certaines d'entre-elles (beaucoup sont liées au TFT) sont encore trop éloignées de ce qui existe sur marlin. Donc pour le moment "Luxuri" va rester sur une branche dérivée de Marlin. La communauté de testeurs s'est beaucoup développée (certains d'entre vous en font partie) et ressemble plus à une communauté d'utilisateurs car les dernières versions publiées sont assez stables pour être utilisées au quotidien sans problèmes. (il y a maintenant une grande communauté Francophone et un canal dédié au Français est en place) Donc si vous avez une machine équipée d'un écran TJC (désolé mais les écran DWIN ne sont pas supportés) vous pouvez nous rejoindre en contactant Richard (le leader du groupe) sur facebook (Richard Layton de Denver) qui vous enverra une invitation pour nous rejoindre sur Discord on vous trouverez tout ce qu'il faut pour flasher vos machines. Alors c'est un peu compliqué à expliquer mais je vais essayer. Au départ l'idée de luxuri firmware n'était pas purement lié aux imprimantes Tenlog, c'était plutôt de proposer une application universelle pour piloter tout types d'imprimantes 3d avec un écran TJC. Vu qu'une majorité des devs avaient une D3 et que cette dernière était équipée d'un écran TJC, cette dernière est devenue le cas pratique à étudier. Certains des devs ont même changé de carte mère etc ... tout en gardant l'écran TJC pour tester "l'universalité" de la solution. (avec succès) Nous avons par exemple un membre qui fonctionne avec une BTT Octopus sur sa D3. Le marlin spécifique à la D3 (et à luxuri) n'est que le cas pratique des modifications à apporter à marlin pour fonctionner avec Luxuri. Au passage nous avons remarqué que beaucoup de choses ne fonctionnaient pas tip-top voir pas du tout avec un marlin "standard" sur une tenlog, nous avons donc corrigé des choses. L'équipes de Marlin qui fait un super boulot à également constatée certains des ces problèmes liés au mode idex en général (pas forcément uniquement à la tenlog) et a appliqués certains correctifs proches (voir identiques pour certains) aux notres, cependant Luxuri lui demande encore trop de spécificité pour pouvoir être fondu dans une version "tout constructeurs" et de ce point de vue notre but n'est pas atteint et c'est pour cette raison que le projet reste au stade "Alpha". (même si il est pour ainsi dire totalement fonctionnel) Cependant la version est opérationnelle dans le cadre des tenlog et peut être compilée à souhait selon vos désirs. N'hésitez pas à nous rejoindre ! Bons prints ! François.

Oui et surtout des accélérations car la gestion des TMCxxxx n'était pas terrible sur les vieille versions de Marlin.(Et même inexistantes sur les très vieilles versions) Et également le contrôle de l'extrusion. La différence est plus ou moins flagrante suivant les modèles et les vitesses paramétrées. Les versions 2.0.8.x arrivent ... Pas de quoi, je n'ai pas fais grand chose pour toi ... (Ce week-end à été un poil chargé ...)

Oui pourquoi pas. Mais tu verras cela se passe bien. Tout a fait. Oui c'est bien cela, la procédure est identique à celle du firmware d'origine. Pour info nous sommes en train de voir pour adapter la version 2.0.8.2 donc Luxuri va rester au top de la modernité du firmware.

C'est assez simple dans ton gcode de démarrage tu ne mets le G29 que si tu veux utiliser l'ABL ... Après il faut penser à la gestion des endstops d'origine. Sur le groupe ils ont pris le parti de ne plus utiliser les endstops d'origine. (cela libère 2 I/O) Pour moi cela n'est pas un bon choix car du coup tu vas gérer la synchro des deux axes Z par le bltouch qui prend lui même pour référence la surface du plateau et si ce derniers n'est pas parfaitement perpendiculaire au Z ... (Carnage) Si en revanche on garde les endstops pour les origines et que l'on ne se sert du bltouch que pour le l'ABL effectivement.Le problème c'est que la carte mère de la D3 ne possède pas beaucoup d'I/O libres ... Donc il faudrait sacrifier des trucs. Mais a part les capteurs de fin de filament ... mais cela ne fait qu'une entrée (il me semble que les deux capeurs sont en série) donc ... Bref l'idée de base est bonne mais franchement pour être franchement idéal c'est compliqué ... Il n'y a pas de dérangement, n'hésites pas ...

Non tu verras c'est que du positif. Alors cela n'est pas exactement cela, je préfère des 2209 mais je trouve que le Linear advance pose parfois quelques soucis. Donc je m'en passe sans problème. Mais pour avoir utilisé longtemps des drivers "classiques" je pense que ce sont les drivers silencieux qui demandent un réglage plus pointu de la machine. En revanche ils ont en plus du bruits des avantages comme par exemple pas d'effet peau de saumon sans tl-smoothers ... Mais concernant les TMC je préfère les 2209 aux 2208 c'est simplement que la machine fonctionne bien et que j'ai la flemme de les changer. Si cela vaut franchement le coup. La qualité de print est franchement améliorée. Ah bhen c'est pas bien compliqué ! En admettant que tes deux têtes sont réglées vraiment vraiment parfaitement : - En mode dual couleurs/matériaux pas de problème cela va bien fonctionner. - En mode clone/miroir Marlin va compenser la hauteur en fonction de la position de E1 et si le coté droit de ton bed est un poil plus haut, E2 va faire racler sa buse sur le bed ... Autant l'ABL est un vrai plus et un vrai confort d'utilisation sur une imprimante "classique". Autant sur une idex ... La seule solution serait d'avoir des axes Z indépendants (je te raconte pas le bronx ...) et un capteur sur chaque tête. J'avais imaginé un truc de guedin et technologiquement super hitech (bien que pas si complex que cela) mais franchement il faut réécrire une trop grande partie du firmware et franchement, franchement là j'ai la flemme ... (Eh puis je pense que la pauvre carte 8 bits de la D3 ferait un burnout !) Surtout que bon dans l'ensemble on peu s'en passer ...

Hello @Lechainon désolé de cette réponse tardive. Oui attention à bien vérifier que tu possèdes un écran TJC. Effectivement le linear advance n'aime vraiment pas les 2208. (Et pour l'avoir testé sur des 2209 c'est acceptable mais je trouve que cela n'est pas parfaitement aussi constant qu'avec des drivers basics) Oui si tu veux cette fonction il faut passer aux 2209 remplacement des drivers et réglage du vref à 1v (Préconisation constructeur) pour se faire le plus confortable c'est de relier la borne négative de ton multimètre sur une masse et de relier la borne positive de ce dernier à ton tournevis via une pince croco. De cette façon tu vois l'ajustement de la valeur en tournant la vis. (Au passage sur ma machine le réglage d'origine n'était pas bon et un des moteurs Z sifflait car il recevait un peu trop de jus ...) Non pas pour le moment. Hmmm possible je n'ai suivi que diagonalement (et pas du tout cette semaine car j'ai été pas mal monopolisé) les discussions sur le bltouch car sur une idex cela heurte quelque peu mes convictions. Car autant en mode dual color si tes deux tête sont parfaitement alignées cela fera le job autant dans les modes clones ou miroir cela va être du grand n'importe quoi ... Donc pour le moment vu qu' avec un bon bed levelling à l'ancienne et en jouant sur l'offset des endstop pour peaufiner la première couche cela se passe super bien, je ne me pose pas la question du bltouch. (Dont je suis pourtant un fervent adepte sur mes autres machines) En très gros pour vulgariser, cela va jouer sur les différents paramètres d'accélération ... de façon à garantir la constance de ton extrusion en maintenant une pression optimale de façon constante quelque soit les vitesse et accélération utilisées. En très gros ... Bons prints

Bhen oui je suis c.. Malynx Merlinx ! Bon ok je sors ... Bien vu je n'y pensais plus à celui là. Oui désolé je n'ai pas été assez clair, je "me suis" parfois dans ma pensée mais j'oublie parfois que les personnes ne sont pas dans ma tête. (Heureusement pour vous car c'est un rude bordèle la haut) Je ne parlais pas du paramètre Z2 de l'écran mais du paramètre "Z2_ENDSTOP_AJUSTEMENT" du firmware. Celui de l'écran joue bien sur le paramètre offset sur l'axe Z entre les buses. (Accessible avec la commande M218) Et effectivement le Z2 de l'écran ne va fonctionner qu'en mode "DUAL_X_CARRIAGE". Ce qui est logique puis ce que dans les modes clones ou duplication la tête ne peut être qu'a une hauteur simultanément. Mais si tout est parfaitement mécaniquement réglé, avec tout à zéro cela doit être parfait. Au passage j'en profite pour un petit rappel pour ceux qui galère avec la hauteur de première couche : (Normalement tout le monde connait mais si il y a des débutants qui passent par là ...) Si une fois votre levelling du bed effectué et parfait et que vous vous apercevez que cependant la hauteur de votre première couche n'est pas parfaite (un poil trop écrasée ou un poil pas assez) plutôt qu'essayer de combiner un niveau parfait des 4 coins plus la hauteur parfaite pour l'écrasement, utilisez la commande gcode M206. Cette dernière vous permettra de passer au firmware un très léger offset sur l'axe Z pour compenser la position réelle des endstops. Par exemple si votre 1ère couche est un poil trop écrasée, envoyer M206 Z-0.02 lèvera votre buse de 0.02 mm en position zéro. (une valeur positive écrasera plus) Cela vous permettra d'avoir plus facilement un lit de niveau sans trop trop vous préoccuper de l'écrasement. Vous trouverez ici la doc officielle de cette commande. Bons prints

C'est pour cela que le réglage des montants du portique et la synchronisation des axes Z est capitale. Pour se faire, il faut parfaitement "équerrer" les éléments du portique et le portique lui même par apport au châssis de la machine. (surtout à l'équerre de mécano et pas avec une équerre de menuisier) Et ensuite il faut pour synchroniser les Z prendre en référence une partie on est certain que le châssis sera bien plat (en fait il y en a pas 50 c'est juste devant la vis qui vient fixer les supports de fixation du portique car à cet endroit la tôle du châssis est plaqué contre le profilé alu. Pour mesurer la hauteur des deux côtés j'ai bricolé à l'arrache cet instrument : Il vient se clipser sur le rail MGN et 3 aimants néodymes aident à le stabiliser. Cela permet de clipser successivement des deux cotés de la machine et d'en déduire une différence approximative de hauteur qui doit au maximum être corrigée de façon mécanique en bougeant le endstop et en s'aidant de cales de réglages de soupapes. puis avec un firmware 2.x en jouant si nécessaire sur le paramètre Z2. (si il y a des intéressés je peux fournir les STL de ma bidouille) Après il n'y a plus qu'a faire un réglage précis du plateau par rapport à la tête E1 (Méthode classique) et de la hauteur de la buse de E2 au comparateur. Oui effectivement il y a un petit temps mort et le mouvant vers l'avant peut correspondre à un relâchement de la courroie lors de la désactivation des moteurs. Cela pourrait être aussi dans le script de changement d'outils si la position de parking est trop vers l'arrière la courroie va aller trop loin sur la poulie et quand le moteur va se désactiver ou simplement aller vers l'avant cela va donner un petit saut supplémentaire. Seulement un saut plus un saut ... Cela expliquerait d'ailleurs pourquoi tu n'as pas le pb avec Ideamaker. (La gestion du parking n'est certainement pas paramétrée de la même façon dans les deux trancheurs.)

Hello, 3 possibilités : - La hauteur des buses n'est pas parfaite et la buse deux accroche un peu la pièce et fait rater des pas. - Tout simplement l'axe Y rate des pas. (Mais tu aurais cela même avec une seul tête.) - Au moment du changement de couleur il y a peut-être une pause pour laisse le temps à la buse de monter en température, peut-être que la machine coupe le moteur provoquant un relâchement de l'axe Y à cause de l'élasticité de la courroie. Cette coupure automatique est assez problématique au passage, je ne sais pas ce qu'il ont voulu faire. Au passage 100mm/s est assez violent pour du vslot (axe Y) (surtout avec une gestion classique jerk) c'est faisable mais si tu ne veux pas rater de pas, il faut vraiment un réglage ultra fin et une pression légère des galets sur le rail.

Hello, oui il est désactivé. C'était de plus une version assez primitive du M600 (vieille version de marlin) de plus la gestion du m600 par un écran série doit être intégrée dans le firmware de ce dernier.

Bonjour à tous, oui c'était aussi le cas, surtout pour la sortie, car la carte dépasse à peine. (Ou alors il faut vraiment vraiment de petits doigts) Belle réalisation.

Alors on va y arriver comme répondu à @hcl28et à @Pouet il est encore en version "alpha". (alpha 3 pour êtres précis) Pour en dire un peu plus : Le projet se nomme "Luxuri Firmware". Il est en phase en "Alpha 3". L'équipe est internationale (une partie est basée aux US) et le jeu des décalages horaire ne facilite pas toujours la communication. Elle est dirigée par Richard LAYTON qui est basé aux Etats Unis. Nous communiquons ensemble via Discord et l'ambiance est franchement super sympathique et très amicale. L'équipe est composé de 4 développeurs et 25 testeurs. Je vous propose donc, avec l'accord de Richard, de vous joindre à nous en tant que testeur et de participer à cette aventure très enrichissante sur le plan technique (vous comprendrez mieux comment opère Marlin et comment opère l'écran avec ce dernier) mais aussi sur le plan humain. Les prérequis pour participer ne sont pas nombreux : - Avoir un peu de temps à consacrer au projet. - Ne pas être effrayé par le fait de devoir flasher sa machine. - Aimer l'expérimentation. - Aimer travailler en équipe. - Ne pas être trop perturbé par la langue de Shakespeare. (Vous pouvez dans certains cas vous aider de la traduction de google si vous êtes perdu et nos amis Anglophones sont très compréhensif sur notre Anglais approximatif) Afin de vous donner envie de nous rejoindre voici quelques-unes des fonctionnalités de la version actuelle qui je l'ai lu dans ce forum peuvent manquer à certains d'entre vous : - Réglages indépendants des "steps/mm" des deux extrudeurs. - Réglages indépendants des "PID" des deux "hotends" et du "bed" avec une super fonctionnalité graphique qui affiche une courbe des températures sur l'écran de la machine. - Ecran de saisie manuelle de commandes "GCODE" depuis l'écran de la machine. - EZ ABL. - BLTOUCH. - Levelling du bed en 5 points. ... Envie de participer à l'aventure ? Rien de plus simple, je vous invite à prendre contacte via MP de FB avec Richard : https://www.facebook.com/groups/752964928487976/user/500284060 Au plaisir de vous croiser sur le Discord du group et d'avoir vos impressions et retours sur "Luxuri". Normalement avec un ender 3 parfaitement calibrée, avec des TL-Smoother si avec A4988 d'origine, et un marlin récent tu dois pouvoir faire bien mieux qu'avec la D3 et son firmware d'origine. Cette machine est vraiment une bête de somme les deux miennes ne comptent plus les heures d'impression (plusieurs milliers) et impriment vraiment à la perfection. J'ai même réalisé des pièces avec des filetages pour de l'optique (pas de vis ultra fins) et le résultat sorti de l'imprimante fonctionne aussi bien que des pièces usinées en alu et sans aucun jeu. Bon après j'ai fais pas mal de modifications changement de carte mère et drivers, extrudeur et une tête optimisée pour les "hoverhangs" de conception maison. Le firmware fait beaucoup, la candidate qui s'approche le plus de cette qualité (et qui plus est sortie de la boite) est la Biqu B1. Avec Luxuri la D3 commence à s'en approcher fortement. Mais le profil de tranchage est plus "pointu" à réaliser. Les ender 3 donnent de meilleurs résultats avec un profil "approximatif". Mais ce n'est pas le sujet ici.

Il sera disponible pour tous une fois stable. Pour le moment le projet est encore en version alpha. (version alpha 4) il est utilisable mais avec précaution. Nous espérons bientôt passer au stade de la bêta.

C'est pour cela que la correction au tranchage doit rester l'ultime solution.

On est synchro pour moi aussi. Santé !