CR10 Ralentissement de la tête, impressions de courbes

[Kachidoki]

Arf, je viens tout juste de passer ma CR-10 (non V2) sous Marlin 2.0.5.3, mais sur une MKS SBase (32bit), et c'est maintenant je vois ce tuto. 

Pour ma part j'ai effectué cette migration car j'avais une SBase qui trainait, et l'épisode des visières étant très enrichissant, j'ai vu des soucis logiciels sur la CR10.

Le résultat en photo :

Même G-Code un cylindre de 25x100mm en mode vase, couches de 0.25mm et vitesse 80mm/s. A gauche, avec la carte d'origine Creality3D V1.1.2, et le firmware d'origine. A droite avec la SBase et Marlin 2.0.5.3, et des réglages à la louche et très conservateurs.

Je n'ai pas essayé de faire le test avec la carte d'origine et Marlin 2.0.5.3, si quelqu'un veut bien essayer ça m'intéresse (CR10 v1 300x300 je rappelle, quoique ça peut être intéressant aussi de tester sur une V2), je poste le G-Code.

Shape-Cylinder_0.25mm_PLA_ENDER3_8m.gcode

Tous les paramètres ne sont pas optimum car c'est une config de config où j'ai cherché à rendre visible le phénomène. (Attention première couche à 60mm/s et plateau à 60°C, ça colle très bien chez moi sur du Magigoo).

Pour résumer, avec le firmware d'origine j'ai constaté qu'a "haute" vitesse, la tête ralentissait à intervalle très régulier. Il s'est avéré que ça venait du rafraîchissement du LCD toutes les secondes. Le simple fait de rentrer dans les menus fait disparaître ce ralentissement. Le soucis de ce ralentissement c'est que ça génère des blobs très moches sur la pièce (et ça m'a bien emm**** pour le nettoyage des visières).

[fran6p]

Il y a 8 heures, Kachidoki a dit :

et c'est maintenant je vois ce tuto.

C'est bien la peine que je me décarcasse .

Je vais tester ton gcode avec mon nouveau plugin pour Octoprint (Arc-Welder) qui analyse le gcode envoyé et le passe dans une «moulinette» afin de transformer les petits segments formant une «courbe» (série de G0/G1) par des G2/G3 (à condition que l'option ARC_SUPPORT) ait été activée dans le Marlin.

Je posterai demain car là il commence à se faire tard

[Kachidoki]

il y a une heure, fran6p a dit :

Je vais tester ton gcode avec mon nouveau plugin pour Octoprint (Arc-Welder) qui analyse le gcode envoyé et le passe dans une «moulinette» afin de transformer les petits segments formant une «courbe» (série de G0/G1) par des G2/G3 (à condition que l'option ARC_SUPPORT) ait été activée dans le Marlin.

Là tu m’intéresse, car justement j'y pensais quand j'ai constaté que le G-Code transmis par USB (à 115.2kBps) est plus lent que ce même G-Code exécuté depuis la carte SD. Logique surtout sur ce modèle, un cylindre en mode vase, constitué essentiellement d'arcs, et donc de beaucoup de petits segments.

Est-ce que ce "plugin" est utilisable en dehors d'octoprint ? En gros un post-processeur de G-Code qui recrache un G-Code avec des arcs ? J'imagine qu'il faut configurer un rayon minimum pour traiter les approximations de segments en arc ?

[fran6p]

Il y a 15 heures, Kachidoki a dit :

Est-ce que ce "plugin" est utilisable en dehors d'octoprint ?

Pas pour le moment

Le créateur envisage après suggestions de plusieurs testeurs d'en faire un plugin pour Cura.

Il y a 15 heures, Kachidoki a dit :

En gros un post-processeur de G-Code qui recrache un G-Code avec des arcs ?

C'est exactement son principe. Gros avantage supplémentaire: le gcode parsé est quasiment réduit de moitié (à condition évidemment qu'il y ait de nombreuses portions d'arcs).

Plus d'infos (post très long) >>> ici <<<

J'ai testé ton fichier en trois tests: via recopie sur la carte SD et impression à partir d'elle, via Octoprint avec / sans transformations via Arc-Welder. Je posterai des photos dans l'après-midi car là mon estomac me fait signe que le petit déjeuner est loin

[Kachidoki]

J'ai hâte de voir les photos. 

Et si tu peux aussi poster le G-Code passé dans Arc-Welder, j'aimerai faire un essai (en activant les arc dans le firmware bien sûr).

[fran6p]

Il y a 6 heures, Kachidoki a dit :

J'ai hâte de voir les photos. 

Heu, va falloir attendre car là je rencontre des problèmes. J'ai bien imprimé ton fichier MAIS le meilleur résultat est obtenu via impression à partir de la carte SD et même lui n'est pas terrible .

Les deux autres impressions (avec / sans utilisation du plugin Arc-Welder) donnent un résultat franchement en dessous de tout: bien qu'imprimé en mode contour (vase), j'ai une «couture» (seam) du haut en bas et l'extérieur se présente comme si j'avais utilisé le mode «flou» de Cura.

Ton gcode ayant été tranché avec Prusaslicer, aurais-tu le fichier STL qui t'a servi pour que je tranche avec Cura avec les mêmes paramètres.

J'ai fait vite fait un tube vide sous OpenSCAD (diamètre 25 mm, hauteur 50mm, une paroi de 0,4mm) mais bizarre quand je le tranche avec Cura en mode vase, dans l'aperçu tout est bon mais quand je tente de l'imprimer une partie du tube n'est pas imprimée (en gros un demi-cercle sur une hauteur de 5-6 mm). Aurais-je trouvé un bug dans la dernière version de Cura (4.6.1) ?

Je retenterai demain.

(Il est probable que je scinde notre discussion dans un autre sujet plus adéquat sinon un modérateur va invoquer le HS )

Modifié (le) Mai 3, 2020 par fran6p
orthographe

[Kachidoki]

Ce n'est pas un tube, mais bien un cylindre plein, ou une barre, Le mode vase enlève automatiquement la face supérieure et ne garde qu'un périmètre complet d'épaisseur. Je ne suis pas parti d'un STL car PrusaSlicer propose nativement des formes basiques (clic droit Add Shape), mais je t'ai fait un export tout de même.

Shape-Cylinder.stl

Pour mon G-Code, les paramètres sont très orientés vitesse d'impression, car justement c'est comme ça que j'arrive à rendre visible le défaut que j'avais avec la carte / firmware d'origine, qui ressemble justement à une couture. Avec la bonne vitesse (1 périmètre par seconde) on doit pouvoir la rendre verticale. Ou alors peut-être que c'est trop rapide pour ta configuration, vibration, ventilation etc... Mais j'en doute, je suis sur une CR10 stock, enfin j'étais.

Volontiers pour splitter le topic, désolé pour le HS.

[fran6p]

Le 03/05/2020 at 20:25, Kachidoki a dit :

Volontiers pour splitter le topic

C'est fait.

Hier ayant effectué de nouvelles modifications dans Marlin, j'ai réussi à tout planter : écran bleu (on aurait un vieux Windows ). J'y ai passé la journée à me dépatouiller et comprendre le pourquoi du comment. Va falloir que je fasse un sujet, ça pourrait en intéresser quelques uns.

Je vais pouvoir retenter les impressions de ces cylindres évidés.

[Kachidoki]

J'attends toujours des news avec impatience. 

En attendant, je cogite à garder ou pas ma SBase, car je voulais lui coller un écran 4x20 à la place du graphique que je trouve peu efficace, mais elle ne le gère pas, malgré quelques tentatives de changements de pins et d'adaptation de tension 3V3 -> 5V. Je dois pas être loin, car je vois bien qu'au démarrage le LCD passe du mode 2 lignes par défaut au mode 4 lignes, mais rien ne s'affiche encore. Bref c'est un autre débat.

Côté mécanique, j'ai pu jouer à chercher les limites des axes de la CR10 en vitesse et accélération, je pense que le 32 bit aide pas mal vu le nombre de kSteps/sec que ça représente, mais ça décoiffe.

De toute façon entre le télétravail et les travaux dans la maison, ça tourne au ralenti...

[fran6p]

Il y a 20 heures, Kachidoki a dit :

J'attends toujours des news avec impatience. 

Des news, j'en ai mais pas forcément bonnes.

Voulant essayer de régler le problème de «blobs / zits» sur les objets cylindriques plus particulièrement visibles quand je passe par Octoprint que par la carte SD, j'ai voulu appliquer des recettes trouvées sur le «Intergalactic Computer Network» (ancêtre de l'ARPANET).

A savoir augmenter certaines valeurs dans configuration_adv.h :

Citation

#if ENABLED(SDSUPPORT)
#define BLOCK_BUFFER_SIZE 64 // SD,LCD,Buttons take more memory, block buffer needs to besmaller
#else
#define BLOCK_BUFFER_SIZE 64 // maximize block buffer
#endif
#define MAX_CMD_SIZE 96
#define BUFSIZE 64
#define TX_BUFFER_SIZE 64

Je modifie donc ces valeur, lance la compilation via VSC, pas d'erreurs affichées. Via Octoprint, je flashe la carte. Octoprint me dit que c'est bon, il a flashé.

Contrairement aux autres fois où après installation d'un nouveau firmware, la carte reboote, même après cinq minutes, la carte n'a toujours pas rebooté . Confiant, j'éteins le boitier puis le rallume et là, c'est le drame: au lieu de voir l'écran Marlin puis celui de statut, il est bleu, totalement bleu et rien d'autre

Bon je me dis que le flash a foiré donc j'en relance un via Octoprint. Octo me dit à nouveau que c'est tout bon, que le flash a réussi. Toujours pas de reboot de la carte, nouvelle extinction du boitier, nouvel allumage, nouvel écran totalement bleu.

Des sueurs froides commencent alors à couler. Aurais-je écrasé le chargeur de démarrage?

Qu'à cela ne tienne, je fouille dans mon tiroir contenant les utilitaires dont je pourrais un jour avoir besoin la clé USBASP. Opération à cœur ouvert sur le boitier pour y brancher adaptateur 6 broches sur le connecteur ICSP de la  carte v2.5.2. connexion de la clé côté PC. Une belle LED rouge s'allume sur la clé mais elle n'est pas reconnue dans le gestionnaire de périphérique.

Je lance mon Zadig (pas celui de Voltaire ) pour installer le pilote qui va bien. Débranchement de la clé, rebranchement, ouf, elle est maintenant bien reconnue MAIS aucune LED ne s'allume sur la carte mère. Je débranche à nouveau la clé, débranche aussi l'adaptateur 6 broches et le reconnecte après lui avoir fait une rotation de 180°. Clé USB rebranchée, cette fois plusieurs LEDs bleues s'allument sur la CM.

Via Arduino, j'installe un bootloader sur la CM (après avoir évidemment fait les bons choix dans les options d'Arduino). Bootloader installé, je reflashe la carte… Au final même résultat: écran bleu de la mort qui tue…

D'un naturel à ne pas paniquer, là je commence à ressentir frissons, sueurs, palpitations : serait-ce le Covid19 ?

Via VSC, sans modifier quoi que ce soit aux fichiers, je relance une compilation. Résultat en vert : SUCCES. Je lis quand même un peu avant ce message que le firmware tiendra bien sur la carte mais un paramètre m'interpelle : la RAM, elle est occupée à plus de 100% (158% en fait)… Bizarre, bizarre, bizarre. Pour VSC ce n'est pas un problème, aucune erreur ne s'affiche.

Pour vérifier et ôter mes doutes, je lance une compilation via Arduino (v1.8.12) avec les mêmes fichiers de configuration et là le doute n'est plus permis : erreur explicite. La quantité de RAM restante ne permet pas de compiler.

Je modifie les valeurs du configuration_adv.h pour revenir aux anciennes, relance la compil, cette fois-ci : SUCCESS.

Je reflashe le firmware, la carte reboote, le logo Marlin s'affiche, mon écran est revenu.

Moralité:

Même si Visual Studio Code n'a pas affiché d'erreur, j'aurais dû être interpelé par cette utilisation «excessive» de la RAM. Arduino lui au moins est plus explicite et empêche la compilation d'aller à son terme.

Les processeurs 8 bits montrent leurs limites pour nos imprimantes: fréquence de fonctionnement faiblarde, capacité de stockage du firmware limitée, RAM faible, etc.

Étrangement, les ATMega2560 ont une RAM de 8K (8162 octets) alors que les ATMega1284p en ont 16K. Et a moins de supprimer de nombreuses options de Marlin, il n'est pas possible d'activer bon nombre de paramètres.

Bref, je continue mes tests   (le premier qui dit que ça m'occupe n'aura pas forcément tord (et le tort tue et la tu meurs …))

Au menu des prochains tests (si je trouve le temps

     - Marlin 1.1.9.1 passera-t'il mieux sur la carte 8 bits de la CR10-V2,

     - Marlin 2.0.5.3 sera t'il plus efficace sur une carte 32 bits (si oui laquelle SKR mini E3, E3 DIP, 1.3, 1.4, 1.4 turbo, Pro 1.1, GTR, ou une autre marque ?)

     - garder la carte 8 bits et passer à Klipper ( @Tircown ?)

     - …

 

[Tircown]

Hello,

T'as un raspberry avec octoprint? Je sais que tu es à l'aise avec linux, ça te prendra 5min d'essayer klipper. Si c'est bien de ta CR10 dont tu parles il y a des config toutes faites, un rapide contrôle de la cohérence et zou. Le 8bit te limitera encore sur la vitesse max d'impression mais t'auras déjà de quoi t'amuser avec.

Petite anécdote: ces deux dernières semaines j'ai (enfin) mis en route ma cubique IDEX (voir Mon projet en signature). Et sous Klipper bien entendu. Avant de tout refaire avec une SKR PRO, triple Z, j'ai voulu me prouver que ça pouvait fonctionner et voir ce qui ne marchais pas dans mon concept. Donc j'ai 2 drivers X indépendants, 2 drivers Y synchronisés, 2 extrudeurs et 1 driver de CNC (TB6600) pour le NEMA23 en Z et le tout sur une MKS GEN qui ne peut en accueillir que 5... Ce n'était encore pas assez compliqué, et surtout je n'avais pas envie de régler le petit potard alors j'ai pris les 6 TMC2209 de la Zatsit (RIP projet) et je les ai tous mis en UART... sur une MKS gen donc... pas vraiment prévue pour. Bref l'usine à gaz avec des fils un peu partout et pas mal de broches utilisées dans les emplacements extensions et servo. Avec Marlin je pense que je serai encore en train de paramétrer les broches à l'heure qu'il est. Avec Klipper, j'ai du passer 1h environ pour configurer, 1/2h pour tester, quelques ajustement par ci par là et tout fonctionne. J'ai même réussi à boucher 2 fois ma première tête et quand même sortir quelques prints utiles. Il me reste à régler les offsets des têtes pour qu'elles puissent imprimer en multicouleur sur la même pièce. J'ai déjà les macro de changements d'outils et l'offset Z est réglé, il ne me manque que les offset X et Y. J'aimerais aussi tester la connexion de l'écran sur un Arduino UNO. L'objectif serait de n'avoir qu'un câble USB entre le rpi et l'écran.

Je suis encore plus convaincu par Klipper. Si je ne le conseille pas à tout le monde c'est que l'installation est un peu particulière (quoique) mais pour toi @fran6p ça te prendra moins de temps à faire que ce que tu as passé ici à me lire . Le seul défaut de ce firmware ce sont les immenses possibilités et l'imaginaire qui ne s'arrête plus. Ex: sur le groupe facebook Klipper, un membre travaille sur un PCB de la taille d'un NEMA17 (42x42mm) qui communique en bus CAN (4fils) et qui pilote toute la tête; refroidissement et driver du moteur direct drive inclus.