V3DP
-
Compteur de contenus
462 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par V3DP
-
@souriceaux C'est super gentil. Comme dit par @fran6p ce n'est pas la même découpe sur la X Max 3 Pas de soucis, je l'imprime actuellement en PETG en une seule pièce sur une de mes autres imprimantes qui a un grand plateau (BCN3D W50). J'ai repris le modèle de printables.com et l'ai un peu adapté pour passer les fils de mon filtre Alveo3D et garder les vis d'origine. J'attends des ventilateurs Sunon 80 * 80 * 15 24 VDC (MF80152V3-F99) pour mettre à l'intérieur du caisson avec les cartes. Ils ne consomment que 0,4 A, donc peuvent être branchés directement sur la carte mère et ne font que 26,5 dBA pour un débit déjà sympathique. Le tout monté sur plots caoutchouc pour diminuer les vibrations. Bonne nouvelle. De mon coté, j'ai vu sur le GitHub la procédure pour ne flasher que l'écran. Je préfère garder la main sur Klipper et comme maintenant tout est au même niveau que la version de FreeDi... J'essayerai de flasher l'écran quand j'aurai stabilisé mes soucis de shutdown. Et bonne nouvelle, mon job de 5h30 a fini sans soucis en ayant utilisé le moteur de slicing classique.
-
@souriceaux Merci. J'ai lancé l'impression d'un nouveau capot arrière qui accueille un ventilateur axial de 80 mm. Ca sera plus silencieux. En fait, c'est plutôt par prudence / dépit que je modifie le refroidissement, car rien n'indique dans les logs que la température est trop élevée pour la carte. Si ca n'est toujours pas ça, je regarderai coté alimentations. Pour l'instant, le même job que ce matin, mais avec le moteur de slicing "classic" est allé plus loin, mais n'est pas encore terminé.
-
Moi non plus. Je viens de nettoyer tous les radiateurs de la carte mère + le RK3328 au KF Contact pour voir si le souci n'est pas un problème de refroidissement. Je vais regarder pour mettre un ventilateur 80 mm en refroidissement de la carte mère et un radiateur sur le RK3328. Même si les températures sont correctes, il peut y avoir un point chaud. En attendant, je vais modifier le moteur de slicing pour voir si c'est ça qui a le plus d'impact.
-
J'ai essayé un job de 5h avec de multiples pièces identiques (des petites tortues pour mettre les marqueurs de mon scan). A nouveau erreur de "timer too close" sur le MCU. La log Klippy ne donne pas beaucoup d'indications, sauf que les temps de transit des paquets ont bien diminué. Pour autant le STM32 est dépassé. klippy.log.zip Je vais relancer en ayant désactivé le moteur Arachnee.
-
Mon petit job d'une heure s'est bien terminé. Je verrais demain en détail l'aspect des pièces. L'analyse de la log Klippy ne donne pas beaucoup d'informations car le même job n'a pas été fait juste avant de changer la configuration. J'avais remis les micro pas à 32 en X, Y et Z, le courant de l'extrudeur à 0.72, le moteur de slicing Arachnee, les variations de vitesse de ventilateur et la résolution à 0.012. Et c'était un job avec le plateau à 80°C et la chambre à 55°C. Je vais essayer de repasser un gros job qui plantait dans les prochains jours pour voir.
-
Je viens de re-flasher toutes les MCU en version 0.13.154 avec le baud rate à 500000. Tout redémarre correctement avec la modification du printer.cfg pour indiquer la vitesse de communication. (Au passage j'ai essayé de réimplémenter Katapult, mais c'est la Katastrophe. Impossible à flasher Kata..... donc retour à la méthode directe). Je vais préparer un petit job pour voir ce que ça donne.
-
En l'occurence ce qui est modifié, c'est la vitesse de l'interface série UART entre le STM32 et le RK3328. Normalement ca ne devrait pas changer la vitesse de l'USB vers la carte MKS_THR.
-
Oui, c'est bien là le souci. C'est pour cela que je suis prudent. Bon flasher dans un sens puis dans l'autre la carte mère c'est simple et rapide une fois qu'on a retiré le capot. Par contre voir les effets indésirables, c'est plus compliqué. Et pour l'instant personne n'a dit que cette manip était "Sure et efficace". Je vais essayer sur une machine cet après midi. Par contre, pour avoir des résultats, ça risque d'être plus long.
-
Je viens de regarder les spécifications du STM32F401 (le STM32F402 étant la version chinoise) la communication série en USART1 (ce qui est le cas de nos Qidi) est données jusqu'à 10,5 Mbit/s suivant le mode. Donc le passage à 500000 bit/s de la vitesse de l'interface série de communication avec le Rockship ne devrait pas poser de problèmes. De son coté le Rockchip 3328 a un contrôleur UART qui supporte jusqu'à 8bit en transmission avec un débit de 1500000 bit/s Reste à voir si ça fonctionne en reflashant le mcu après avoir compilé avec un débit pour le port série à 500000.
-
Merci, mais j'ai reçu deux cables USB C de remplacement en fin de semaine dernière de Qidi EU.
-
Je viens de voir dans le GitHub de Phil1988 sur les changements de FreeDi 2.0 la chose suivante In FreeDi v2.00 the mainbaord MCU baudrate changed from 250000 to 500000 to prevent "timer to close" errors. This is a rare problem, but users of beacon/carto might need it. Comme il est basé sur Armbian 25 et Klipper 0.13 comme mes X Max 3 Libérées, il y a peut-être une piste à creuser. A priori la compilation du firmware du MCU a été faite avec une communication de 500000 bauds et le printer.cfg est modifié en conséquence For X3 series users (X-Smart3, X-Plus3, X-Max3) I recommend using the provided X_4.bin from ~/FreeDi/mainboard_and_toolhead_firmwares/v0.13.0-154/. Its a compiled klipper version for the mainboard MCU with 500000 baud rate instread 250000. This speeds up the communication and can help "timer too close" errors especially for some beacon/carto users. You then have to change the printer.cfg section accordingly to: [mcu] serial: /dev/ttyS0 restart_method: command baud: 500000
-
Et pas de nouveau modèle en vue ?
-
Je parlais des projets au format .3mf. Il y a toutes les infos. Mais comme tu as répondu à ma question, à savoir que tu utilises les paramètres par défaut de Qidi Studio (et j'imagine de Qidi Slicer avant), pas de soucis. Mon raisonnement actuel, vu les 2 machines, quelque soit leur age / utilisation me font le problème de shutdown pour une erreur "Timer too close" soit sur la tête, soit sur la MCU de la carte, que remplacer / nettoyer la connectique ne change rient, c'est que c'est lié aux paramétrages utilisés dans le slicer. Et que j'utilise Orca, avec majoritairement le moteur Arachnee, une résolution d'impression de 0.012 sur des pièces pleines de congés et relativement volumineuses / longues à imprimer quand ça plante. Je vais continuer à tourner avec les paramètres "standard" mais une résolution plutôt de 0.05 sur les grosses pièces pour voir si ça se confirme que c'est ça. Et si c'est bon, je reviendrais à 32 micro pas interpolés pour diminuer le bruit et augmenter un peu la précision.
-
@pjtlivjy Merci du retour. J'ai eu le souci aussi avec des pièces bien plus petites, en 100 microns de hauteur de couche, mais avec des arrondis de partout. Est-ce que tu utilisais Qidi Slicer ou Qidi Studio avec les paramètres par défaut pour la résolution (celui que j'ai mis à 0,05 au lieu de 0,012) et le moteur de slicing classic ? Ca m'intéresse si tu as la possibilité de retrouver tes fichiers d'impression.
-
Bonne nouvelle ! Mon job s'est terminée après 17h d'impression. Bon il y a eu une heure de pause pour une fausse alerte du capteur de filament, mais je ne pense pas que ça ait eu un impact. L'analyse des logs d'hier soir et d'aujourd'hui montre que jusqu'à 30% de la bande passante du MCU est utilisée en début de job (grosse pièce de 370 * 270 * 75) et qu'en fin de job ça diminue du fait qu'il ne reste que 2 ilots à chaque bout. Ce qui est intéressant, c'est que la charge du MCU est plus importante en idle que lors de l'impression. Tout porte à croire que le souci est directement lié aux paramtétrages du slicer qui saturent les MCU : moteur d'extrusion Arachnee, résolution du slicing principalement. Je vais faire attention sur les prochaines grosses pièces aux paramétrages, car je n'ai pas constaté le problème sur les petites pièces. Je m'interroge sur le paramètre résolution mis par Qidi à 0,0125 pour des impression de grande taille ou de hauteur de couche importante.
-
J'ai eu le souci lors d'une corruption de fichiers de Klipper. L'écran démarre mais n'a aucune communication avec Klipper, car celui ci n'est pas complètement démarré. Le fait d'avoir la carte de la tête de débranché ne permet pas de démarrer Klipper, car il manque le retour du thermocouple. @souriceaux il faudrait que tu te connectes via Fluidd et que tu regardes ce que tu as dans le bandeau en haut de la page d'accueil.
-
@fran6p C'est vrai que ses graphiques sont très instructifs, mais difficiles à lire. Les axes et les échelles sont trop fins. Je viens de relancer la machine avec le job client de 17h, mais en ayant joué sur le paramètre résolution d'Orca Pour une impression en 300 microns, ca devrait passer. Ce qui a réduit mon fichier de 3 Mo, mais surtout le nombre d'instructions pour les périmètres est passé pour la première couche de 80 à 49. Donc moins de segments dans les arrondis. J'ai gardé le service MCU Host démarré. On va voir si ça marche. Dans Qidi Slicer et Qidi Studio, le paramètre est à 0.012 mm. Perso je préfère la méthode de Cura avec la longueur max d'un segment et la déviation.
-
Oui, surtout que si tu utilises Sineos sur la log que j'avais uploadée, tu vois bien le shutdown en question
-
Le shutdown était entre 0h et 1h du matin. Ce que tu vois à 9h45, c'est plutôt les manipulations opérateurs (chargement / déchargement filament, nettoyage de buse) En fait, c'est plutôt une erreur d'analyse de Klippylyser qui regarde juste les variations sans avoir la cause. Si c'est un problème de Thermocouple, tu as une erreur spécifique dans Klipper qui est explicite, mais pas un "timer too close". Pour avoir essayé en débranchant volontairement le thermocouple.
-
QIDI filtre charbon la durée de vie ?
V3DP en réponse au topic de vap38 dans Consommables (filaments, résines...)
Oui j'ai fait un post sur le sujet il y a presque un an. Ca marche très bien; Personnellement je m'en sers plus pour faire une dépression dans la chambre avec les matières "toxiques", ce qui fait qu'ils tiennent assez longtemps. Au maximum les ventilateurs tournent à 50% quand il faut refroidir l'intérieur de la chambre (PLA. PETG, TPU) sinon c'est 25%. Et O odeur dans ma salle d'impression avec les matières type ABS, ASA, PC, ..... -
La sonde de température étant dans la puce, il y aurait des montées en température de visibles sur la log. Or c'est bien régulé à 45 °C. J'ai pensé aussi aux ventilateurs, mais j'aurais des traces sur les logs. Cest une piste que je vais regarder en dernier recours. J'avais pensé aussi à mon onduleur qui alimente les 2 machines, mais comme le problème n'arrive pas en même temps alors qu'elles tournent toutes les deux sur le même job, j'ai laissé tombé cette piste là. Par contre 2 alimentations qui posent problème avec un temps de fonctionnement différent (la deuxième est arrivée en production 5 mois après). Pour ce qui est du MCU host, merci pour les infos. Je me demande si le problème ne vient pas d'une montée de version de Klipper avec un service qui n'est plus à jour. Je vais regarder les versions entre les deux directories. Au besoin je vais refaire l'opération de flashage de cette MCU complètement. J'ai vérifié les versions du service mcu-host, pas de soucis. J'ai reflashé ce mcu par acquis de consience. @fran6pUne question bête, si la fréquence d'horloge utilisée pour flasher le STM32 n'est pas la bonne, ça ne va pas créer des problèmes de timing donc de communication ?
-
A nouveau shutdown cette nuit, même en ayant modifié le moteur de slicing et ajusté toutes les valeurs qui pourraient augmenter la charge CPU aux valeurs de Qidi Studio C'est à nouveau le MCU (STM32) et non pas la tête. Il semble bien refroidi d'après les logs. C'est maintenant devenu très galère car les commandes clients ne sortent pas. @fran6pJe me posais une question liée à la libération de la Qidi : sous la version officielle Qidi, il n'y a pas de MCU Host, on l'a crée avec la procédure de libération. Ca ne pourrait pas surcharger le STM32 ? Est-ce que ce MCU Host est bien nécessaire ? Ou plutôt il sert à quoi dans la configuration ?
-
Tu as le firmware original de l'écran ?
-
BAD NEWS..... J'ai encore eu un shutdown du MCU, plus de la tête. C'est sur la machine qui a un cable usb c neuf, la carte fille nettoyée et le printer.cfg de remis aux valeurs Qidi pour les moteurs. Elle avait bien tourné juste avant pour 21h d'impression. La seule chose qui a changé c'est le fichier à imprimer. Voici la log Klippy, mais je n'ai rien trouvé dans l'analyseur de Sineos. Peut-être que quelqu'un plus calé que moi aura des idées. Le shutdown est peu après 0h klippy.log.zip Je vais regarder la piste du fichier d'impression généré par Orca slicer 2.3. J'ai comparé les paramètres de Qidi Studio avec ceux que j'ai mis dans Orca. Des différences sur les paramètres liés au filament et aux vitesses, mais surtout une grosse différence : Qidi Studio utilise le moteur classique pour les périmètres alors que j'utilise le moteur Arachnee. Arachnee introduit des variations de débit fréquentes pour adapter la largeur de trait, donc potentiellement charge sur les MCU. J'ai aussi, vu que le ventilateur de pièce est à 100%, supprimé le forçage pour les overhangs et bridges. Je vais relancer le job de cette nuit....
-
@vap38 Oui comme pour de nombreuses machines, c'est le cable qui encaisse la flexion. Dans le cas des Qidi séries 3, la prise USB est pluggée sur la carte fille qui est dans la tête d'impression et tous les périphériques de la tête sont connectés sur cette carte avec des connecteurs XH sauf le thermistor qui a une connectique différente mais c'est un standard. Toutefois la prise usb c coudée coté tête est maintenue par une patte de fixation vissée dans la tête et si on met un petit bout de caoutchouc il n'y a aucun jeu. Donc les contacts sont plutôt bons, hormis si il y a des graisses qui pénètrent. Dans mon cas et sur les 2 machines, le souci était dans un des connecteurs XH. Je pense celui de l'extrudeur car les ventilateurs n'ont pas de retour, ni la cartouche chauffante. Et un faux contact sur le thermistor te fait une belle erreur qui est bien distincte avec un shutdown pour des raisons de sécurité.
