Jump to content
Cura Connect | Survey Read more... ×
Ultimaker Community of 3D Printing Experts
Cupra Power

Soucis avec Cura

Recommended Posts

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?

 

 

 

 

28309745_10214594690476611_1377618501_o.thumb.jpg.f2bcfaddf1d93d4bc5d76be1c901a2ad.jpg

Edited by Cupra Power

Share this post


Link to post
Share on other sites

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é....

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by darkdvd

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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...

 

 

Share this post


Link to post
Share on other sites

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... :'(

 

28500197_10214619344532947_183420155_o.thumb.jpg.8c00a63dd97710dff9861e254a625f91.jpg

Share this post


Link to post
Share on other sites

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 ?

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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é.

Share this post


Link to post
Share on other sites

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.

 

lithophane.JPG

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Our picks

    • Architect Design Contest | People
      The goal of this contest is to design a set of people figurines that could be used in such a project to make an area, office or mall seem populated. 
      Think of different types of people in different environments, like walking people, people standing still, working people, and both men and women.
       
      • 9 replies
    • Taking Advantage of DfAM
      This is a statement that’s often made about AM/3DP. I'll focus on the way DfAM can take advantage of some of the unique capabilities that AM and 3DP have to offer. I personally think that the use of AM/3DP for light-weighting is one of it’s most exciting possibilities and one that could play a key part in the sustainability of design and manufacturing in the future.
        • Like
      • 3 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!