Reprise du message précédent :

Tu as essayé d'ajouter une ou deux couches et/ou le infill? 9 fois sur 10 c'est la cause

Question hardware : sur une cartésienne vous conseilleriez quoi comme mobo en remplacement de l'actuelle équipée de drivers "bâtards" ?
 
Modèle d'origine Ramps Plus2 V1.8.26. Mais je ne serai pas contre l'idée de devoir mettre les mains dans le "cambouis" avec un modèle qui n'est pas ready out of the box  
 

 
 
Tu reproches qq chose à l'actuelle?
 

Il m'arrive un truc de fou :
 
J'essaie d'imprimer un objet :
 
celui là :
 
https://www.thingiverse.com/thing:2534990
 
ou un autre dans le même genre.
 
Tout se passe bien, les couches du bas sont "parfaites" et dès qu'il faut commencer à monter : mur ou pas de vis dans l'exemple donné : les premières couches ne tiennent pas bien et après ça continue à imprimer parfaitement. Sur les deux objets imprimés ça se passe exactement au même moment : dès que la partie épaisse touchant la plaque est finie et qu'il faut continuer à monter ça s'imprime pas bien. Voici des exemples sur les photos.
 

 

 
 

 
Le filament est un filament Amazon que je viens d'ouvrir (mais que je ne peux plus renvoyer car acheté il y a deux mois). Je suis en train de tester avec un autre filament noir (Filmanent en PLA pour les deux)
 
Divers essais :
 
ça le fait sur une ultrabase ou une plaque en verre avec laque.
 
J'ai mis à jour Cura et remis tous les paramètres à 0 idem
 
Infill : sur les premières impressions c'était 20% et je pensais que c'était un peu léger pour les murs, essais à 100% idem
 
Resserage de tous les écrous concentrique (chose que j'avais pas fait au déballage) : idem
 
 
Paramètres communs :
- Bobine PLA Rouge Amazon Basics (en cours d'impression avec un PLA noir)
- Z Hop activé depuis hier : est ce que ça peut venir de là ?
 
Merci de votre aide
 

 
Elle doit être HS au niveau du connecteur de l'extrudeur car quand je change les fils, drivers d'emplacement sur un autre l'extrudeur fonctionne. Et un moteur sur E lui non
 
 

ca peut venir du modele, vu comme un "assemblage" de 2 pièces, la base et le reste. C'est peut etre visible dans le slicer.

 
Comment as-tu réglé la ventilation? Quelle est la T° du plateau? J'essaie de trouver la faille. Et commence par dire ce que ça donne avec un filament que tu connais, puisque c'est un nouveau filament c'était la première chose à faire avant de poster.

Essaye sans le Z Hop pour éliminer cette piste, si ça le fait au moment du passage de la base au mur, c'est exactement à ce moment que le Z Hop intervient, puisque l'objectif est de ne pas "marquer" la surface de ta base lors du déplacement de la buse vers le point de départ du périmètre du mur.

Tiens, en parlant de Z Hop, ya moyen de ne l'activer que pour les finitions, genre top et bottom layers? Je ne l'utilise plus depuis longtemps, mais maintenant que je commence à avoir une super finition sur les top et bottom, les déplacements en diagonale se voient méchamment. EDIT : quelqu'un a fait la même demande ici : https://community.ultimaker.com/topic/25106-z-hop-tips/
 

 
 
EDIT : j'en profite pour dénoncer un horrible bug de Cura, sur l'objet en photo Cura a imposé un brim sur les lettres, en plus d'un brim que j'avais défini sur l'extérieur de la pièce . Pourtant j'avais décoché l'option "brim on inner parts" (libellé approximatif). J'ai fait tout ce que j'ai pu, sans succès. Du coup c'est un fail sur ce point.
 

 
ventilation sur la pièce : essai à 20% et à 100% : même résultat
 
Plateau 60°, extrusion à 210°
 
c’est pour ça que le test vécu le PLA noir que je connais est en cours

 
bah sur la pièce que j’ai faite idem : il y a un espèce de brim sur les lettres posées sur le lit. Ça me le faisait pas il y a quelques mois quand j’avais imprimé la même pièce.

poste ton modele si possible
change de slicer

 
C'est probablement le Z hop, j'avais le même problème, résolu en le désactivant.
 
En gros si tu demande de monter de 0.1 puis de 0.1, pas de soucis c'est ultra précis
Mais si tu demande de monter de 0.1, puis de descendre de 0.1, puis de remonter de 0.1, tu retombe pas exactement à la même hauteur à cause du jeu dans ta mécanique de Z (backlash)

Le problème est encore présent avec le filament noir même si un poil moins prononcé mais on voit toujours la séparation entre la base et les murs.
 
Test en cours avec filament rouge et z hop désactivé

quel est le slicer?

 
cura sur mac

et tu ne voit rien de bizarre au niveau du tranchage et de la transition base/mur? (en affichant les coloris de type de couches)
Avec Slic3r, le modèle est tout pété.

Je viens de publier ça :
 
AM4 Raystorm Waterblock Adapter (including generic version)

ça me donne ça sur la première couche après la finition du bloc du bas :
 

 
la ligne extérieure reste verte comme sur les couches du dessous, cela rajoute une ligne intérieure verte en périphérie ainsi qu'une ligne noire sur la partie interne/externe
 
Je vois rien de fou

Pour rappel, le plugin greasemonkey "SFBA descriptor" permet de mettre en forme les liens amazon, gearbest, etc. et surtout thingiverse quand vous collez l'url dans la saisie de post.
 
https://greasyfork.org/fr/scripts/3 [...] descriptor

Tu as essayé de mettre Combing -> Not in skin dans Cura pour enlever les traces de déplacement sur les premières/dernières couches?

J'essayerai ça, j'ai vu ça en googlant tout à l'heure . Un gars semblait dire que ça générait d'autres artefacts, des points. On verra. Je me ré-habitue à Cura et ses milliers d'options.

Il y a du monde qui utilise klipper ici?  
Je commence à valider klipper en remplacement de marlin, j'ai juste une limitation, je ne peux pas dépasser une vitesse d'impression autour de 40mm/s, ensuite j'ai des timeout en raison de la liaison USB longue de 5m entre mon serveur et la CR10S. Dans l'absolu avec Marlin je n'allais pas beaucoup plus vite, mais le paradoxe c'est que klipper imprime plus propre plus vite que marlin. Je réfléchis donc à la solution rpi3 même si je ne suis pas spécialement emballé d'ajouter encore un élément allumé H24 dans mon installation, sans parler des coûts et de la maintenance. Du coup je veux bien savoir ce que vous préconisez pour klipper sur rpi3 :  
 
- stockage carte SD ou SSD?
- est-ce que la solution octoprint + écran LCD tactile est viable avec klipper? J'arrive pas à avoir une réponse claire sur les internets.
 
Merci

 
Le raspberry consomme que dalle, genre 3w. Tu peux t'en servir pour plein de chose. Franchement si ça marche bien, faut pas se priver. A mon boulot on en a 6 qui tourne H24. Par contre disque dur obligatoire, pas de ssd ni de carte SD, vu le nombre d'écriture avec les fichiers linux, tes cartes vont tenir que quelques mois.
 
 

 
J'ai klipper sur R3B+ (SD card), alimenté via une alim ATX contrôlée par octoprint (sauf le 5v permanent qui alimente le raspberry)
En vitesse j'ai pas testé au dessus de 170mm/s mais après c'est la mécanique qui suis pas.
 
Niveau conso c'est négligeable.
 
Par contre j'imprime tout via le réseau, j'utilise pas l'écran sauf quelques réglages de dernière minutes.
Je sais qu'il y en a qui incluent un vieux tel android ou une tablette sur l'imprimante comme interface de contrôle.

Ici aussi R3B+ et écran 5 pouces, sur SD card, aucun problème et fort pratique. L'écran sert pour lancer un fichier préalablement déposé depuis le PC, mettre en chauffe, quelques manips de base, sinon je fais du PC

Merci pour vos retours. Je vais tenter une dernière fois de fiabiliser la communication depuis mon serveur vers klippy, ensuite je verrai si je pars sur un rpi3, pour le moment partir sur une nouvelle machine avec carte, alim, ssd, maintenance, ça ne m'emballe pas plus que ça puisque ça sera du temps, de l'encombrement et de l'argent pour être isofonctionnel avec actuellement (hormis la vitesse).

 
j'ai une carte sd sur mon pi3b+
d’après les docs de klipper, la ramps limitera avant la limite de connexion usb entre ramps et rpi3b+ (cable pas trop long j'imagine))
liaison wifi entre le pi et ton pc, c'est pas très rapide chez moi, il faudrait que je regarde ça mais de toute façons même avec cura, le logiciel envoi d'abord tout le gcode sur le server pi
et ensuite le serveur se charge de la com avec l'imprimante tout le long de l'impression
 
je suis monté à 200mm/s mais je pense que la pièce pas assez grande ne permettait pas de monter rééllement à 200
je suis parti de 20 et j'ai augmenté le feedrate, au début c'est facile de voir et d'entendre que ça accelère mais à la fin    
 
je peux retester ce soir sur une pièce large si tu veux
genre un gros arc de cercle + des lignes droites pour avoir bcp de mouvement et de la vitesses réélle
en couche de 0.2, la limite des hotends de qualité est aux alentours de 150mm/s  (12 mm3/s)
en couche de 0.1 le double
 
c'est quoi comme carte sur la CR10 ? une 8bits comme une ramps ?
 
pour la gestion du pi, depuis un pc en wifi ou depuis un smartphone en wifi
si ton gcode est déjà prèt ça le fait
 
s'il faut trancher depuis octoprint, un pc en wifi me semble plus adapté qu'un smartphone ou un écran tactile
mais je ne l'ai jamais essayé
 
l'ecran de l'imprimante a un onglet octoprint mais je ne suis jamais allé voir ce qu'il y avait dedans ?

 
Merci pour tes retours à ce sujet, sur le coup tu n'as pas eu d'interactions, mais maintenant que je m'y mets c'est très utile. J'ai un souci de compréhension de base : par défaut le pressure advance n'est pas actif ou alors il est actif avec des valeurs par défaut? En gros dans mon printer.cfg actuel je n'ai rien : je dois définir combien de variables? Les deux que tu cites ci-dessus? J'ai lu les différentes docs mais je n'ai pas trouvé de façon claire s'il y a un interrupteur ON/OFF pour le pressure advance. Au final si quequ'un a une CR10(s) ou ender3, et un bondtech en bowden je veux bien ses valeurs pour avoir une base de départ. En fait avec klipper j'ai des impressions nickel sans rien toucher, hormis la fois où j'ai imprimé un cylindre stupide, là il m'a fait un bourrelet vertical continu totalement inattendu. Je ne sais pas si c'est lié à Cura, j'étais en adaptative layer, la hauteur de couche était bâtarde (0.15mm de mémoire)
 

 
Merci mais c'est pas la peine de tester pour moi, en fait j'ai une config particulière puisque c'est une VM Debian sur un PC, avec une rallonge USB active de 5m et un câble USB au bout. ça marche depuis 8 mois avec marlin peu importe la vitesse grâce à la file d'attente, mais avec klipper c'est du temps réel et dès que le micro tampon de la carte CR10S est vide le firmware se met en exception. Avec marlin c'est moins extrême, si le tampon est vide (ce qui est rare) les moteurs s'arrêtent en attendant le retour des données. En fait les plus grandes sollicitations ne viennent pas des grandes pièces, mais au contraire des petites. L'extrême étant un remplissage de couche intermédaire  sur des toutes petites surfaces : par exemple quand tu as 3 top ou bottom layers, les couches intermédiaires il va les imprimer rapidement avec des petits allers/retours, c'est ça qui le stress le plus. Je le sais car j'ai l'imprimante qui s'arrête avec un message "firmware MCU timeout" dans ces passages quand je mets trop de vitesse.
 
J'ai commandé un câble USB blindé passif, je vais voir s'il résout le timeout, sinon je passerai sur rpi.
Concernant le menu octoprint sur l'imprimante, c'est le seul moyen de mettre en pause ou annuler l'impression. Plutôt utile quand tu as le nez sur l'imprimante et que ça part en sucette, je suis surpris que tu ne le connaisse pas du coup.

 
tu mets juste une ligne dans la partie [extruder] de la config
pressure_advance: 0.0x
 
par défaut ce n'est pas activé
 
si tu veux le mettre en Off, tu le regle à 0 dans ta config
ou en début de gcode avec SET_PRESSURE_ADVANCE ADVANCE=0
 
de mon côté j'ai trouvé une valeur quasi identique sur marlin et sur klipper
 
donc tu peux mettre pressure_advance: 0.0x (valeur de linear advance 1.5 de marlin que tu avais) dans ta config
 
si tu veux vérifier, tu fais une tour en mettant SET_PRESSURE_ADVANCE ADVANCE=0.x toutes les x couches
 
pour le reste c'est des variables indépendantes du pressure advance
tu peux ne pas les mettre dans un premier temps
 
je regarde ce que j'ai dans mon fichier config ce soir
 

 
ok    

J'ai un petit soucis avec ma CR 10 et un octopi (octoprint sur un Raspberry Pi) :
 
si l'octopi est allumé et que la CR10 est éteinte : une partie de la CR10 reste alimenté dont l'écran et je vois même les températures descendre sur l'écran.
 
Est ce que quelqu'un connait ce problème et comment le résoudre ?

un petit bout de scotch sur la piste du connecteur usb  

C'est normal. Les seuls parties qui nécessitent l'alimentation sont les moteurs, et les parties chauffantes.

 
Oui le raspberry alimente ton imprimante via l'usb.
 
moi j'ai résolu le problème en fabriquant une mini ralonge usb sur laquelle j'ai coupé le +5v.
Ou un bout de scotch ou de vernis comme dit Delatruel.

c'est bon j'ai tailladé un câble mini usb pour couper le 5V

quelqu'un a déjà essayé d'imprimer de l'acetal ?
Est-ce que vous obtenez des pièces qui résistent bien à la chaleur?

Duet wifi + clone de paneldue problem solved

Si jamais vous voulez mettre un j'aime, je participe au concours Cults
https://cults3d.com/fr/mod%C3%A8le- [...] re-message

 
J'ai voté pour l'indicateur de niveau bas de PQ    
https://cults3d.com/fr/modèle-3d/ma [...] -papier-wc

 
j'ai fait un test pour voir ce que ça donne en vitesse en 0.2 mm
la photo est a vitesse max en fin de couche le long de Y
20mm/s au début, puis 40, puis 80, 120, 160 et 200mm/s jusqu'en haut
un seul périmètre
brillant jusqu'à 80
à 80 j'ai une sorte de raisonnance de vibration a priori
a 120 et 160 j'ai un résidu de vibration
en vrai ça se voit vraiment sur le 80 pas sur le reste
sinon nickel

 
le long de X c'est hiper propre
sur XY à 45° j'ai des ligne verticales à 120 et au dessus (plus de atterie pour une photo)
le log de charge di pi3b+
avec les palliers cités + haut plus la charge pour le timelaps à la fin à 2.10