fran6p

Sous réserve, il me semble que les pièces de la XM3 et de la XP3 sont différentes . Pas sûr que ce soit interchangeable.

Je ne sais plus où j'avais récupéré ces fichiers au format step (les noms sont en allemand) : Druckkopf.zip À voir si tu y trouves ton bonheur.

Tout se trouve sur le Wiki : https://wiki.qidi3d.com/en/Q2/Printable-Components#q2-printable-components On en trouve d'autres sur printables. Une poubelle à purges .

Le frottement du PTFE sur les vis de la poignée du capot n'ont lieu que lorsqu'il est entrouvert (ou partiellement fermé) . Avec les filaments techniques où porte et capot doivent être fermés, aucun frottement. Sinon, Qidi recommande d'imprimer un rehausseur. Ce qui règle le problème du «frottement» (à proprement parler, ce n'est pas un frottement, mais plutôt un blocage). Je n'ai pas le problème de la porte qui frotte sur le bas de l'écran même positionné verticalement . L'encoche, j'avais indiqué sa présence, mais pour les cuvettes au bas des axes de guidage, effectivement ça récolte les miettes (il est rare que je fasse des impressions de 256 mm de haut donc ça ne devrait pas avoir d'incidence, à moins que le ménage n'ait pas été réalisé depuis un paquet de temps ). Pour la Qidi Box, je n'ai pas encore suffisamment de recul, ni pour en rire, ni pour en pleurer. La mienne fonctionne. Elle n'a qu'un «problème» : la LED de la seconde bobine ne s'allume jamais (ni blanche, ni rouge, rien), mais ça ne l'empêche pas de fonctionner.

Il y a un tutoriel, pas trop mal :

C'est tout le problème avec Armbian contrairement à Debian. Armbian est prévue pour des SBC. Vu la quantité de microprocesseurs différents, suivant la «qualité» des Device Tree proposés par les constructeurs, la méthode de construction de l'image système (particulièrement avec Buildroot), ça peut mener à des problèmes non souhaités. D'autant plus que ces images système ne sont pas toujours pleinement testées. Avec Debian, on peut effectuer une mise à jour vers une version supérieure (Bookworm => Trixie), pour Armbian, c'est très fortement déconseillé sauf à aimer vivre dangereusement . On croise les doigts, mais je pense que c'est bon désormais. Bons prints,

<Mode sarcasme> Pourtant, au moins une marque très connue affirme le contraire . M'aurait-on «enduit d'erreurs» ? </> Il y a également le Reprap firmware plutôt dédié aux adeptes des cartes Duet (mais pas que) qui possède sa propre interface Web (accès via un navigateur). Salut Jean-Claude, ça fait plaisir de relire ta prose. Klipper est toujours d'actualité comme firmware. Octoprint est plutôt en chute libre, mais reste utilisable avec Klipper moyennant l'ajout d'un greffon. Comme le dit @Savate, une majorité d'utilisateurs de Klipper préfère utiliser des interfaces Web, plus «modernes et réactives» comme Fluidd ou Mainsail pour lesquelles l'ajout de fonctionnalités est plus difficile. L'intérêt de Octoprint reste encore sa facilité de modifications ou d'ajout de fonctionnalités via l'installation de greffons (plugins).

J'utilise l'Ethernet sur ma Q2, comme sur la plupart de mes imprimantes équipées d'une prise RJ45. Au pire, mais ça demande un peu de démontage, cette antenne est montée sur la carte X-9-1 à l'aide d'une prise «pigtail» => on peut donc la remplacer .

Ce nom «max4» apparait plusieurs fois dans les fichiers (OS) de la Q2 . Avec un nom pareil, ça ne m'étonnerait pas… et l'œuf pourri ça ne sent vraiment pas bon (encore heureux que BBL ait ajouté un 2 entre le H et le S ).

En espérant que si c'est l'antenne Wifi, elle n'ait pas été détériorée (c'est fragile ces petites antennes) .

Quand j'avais ajouté le SFS2.0 de bigtreetech, j'avais ajouté une macro qui permet de continuer à imprimer une fois le détecteur de fin de filament déclenché :

Toutes les imprimantes que j'ai eu à tester ayant une fonction «IA» (détection de spaghetti) m'ont provoqué des faux-positifs, rarement de réelles détections. Désormais, je les désactive. Si j'ai besoin d'avoir de tels garde-fous, je préfère me reposer sur Obico, Octoeverywhere ou Simplyprint. Actuellement, les solutions propriétaires ressemblent plus à du «gadget» qu'autre chose. Même avec mes vieilles imprimantes (CR10, CR10V2, CR6-SE, CR30,…), j'ai rarement eu de plat de spaghetti à me mettre sous la dent…, c'est arrivé quelques fois, mais très peu souvent. Si la première couche est bonne, normalement l'impression va jusqu'au bout. La plupart du temps, quand j'avais eu des «fried nozzle» (terme utilisé par Qidi sur l'écran de la Q2 ), c'étaient généralement les supports qui en étaient la cause (solution: éviter au maximum l'utilisation de supports). La Q2 a 512 Mo de RAM, le processeur Rk3308B-S n'est pas un foudre de guerre. L'analyse des détections d'impression se fait localement sur la carte via le programme main. Tout est dans le dossier /usr/local/bin/algo_app : Ce programme est lancé comme un processus (daemon) : «main» est un binaire dont les symboles ont été retirés lors de la compilation. Peut-être qu'avec ghidra, il serait possible de le décompiler, mais je n'ai pas le temps de faire des essais. Ce qui est sûr, c'est que la désactivation via l'écran des fonctions d'IA et encore mieux, l'arrêt du daemon et sa désactivation, font chuter l'utilisation de la RAM et l'occupation du processeur (Fluidd, Système, Utilisation du système => graphiques Charge et mémoire système) .

Comme toi, j'avais depuis longtemps surélevé ma XM3 avec des pieds incorporant une balle de tennis pour avoir une meilleure ventilation. J'ai également ajouté sur chacune de ces alimentations un « atténuateur » de bruit (ça réduit marginalement le bruit ). Quand j'avais libéré ma XM3, j'avais utilisé la version de Redrathnure (Bookworm (24.2.0), noyau (6.6.17) current pas edge) de février 2024. Je ne l'ai pas upgradé depuis. Je n'ai pas souvenir d'avoir rencontré de MCU shutdown, time too close, mais ma XM3 n'est pas un outil de production tournant H24 7/7. Elle a bien moins d'heures d'utilisation que les tiennes (≃ 800 heures).

Comme tu n'indiques pas quel filament a été utilisé, le décollement de parties peut être dû à de nombreux facteurs (surface bien dégraissée, température du lit pas assez chaude, vitesse de première couche trop rapide, …). De plus, si les petites pièces ont une faible surface d'accroche sur le plateau, même un nivellement / tramming parfait ne changera pas grand-chose , une bordure pourrait plus aider. Mes dernières impressions avec des filaments un poil plus techniques (PETG-GF, PET-CF) ont tellement bien adhéré que j'en ai bien sué à les retirer (depuis j'ai ajouté un offset dans le paramétrage du filament avec le trancheur QidiStudio).

@Grayshif Bonjour, Est-ce que tu rencontres des problèmes d'adhérence ? Non => ne touche à rien, le maillage (bed mesh) sera utilisé pour compenser. Oui => suis la procédure indiquée dans la vidéo du Wiki de Qidi (imprime d'abord les pièces ). Tu peux aussi ajouter une section screws_tilt_adjust au fichier printer.cfg pour savoir quel coin ajuster : [screws_tilt_adjust] screw1:30,32 screw1_name: front left screw2: 240,32 screw2_name: front right screw3: 240,242 screw3_name: rear right screw4: 30,242 screw4_name: rear left horizontal_move_z: 10 speed: 50 screw_thread: CW-M4 Actuellement ton «range» de 0,52 est surtout dû au coin avant droit en (0,275).

Tu peux aussi remercier l'auteur du tutoriel .

Linux process (faute de frappe probablement). Cliquer sur la ligne «micro-controller architecture» pour accéder à la liste proposant entre autres «linux process». Même si ce n'est pas spécifique à ton microcontrôleur, tu peux t'aider des étapes (avec images) décrites ici (uniquement pour le MCU linux, les autres contrôleurs sont différents de ce que tu as sur ton imprimante).

Les deux (OpenNept4ne ou stock) doivent, d'après Coprint être possibles, le Github donne les fichiers de configuration : https://github.com/coprint/Printer-Config-Files/tree/main/Elegoo Le Chromapad permet effectivement si l'imprimante n'est pas Klipper d'ajouter le SBC, mais si l'imprimante est déjà sous Klipper, ça ressemble alors à un SonicPad, un SpeederPad, un BTTPad7, un RPi+écran 7",… J'avais testé le Chromascreen sur une BTTPad7, mais il fallait modifier de mémoire au moins un fichier car la résolution de l'écran d'une Pad7 est de 800x600, le chromascreen demande 1024x768 .

C'est une tablette utilisant Chromascreen (un Klipperscreen modifié ) et c'est prévu pour Klipper : la fiche produit .

Tu as le kit «complet» : 4 extrudeurs, tête, le module Klipper ? pas de chromapad ? Il me semble que tu avais «libéré» ta Netpune4 (full Klipper), donc l'installation ne devrait ne pas être trop problématique . J'ai un kit Coprint issu du Kickstarter, je n'avais eu à l'époque aucuns frais supplémentaires. Ça sera intéressant que l'acheteur nous tienne au courant.

Ton shimilimili koikesse serait-il capable de faire du multicouleur / filaments, genre un truc commençant par co et finissant par print ?

Je préfère la CN (connerie naturelle) , c'est plus efficace.

Mon seul conseil, actuellement, est de ne pas utiliser la détection IA (désactiver toutes les options via l'écran). Comme le processus d'analyse «en temps réel» est fait localement de manière logicielle, le processeur Rockchip RK3308B-S est saturé, la mémoire vive (512 Mo) est surchargée (il suffit de regarder dans Fluidd l'utilisation du système). Cela, avant que je désactive l'IA, m'a provoqué plusieurs échecs sur des impressions longues (PETG-GF, ABS) que je n'ai plus rencontré depuis cette modification. À voir, si ce n'était que chez moi, ou d'autres «vrais» testeurs auraient eu de semblables soucis ? Sinon, mon test est complété par un nouveau chapitre (matériels).

Un premier examen des matériels est en ligne : >>> ici <<<

Elles n'étaient pas recouvertes de graisse en sortie de carton ? Pour Shake and Tune, je n'ai eu aucun besoin de passer par une version modifiée pour la Plus4 (j'avais d'ailleurs décrit la procédure sur le Discord, mais visiblement, d'autres plus «savants» tiennent à utiliser le S&T modifié pour la +4. Why ? Ont-ils testé la procédure standard ? Croyances magiques ? Autre ? Je m'étonne d'ailleurs qu'ils aient réussi à faire une mise à jour (a minima nécessaire car git n'est pas installé d'origine sur l'OS de Qidi) sans réaliser de modifications dans les sources de dépôts Debian. Depuis la sortie de la version Trixie (v13), la Bullseye (v10) est passée en status «oldoldstable» et donc n'est plus atteignable autrement que par les archives Debian .