LeLutin

J'ai également rencontré ce problème lors de mes tests sur les premières versions de firmware Dagoma disponibles sur dist.dagoma.fr. Sur une suggestion de @Sancho, j'ai recalibré les paramètres thermiques (PID) de l'imprimante avec une commande M303 E0 C8 S200, qui effectue 8 cycles de montée en température à 200°. Cela permet d'adapter l'algorithme de régulation thermique du firmware au plus près des caractéristiques physiques de votre imprimante et de l'usure éventuelle des composants. Les nouveaux paramètres sont consultables par une commande M503 et peuvent être sauvegardés en EEPROM par une commande M500. Plus de souci depuis.

OK, merci pour l'info.

@Morpheus : je te demande ça parce que de base le Marlin 1.1.0 RC5+ refuse de se compiler avec un IDE < 1.6.0 avec un message d'erreur. On peut contourner simplement cette vérification?

@Morpheus : tu arrives à compiler un Marlin 1.1.0 RC5 et + avec l'IDE 1.0.6?

@Sancho : Eh oui, c'est pour la Melzi de notre Dago

@Demoniac : le SSR (ou un power expander) n'est pas strictement nécessaire en 12V, tu peux alimenter directement ton heatbed avec le Mosfet de la Melzi. Mais certains on eu de problèmes de surchauffe et je pense que passer plus de 10A dans le connecteur d'alim de la Melzi, c'est pas top. Par contre c'est obligatoire pour alimenter en 24V. PS : j'ai pris un plateau alu plua léger que celui d'origine (http://www.banggood.com/Anodized-Aluminum-Heated-Bed-Buld-Plate-For-3D-Printer-RepRap-Prusa-Makerbot-p-1003367.html) ainsi qu'un pareflamme emballé dans du kapton (http://www.castorama.fr/store/Ecran-pareflamme-PRDm211063.html?navAction=jump&isSearchResult=true)

Petit retour d'expérience sur l'installation d'un écran REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER avec les nouveaux firmwares Dagoma basés sur Marlin 1.1.0 RC6 (attention, encore en beta au moment de l'écriture du post). Ces nouveaux firmwares nécessitent d'utiliser un IDE Arduino > 1.6.0. J'utilise la version 1.6.11. De base, l'écran ne fonctionne pas correctement : Il s'avère que cela est dû à une évolution de la manière dont le compilateur optimise le code dans les nouvelles versions de l'IDE. Dans le fichier ultralcd_st7920_u8glib_rrd.h il y a une ligne qui force une optimisation du code par le compilateur : #pragma GCC optimize (3). En mettant cette ligne en commentaires, voici le résultat : Cerise sur le gateau, cela fait gagner 2K de mémoire programme. Je n'ai pas de mérite, la source de l'info est ici : https://github.com/MarlinFirmware/Marlin/issues/3815 Pour suivre la finalisation des nouveaux firmwares, c'est ici : @Sancho, peut-être une optimisation à intégrer dans la release finale? PS : même avec l'option, il n'y a plus assez de mémoire programme dans la Melzi . Pour gagner rapidement suffisamment de place, dans le fichier configuration.h, mettre les lignes suivantes en commentaire : //#define STRING_CONFIG_H_AUTHOR "Dagoma.Fr" //#define SHOW_BOOTSCREEN //#define STRING_SPLASH_LINE1 SHORT_BUILD_VERSION // will be shown during bootup in line 1 //#define STRING_SPLASH_LINE2 STRING_DISTRIBUTION_DATE // will be shown during bootup in line 2 Le croquis utilise 128 236 octets (98%) de l'espace de stockage de programmes. Le maximum est de 130 048 octets.

Une petite vérification de l'efficacité du paramètre U8G_I2C_OPT_FAST|U8G_I2C_OPT_NO_ACK pour l'initialisation du bus I2C (attention les yeux, séquence émotion, j'ai ressorti mon oscillo acheté en 1984 de la naphtaline, c'est increvable ) : u8g(U8G_I2C_OPT_NONE) => 100kHz (2 ms / carreau) u8g(U8G_I2C_OPT_FAST|U8G_I2C_OPT_NO_ACK ) => 400 kHz(2 ms / carreau) Donc efficacité validée de mon côté !

@falcom : j'ai aussi trouvé l'ergonomie de DagomaDoctor déroutante au premier abord : il ne faut pas "Glisser/Déposer" le fichier .hex dans le cadre où l'appli te demande de le faire, mais sur une d'une des deux listes déroulantes au dessus. Pas très intuitif , j'espère que Dagoma corrigera dans la version finale. Pour la compilation, tu dois effectivement mettre à jour ton IDE depuis la version 1.1.0-RC5 de Marlin. J'utilise la version 1.6.11. L'inconvénient, c'est que tu ne peux plus téléverser directement le .hex depuis l'IDE... apparemment un problème de timings USB de la Melzi. Il y a peut-être une solution via une mise à jour du BootLoader, mais j'ai préféré faire simple en utilisant DagomaDoctor. Pour retrouver le fichier .hex, c'est ici : D'ailleurs, si quelqu'un sait comment téléverser dans la Melzi avec un IDE récent, je suis preneur !

@CaliBx : L'optimisation de la compilation pourrait être une piste, mais il faut vraiment faire attention et être sélectif ! Notre Melzi n'ayant pas un OS temps réel, il se trouve que de nombreuses portions de code sont optimisées en termes de temps d'exécution pour se conformer aux timings des composants ; à un endroit, j'ai par exemple vu un système qui ajoute des commandes NOP en fonction de la fréquence du processeur ! Un changement d'option de compilation, et hop, c'est dans les choux. Certains ont ainsi eu des problèmes pour piloter leurs écrans FullReprapGraphic pour des problèmes d'optimisation qui étaient gérées différemment entre les versions de l'IDE Arduino. De base, seul le fichier ultralcd_st7920_u8glib_rrd.h se compile effectivement avec cette option, qui est intégrée dans le source par un #pragma GCC optimize (3).

@falcom : c'est ma config, j'utilise une alim 24V pour alimenter mon MK3 via un SSR continu qui est déclenché par la sortie BED de la Melzi. Ainsi le chauffage s'arrête en fin d'impression. La MK3 (comme la MK2b) sont bi-tension, il suffit de câbler les bonnes bornes. Le temps de chauffe du plateau à 50° est plus rapide que celui de l'extrudeur à 200° !

@Sancho : quelques pistes d'optimisation qui m'ont permis d'obtenir un meilleur résultat : Dans dogm_lcd_implementation.h, initialiser l'afficheur avec U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_FAST|U8G_I2C_OPT_NO_ACK) à la place de U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NONE). C'est censé initialiser le bus I2C à vitesse élevée (400kHz au lieu de 100kHz, voir par ex. ici : https://forum.arduino.cc/index.php?topic=277381.15). J'ai pas vérifié à l'oscilloscope. Toujours dans dogm_lcd_implementation.h, il y a une large place à l'optimisation du code dans lcd_implementation_status_screen() : tout l'écran est redessiné à chaque rafraîchissement , y compris les buses, le ventilo, le cadre de progression et la carte SD... Pas étonnant que ce soit consommateur de CPU ! comme il reste un peu de RAM, il faudrait comparer la nouvelle valeur à afficher par rapport à l'ancienne et ne l'afficher que s'il existe une différence. J'ai fait une rapide optimisation de l'affichage de la buse et du ventilateur : affichage seulement la première fois et plus d'animation du ventilateur. Dans ultralcd.h, modifier LCD_UPDATE_INTERVAL. J'imagine que c'est cette valeur que vous avez modifiée pour la passer à 5mn ; je proposerais de la mettre à 300 (3s) Avec ces quelques modifs, j'arrive à un résultat à peu près normal. Je pense qu'en poussant l'optimisation dans lcd_implementation_status_screen() et _draw_heater_status() on pourrait obtenir quelque chose d'acceptable. Qu'en penses-tu?

@Sancho Les bonnes nouvelles d'abord : j'ai relancé l'impression du Groot, sans aller au bout, voici le résultat : Donc plus de blobs ! Par contre, je pense que le rafraîchissement de l'écran toutes les 5mn c'est vraiment trop drastique Limite l'écran ne sert plus à rien. Je pense que ça passerait difficilement auprès des utilisateurs. Mais le point positif c'est que cela confirme que le temps de rafraichissement de l'écran est trop long pour un traitement correct des moteurs pas à pas (ou alors que le processeur n'est pas assez puissant...). Les pistes seraient donc pour moi : Baisser la fréquence de rafraichissement, mais pas autant : 2 à 3 secondes seraient acceptables Minimiser les infos rafraichies à chaque itération, quitte à ne pas tout rafraichir à chaque fois. Je vais regarder si possibilité d'accélérer l'I2C ou d'utiliser une autre librairie que U8glib genre Adafruit.

@Sancho : merci, j'essaye ce soir (y'a encore quelques obligations diurnes... )

@Sancho : bon courage à toute l'équipe, nous attendons vos productions avec impatience ! Et ma proposition d'aide pour des tests tient toujours. [HS] @Wrmaeleun : autant le N&B n'était finalement pas si gênant que ça (je pense que l'on compensait largement par l'imaginaire dans nos têtes), autant l'arrivée de la 3ème chaine était une bénédiction car avec seulement deux chaines d'état, je ne vous raconte pas l'éclate... Mais bon tous ça fait discours de vieux combattants

@Djdirtboy : je pense que tes problèmes viennenent des Gcode de démarrage. Tu dois encore avoir des décalages d'offset à ce niveau dans les scripts de Cura 15 et 2.1.3 : as-tu encore des commandes G92 Znnn après un G28Z ou un G29? Si oui, essaye de les mettre en commentaire car ce décalage de référentiel vient s'ajouter à celui que tu as défini dans DagomaDoctor.

Pour les 2 ventilos, n'oubliez pas l'add-on de DAL sur nos disco V1 qui permet de refroidir capteur et objet imprimé, et que j'utilise avec bonheur depuis plusieurs mois : http://www.thingiverse.com/thing:1233309

@Wrmaeleun, tu avais déjà bien de la chance avec le Minitel ! Moi c'était la photocopie de photocopie où on s'arrachait les yeux, ou alors summum du luxe, le databook que l'on avait quémandé chez un fabricant de composants

Ou éventuellement réutiliser le code M226 qui fait déjà cela très bien, à condition qu'il soit intégré dans ton firmware. M226 P<pin> S<mode> If S == 0, then M226 will wait for the pin to go LOW. If S == 1, then M226 will wait for the pin to go HIGH. If S == -1, then M226 will wait for the pin to change from its current value. Je suis preneur du résultat !

Bon, eh bien comment dire ... y'a pas photo ! ou plutôt si : Je vous laisse deviner sur quel FW la Discoled est activée et sur lequel elle ne l'est pas... Donc malheureusement, le problème est toujours présent. En fouillant un peu sur le net anglosaxon, on trouve pas mal de personnes qui ont rencontré ces problèmes sur Marlin avec un écran écran graphique I2C ; en synthèse, le consensus se fait sur un problème de performances, avec l'interface I2C qui n'est pas assez performante et / ou la librairie graphique u8glib qui n'est pas optimisée / adaptée pour supporter le pilotage temps réel requis par les moteurs de l'imprimante. Plusieurs pistes ont été explorées, avec plus ou moins de bonheur : De base I2C est à 100kHz ; en allant modifier des paramètres dans l'interface, il semblerait possible de passer à 400kHz, mais pas sûr que notre Melzi le supporte... Un courageux s'est apparemment attelé à à l'optimisation de l'interface SPI de la u8glib, avec pas mal de succès semble-t-il. Mais pas l'interface I2C. Il y a des volontaires? Ou bien pour faire un test avec un écran sur interface SPI? Il y a également des optimisations possibles pour baisser la fréquence de rafraichissement de l'afficheur (10Hz par défaut), minimiser la quantité d'infos rafraichies, ... Mais après, on peut se demander quel est l'intérêt d'un afficheur Ou des solutions plus radicales, comme revenir à un écran LCD en mode caractères. J'ai bien l'impression que la solution (si tant est qu'elle existe !) sera probablement complexe à finaliser. Bon, de mon côté, je pense que je vais repartir de ce nouveau FW sans Discoled et réinjecter mon code de pilotage d'un écran 7 segments. Perso, cette petite Dago française est une vraie réussite : je retourne en adolescence en bidouillant dans tous les sens . Et maintenant avec Internet sous la main, c'est tellement cool ! à l'époque, on se demande encore comment on faisait... Allez bon courage à toute l'équipe Dagoma, et n'hésitez pas à me contacter si vous avec des trucs à tester.

@Sancho : pas de bonnes nouvelles de mon côté, je pense que je m'étais enflammé trop vite... Alors oui, la DISCOLED était active. Mais voici le résultat avec l'impression d'une pièce aux surfaces plus complexes : on retrouve malheureusement les blobs. A noter que là j'étais en impression depuis la carte SD. Je reflashe avec un FW sans DISCOLED et vous tiens au courant.

@BourrinDesBois : voici la config des pins le la Melzi : A1 correspond à D30 en arduino, etc...

@Wrmaeleun : pour ma part, aucun reproche bien au contraire ! dist.dagoma.fr et DagomaDoctor sont en bêta, c'est bien indiqué dessus ; donc pas de support et c'est à nos risques et périls. Dommage que tout le monde n'ait pas joué le jeu en appelant le support Dagoma alors que l'on essayait d'avancer collaborativement sur le forum... Comme quoi ce serait intéressant que Dagoma formalise un peu plus un process de bêta test qui permettrait à tous les volontaires de participer et de faire avancer ensemble le schmilblick.

@Sancho: quelques retours après les tests de la journée (2 deux meubles IKEA montés + courses + tout le reste du samedi ). Bon, j'ai fait mon boulet sur le premier retour : en fait les blobs étaient dus à une option du slicer que j'avais oubliée d'activer (avoid crossing outline for travel movements) et correspondaient aux déplacements de la tête sans impression qui repassait sur des zones déjà imprimées... Voici le résultat : Il reste encore quelques différences par rapport à l'ancien FW. A titre de comparaison, j'ai réimprimé le requin avec le FW "officiel" actuellement dispo sur le site ; les blobs au bout de la nageoire n'apparaissenent pas : J'avais déjà remarqué que les blobs avaient une propension à apparaitre dans les courbes à faible rayon. Donc bravo, je pense que nous avons quelque chose de fonctionnel !!! Nous pouvons tous vous remercier pour le travail accompli ! Si vous êtres preneurs de suggestions d'améliorations pour le DagomaDoctor, j'ai bien quelques idées : Intégrer le PID autotune de l'extrudeur et du bed avec sauvegarde Recalage du centre du plateau via un M206 pour les problème de décalage en X et Y (je dois faire un G92 X97 Y102 après un G01 X100 Y100) Affichage de la versionMarlin + custo Dagoma (M115) Diagnostic de fiabilité de la mesure Z via un M48 Intégrer un timeout systématique sur toutes les communications Barre de progression sur le flashage.

Bon, malheureusement, j'ai bien l'impression que les problèmes de blobs ne sont pas réglés. A noter que ceux-ci ne correspondent pas aux changements de couches car j'ai défini un point fixe pour le début de chaque couche dans le slicer (le haut de l'aileron). Demain je refais le même avec le FW d'origine. PS : point positif : impression d'1h en USB sans plantage (plusieurs exemplaires simultanément) PS2 : l'alignement vertical de certains blobs me fait dire que leur positionnement n'est pas tout à fait aléatoire...