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