Soucis avec Cura

[Cupra Power 0]

Bonjour,

 

Je me tourne vers la communauté pour un gros soucis avec CURA.

 

Il peut s'agir d'un problème, de 2 voire de 3 différents, c'est ce que j'essaie de savoir.

 

1/ Mes pièces imprimées d'un STL (Anet A6) se décalent à une certaine hauteur qui est variable

(idem sur une autre Anet A6, donc pas de soucis mécanique, il s'agit d'un soucis informatique. Le décalage arrive entre 14 et 16cm de haut, pire, une fois il s'est inversé de sens allant de gauche à droite..!)

(Après vérification el STL était à réparer, après réparation même soucis)

2/ Cura ne lit pas les fichiers gcode générés, pour cela il faut que je retire les gcode Début et Fin

(Ces derniers marchaient très bien jusqu'alors, j'ai le même soucis que Shinobu74)

3/ Les fichiers gcode générés des STL ne pèsent pas le même poids bien qu'ils soient slicés avec les mêmes paramètres.

(ouvre un STL avec Cura, agrandi la pièce, slice et génère le gcode, ferme Cura et reproduis la même manip', résultat les fichiers n'ont pas le même poids)

 

J'ai testé avec les 3 dernières versions de Cura 3, idem, désinstallé avec CCleaner + effacé manuellement les résidus dans AppData...

 

Rien y fait.. 

 

Qu'en pensez-vous?

 

 

 

 

Edited February 26, 2018 by Cupra Power

[darkdvd 981]

Je vais tenter de répondre mais en faisant abstraction de ton imprimante car je ne la connais pas cette Anet 06, pourtant, j'ai connu une Annette mais elle doit être en prison maintenant (une longue histoire....) sachant que je ne suis pas un spécialiste du Gcode....

 

1/ Pour qu'il y ait un décalage d'une ou plusieurs couches sur un fichier STL, il faudrait que le bug décale les couches en X/Y sans toucher à Z : je n'y crois pas mais sait-on jamais....
Quand du dis que tu as "réparé" le STL, tu as utilisé quoi ?
Si tu regardes dans CURA (quelle version utilises-tu d'ailleurs ?) ton objet en vue "layer / couche", il est comment au niveau de ton décalage ? Normal ?
Si il est normal, c'est un problème pendant l'écriture du fichier sur la carte (ça utilise une carte une Anet A6 ?) = carte poubelle.

 

2/ Cura ne sert pas à lire le gcode généré, il sert à le faire. Tu ne pourras que voir ce qui se passe sur les couches sans jamais pouvoir modifier un paramètre. Si il n'arrive pas à lire le Gcode avec les parties ajoutées pour ton profil d'imprimante, c'est que quelque chose le dérange, mais quoi ? Bonne question !

 

3/ C'est normal : si tu changes l'échelle de ton objet, tu changes le nombre de couche donc la taille du STL : imaginons pour simplifier qu'une couche prenne 1 Ko dans ton fichier STL pour un objet faisant 10 couches, il fera 10 Ko. Si tu le redimensionne pour faire un objet deux fois plus grand, tu auras deux fois plus de couches, ton fichier fera 20 Ko.

 

J'espère avoir un peu aidé....

[Cupra Power 0]

Salut Darkdvd,

 

Merci pour ton retour rapide.

 

Alors :

 

1/ Je confirme que le décalage se fait en X ET en Y en même temps et de manière proportionné, c'est à dire en suivant bien la forme de la pièce. Détail important ou non, la pièce est imprimée sur la diagonale du bed, car trop longue sinon (225x225x4), le bed de la Anet A6 fait 220x220x250. J'ai eu environ 7 pièces décalées N-O vers S-E et un seule S-E vers N-O!

J'ai utilisé Slic3r puis Netfabb, à la suite pour être sûr, donc doublement réparé. (le problème de poids de gcode arrivent même avec des STL de Thingiverse ou ceux que je crée)

Aussi, l'objet en STL est visuellement nickel, le gcode est visuellement nickel, Rayon-X aussi.

J'ai utilisé les 3 dernières versions, là je viens de réinstaller proprement la dernière.

 

2/ Oui mais Cura est capable d'ouvrir les fichiers gcode pour les visualiser tout de même. Là, sans effacer le gcode début et fin ça n'est pas possible, il s'agit d'un bug.

 

3/ Non non non, je parle bien de la même procédure à chaque pas, je compare 2 mêmes objets redimensionnés aux mêmes dimensions slicé avec les mêmes paramètres, je reproduis tout strictement de la même manière et pourtant les fichiers ne pèsent pas le même poids, pour moi c'est un bug.

[darkdvd 981]

1/ Il y a peut être un problème avec les informations qu'ajoute CURA pour ton imprimante mais la, je ne peux pas t'aider.

 

2/ Cura est fait pour communiquer avec les UMs PUIS les imprimantes supportées "officiellement" (quand le fabricant a pris le soin de donner les paramètres pour créer un vrai profil).
Pour moi, ce n'est pas un bug si CURA n'arrive pas à relire un gcode d'une imprimante non supportée officiellement.
Dans le doute, tu peux poster ta remarque sur github : https://github.com/Ultimaker/Cura

 

3/ je viens de faire le test en sliçant le même fichier deux fois après l'avoir supprimé puis rechargé (avec changement d'échelle et positionnement sur le plateau en X0/Y0/Z0) : les fichiers font la même taille. J'ai même fait une comparaison des deux dans Notepad++ : ils sont bien droits, au ; près.

Edited February 26, 2018 by darkdvd

[Cupra Power 0]

1/ Certainement, mais cela fonctionnait bien il y a quelques semaines avant que je ne mette à jour. Et puis les soucis sont présents avec les 3 dernières versions...

 

2/ Oui je vais faire remonter l'info car ce n'est pas normal

 

3/ Non, car si je ne ferme pas Cura effectivement les gcode ont le même poids. Il faut fermer Cura entre temps et refaire la même manip (charger le STL l'agrandir puis le slicer)

 

Dis-moi si les fichiers ont le même poids, car chez moi je peux faire la même manip' 10 fois je n'aurais jamais le même poids...

[darkdvd 981]

C'est bien parce que c'est toi....

 

3/ je viens de faire le test en ouvrant un fichier STL, en passant sa taille à 300% puis en le positionnant au centre du plateau car du coup, il était en Z à -16 mm, j'ai enregistré le gcode, j'ai fermé CURA (3.2.1 sous W10) j'ai ouvert CURA et fait exactement la même manip bilan.....roulement de tambour....les deux fichiers.....font la même taille à l'octet prêt.

 

Pourquoi ne pas repasser sur la version qui marchait ?

[Cupra Power 0]

Merci beaucoup c'est sympa.

 

Car elle ne marcheplus justement, plus aucune, moi j'ai un écart de milliers d'octets voire dizaine de milliers...

 

Mais le soucis c'est qu'1'aujourd'hui j'ai imprimé avec Slic3r et même problème...

 

Je suis perdu...

[darkdvd 981]

Tu imprimes en USB ? Via une carte ?

[Cupra Power 0]

Avec la carte micro sd d'origine, je l'ai même formaté.

 

Mais demain j'imprimerai sur une "vraie" carte, au cas où.

 

As-tu d'autres pistes à explorer?

[darkdvd 981]

Oui, essaye une autre carte, on a déjà vu des trucs rigolos avec les SD.

 

Pour les autres pistes, non. Mais avant d'en ouvrir d'autres, enlevons celle de la carte SD...

[Cupra Power 0]

Salut,

 

Encore un échec.

 

Aujourd'hui j'ai testé avec une autre carte SD mais surtout j'ai imprimé en tronquant la pièce.

C'est à dire que comme le défaut arrive vers les 12 cm, et bien je descends la pièce pour imprimer à partir de là où le défaut arrive sur la pièce.

Bilan, pas de décalage là où la pièce se décale en temps normal, par contre le décalage arrive toujours à + ou - 12 cm...

 

 

[darkdvd 981]

C'est donc matériel...

[Cupra Power 0]

Non non, car j'ai fais imprimer sur d'autres ANET A6 et même problème.

Sur la mienne, pour être sûr j'ai imprimé une tour de test de 24cm, sans soucis.

 

Le soucis n'est vraiment pas lié à l'imprimante, ni à la bobine ou carte mère, courroie etc, il s'agit bien d'un soucis informatique.

J'essaie de procéder par élimination, d'ailleurs même soucis avec Slic3r, donc le soucis doit être le modèle en lui-même.

 

Repetier m'indique qu'il est à réparer, d'accord, je le répare avec Netfabb et avec Slic3r à la suite pour être sûr, et reslice avec Cura et pareil, décalage au même endroit.

 

C'est vraiment un soucis... 

 

[darkdvd 981]

envoi ton fichier, stp...

[Cupra Power 0]

Fichier à réparer : https://www.transfernow.net/download/?utm_source=54j3b5j4clbe

Fichier réparé 2 fois à la suite : https://www.transfernow.net/download/?utm_source=430ro5d5kd47

[darkdvd 981]

Il n'y a aucune erreur dans le premier fichier, je l'ai vérifié avec MeshMixer.

 

Au passage, je ne comprends pas pourquoi tu veux l'imprimer sur la tranche, ton lithophane ?

 

[Cupra Power 0]

Car les lithophanes s'impriment sur la tranche, sinon le rendu est médiocre.

Aussi, vu la dimension supérieur à la taille du bed, je n'ai pas le choix.

 

Merci pour la vérification, je suis plus que perdu alors...

Car même avec un autre Slic3r j'ai le décalage.. Donc normalement la pièce est fautive, cette hypothèse est appuyé par le fait que j'ai réussi à imprimer la tour de test sans soucis.

 

C'est incompréhensible, cela fait une semaine que je me prends la tête avec ça tous les jours, c'est dingue!

[darkdvd 981]

Tu sais que tu peux faire des lithophanes directement dans CURA en important une photo en JPG ?
Et tous les lithophanes que j'ai vu ont tous été imprimés à plat.

D'ailleurs, je doute que le cadre de ton lithophane puisse être imprimé si tu veux le faire à la vertical.

 

Tu es certain que le décalage n'est pas dû déplacement de ton objet pendant l'impression ?

[Cupra Power 0]

Exact, mais j'ai besoin de la bordure et Cura ne la génère pas malheureusement...

Je t'assure qu'il faut les imprimer à la verticale, la logique voudrait l'inverse, je te l'accorde, mais le rendu est nettement meilleur ainsi.

 

Sinon si, le cadre (la bordure) s'imprime très bien, pas de soucis là dessus.

 

Mon objet ne peut se déplacé car fixé avec un brim (encore une bordure tient!), et je n'ai pas de verre donc pas de risque de glissement.

 

L'imprimante est vraiment étrangère à ce soucis, car j'ai fais imprimé sur une autre imprimante c'était pareil, et regarde ma tour de test de 24 cm, nickel elle!

[darkdvd 981]

Tu peux mélanger plusieurs objets dans CURA....

 

Du coup, si tu penses que c'est une erreur de CURA, je te suggère de poster un message sur github.

[DidierKlein 729]

Pas de mise à jour du firmware?

 

Si tu as le soucis avec Slic3r et Cura c'est que ça vient d'autre chose que du slicer d'après moi

[Cupra Power 0]

Salut Didier,

 

Je n'ai pas touché au firmware.

 

C'est ce que je pense, en point commun il y a donc :

- Carte micro SD (j'ai essayé hier avec une autre étrangère à l'impression 3D et idem)

- Fichier STL (j'ai essayé avec OBJ idem)

- Ordinateur (j'ai essayé avec un ordi portable hier, donc idem)

 

A part le fichier STL tellement endommagé (vérifiable sous FreeCad et Repetier) que même après moultes réparations rien n'y fait, je ne vois pas d'autres causes probables à ce stade.

[darkdvd 981]

Je ne veux pas avoir l'air de trop insister mais le fichier STL est nickel, sous MeshMixer et CURA et MeshMixer pardonne beaucoup moins que CURA en la matière : la moindre facette avec une normale inversée est détectée, la moindre facette manquante est détectée également...

[Cupra Power 0]

Pas de problème, je n'ai pas d'erreur non plus avec Meshmixer, c'est pourquoi j'ai approfondis avec d'autres logiciels.

 

J'ai suivi ton conseil et ai créer un topic sur githiub, en espérant que la communauté aura réponse à mes soucis.

 

Merci de ton aide en tout cas, c'est appréciable. Je ferai un retour dans le cas où des solutions ont été trouvé.

[darkdvd 981]

Le problème vient de ton STL.
J'ai fait la manip suivante :

ouverture du STL dans MeshMixer
analyse via la fonction "inspector" : RAS

remise à tes cotes de l'objet : 225 x 225 x 4
découpage d'une bande de 4 cm au milieu de l'objet soit à peu prêt ou se produit le problème
note : normalement, si l'objet est fermé (propre) la coupe se referme automatiquement mais la, non.

 

Comme on peut le voir sur l'image ci-dessous, en bleu, c'est la coupe effectuée qui génère une erreur dans l'"inspector", l'objet n'étant pas étanche.

 

Conclusion : il y a un problème dans le STL qui n'est pas corrigé par les divers logiciels permettant de le faire, a priori ce qui provoque une erreur lors du slicing dans CURA.