fran6p

Bizarre cette photo du pilote, on dirait de l'art moderne

Détrompe-toi, tous le font plus ou moins, y compris une certaine marque en vogue

C'est ainsi que je dépanne mes parents et d'autres membres de la famille depuis quelques décades . Par contre, ça ne fonctionne pas quand / si c'est un problème matériel .

Effectivement, quand elle fonctionne, c'est une bonne imprimante. Testé sur le forum ici.

C'est marrant, on dirait un clone de la MKSPI

Non, le Bltouch utilise un pointeau qui palpe la surface du plateau. Par contre, ma CR10-V2 utilisant un plateau en verre (carborundum) n'a pas de base magnétique, il faudrait donc pour pouvoir utiliser au mieux la tôle métallique en ajouter une. Non, sauf si tu veux imprimer un filament chargé de fibres (carbone, verre, métal, …) Pourquoi pas, mais le risque est d'alourdir la tête et donc de devoir réduire les vitesses. Sur ma CR10-V2, j'avais monté le Mini Xtruder de @Fourmi (hotends.fr). Il y a aussi la solution officielle de Creality prévue pour la CR10-V3 à base d'extrudeur Titan de E3D.

Jamais eu d'Artillery, aucune idée. Le prolixe @MrMagounet en ayant possédé quelques-unes devraient apporter de l'eau au moulin

Il faudrait y apporter quelques modifications (coupe filament, éjection des purges), mais cela reste du domaine du faisable (avec ou sans l'hypothétique (arlésienne) boitier multifilaments). Les SAV de Qidi ou d'Anycubic, pour les avoir pratiqués, me semblent plus «performants» que celui de Creality (non utilisé) au vu des retours utilisateurs.

La majorité des cas de pertes de connexions entrainant l'arrêt de Klipper sont dus à une liaison défectueuse (câble USB, prise de connexion sur la tête, interférence électriques). Donc pas simple à résoudre… D'autant plus que dans le câble USB de nos modèles (XM3, XP3) passe du 24 V, il faut juste espérer que les deux lignes de data soient bien isolées des interférences… ce dont je ne suis pas certain . En plus, le moteur de l'extrudeur peut lui aussi induire des perturbations électromagnétiques.

Aucune idée s'il existe une telle macro Sur nos systèmes à base de Debian, habituellement, c'est Network Manager qui gère les interfaces réseaux. On peut utiliser l'utilitaire « nmcli » en ligne de commandes (ssh donc): nmcli, seul, affiche la liste et l'état des connexions réseaux. mks@mkspi:/etc/network$ nmcli eth0: connecté à Wired connection 1 "eth0" ethernet (rk_gmac-dwmac), 76:09:8F:72:F7:44, hw, mtu 1500 ip4 par défaut inet4 192.168.1.126/24 route4 192.168.1.0/24 metric 100 route4 default via 192.168.1.254 metric 100 route4 169.254.0.0/16 metric 1000 inet6 fdad:14fd:cba9:6db3:2bbf:dd73:bff:4821/64 inet6 fe80::62b:66de:8f1:6305/64 route6 fe80::/64 metric 1024 route6 fdad:14fd:cba9:6db3::/64 metric 100 route6 fd46:bb36:a72a:1::/64 via fe80::d5c9:5c78:c443:ffea metric 100 lo: connecté (en externe) à lo "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 inet4 127.0.0.1/8 inet6 ::1/128 DNS configuration: servers: 192.168.1.254 domains: poulizac.net interface: eth0 Utilisez « nmcli device show » pour obtenir des informations complètes sur les périphériques connus et « nmcli connection show » pour obtenir une vue d'ensemble des prof> Consultez les pages de manuel nmcli(1) et nmcli-examples(7) pour les détails complets d'utilisation. nmcli connection (ou nmcli connection show) [!!! attention en anglais => connection, français => connexion !!!], affiche la liste des profils existants mks@mkspi:/etc/network$ nmcli connection NAME UUID TYPE DEVICE Wired connection 1 447463f3-b50b-39c2-bfba-5b34b8bf919d ethernet eth0 lo 25071737-28bf-4c45-8034-e194e762e601 loopback lo WESTEROS-NOVA 4e3b12ba-d78e-46fa-a7d2-374e3155866b wifi -- Chez moi, le Wifi est désactivé, seule la connexion Ethernet est active (plus l'interface réseau locale (lo)). Pour configurer la connexion Ethernet si elle n'est pas active, il faut d'abord configurer l'interface. Exemple pour que cette interface récupère une adresse IP via DHCP (box internet) : nmcli connection add type ethernet ifname eth0 con-name eth0-dhcp autoconnect yes Dans la ligne ci-dessus, il faudra remplacer le nom de l'interface réseau (eth0) par celle affichée dans la colonne DEVICE du résultat de la commande `nmcli connection`. En scindant la commande précédente : add type ethernet => on ajoute une connexion de type ethernet ifname eth0 => l'interface réseau con-name eth0-dhcp => nom donné à la connexion pour Network Manager autoconnect yes => active automatiquement la connexion au démarrage Restera à activer cette connexion : nmcli connection up eth0-dhcp Vérifier qu'elle est bien montée : nmcli device La colonne STATE de la ligne de l'interface réseau (eth0) doit indiquer : connecté (ou connected). On pourrait utiliser nmtui pour réaliser les manipulations précédentes : c'est une interface semi-graphique en mode texte. Moins puissante que nmcli, pratique pour une configuration rapide sans passer par des lignes de commande complexes, mais comme je ne l'utilise presque jamais, je ne m'attarderais pas.

Ça, c'est leur procédure standard quand un utilisateur via Mainsail ou Fluidd a tenté de mettre à jour Klipper / Moonraker pour revenir à leur système (Klippet en v0.10 et Moonraker en version antédiluvienne). Comme ton installation faite avec FreeDi n'utilise plus vraiment la solution Qiditech, n'applique pas cette procédure, tu risques d'empirer les choses et de t'arracher les cheveux (s'il t'en reste encore ). Dans un premier temps, même si Monsieur Freedi est désagréable et guère pédagogue, essaie de continuer à le faire te dépanner via le Discord ou le Github. Sinon, tu peux flasher ton eMMC actuelle (pas celle qui contient le système originel) avec la version 1.40 (qui contient l'image système), les versions suivantes (pas la V2.0 évidemment), sont prévues pour être mises à jour via Fluidd / Mainsail (Moonraker). Pense à ne pas te coucher trop tard, ce n'est pas bon à nos âges

De rien, je n'ai rien inventé, juste partagé. C'est le principe du forum : aider si / quand on le peut; la connaissance ne s'accroit que si on la partage (à ne pas confondre avec le kakemphaton célèbre de P, Corneille : «Et le désir s'accroît quand l'effet se recule.»).

Je ne sais pas non plus. Sur ma XMax3, le flash des MCUs avait été réalisé avec un Klipper v0.12. Via KIAUH, ma version actuelle de Klipper est en v0.13 et je n'ai pas eu de blocage me demandant de reflasher les MCUs. Là, comme @souriceaux est partie sur la version 2.0 de Freedi, il me semble que si les MCUs ont été flashés, ils sont en version Klipper v0.13. Je ne suis pas certain qu'en installant la version 1.40 de FreeDi si le flash des MCUs ne se refait pas en Klipper v0.12, que Klipper veuille bien démarrer. Si Freedi 1.40 ne reflashait pas les MCUs, ça reste faisable manuellement (facile pour la carte X4/X6, un poil plus pénible pour la carte de la tête d'impression).

@electroremy Je me suis permis de corriger ton titre (adhésion => adhérence)

Flasher l'image complète de la version 1.40 comme dit plus haut. Normalement avec cette version, les différents MCUs devraient être reflashés ainsi que l'écran, mais comme je n'ai jamais utilisé Freedi (j'aime pas la personne que je trouve prétentieuse et qui répond souvent quand on lui dit que ça ne fonctionne pas que chez lui tout est OK), j'espère que ça fonctionne comme le développeur le dit . Sur le Discord, j'ai bien cru que tu allais le rendre chèvre : envoie lui ce qu'il demande (-debug) et surtout fais attention, Linux contrairement à Windows est sensible à la casse (minuscule / majuscule), Freedi n'est pas la même chose que FreeDi, klippy~env pas pareil que klippy-env…