Problème d'impression bizarre

[Eclipse]

Bonjour à tous,

Je rencontre un problème d'impression que je n'arrive pas à identifier.

Les photos parlent d'elles même, quelques infos supplémentaires:

Cela arrive progressivement à partir d'une hauteur de 10cm, la pièce en fait 20 de haut

Uniquement sur la partie extérieur gauche, intérieur droit, par rapport a l'orientation de la pièce sur le plateau

Comme on le vois sur la 1ere photo, les autre éléments internes sont parfaits. Ce qui selon moi exclu un problème de vibration, voir mécanique.

La pièce est imprimé en pla à 100mm/s pour quasi tout, il n y a que le remplissage et les support a 80mm/s. Les parois sont à 3 couches (1.2mm), remplissage 15%

J'ai inspecté le tranchage et rien d'anormal, il y a eu de plus grosses pièces imprimées sans problème précedemment mais avant celle ci le firmware tft et octoprint ont été mis à jour, ça ne peux pas venir de la qd mm?

Et d'autres bricoles modifiés aussi comme le motif de remplissage et la hauteur de couche 

Merci de votre aide et bon dimanche 

[Motard Geek]

Je sais que la pièce est grosse mais peut-être la découper pour essayer la partie en question avec différents slicers pour voir ?

[PPAC]

Salutation !

Et il n'y a riens de spécial dans la prévisualisation / aperçu après découpage dans cette zone ? (les jointures en Z par exemple ? )

Je me dit que cela pourrais (mais pas convaincue) venir

• d'une histoire de linear advance mal ajusté
• ou d'une notion de remplissage des petits trous ("Filtrer les très petits trous" a activer ?)qui pousse la coque
• ou encore d'une valeur de "débit minimal de la parois" dans le cas d'"imprimer parois fines" ...

Mais le plus probable c'est la position de la jointure en Z ...

Modifié (le) Aout 24, 2021 par PPAC

[Eclipse]

Bonjour à tous,

Merci pour les réponses. Un soucis sur ma X1 m'a retarder dans la recherche d'une solution.

Le problème a été trouvé: cela viens du gcode généré par ideamker. Sur les grands prints, à partir de 15cm de haut, d'un coup, plus on s'approches des limites en X et Y, plus l'extrusion s'accellere ou se réduit alternativement juste avant d'arriver autour des angles de la pièce. Je l'ai constater visuellement avec la roue de l'extrudeur qui s'accélère ou se ralenti brièvement. Autre soucis, les parties arrondies ne sont pas belles, arrivé à 25cm de hauteur les couches ne semblent pas bien alignées, et la buse semble frotter sur les couches précédentes, alors que c'est ok sur les lignes. J'ai testé les réglages dans tous les sens, sans succès. En revanche les pièces moyennes n'ont aucun problème.

J'ai donc testé avec cura, mais il y a un autre problème sur les partie arrondies de la pièce: le mouvement devient saccadé et cela créer des artefacts bien visibles. Testé avec plusieurs profile dont celui fourni par cura pour la X1, a vitesse lente ou rapide, ou en diminuant l'accélération

J'ai enfin testé avec prusaslicer, avec exactement les même réglages qu'ideamaker. Non seulement le problème a disparue complètement, mais overall la qualité d'impression est au dessus. Les fichiers gcode sont bien moins volumineux: 70Mo, contre 170 pour cura et ideamaker, et le tranchage est logiquement plus rapide (plusieurs minute pour ideamaker vs 30s pour prusa)

Les 3 logiciels sont pourtant bien à jour, et c'est vraiment étonnant que les résultats se dégradent pour cura et ideamaker lorsque la pièce se rapproche des limites de la taille d'impression.

Me reste plus qu'a me familiariser avec prusaslicer 

 

La piece fait 35cm de haut. Prusaslicer (en cours)

Cura:

Ideamaker:

[MrMagounet]

Juste pour info j'utilise Cura et Prusa, avec mon profil je n'ai aucun soucis avec Cura sur ma Genius. J'arrive a d'aussi bon résultat sous cura que sous Prusa surtout depuis l'arrive de mode monotonique sur Cura 4.11

[Eclipse]

C'est ce que je trouve bizarre, un tel problème ne passerai pas inaperçu. J'ai même essayé de réinstaller les 2 softs.

Est ce que cela viendrais d'une incompatibilité avec le firmware de la X1 ?

je comprends pas non plus la grosse différence de taille entre les gcodes comparé a prusaslicer 

Un exemple de stl: https://drive.google.com/file/d/1-LeF9xN2Ye29drYpK63L2Sgfbw9t14nC/view?usp=sharing

[PPAC]

Il y a 4 heures, Eclipse a dit :

je comprends pas non plus la grosse différence de taille entre les gcodes comparé a prusaslicer

Peut être une histoire de taille de segment / "Résolution maximum" sous Ultimaker Cura.

Sinon tu imprime depuis OctoPrint sur un RPi via USB ou depuis la carte SD de la machine ? (si carte SD d'origine la changer par une de qualité de maximum 32GB a formater en FAT32, car souvent celles fournis sont de mauvaise qualités. Voir simplement formaté la carte SD car de temps en temps elles "sature")

Edit : Aussi peut être tester ArcWelder 

Citation

 

Modifié (le) Octobre 7, 2021 par PPAC

[MrMagounet]

Le Slice ne ce fait absolument pas de la même façon, et j'ai jamais fait attention donc difficile de donner un avis sur le soucis de taille.

Après sur ta X1 tu utilise quels Firmware, si c'est celui d'origine il s'agit du même firmware que la Genius seule les PID et taille de bed diffère.

Si c'est un autre firmware faudrait savoir lequel et ce qui a été configuré, sur un MKS GenL 8bits d'origine des fonctions comme le Junction Deviation et s-curve pose très vite soucis il est préférable d'utilise le classic Jerk sur un 8bits.

[Eclipse]

Il y a 9 heures, PPAC a dit :

Peut être une histoire de taille de segment / "Résolution maximum" sous Ultimaker Cura.

Sinon tu imprime depuis OctoPrint sur un RPi via USB ou depuis la carte SD de la machine ? (si carte SD d'origine la changer par une de qualité de maximum 32GB a formater en FAT32, car souvent celles fournis sont de mauvaise qualités. Voir simplement formaté la carte SD car de temps en temps elles "sature")

Edit : Aussi peut être tester ArcWelder 

C'est exactement ce a quoi j'ai pensé, que cura ou im découpe les courbes en petite ligne droite, quand prusa utilise une extrapolation. Cela expliquerai le rendu ainsi que la taille du fichier différente.

Je vérifierai les gcodes ce soir, et le réglage résolution. J'imprime via octoprint, et le plug in Arcwelder a l'air super interressant ! merci pour le partage

Il y a 7 heures, MrMagounet a dit :

Le Slice ne ce fait absolument pas de la même façon, et j'ai jamais fait attention donc difficile de donner un avis sur le soucis de taille.

Après sur ta X1 tu utilise quels Firmware, si c'est celui d'origine il s'agit du même firmware que la Genius seule les PID et taille de bed diffère.

Si c'est un autre firmware faudrait savoir lequel et ce qui a été configuré, sur un MKS GenL 8bits d'origine des fonctions comme le Junction Deviation et s-curve pose très vite soucis il est préférable d'utilise le classic Jerk sur un 8bits.

Effectivement les slices sont différents, surtout quand on sais que des moves linéaires sont utilisés pour des courbes quand il existe une commande dédié (G2)

Le firmware c'est celui de base (2.0.5.2) auquel j'ai ajouté le bltouch, activer le babysteps et des bricoles je crois.
Je vais me renseigner sur les s-curves, mais ce qui est sur c'est que le gcode generé par prusa est plus compact et exempt de bug, dans mon cas

[fran6p]

Il y a 17 heures, Eclipse a dit :

Effectivement les slices sont différents, surtout quand on sais que des moves linéaires sont utilisés pour des courbes quand il existe une commande dédié (G2)

A condition que ce soit géré par le firmware : configuration_adv.h

Citation

//
// G2/G3 Arc Support
//
#define ARC_SUPPORT                 // Disable this feature to save ~3226 bytes
#if ENABLED(ARC_SUPPORT)
  #define MM_PER_ARC_SEGMENT      1 // (mm) Length (or minimum length) of each arc segment
  //#define ARC_SEGMENTS_PER_R    1 // Max segment length, MM_PER = Min
  #define MIN_ARC_SEGMENTS       24 // Minimum number of segments in a complete circle
  //#define ARC_SEGMENTS_PER_SEC 50 // Use feedrate to choose segment length (with MM_PER_ARC_SEGMENT as the minimum)
  #define N_ARC_CORRECTION       25 // Number of interpolated segments between corrections
  //#define ARC_P_CIRCLES           // Enable the 'P' parameter to specify complete circles
  //#define CNC_WORKSPACE_PLANES    // Allow G2/G3 to operate in XY, ZX, or YZ planes
  //#define SF_ARC_FIX              // Enable only if using SkeinForge with "Arc Point" fillet procedure
#endif

 

ET que le trancheur l'utilise or aucun trancheur n'utilise par défaut ces gcode (G2/G3). D'où l'intérêt de Arc Welder

[MrMagounet]

Le 07/10/2021 at 16:45, Eclipse a dit :

C'est exactement ce a quoi j'ai pensé, que cura ou im découpe les courbes en petite ligne droite, quand prusa utilise une extrapolation. Cela expliquerai le rendu ainsi que la taille du fichier différente.

Je vérifierai les gcodes ce soir, et le réglage résolution. J'imprime via octoprint, et le plug in Arcwelder a l'air super interressant ! merci pour le partage

Effectivement les slices sont différents, surtout quand on sais que des moves linéaires sont utilisés pour des courbes quand il existe une commande dédié (G2)

Le firmware c'est celui de base (2.0.5.2) auquel j'ai ajouté le bltouch, activer le babysteps et des bricoles je crois.
Je vais me renseigner sur les s-curves, mais ce qui est sur c'est que le gcode generé par prusa est plus compact et exempt de bug, dans mon cas

Sur la X1 le Marlin de Base est 1.1.9, absolument pas en version 2.0.5.2 d'ou ma question si tu as en 2.0.5.2 tu es partie d'un fichier d'exemple Marlin ou a utilisé firmware déjà conçu.

Pour ma part je me fait mes propres firmware sur ma Genius actuellement je suis en 2.0.8.1 et comme dit plus haut jamais de soucis de print soucis Cura avec mes profils.

Après si tu t'en sent capable tu peux tenté de passer sous firmware Klipper.

[Eclipse]

Je crois que j'était un fichier d'exemple de marlin, ça remonte à loin. Actuellement la qualité d'impression est très satisfaisante, peut être un peu de ringing à diminuer, j'aimerai tenter le plug d'arc welder mais il faut une version supérieur a 2.0.5, est ce que le tient est adaptable pour la X1? J'ai un 3D touch (wagster mode) avec le capteur de filament déporter sur le rpi, et des tmc2209

Klipper propose une solution alléchante avec un accéléromètre mais à vrai dire j'ai un peu la flemme de switcher à quelque chose de radicalement nouveau alors qu'il y a pas mal de gros print en file d'attente. Mais c'est vers quoi je pense me diriger, plutôt la case 32bit

Modifié (le) Octobre 8, 2021 par Eclipse

[MrMagounet]

Moi je tourne en 32bits sur SGenL V2 mais je passerais probablement la CR10s Pro en Klipper un de c'est 4 pour tester et comparer avec la Genius.

J'ai développer des version pour X1, avec TMC2208 ou 2209 et support BLT, passer sur un support BLT wargster mode est pas difficile c'est natif sur la Genius suffit d'inverser les pins Zmin et Zmax, je pourrait te fournir les sources de mon firmware, mais adapter a ce que a besoin d'autre comme option.

[Eclipse]

Je veux bien ton firmware 2.0.8 pour la X1 

Je dois rajouter le wagster mode et c'est good? Celui que j'ai était basé sur un fichier d'exemple de la 2.0.5, mais apparemment il faut la 2.0.6 a minima pour l'arc welder

[MrMagounet]

Il y a 2 heures, Eclipse a dit :

Je veux bien ton firmware 2.0.8 pour la X1 

Je dois rajouter le wagster mode et c'est good? Celui que j'ai était basé sur un fichier d'exemple de la 2.0.5, mais apparemment il faut la 2.0.6 a minima pour l'arc welder

Ok je te met les sources qui vont bien sur mon drive dès que j'ai du temps et je te MP

[Eclipse]

Merci beaucoup Magounet, je ferai un retour du plug Arc welder pour ceux que ça intéresse