V3DP
-
Compteur de contenus
466 -
Inscrit(e) le
-
Dernière visite
1 abonné
Visiteurs récents du profil
608 visualisations du profil
Récompenses de V3DP
-
Mean Well LRS 600 N2 24V en commande chez Mouser. C'est le seul distributeur avec un délai rapide.
-
@fran6p Tu avais avancé la piste il y a un petit bout de temps, après avoir tout exploré je pense que c'est certainement la source des problèmes. J'ai démonté l'alimentation et nettoyé le ventilateur, mais c'était plutôt très propre après 1 an de travail. J'ai essayé de mettre une alimentation TDK Lambda de 500 W en 24V que j'avais en stock, mais elle a un souci car elle ne délivre plus que 0.4V........ Sur l'alim de la CM, j'ai en plus : un ventilateur pour mon filtre Alvéo3D, 4 * plus de LED qu'à l'origine et maintenant le ventilateur de 80 mm, un moteur LDO un poil plus puissant que l'origine sur l'extrudeur. Tout ça, ca commence certainement à faire beaucoup. D'autant que la marge au départ ne devait pas être bien grande par rapport à la capacité théorique (à moins de 50°C en température interne de l'alim) de 450 W. Je pense plutôt remplacer l'alim d'origine de la CM par une Mean Well LRS 600N2 24, qui fait 600 W. Je dois encore vérifier le facteur de forme pour être sur que ça rentre. Ca donnerait une marge si la température de l'alimentation monte.
-
A nouveau sur la même machine, un shutdown pour un MCU Timer too close..... Ce qui est intéressant c'est que la log Klippy montre que la machine a d'abord eu un arrêt de la chauffe de la hotend bien avant le shutdown. klippy.log.2025-07-03.zip Les shutdown sur cette machine avec le ventilateur de 80 mm sont plus fréquents maintenant. Je pense que le souci vient de la charge / température de l'alimentation 24V (car la charge décroit à compter de 50°C). Ca expliquerait aussi que les soucis sont plus fréquents alors que la température de ma salle d'impression a augmenté depuis cet hiver. Peut-être des ventilos encrassés. Ou alors une charge de l'alimentation trop proche de la charge maxi.
-
J'ai monté le ventilateur de 80 mm pour refroidir la carte mère ainsi qu'un radiateur cuivre sur le Rockchip sur la X Max qui a un cable usb c tout neuf, la vitesse de communication à 500 000 bauds.... J'ai réglé la température de la carte mère à 40°C (j'utilisais déjà un temperature_fan pour piloter le ventilateur avec un PID, mais à 45°C). Le STM32 est maintenant dans les 25°C. Malgré ces dernières modifications, j'ai eu deux shutdown pour un Timer too close sur le MCU. Pourtant le job était tout petit avec 1 h d'impression et 5 pièces identiques sur le plateau. Dès que je peux, je regarde l'alimentation de la carte mère.
-
@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
