
V3DP
Membres-
Compteur de contenus
498 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par V3DP
-
Après mise à jour des versions de la machine en production, flashage des MCU (MCU principale à 500 000 bauds), retrait de FreeDi et installation de KlipperScreen + serveur VNC sur la machine en production hier après midi. Premier job de 2h sans problèmes (sur la base d'un job validé précédemment) Deuxième job de 8h40, le meme que le précédent mais plus de pièces, sans soucis non plus. Reste à voir dans la durée sur des jobs plus importants. Espérons que ça soit ça et que ce souci majeur soit derrière moi.
-
J'ai encore eu un shutdown cette nuit, après 3 heures d'impression. Donc j'ai retiré FreeDi (désactive ses services, l'entrée dans Moonraker.conf et débranché l'écran). L'installation de KlipperScreen a pris un peu de temps, j'avais oublié le fichier de configuration et de mettre le script de démarrage de KlipperScreen exécutable ... Maintenant ça marche avec un client VNC sur un viel iPad Air de 2013 (Remote Ripple qui tourne meme avec une version ancienne d'iOS). Je vais pouvoir m'attaquer à la machine qui est en production et qui a planté cette nuit après lui avoir fait toutes les mises à jour et flashage des MCU en dernière version de Klipper comme l'autre. A voir si ça règle le problème de shutdown.
-
Les sécheurs de Filaments
V3DP en réponse au topic de pjtlivjy dans Consommables (filaments, résines...)
Je viens de mettre en service mon nouveau sécheur. Bon c'est pas du Memmert, mais plus abordable pour un volume de 50l qui permet de loger 2 bobines de 2,3 kg. Il me manque encore le filtre d'échappement pour la pompe à vide car elle pollue un peu avec de la vapeur d'huile, mais c'est en commande. Il faut savoir que mes imprimantes sont toutes alimentées par des dry box (au travers de tubes PTFE), qui maintiennent le taux d'humidité durant l'impression grace à des gros sacs de silica gel. Je régénère régulièrement le silica gel. Je n'ai pas tout à fait la même problématique que la majorité des membres du forum (nombre d'imprimantes et production de séries), mais certains ont peut-être de l'expérience sur les étuves à vide pour sécher leurs filaments. Pour l'instant je fais un vide de l'ordre de 100 mbar dans la chambre chauffée à une température légèrement inférieure à la température de transition vitreuse.Par exemple 60°C pour du PETG. Je maintien le vide mais coupe la pompe. Et je divise le temps par deux par rapport à mon ancien four à chaleur tournante. Soit 3h pour du PETG. Est-ce la bonne approche ? Vos retours sont les bienvenus ! Merci d'avance -
Je n'utilise FreeDi que pour l'écran. L'OS est celui de Redrathnure, j'ai suivi ta documentation @fran6p. Les problèmes de shutdown étaient déjà existants avec FreeDi 1.42. FreeDi 2.0 a certainement introduit d'autres soucis comme la mauvaise synchronisation de l'écran si on est à 250 000 bauds au niveau de la MCU prinicpale. Le clonage de l'emmc a apporté semble t il un mieux mais à voir avec quelques impressions longues. Pour l'instant 6h30 sans problèmes alors qu'hier soir c'était 4h max pour le même job. Voire peut-être même par FreeDi 1.42. Pour l'instant je n'ai pas d'éléments pour le confirmer. Le doute vient du fait que lors d'un shutdown pour un MCU timer too close, les analyses Sineos ne mesurent que les communications entre les différentes MCU, pas l'écran. Et qu'il n'y a aucune anomalie sur les logs. De même, j'ai remarqué qu'éteindre puis redémarrer l'imprimante entre deux jobs diminuait fortement le risque de shutdown. Comme on reset tout ... D'un point de vue temporel, les problèmes ont commencé en fin Avril 2025, sachant que je suis passé directement de FreeDi 1.40 à 1.42 après le 8 Avril (release de la 1.42 le 11 mars). Si j'ai toujours mes soucis fin de semaine, je pense que je vais retirer les services FreeDi (Autoflasher.service et FreeDi.service) et déconnecter l'écran pour voir ce que ça donne avec juste Klipper 0.13 et son écosystème. Klipperscreen + client VNC sur un vieil iPad à priori.
-
Je ressort mon problème après une longue pause de l'activité pour cause de déménagement + congés. J'ai redémarré mes deux X Max 3 et après 24h de fonctionnement dans une salle à moins de 25°C, les shutdown ont recommencé. Galère totale pour la reprise. Comme les logs ne montrent pas de souci de communication, que les alimentations ne sont pas en cause (des 600 W neuves) et que toutes les versions sont à jour, les MCU reflashées à 500 000 bauds et FreeDi 2.0, je penche pour un souci de carte mémoire. Au passage l'écran flashé FreeDi 2.0 avec une vitesse de communication à 250000 bauds ne fonctionne pas bien du tout. Donc à ne pas faire. Je me suis lancé dans le remplacement des emmc et là galère pour les cloner avec mon Mac. La copie avec l'Utilitaire de Disque de macOS comme un CD / DVD Master (copie théoriquement bit à bit) ne se fait pas bien. Derrière Etcher copie bien, mais une mauvaise image. Bref la machine ne boote plus, même si l'écran démarre, mais ne se synchronise pas avec Klipper. J'ai mis une journée à comprendre le problème .... Clonage réussi avec ImageUSB sur une machine virtuelle Windows et c'est reparti avec une emmc 32Go. Impression en cours. A suivre.....
-
@vap38 Regarde chez Motedis , ils ont des prix intéressants
-
D'expérience, les calibrations de filaments sont à faire en fonction de la taille de buse. La température et le pressure advance sont légèrement différents. J'ai oublié mes cours de rhéologie depuis longtemps, mais l'écoulement de la matière est différent du fait de la section plus importante du passage de la buse.
-
La difficulté avec les imprimantes 3D, c'est que la plage d'utilisation "efficace" est assez réduite : en dessous d'une certaine température certains filaments deviennent difficile à dérouler (même si c'est mieux en 1,7 5 mm) et au dessus d'une certaine température, le refroidissement n'est plus assez efficace et cela peut conduire à des blocages de têtes d'impression (par exemple du PVA peut poser des problèmes vers 27-30°C de température ambiante sur certaines machines européennes (Ulimaker / BCN3D) L'autre sujet (et j'en sais quelque chose avec mes X Max 3) c'est que les alimentations sont sujettes à des phénomènes de perte de puissance (significatives) lorsque la température interne de celle ci augmente au delà de 50°C et coupent à 70°C. Quand l'ambiante augmente, la température interne de l'alimentation augmente et on rentre dans une spirale infernale où plus elle chauffe et moins elle délivre de puissance (et plus elle chauffe). Enfin pour certaines matières comme le PLA/TPU, plus l'ambiante est chaude, moins le refroidissement de la pièce est efficace et plus on a de soucis sur les zones critiques. Je ne parle pas du sujet de l'humidité de l'air, @pjtlivjy l'a bien exposé. Donc il faut réguler à minima la température du local d'impression pour avoir un fonctionnement correct de l'imprimante, de 18-19°C à 25-26°C. Et vu le prix de vente des Qidi, elles ont forcément été calculées au plus juste....
-
@fran6p Sur la vidéo d'installation, on voit qu'ils changent l'extrudeur qui comprend le coupe filament et le détecteur de filament. Donc ça ne serait pas trop compliqué pour ces éléments. Le point compliqué c'est que la hotend n'est pas sur l'extrudeur comme sur les séries 3 mais sur la tête en elle même. Ca fait un bon projet pour quelqu'un de motivé. Q2 ça doit être une abréviation déposée par Audi ... comme tous les Qx... Mais bonne nouvelle si ils ont bien une machine taille X Max 3 / K2 avec la Qidibox dans les sorties à venir.
-
Ben oui, si ils ont une Max 4 dans les cartons, le retrofit de la Qidi Box sur les X Max 3 casserait une partie du marché. Et pour la X Plus 3, il y a déjà la Plus 4 qui est la remplaçante. Cela dit, le système de purge et de nettoyage de la buse serait difficile à caser dans les Plus / Max 3, même si le remplacement de l'extrudeur, le hub usb et le hub de la box ne devraient pas poser de problèmes à intégrer. La question du Firmware de l'écran se poserait à nouveau. La partie Klipper sur une machine libérée ne devrait pas être trop complexe. Et le slicer est déjà prévu pour, il suffirait de le paramétrer.
-
@fran6p Oui elle est allée jusqu'au bout, soit 4h45. Avec une température extérieure de 25°C, la chambre à 55°C, le plateau à 80°C et la buse à 260°C. Je tourne avec 32 micro steps, interpolés. C'était déjà comme ça avant les problèmes. J'avais essayé à 16 micros steps lors des problèmes mais cela n'avait pas modifié le comportement. Vu les derniers shutdown qui ont eu lieu alors que la machine était idle mais juste la chauffe, je ne pense pas que le souci soit une bande passante ou une charge trop élevée. La piste d'un problème de stabilité de la tension me semble la plus probable. Mais normalement avec 600 W, même avec le derating il reste 480 W de dispo, soit bien assez pour les cartes, le plateau chauffant, la hotend, les LED et les ventilateurs du filtre à charbon. Mais j'ai un doute sur la machine qui a fait les derniers shutdown car la mise en chauffe de la chambre a déclenché la ventilation de l'alimentation de 600 W. Comme elle avait déjà le ventilateur d'origine du filtre à charbon monté à l'envers ..... en sortie d'usine....
-
Oups de 250 000 bauds (standard Klipper et Qidi). Je viens de reflasher la carte mère et c'est reparti pour un tour avec le même job.
-
Quelques progrès dans ce problème qui devient pénalisant avec mes X Max 3. Donc hier matin désactivation du MCU Host Linux qui n'est pas dans la configuration d'origine Qidi (ni dans FreeDi). Pas de pertes de paramètres ou de fonctionnalités. Remplacement de l'alimentation principale de ma deuxième X Max 3 par une de 600 W, comme pour la première X Max 3. Pour le reste les MCU sont flashées de manière normale avec l'écran FreeDi 1.42, le ventilateur de refroidissement de la carte est d'origine tout comme le cable USB C. Et c'est parti pour des jobs de production sur les deux machines, mais cette fois ci sans la clim -> 25°C dans la salle d'impression. La deuxième X Max 3 a tourné 24h au total sans problèmes de shutdown (MCU Timer Too Close) dont 19h d'impression et une pause car le capteur de filament avait détecté un problème de débit. Dans tous les cas, c'est bien mieux que quelques jours auparavant où le même job plantait vers 9h d'impression. La première X Max 3 a imprimé 4h45 avant un shutdown (MCU Timer Too Close) au bout de 6h alors qu'elle était en pause pour un problème de débit de filament. Même scénario que la veille. Sur les logs, rien d'anormal à nouveau. Sur celle ci le MCU est flashé avec une vitesse de communication série à 500 000 bauds et l'écran flashé avec FreeDi 2.0, ventilateur de 80 mm pour refroidir la carte mère, cable USB -C changé. En rentrant de weekend, je vais reflasher la première avec une vitesse de communication de 115 000 bauds (standard Qidi) et relancer le même job.
-
Toutes mes machines sont sur onduleur inline interactive. Donc stabilité de la tension et de la fréquence. (c'est mon boulot et des jobs de 5 jours ca arrive...). Celui sur lequel sont mes deux X Max est un Riello 3000 VA. C'est une option valide, j'ai une carte en stock. J'ai changé les alimentations principales sur mes deux machines et je vais couper la clim pour voir si cela se produit toujours avec un job un peu long. Pour autant, c'est mes 2 X Max 3 qui ont le problème, alors qu'elles n'ont pas le même age ni le même kilométrage. Un problème de carte sur les deux, c'est un peu bizarre. Dans ce cas, les valeurs de srtt, rttvar et rto montreraient des anomalies. Tout comme les ready bytes et upcoming bytes. (analyses de Sineos des logs klippy) Cela dit, les cpus n'étant pas des foudres de guerre, la piste du MCU linux qui a été ajouté n'est pas négligeable. D'autant qu'il n'apporte rien dans le cas de ma configuration actuelle. Je l'ai retiré des deux machines, on verra si le job de test va jusqu'au bout et ce que disent les logs.
-
Résultat des courses après un premier job d'essai : Encore un shutdown : MCU shutdown : Timer too close. Bref comme les autres fois. Ou presque, car le shutdown a eu lieu alors que la machine était en pause pour un problème de filament ...donc sans activité. Et l'analyse de la log klippy ne donne toujours rien d'anormal. Donc sur cette machine où le cable usb c a été changé, où la fréquence de communication série a été montée à 500 000 bauds, où un radiateur a été monté sur le Rockchip, où un ventilateur de 80 mm refroidit à 40°C la carte mère et où l'alimentation a été changée pour une 600 W, le souci est toujours là. Les versions sont toutes à jour sur cette machine et toutes les macros inutiles ont été retirées ainsi que timelapse. Après réflexion, je viens de retirer le MCU linux (mcu-host) qui n'est pas présent ni dans la configuration de Qidi, ni dans celle de FreeDi. Je relance le job de cette nuit pour voir.
-
@fran6p Je pense avoir trouvé le problème du démarrage de FreeDi. En fait on démarre le service klipper-mcu avant klipper sur une machine libérée avec ton tutoriel. Et c'est cet enchainement qui prend du temps.
-
Ca y est ! Alimentations reçues de chez Mouser ! Elles sont parties lundi après midi de Memphis Tennessee .... arrivées ce matin. Montage assez rapide, à part la hauteur de l'alimentation, c'est exactement les mêmes emplacements de vis et de borniers. La seule différence c'est que ce dernier n'est pas protégé. Mais bon, comme c'est sous la machine, pas de soucis. L'alimentation ne dépasse pas du caisson, ce qui est un très bon point. J'ai remis le ventilateur de 80 mm pour améliorer le refroidissement. Je viens de lancer un job de 5h en ABS, on va voir ce que ça donne. Pour l'instant, j'ai gardé la clim à 19°C car j'ai l'autre X Max qui doit produire avec l'alimentation d'origine. Si tout va bien, je la change demain.
-
@fran6p J'ai essayé en mettant une condition Start= dans le service de FreeDi, mais il doit y avoir d'autres paramètres qui rentrent en ligne de compte car ca ne marche pas bien. Ou alors un service dépendant de klipper ou Moonraker qui est lancé en parallèle, mais sans conditions..... Le mieux que j'ai trouvé pour l'instant, c'est augmenter la pause avant le démarrage du service à 15 secondes (au lieu de 5). Ce qui fait que le service FreeDi démarre plus tard ou redémarre plus tard si il s'était lancé trop tot. Bref ça ne reste plus planté avec un écran demandant le restart de klipper ou du firmware, mais vient bien sur l'UI attendue dans tous les cas.
-
@pommeverte Mea culpa. Je ne l'avais pas vu lorsque j'ai testé Qidi Studio en début d'année. Donc c'est une bonne nouvelle si ils ont gardé les fonctionnalités d'Orca. Je vais quand même rester sur Orca.
-
Je parlais du paramètre qui augmente la surface du support par rapport à la partie à supporter, pas celui qui crée un brim pour les supports sur la première couche. Dans Cura ça s'appelle Support Horizontal expansion.. Il y a quelques mois cette option n'existait pas dans Qidi Studio, raison pour laquelle j'utilise Orca qui avait ce paramètre. C'est pour cela que je disais qu'il fallait vérifier.
-
Pas sur. Il y a de légères simplifications dans Qidi Studio par rapport à Orca au niveau des supports. Par exemple l'expansion des supports n'est pas dans Qidi Studio. A vérifier donc
-
En fait, il ne faut plus considérer la vitesse d'impression comme paramètre pour la détermination de la température mais le MVS. A MVS équivalent, la température est légèrement inférieure avec une buse de 0.6 vs 0.4 mm (et encore inférieure avec une buse de 0.8 mm) J'ai gardé les largeurs de Qidi, qui sont conservatrices sur mes X Max. Par contre sur toutes mes autres machines je pousse régulièrement la largeur pour les couches sup et inf (sauf la dernière supérieure qui reste à 0,6) à 0,7 et le remplissage à 0,7. Règle empirique, on peut sans problèmes tenir une largeur de trait de 1,2 * diamètre de la buse tant qu'on ne dépasse pas une hauteur de couche de 50% du diamètre de la buse. Après il faut tester car ça dépends de plein de paramètres. La pratique fait qu'on gagne de l'ordre de 30% si on imprime le remplissage à chaque couche avec les mêmes vitesses sans limitation du MVS. Avec les machines qui limitent au MVS comme les Qidi, le gain est moindre, mais pas négligeable. D'autant que le remplissage peut être imprimé moins souvent (0,4 mm de hauteur de couche n'est pas un souci pour le remplissage)
-
@pjtlivjy En fait, on baisse légèrement les températures avec une buse de 0.6 mm, donc matière plus visqueuse. Sur les machines avec une pressure advance, c'est cette calibration qui règle le stringing. Sur les machines anciennes, la rétraction n'est pas modifiée par rapport à une buse de 0,4 mm. Pour du TPU, quelque soit la taille de buse, le souci du stringing vient souvent du Z Hop, donc pas de Z Hop et une rétraction durant le wipe d'au moins 50% Voici une pièce qui remplit le volume de ma X Max 3. PLA 300 microns, buse de 0.6 mm. Quelques défauts de surface car il fallait aller vite. MVS de 30 mm"/s. Infill 20%. PLA recyclé de FormFutura.
-
J'utilise principalement des buses de 0.6 sur toutes mes machines. Effectivement ça permet de travailler avec des couches de 300 microns sans soucis, ainsi que des filaments chargés. Pour le remplissage, on augmente la largeur de ligne, donc l'espacement du motif augmente pour un même taux de remplissage. Pour la résistance mécanique, pas de gain notable. La perte de définition par rapport à une buse de 0,4 mm n'est pas significative sur des pièces techniques. Un point intéressant est que la buse étant plus grosse, la MVS augmente pour une même température. Personnellement j'utilise des buses Bondtech CHT (avec 3 petits canaux) ce qui permet d'avoir des MVS de l'ordre de 20 - 25 mm3/s avec du PETG et plus pour du PLA / ABS. Il faut un adaptateur sur les X Max 3. Mais pour les Plus 4 je ne crois pas qu'il y ait des buses CHT.
-
Malheureusement non, j'ai suivi la procédure d'upgrade de son GitHub, en executant le script start.py qui est dans FreeDiLCD. Sur la V1.42 l'upgrade de l'écran seul se passait bien ... Le Wizard se déclenche en fonction d'une variable qui a été définie dans le fichier freedi.cfg, mais par défaut il est à True. Le plus casse pieds actuellement c'est le fait que le service FreeDi ne se lance pas toujours bien (pas toujours après Moonraker) et l'écran reste en attente d'un restart pour se connecter.... Je pense que le service est mal réécrit.