Civade.com

Découverte de la carte :

En plus de la carte SKR 1.4 Turbo, j'ai fait l'acquisition d'un LCD TFT24 V1.1, du booster d'alimentation DCDC Mode V1.0 et de l’extension Wifi ESP01s pour environ 35 euros. Mais qu'est ce qu'on peut en attendre? Une petite visite s'impose...

En comparant les schémas et implantations, la version 1.4 n'apporte que peu de changements par rapport à la version 1.3:

• Processeur jusqu'à 120Mhz (version turbo)
• support d'un booster d'alimentation additionnel pour générer du 5V pour les périphériques qui le nécessitent (Neopixel, Bltouch, TFT), et ainsi éviter de 'tirer' trop sur le convertisseur intégré.
• Support d'un module wifi ESP01
• Support de 2 ventilateurs fixes supplémentaires (en 24V)
• Support de la carte UPS (protection coupures d'alimentation)
• Support d'un BL Touch (implantation connecteur servo revu + nouveau connecteur Probe juste à côté)
• Suppression de la diode de protection en série sur l'alimentation USB qui consommait quelques dixièmes de volts...
• Reroutage partiel de la carte

Tout d'abord, sur le plan alimentation, la carte est plutôt bien équipée :

• Alimentation unique jusqu'à 24V (360W max), avec une LED rouge de témoin d'alimentation. 24V c'est top pour maximiser la vitesse de déplacement des moteurs, et sur une imprimante 3D permet de limiter le courant dans le lit chauffant. Donc un bon point....
• Protection en tête de carte, par 2 fusibles à lame 'automobile', l'un de 20A pour le lit chauffant et l'autre de 10A pour les têtes et le reste de l'électronique.
• Multiples sous protections par fusibles sur les différents étages (sous le 10A)
• Alimentation à découpage intégrée pour générer du 5V, avec fusible réarmable de 2.5A (T250) intégrés à la carte. Pas besoin d'une double alimentation, ou d'une alim via l'USB, la seule tension primaire suffit...
• Alimentation linéaire intégrée pour générer du 3.3V à partir du 5V avec fusible de 750ma.
• Alimentation à découpage optionnelle (DCDC Mode V1.0) pour générer du 5V sous 'forte puissance' à partir du 24V. Elle complémente celle déjà présente en interne et lorsque présente alimente le port LEDS neopixels, l'écran TFT et le servo/BL Touch. Une LED verte s'allume sur le convertisseur lorsqu'il est alimenté. Un cavalier permet de configurer ces 3 alimentation sur le convertisseur si présent, ou en prélevant sur le rail 5V interne. Cette carte ne serait nécessaire que si l'on compte consommer de façon significative ( >500 mA) sur le LCD/Servo/Leds externes.
• Cavalier pour alimenter la carte par l'USB (pour la mise au point logicielle, sans alim 24V branchée) ou par le convertisseur 24v>5V (nécessite de brancher l'alimentation de la carte)

La SKR 1.4 possède un grand nombre d'entrées sorties :

• Processeur à 100 mhz (SKR 1.4) ou 120 mhz (SKR 1.4 Turbo)
• Bouton de reset intégré
• Port USB natif, avec support en tant que disque (pour les mises à jour et la config) et liaison série (pour l'envoi de gcode)
• Carte SD intégrée, permettant de faire les mises à jour et le stockage de fichiers (c'est le disque visible de l'USB). Un LED verte s'allume lorsque la carte SD est présente.
• 2 connecteurs HE10 à 10 broches (EXP1 et EXP2) pour raccorder un afficheur LCD de type "Reprap Discount Smart LCD Controler", avec carte SD et encodeur de panneau, on un afficheur de type
• Connecteur série dédié au support d'un afficheur TFT et son alimentation (sur le port série 0)
• Commande de 5 moteurs pas à pas, dont l'un (le Z) en double sortie (pour les imprimantes 3D le nécessitant, comme les type Prusa I3)
• Nombreuses options de pilotage des moteurs: Step/Dir, SPI, série, avec support contrôleurs de type "Pollolu"
• Support des fins de course logiques "sensorless" avec les contrôleurs de moteur pas à pas adaptés (ex: TMC2130) ou matériels sur les 3 à 6 entrées prévues
• 1 sortie de puissance 20A sur MOSFET en PWM pour le lit chauffant, avec LED témoin verte.
• 2 sorties de puissances jusqu'à 10A sur MOSFET en PWM pour les deux chauffage de tête, avec LED témoin verte.
• 1 sortie ventilateur jusqu'à 1A, commandé en PWM par MOSFET (pour le refroidissement de la pièce sur une imprimante 3D), avec LED témoin verte.
• 3 sorties ventilateurs à tension fixe de 12 ou 24V (ex : pour le refroidissement des têtes sur une imprimante 3D)
• 1 sortie Servo (3 broches) commandée en PWM pour palpeur de lit chauffant, avec optionnellement alimentation boostée.
• 1 sortie pour commander une rampe de LED en Neo-pixel (3 couleurs) avec optionnellement alimentation boostée.
• 3 entrées analogiques pour thermistances de mesure de température, avec filtrage intégré
• 6 entrées digitales pour les fins de course ( sur 5 axes) et l'entrée détection de présence de tension d'alimentation (pour l'onduleur optionnel)
• 1 entrée "probe" pour capteur de longueur d'outil ou palpeur de lit chauffant.
• Connecteur HE10 à 8 broches pour raccorder directement un ESP01S et ajouter le support du Wifi
• Connecteurs Dupont pour port SPI, I2C, Software debugger
• Connecteurs Dupont sur chaque axe (X-CLS, Y-CLS, etc..) pour connecter un driver pas à pas externe (avec tous les signaux y compris le 24V). Ils sont directement compatibles avec les "Closed Loop Stepper" (contrôle en boucle fermée) de la marque, mais on peut y raccorder n’importe quel contrôleur externe.

A l'exception des connecteurs mentionnés ci dessus comme étant des "Dupont", tous les autres sont des connecteurs "JST". Les broches étant un peu plus petites, il n'est pas recommandé de mettre des connecteurs Dupont femelle dessus sous peine de gros faux contacts.. Mais on peut trouver des kits JST-XH sur Aliexpress avec une centaine de connecteurs mâle et femelle et les broches à sertir pour quelques euros. Ce n'est donc pas un gros soucis. Autre intérêt, les connecteurs JST ont un verrouillage, ce qui empêchera un arrachement intempestif... Par contre, si vous prévoyez d'acheter des connecteurs JST en kit, la pince à sertir n'est pas un luxe...

Le schéma de la SKR 1.4 est disponible ICI ce qui fait qu'on peut lever toute ambiguïté lorsque l'on adapte un logiciel dessus. C'est nouveau chez Bigtreetech.

Sur le papier, il ne manque donc pas grand chose. J'ai noté :

• Ce serait bien d'avoir la possiblilité de commuter les ventilateurs en 12/24V ou 5V
• Entrées température uniquement prévues pour mettre des thermistances (résistance de tirage de 4.7K et entrée 3.3V). Ceci empêche de brancher des thermocouples, qui délivrent directement une tension et n'ont pas besoin de la résistance de tirage, mais d'une adaptation de niveau 5V>3.3V. C'est contournable, mail il fait bidouille (dessouder la résistance et mettre un pont diviseur).
• Sorties Step ne sont pas toutes sur le même port, ce qui empêche la compilation de GRBL pour LPC1769
• Même remarque pour les sorties Dir.
• Pas de SPI matériel routé sur le LCD. Impossible de l'utiliser sur Smoothieware sans adaptateur à faire soi même ou modification de Smoothieware pour ajouter le support d'un SPI "logiciel". Nous verrons plus loin qu ec'est contournable.
• Liaison série 0 sur le LCD et 3 sur le Wifi. Impossible d'utiliser la liaison série 0 sur le Wifi. Une configuration par cavalier aurait pu permettre de l'utiliser sur Smoothieware. C'est aussi contournable avec une petite bidouille.

Fonctionnement sous Marlin:

J'ai fait les tests d'intégration avec succès sur la dernière version de Marlin 2 disponible sur le Git : https://github.com/MarlinFirmware/Marlin. Elle intègre directement une configuration pour la SKR 1.4 / Turbo ( MOTHERBOARD BOARD_BTT_SKR_V1_4_TURBO ) . Tout fonctionne sans soucis. L'intégration du Wifi est assez facile (voir https://www.civade.com/post/2020/09/22/Ajouter-le-support-du-Wifi-sur-une-imprimante-3D-fonctionnant-avec-Marlin-2 ).

L'écran fonctionne aussi bien en mode "touch" qu'en mode émulé Reprap Discount Graphic LCD Controler, ainsi que la carte SD externe. Idem avec les Neopixel ou le BL touch qui peut être raccordé sur l'entrée sonde + la sortie servo. C'est juste quand on veut le Wifi ET l'écran TFT et la liaison série USB que c'est plus sport.

Malheureusement, Marlin n'est pas le meilleur candidat pour une découpe laser, c'est même le pire. Il n'est en effet pas très performant en terme de vitesse de traitement de gcode, et ne gère pas la modulation de la puissance du laser pendant les accélérations / décélérations, ce qui a une fâcheuse tendance à brûler les angles lors d'une découpe. Enfin il est incapable de générer un PWM a 25Khz, ce qui est indispensable pour un K40. Ce dernier point peut encore se contourner avec un filtrage sur le PWM en vue de produire une tension analogique.

L'auteur du logiciel de pilotage laser Lightburn écrivait au sujet de Marlin en 2019 :

I’ve tested with Marlin 1.9, I believe, and other users have reported using 2.0 without issues, but I’ll warn you that I’m not strong with Marlin and much of the Marlin support in LightBurn is a direct result of user suggestions.

Most people use the first fan output for the PWM of the laser, though that can be changed in the device options in LightBurn if you need to use a different PWM index, and the baud rate is configurable as well (250,000 is favored because it’s nicely divisible by the clock rate, where 230,400 is not).

If you find the configuration daunting, I’m not going to be much help there as Marlin is not my forte - I have a good amount of experience with Grbl and Smoothieware (even having delved into the code for both of those), but no real experience with Marlin.

Il indique aussi :

When I say “ramped power output” I mean velocity-modulated PWM, ramping the PWM up and down as the velocity increases, then decreases for corners. Smoothieware and GRBL another support this, but none of the others as far as I’m aware.

C'est donc plié pour Marlin si on veut ce support de la modulation de puissance pendant les accélérations... Next!

Fonctionnement sous grbl-lpc:

Sur GRBL adapté pour LPC par Claudio Prezzi ( https://github.com/cprezzi/grbl-LPC/releases ) cela va être encore plus rapide. Les cartes SKR ne sont tout simplement pas supportées. En effet, seules sont supportées ( Smoothieboard, Cohesion3D, Azteeg X5, MKS SBASE) les cartes dont les signaux step et sont sur le même port d'entrée sortie. C'est d'ailleurs grâce à cette contrainte et à des manipulations de bits sur un même port que GRBL est si rapide...

Le brochage de la SKR 1.4 ne respectant pas ce standard, c'est donc aussi plié.. Next!

Smoothieware :

Un petit mot sur la communauté et l'écosystème Smoothie

Les concepteurs de Smoothieware on fait un choix, celui de ne pas utiliser de liaison émulée (à l'exception de celle qui pilote une broche de CNC en RS485), principalement car il n'y en a pas besoin sur une carte Smoothieware, mais peut être aussi pour des raisons de performance. Du coup, ce qui pourrait marcher avec un SPI 'software' ou un port série 'software' ne fonctionne pas :

• Écran LCD Reprap discount Smart LCD controler (SKR 1.3 et 1.4).
• Contrôleurs pas à pas en mode 'SPI' (SKR 1.3 et 1.4)
• Contrôleurs pas à pas en mode 'série' (SKR 1.3 et 1.4)

En fait, tout est prévu pour supporter les Smoothieboard. Si ça marche pour d'autre cartes, tant mieux pour vous... mais si il faut supporter des cartes avec des fonctionnalités spécifiques (ex : SKR et le support d'un grand nombre de drivers de moteurs pas à pas), on se heurte à un quasi mur de la part des 2 mainteneurs principaux.

Ils argumentent sur le fait qu'il n'y ait plus de place dans la mémoire du micro contrôleur (admettons.. mais les compilations conditionnelles ça existe.. et sont déjà utilisées pour distinguer la version CNC de la version imprimante 3D) et qu'ils ne veulent pas faire de support pour des cartes chinoises... Sous entendu vous n'avez qu'à acheter une Smoothieware. C'est déjà limite limite de coupler le hard au soft...

Cette haine des autres cartes (chinoises notamment) en est au point ou ils les appellent 'contrefaçons', n'intègrent pas les patch request que les gentils développeurs leurs proposent, ou alors dans des branches annexes. C'est dommage et ce n'est clairement pas l'esprit du logiciel libre, dont il s'agit plus de fabriquer un bien commun avec des contribution communes que de servir des intérêts particuliers, tout en respectant a propriété intellectuelle.

Cette notion de contrefaçon est d'ailleurs très discutable, car si au départ elle était alimentée par le fait que les premières cartes conçues pour faire fonctionner Smoothieware (MKS) ne publiaient pas les schémas, cela a un peu changé, et certaines - comme les SKR - publient les leurs et amènent des innovations (ex : support de pléthore de contrôleurs moteur pas à pas, d'afficheurs supplémentaires, leds, etc..) sur un reroutage complet du circuit imprimé (optimisations??). Est on encore face à une contrefaçon dans ce cas? Il me semble que non, c'est d'ailleurs l'esprit du libre que d'améliorer à chaque itération.

Si Smoothie considère comme contrefaçon une carte comme la SKR 1.4 (dont le schéma est publié...) on peut aussi considérer que Smoothieware est une contrefaçon :

• de LAOS, qui a utilisé pour la première fois de processeurs LPC176x et Mbed sur une carte de pilotage de machine à commande numérique (dédiée laser). C'était en 2010.
• de RAMPS (Reprap Arduino Mega Pollolu Shield) pour l'architecture, tous les étages de puissance, les méthodes de mesure de température
• de Pollolu, pour choix de contrôleurs pas à pas basés sur des composants d'Allegro Semiconductors
• etc...

Et sur le fond, l'open hardware et les logiciels libres n'inventent que très rarement tout, mais procèdent par itérations successives, dont Smoothie (et spécialement Smoothieware) n'est qu'une itération. Je me demande si il n'y a pas un sérieux manque de culture Libre de la part des développeurs. En effet, s'arque-bouter sur un développement fait il y a près de 7 ans, qui n'a pratiquement pas bougé depuis, et qui n'annonce rien de révolutionnaire, c'est presque le début de la fin.

OK, c'est un troll, mais pour vous faire réfléchir sur le sujet, quand Arthur Wolf, son concepteur, écrit lui: http://smoothieware.org/troubleshooting#what-is-wrong-with-mks, en mettant tout le monde dans le même panier, on peut légitimement se demander si il n'est pas à côté de la plaque, même avec sa licence GPL V3 et son logo OSHW. Qu'est ce qui empêche de fabriquer une carte OSHW à l'identique? Ou de prendre le schéma et le rerouter? D'un point de vue légal, pas grand chose....

De plus il y a quelques incohérences dans le modèle. Par exemple, le fait que Cohesion3D ne publie pas ses schémas n'a pas l'air de le déranger. Contribuent t'ils financièrement à Smoothie? C'est donc de l'open source à 2 vitesse, ceux qui payent une licence et les autres? D'ou ça sort cette licence? Dans ce cas, les contributeurs sont ils rémunérés et comment? Je vous laisse méditer là dessus, mais il est clair qu'on est dans les limites du modèle. Si les cartes Smoothieware ne valaient pas 200 euros, cela ne laisserait pas un boulevard aux solutions alternatives... Autant directement mettre le tout sous licence MIT ou creative common CCBYSA (partage à l'identique, mais pas d'exploitation commerciale), cela serait plus clair...

J'ai creusé par exemple l'amélioration proposée par Cohésion3D/LightBurn sur Smoothieware, visant à intégrer des commandes Gcode spéciales pour traiter les variations rapides de puissance d'un laser pour faire de la gravure en nuance de gris avec le logiciel Lightburn. Leurs modifications sur le code sont assez difficile à trouver ( chercher "SmooChanges.zip" dans https://forum.cohesion3d.com/t/improved-raster-speed-firmware-update-for-cohesion3d-boards/850/12 ). Ceci a été publié le 16 Juillet 2019 .

Le développeur (LightBurn) a tenté de réinjecter les modifications sur Smoothieware, ce que l'on retrouve dans un échange sur le Github de Smoothieware ( https://github.com/Smoothieware/Smoothieware/issues/1446 ). Je vous la fait courte et en français, mais en gros les développeurs de Smoothie disent qu'il ne l'intégreront pas car cela viole les standards du Gcode. Plus loin ils disent aussi que pour demander l'intégration du code il faut faire un Pull Request (NDLR: méthode pour proposer une amélioration de code dans Git), ce à quoi l'auteur de la modification répond "pourquoi faire Pull Request si vous ne l'intégrerez pas?"... Dialogue de sourds... Du coup, pas de pull request, et du code source uniquement disponible sous forme de quelques fichiers modifiés sur une Dropbox, sans savoir à partir de quelle version cela part. Pas très simple à manipuler. Mais je ne jetterai pas la pierre au concepteur de Lightburn, il s'est fait jeter avant même de pouvoir proposer quoi que ce soit...

Partant du principe que la méthode de demande d'une amélioration conditionnera le fait qu'elle soit considérée, je me fade la doc pour voir comment intégrer un PR et j'en propose un avec une amélioration visant à ajouter le support d'un SPI logiciel pour les LCD ( https://github.com/Smoothieware/Smoothieware/pull/1494 ). En tout la totalité de a manip m'a pris 3 heures.

Le PR a été totalement clos en moins de 15 minutes (et le tout à 23h00...) , sans laisser la possibilité de poser par exemple des questions sur comment contourner la contrainte exprimée, probablement très légitime (no wait() ). C'est très violent, et très loin du "Code of conduct" ( https://github.com/Smoothieware/Smoothieware/blob/edge/CODE_OF_CONDUCT.md ) fixé par les deux développeurs eux même. Ou se trouve la bienveillance et le respect attendus?

Arthur (Wolf), une solution aurait pu être de laisser ouvert le PR, d'exprimer vos désidératas et pourquoi pas des pistes pour les modifs de code de façon à ne plus avoir ces wait() qui vous gênent tant, et attendre que je propose un PR modifié tenant compte de vos remarques... De la même manière, la modif "Smoothie Clustering" aurait pu être intégrée avec une compilation conditionnelle.. (CNC=1 CLUSTERING=1), avec les réserves sur son usage? Ca donne pas très envie de faire des efforts pour vous. Heureusement que Linus et les contributeurs historiques de Linux ou de la FSF n'étaient pas aussi sévères, on n'aurait surement pas le GNU/Linux que l'on connait aujourd'hui et qui a juste changé le monde de l'informatique...

Peut être que le fait que ce PR soit pour les cartes SKR/Bigtreetech, rappelle que les schémas soient dispos (c'est pas closed source...) les a énervés??? Chatouilleux les types. Voila ce a quoi peut mener l'open source quand managé par des intégristes, les intérêts personnels ou une combinaison des 2 . C'est lamentable. Et sur le sujet, j'en connais un rayon, puisque j'ai opéré une SSLL (Société de Services en Logiciels Libres) pendant près de 20 ans, monté un Fablab, et fait un paquet de contributions en hard et en soft, sous différentes licences..

Donc bien qu'un assez beau logiciel, je ne parierai pas sur le fait que Smoothie soit la solution pour les 10 ans à venir. Alors que pour Marlin, qui a su passer en 32 bits, adapter on support à des dizaines de processeurs différents (contre 1 sur Smoothie), et près d'une centaine de cartes, oui... Et même si la Smoothie V2 arrive, il n'est pas sur qu'elle remporte le succès attendu. Entre son prix, et le fait que le processeur ne tourne qu'à 200Mhz, il n'est pas sur que la présence d'un FPGA suffise à elle seule à justifier un emploi généralisé de la version pro. Une erreur de casting?

Néanmoins, je vais poursuivre, car une fois l'intégration réalisée sur ma découpe laser K40, je ne vais pas y toucher pendant un moment.. et il sera toujours temps de revenir sur marlin ou un autre firmware si d'ici là la situation change. De plus, le cout et la notoriété des cartes SKR fait que d'autres pourraient être intéressés par ma modification.

Mise en œuvre

C'était ma première expérience de Smoothieware, et j'ai pas forcément trouvé le démarrage simple. Après avoir flashé le firmware, on ne sait pas du tout si cela fonctionne ou pas.. En effet, même les éventuels messages d'erreur liés à la lecture / compréhension du fichier de config ne s'affichent que sur le port série matériel 0 (UART0). De plus, certains configuration font carrément planter le firmware, comme par exemple de laisser activé l’Ethernet sur une carte qui n'en dispose pas.. Mais nous allons voir que rien de tout ceci n'est insurmontable..

Programmation de la carte

La programmation de la carte est assez simple puisqu'il suffit de copier le fichier "firmware.bin" sur le lecteur disque ou est monté la carte SD. Un simple reboot provoque le flashage. Des version pré-compilées sont disponibles ICI. Pour une découpe laser, et pour les premiers essais, il faut prendre la version firmware-cnc.bin ou firmware-cnc-latest.bin , et la renommer en firmware.bin avant de la copier sur le disque USB et d'appuyer sur le bouton reset. Le boot du processeur se charge du reste, en détectant la présence du fichier et en flashant la mise à jour. Il sauve également l'ancien firmware sur la carte SD au cas ou l'on ait besoin de revenir en arrière.

Configuration du firmware

Sur Smoothiware, une caractéristique unique est que la configuration du firmware se fait par un simple fichier texte, nommé config ou config.txt et placé dans la racine de la carte SD. Les modifications sont donc possible par le PC en éditant le fichier directement sur le lecteur monté par la carte et en redémarrant la carte pour qu'elles soient prises en compte. On peut aussi tout à fait extraire la carte SD et la lire directement sur un ordinateur.

Lors des éditions sur le fichier de config, il faut faire très attention à ce que les lignes dépassent pas 132 caractères, et on y est vite avec des commentaires.. J'en ai fais les frais lors des premiers essais, mon fichier de config n'était pas pris en compte... Une astuce consiste à utiliser un éditeur de texte moderne (ex notepad++) et à utiliser les tabulations pour aligner les commentaires sans exploser le nombre de caractères. (une tabulation = 4 espace...). Pour plus de clarté, les tabulations peuvent être affichées avec "Affichage / Symboles Spéciaux / Afficher les blancs et les tabulations". Cela aide pour nettoyer le fichier et donne ceci (cliquer pour zoomer):

La fabrication du fichier de configuration est une opération longue et fastidieuse. Il faut en effet reprendre les entrées / sorties du schéma et reconfigurer chaque fonction supportée par Smoothie.

Cliquez sur le schéma pour l'agrandir :

La première chose à faire dans le fichier de config est de désactiver l'ethernet pour éviter le plantage de la carte :

network.enable   	false		# Enable the ethernet network services

Ensuite on peut commencer à configurer....

Voici le fichier config.txt résultant pour une K40. Il est abondamment commenté pour permettre de comprendre ce qui a été fait. Il faudra bien sur le renommer en config.txt avant de le copier sur la carte SD. A noter qu'il ne se présentera pas bien dans un navigateur web, car les tabulations sont traitées comme faisant 8 caractères, contre 4 dans un éditeur de code moderne (ex: notepad++).

Une liaison série additionnelle pour comprendre ce qui se passe

Mettre un adaptateur USB / Série 3.3V sur la sortie écran (UART0) peut être une très bonne idée, car ce port résistera au reboot, et permettra d'afficher les éventuelles erreurs détectées dans le fichier de config dès le tout début du démarrage, contrairement au port série émulé sur USB de la carte .

Comme indiqué ci dessus, L'uart 0 (TX0, RX0) sort sur le port destiné au branchement du TFT. Un simple adaptateur FTDI232 ( ex : https://fr.banggood.com/3pcs-FT232RL-FTDI-3_3V-5_5V-USB-to-TTL-Serial-Adapter-Module-Converter-Geekcreit-for-Arduino-products-that-work-with-official-Arduino-boards-p-1633685.html ) suffit pour disposer de cette liaison de debug. Penser à le mettre en 3.3V à l'aide du cavalier, avant de le raccorder à la SKR... Tx sur RX et RX sur TX, et un fil de masse et le tour est joué.

L'autre solution est de mettre en place un module wifi. Cette solution est détaillée ci dessous.

Ce qui marche en standard, et ce qui ne marche pas.

Nous avons vu précédemment pourquoi Smoothieware est à la traine pour supporter des cartes comme la SKR 1.4. Le bilan à priori ne sera pas très bon :

• Bien que le hardware supporte pléthore de drivers, il n'est possible de mettre que ceux qui sont en Step/Dir (A4988, DRV8825, LV8729, ST820, etc..)
• Aucun afficheur LCD ne fonctionnera sans recâblage ou logiciel modifié. Le broches du SPI de l'écran ne sont en effet pas câblées sur un SPI matériel du LPC176x.
• Le connecteur Neopixel ne servira à rien, ou en tout cas pas pour des leds neopixel (pas de driver).
• Toutes les autres entrées sorties sont fonctionnelles.
• Et bonne nouvelle, la carte SD externe, peut marcher en même temps que celle interne, n'étant pas sur le même port SPI.

Pas d'écran: on est dans le noir...

Comme vu précédemment, l'écran avec Smoothieware ne peut fonctionner que lorsqu'il est câblé à un SPI matériel. Or sur la SKR 1.4, les broches MOSI et SCK de l'écran sont branchée à des entrées sorties générales.

Il y a 2 solutions pour le faire fonctionner :

• Faire un adaptateur qui va utiliser le même SPI que la carte SD. Cela sera compatible avec un firmware standard. La différentiation entre l'écran et la carte SD se fera pas le Chip Select, câblé à une broche différente.
• Modifier smoothie pour ajouter le support d'un SPI logiciel. Dans ce cas pas de recâblage, toute l’adaptation est faite par logiciel, qu'il faudra modifier.

En ce qui concerne la première solution, en voici le schéma (cliquer pour agrandir). Cela consiste à utiliser le SPI0 (utilisé par la SD) aussi pour le LCD. C'est grâce au chip select (LCD_CS / SD_CSEL) que smoothie pourra écrire sur l'un ou l'autre des périphériques.

Une fois câblé cela donne ceci:

Et l'adaptateur en situation, avec la carte, et l'écran fonctionnel (ainsi que la carte SD, le buzzer et l'encodeur de panneau) sur une version officielle de Smoothieware :

Bien sur il faut adapter la configuration (dans config.txt), pour refléter le câblage de l'adaptateur. A noter que sur mon écran j'ai du réduire la fréquence de pilotage du LCD (panel.spi_frequency) à 100 khz au lieu de 1 mhz, sinon il y avait des erreurs de transmission. C'est probablement lié à la longeur des nappes 10 broches qui relient la carte au LCD.

############################################
# For SPI0 hardwired to lcd via a custom adapter
panel.spi_channel                     0      # Spi on Hardware channel 0
panel.spi_cs_pin                   1.19      # SPI chip select     ; GLCD EXP1 Pin 4
panel.spi_frequency              100000      # Needs to reduce spi frequency for emulated rrdglcd
                                             # default : 1 000 000 Hz

panel.encoder_a_pin                3.25!^    # Encoder pin         ; GLCD EXP2 Pin 3
panel.encoder_b_pin                3.26!^    # Encoder pin         ; GLCD EXP2 Pin 5
panel.click_button_pin             0.28!^    # Click button        ; GLCD EXP1 Pin 2
panel.buzz_pin                     1.30      # Pin for buzzer      ; GLCD EXP1 Pin 1
#panel.back_button_pin             0.28!^    # Back button         ; GLCD EXP2 Pin 8
panel.encoder_resolution              4
panel.external_sd                  true      # set to true if there is an extrernal sdcard on the panel
panel.external_sd.spi_channel         0      # On SKR 1.4, wired to spi0 (free).
panel.external_sd.spi_cs_pin       0.16      # set spi chip select for the sdcard (or any spare pin)
panel.external_sd.sdcd_pin         1.31!^    # sd detect signal (set to nc if no sdcard detect)
panel.menu_offset                     1      # Some panels will need 1 here
panel.alpha_jog_feedrate           6000      # X jogging feedrate in mm/min
panel.beta_jog_feedrate            6000      # Y jogging feedrate in mm/min
panel.gamma_jog_feedrate           3000      # Z jogging feedrate in mm/min
panel.hotend_temperature            185      # Temp to set hotend when preheat is selected
panel.bed_temperature                60      # Temp to set bed when preheat is selected

La seconde solution est de faire une modification dans Smoothieware afin d'ajouter le support d'un SPI logiciel. C'est certes moins performant qu'un SPI matériel, mais suffit amplement pour l'affichage. Voici la modification, basée sur les sources du 23/10/2020 (dernier commit = "Added support for ABC (and E) axis for G2 and G3 "): rrdglcd.zip.

Il suffit de décompresser ce fichier et le placer dans Smoothieware\src\modules\utils\panel\panels\rrdglcd. Il ajoute une bibliothèque logicielle "SWSPI.cpp/h" , fork de celle de Ella Robotics (https://os.mbed.com/teams/ELLA-Robotics-Inc/code/SWSPI/ ) et modifie les fichiers RrdGlcd.cpp/.h pour ajouter le support du SPI logiciel.

Les broches de configuration du SPI logiciel sont encodées en dur ligne 155 de RRDGlcd.cpp (mosi = P1_18; miso = P1_21; sclk = P1_20;). Cette configuration est celle convenant à une SKR 1.3 ou 1.4. Ici aussi, réduction de la fréquence du SPI pour éviter les erreurs d'affichage.

Voici la solution en fonctionnement avec le logiciel modifié :

L'appel du SPI logiciel dans le fichier de configuration, se fait tout simplement en nommant le numéro de canal SPI "-1" (SPI logiciel) au lieu de "0" ou "1" (Numéro de canal spi matériel) :

############################################
# For Software SPI (unsupported hack on smoothieware)
panel.spi_channel                    -1      # Software spi mosi = P1_18; miso = P1_21; sclk = P1_20;
panel.spi_cs_pin                   1.19      # CS on SKR 1.4
panel.spi_frequency              100000      # Needs to reduce spi frequency for emulated rrdglcd
                                             # default : 1 000 000 Hz

panel.encoder_a_pin                3.25!^    # Encoder pin         ; GLCD EXP2 Pin 3
panel.encoder_b_pin                3.26!^    # Encoder pin         ; GLCD EXP2 Pin 5
panel.click_button_pin             0.28!^    # Click button        ; GLCD EXP1 Pin 2
panel.buzz_pin                     1.30      # Pin for buzzer      ; GLCD EXP1 Pin 1
#panel.back_button_pin             0.28!^    # Back button         ; GLCD EXP2 Pin 8
panel.encoder_resolution              4
panel.external_sd                  true      # set to true if there is an extrernal sdcard on the panel
panel.external_sd.spi_channel         0      # On SKR 1.4, wired to spi0 (free).
panel.external_sd.spi_cs_pin       0.16      # set spi chip select for the sdcard (or any spare pin)
panel.external_sd.sdcd_pin         1.31!^    # sd detect signal (set to nc if no sdcard detect)
panel.menu_offset                     1      # Some panels will need 1 here
panel.alpha_jog_feedrate           6000      # X jogging feedrate in mm/min
panel.beta_jog_feedrate            6000      # Y jogging feedrate in mm/min
panel.gamma_jog_feedrate           3000      # Z jogging feedrate in mm/min
panel.hotend_temperature            185      # Temp to set hotend when preheat is selected
panel.bed_temperature                60      # Temp to set bed when preheat is selected

Ce micro logiciel reste bien sur compatible avec le support du SPI matériel, et pourra aussi faire fonctionnner le LCD avec l'adaptateur décrit ci dessus. Pour recompiler le logiciel, le plus simple est de suivre le tuto : http://smoothieware.org/compiling-smoothie

La support de la carte SD, du buzzer, de l'encodeur de panneau est ok pour les 2 configurations, que j'ai testées.

Le module wifi ne fonctionne pas...

Le connecteur du module wifi utilise la liaison UART 3, et il nous faut l'UART 0... Ça peut se régler avec un petit hack matériel simple à réaliser. Il faut dessouder les broches TX et RX du module (les retirer complètement), et souder 2 fils se terminant par une boche femelle Dupont ou un connecteur JST 6 broches qui seront à brancher sur le connecteur du TFT.

Voici ce que cela donne :

Sur la programmation du module Wifi et sa configuration se reporter à mon post sur l'ajout de wifi sur une imprimante 3D. Il faut bien sur penser à choisir le bon protocole (Smoothieware au lieu de Marlin) dans le module wifi et la vitesse adaptée (d'après le fichier de config. Dans le mien, 250 000 bauds) pour que la communication se fasse avec le module wifi.

A noter que la broche Reset n'est pas cablée sur le support du module Wifi. C'est pas mal, car cela nous permettra de voir les messages de boot de la carte après un reset, dans l'interface web, le wifi n'étant lui pas rebooté. Voici ce que l'on voir après un reboot de Smoothieware dans l'interface web du module wifi. On voit notamment très bien la console avec les premiers messages envoyés par Smoothieware :

Smoothieware et une découpe laser K40

D'un point de vue logiciel

Logiciel de pilotage :

Le logiciel idéal pour piloter une découpe laser est LightBurn. Il est très complet et fonctionne avec Marlin, Smoothie et GRBL. Il n'est pas libre, et est commercialisé 40USD (35 euros), ce qui en fait une dépense acceptable.

Smoothieware

Il y a 3 options possibles pour Smoothieware :

• Utiliser la version CNC standard de Smoothieware
• Utiliser une version spécifique "Smoothie Clustering" adaptée à la découpe laser (développée par Cohesion3D / LightBurn)
• Utiliser ma version avec support du Smoothie Clustering ET software SPI.

La version standard est tout à fait adaptée à la découpe, et peut faire de la gravure, mais relativement lentement. En effet il faut beaucoup de commandes GCODE pour moduler la puissance du laser pendant la découpe, ce qui 'plombe' un peu la vitesse. "Enable Smoothie Clustering" doit être impérativement désactivé dans Lightburn pour utiliser ce firmware.

La version "Smoothie Clustering" ( téléchargeable ici: https://forum.cohesion3d.com/t/improved-raster-speed-firmware-update-for-cohesion3d-boards/850 ) qui ajoute une optimisation pour la gravure à haute vitesse. "Enable Smoothie Clustering" doit être activé dans Lightburn pour utiliser ce firmware. Elle a une petite particularité: La carte SD n'est pas montée automatiquement sur le PC. Je n'ai pas tenté, mais il est probable qu'en mettant "msd_disable false" cela rétablisse l'accès.

Enfin sur ma version j'ai repris celle de Smoothie, et à défaut d'avoir une contribution acceptée, j'ai intégré le correctif pour supporter le software SPI (support du LCD graphique de Reprap Discount) et celui de Cohesion3D/LightBurn en ce qui concerne le Smoothie Clustering. Ici, pas besoin d'adaptateur matériel pour le LCD, "Enable Smoothie Clustering" doit être activé dans Lightburn pour utiliser ce firmware. Il est disponible sur https://gitlab.civade.com/pub/Smoothieware sous forme de source. Une version précompilée est disponible ICI : https://gitlab.civade.com/pub/Smoothieware/-/tree/edge/FirmwareBin.

D'un point de vue matériel

D'un point de vue matériel, le pilotage d'une K40 nécessite 2 signaux : - Un signal PWM (modulation de largeur d'impulsion) pour régler la puissance du laser par logiciel. Avec 0V, le laser est à puisance 0, à 5V/100% de PWM il est allumé au maximum. - Un signal LO (Laser On) pour allumer ou éteindre le laser. Ce signal doit être à zéro pour allumer le laser, et 5V pour l'éteindre.

Comme la SKR 1.4 ne délivre que du 3.3V sur ses sorties, il va nous falloir adapter les signaux pour sortir en 5V. Ici j'ai fait ceci avec le "Level Translator". Cela s'alimente d'un coté en 3.3V (d'ou le régulateur), de l'autre coté en 5V. L'alimentation 5V est prélevée du connecteur "servo" sur lequel il y a l'une des rares sorties PWM disponibles sur la SKR 1.4. En ce qui concerne l'autre sortie, j'ai utilisé le connecteur adjacent, c'est à dire le "Probe".

Level translator unidirectionnel à 4 voies (provenance aliexpress) :

Par ailleurs, nous allons aussi avoir besoin de l'alimentation 24V fournie par l'alimentation du Laser. Cette alimentation étant à peine assez dimentionnée, la prudence recommanderait de mettre une alimentation 24V externe et ne pas utiliser celle fournie par l'alimentation du laser. C'est comme vous voulez...

Afin de récupérer la nappe d'origine de la K40 qui amène les fins de courses et le moteur du X, j'ai intercalé une carte "K40 Middle Man" qui fait l'adaptation de la connectique. Je n'ai utilisé que les sorties fin de course, moteur pas à pas et l'entrée alimentation 24V qui sert à alimenter les fins de course optique. Le connecteur qui se branche sur la nape venant du moteur X et des fins de courses (CONN FFC VERT 12POS 1.25MM ) n'est pas super simple à trouver à l'unité et pas cher.

Voici une vue de la carte Middle Man K40 (trouvée sur Ebay à 10 euros):

A noter que cette carte peut être parfois un peu dure à trouver. On peut bien sur aussi acheter juste le connecteur et faire fabriquer les circuits imprimés chez OSHPark, mais ceci n'est rentable que pour faire un lot de 10 cartes minimum.

Avec ce cablage, les commandes du panneau avant resteront fonctionnelles :

• Potentiomètre de réglage du courant
• Bouton de test laser
• Bouton de M/A laser
• Vumètre de mesure de puissance du laser.

Ceci permettra notamment de régler le potentiomètre de façon presque définitive à la valeur max de pilotage du laser (14 à 18 ma sur le vu mètre de mesure de puissance, en appuyant sur le bouton test), et moduler ensuite la puissance par logiciel de 0 à 100% en PWM. Je trouve cette solution de limitation matérielle plus sécurisante pour le laser que de le faire par logiciel.

Voici le schéma de la modification :

Afin de faciliter le cablage, j'ai fait une petite carte qui prend toutes les commandes, héberge la Middle Man et sort sur des connecteurs JST. Le bornier à vis noir en haut de la carte héberge les sorties PWM, Laser On et une masse qui vont aller vers la carte alimentation. Un fois raccordé la nappe enlevée dans l'ancienne carte sur la K40 middle man et l'alimentation, la solution est opérationnelle. Voici l'ensemble câblé sur table :

Mise en oeuvre avec une découpe laser K40

Avant toute chose ...

Manipuler une carte électronique avec des "fils volants" est souvent dangereux (pour la carte). Aussi il est préférable de sécuriser le tout pour éviter qu'un fil se promène et ne fasse de court-circuit intempesif. Qu'à cela ne tienne, un petit coup de découpe laser et hop, une platine pour fixer le tout! J'ai au passage adjoint une alimentation externe et un voltmètre pour surveiler la tension d'alimentation.

Avant de monter la carte, il va falloir régler le courant sur les drivers moteurs. La méthode dépend bien sur des drivers choisis. Les moteurs nécessitent 800mA. Pour info, dans un premier temps j'avais mis des DRV8825. Malheureusement, sur ces moteurs beaucoup de sifflements étaient à déplorer, même au courant nominal. Je suis donc revenu sur des classiques Pollolu A4988, un peu moins bruyants. Je les ais configurés en 1/16e de pas (les 4 cavaliers de configuration sous le driver moteur positionnés à droite). J'ai commandé deux TMC2130 pour essayer. Je pense y gagner en bruit et en souplesse, et ceux ci se pilotent possiblement en Step/Dir (prendre la version 'DIY' et la configurer). Je rajouterai une note là dessus plus tard.

Installation et configuration de LightBurn

Il faut ensuite installer Lightburn ( https://lightburnsoftware.com/ ) . Le logiciel est payant (35 euros), mais bien développé et supporté. Lorsqu'il est installé pour la première fois, il est en version d'évaluation complète, pendant 30 jours. Ceci vous permettra de faire tous les essais avant de décider si c'est l'outil pour vous ou pas.

Une fois installé, il faut le configurer pour une K40. Pour cela utiliser l'assistant de nouvel appareil (il se lance tout seul au premier lancement, ou sinon en bas à droite, appuyer sur "Appareils".

• Choisissez Smoothieware dans la liste des contrôleurs, puis Next
• Choisissez Serial / USB puis Next
• Nommer la machine (ex : "Smoothieware K40" ) et préciser ses dimentions (pour moi, X=330, Y=210, mais cela peut être plus petit pour vous si vous n'avez pas modifié le cadre pour augmenter les courses).

Ces réglages de base vont permettre d'exploiter Smoothie, mais sans le firmware "Cluster", ou le mien modifier pour supporter le "Cluster mode".

Pour accéder aux réglages avancés, Allez sur l'icone "clé à molette+tournevis" sur la barre d'icones de Lightburn. Voici les réglages que j'ai changés :

• (1) : Dimensions de la table (déjà vu dans l'assistant) et origine en bas à droite
• (2) : Homing automatique lors de la connexion de la prise USB / Allumage machine
• (3) : Activer le Clustering Smoothie : pour tirer partie du firmware "Cluster". Ne pas mettre 'on' si firmware standard Smoothieware.
• (4) : Reduce Smoothieware pause Delay: Smoothie ne supporte pas la mise en pause automatique dans un mouvement en cours. Permet de diviser les grands mouvements en plusieurs petits pour que l'utilisateur puisse mettre en pause plus facilement.

Tests de déplacement et vitesses moteurs

Ensuite, on peut raccorer la nappe portant le moteur X et les fins de courses, et le moteur Y (seulement 2 connecteurs à cabler...). Le laser doit être impérativement coupé en le mettant sur 'Off' sur le panneau avant.

Les essais moteurs peuvent maintenant démarrer avec le laser coupé. Si vous avez raccordé la carte par votre propre alim 24V, vous n'êtes d'ailleurs même pas obligé d'allumé la machine, seulement l'alim de la carte Bigtreetech... encore plus sûr..

Une fois compris que l'origine est en haut à gauche, et qu'il faut faire la recherche d'origine dans le sens négatif sur l'axe X et positif sur l'axe Y (c'est bien sur lié à la position physique des capteurs optiques sur la K40), ca commence à se comporter normalement lors du homing. La tête doit se déplacer vers le haut gauche. Le homing peut être demandé dans Smoothieware en allant dans le menu "Prepare / Homing all axes".

alpha_min_endstop       1.29^        # Connecteur homing X-
alpha_homing_direction  home_to_min  # Recherche le home en décrémentant  (X--)
alpha_min               0
alpha_max               330          # largeur = 330 mm sur une K40 modifiée

beta_max_endstop        1.28^        # Connecteur homing Y-
beta_homing_direction   home_to_max  # Recherche le home en incrémentant  (Y++)
beta_min                0
beta_max                210          # hauteur = 220 mm sur une K40 modifiée

Les mouvements, au courant nominal (0.8A), marchent pas mal jusqu'à 25 000 mm/min (soit 417 mm/s). J'ai même pu aller au delà mais après ce sont les moteurs/mécanique qui ne suivent plus...

Les moteurs étant en 400 pas/tour, en 1/16e de pas (6400 pas par tour), avec une courroie au pas de 2mm sur la poulie de 20 dents (40mm / tour), il faut (6400 pas / 40 mm ) = 160 pas pour faire 1mm.

A 417mm/s (soit 25 000 mm/minute) cela nous donne donc une fréquence de pase de (417mm/s X 160 pas) = 66.72 kHz. Pas mal ! On bien au delà des 25 kHz max d'un Grbl sur arduino Uno...

Au passage, c'est aussi pour cela qu'il ne me semble pas une bonne idée de mettre un GRBL/Uno sur une K40, car cela ira 2.5 fois moins vite sur les déplacements rapides. Avec GRBL sur STM32 ou ESP32 (voir sur ce même blog 2 articles sur le sujet) cela passerait sans problème. Donc oubliez l'Arduino de base à 16Mhz pour ce genre de projet...

A noter que Lightburn utilise la vitesse de jog par défaut qui est réglée dans Smoothieware pour se déplacer à vitesse rapide (default_seek_rate) . Il faut donc positionner celle-ci en fonction des caractéristiques machine. Bien que cela était fonctionnel à 24000 mm/mn, j'ai pris une marge de sécurité pour ne pas travailler toujours au max, en réduisant la vitesse de jog de 25% par rapport aux tests faits ci dessus (18000 mm/min, soit 300 mm/s):

default_seek_rate    18000             # Default speed (mm/minute) for G0 moves

J'ai néanmoins laissé à 24000 les déplacements des moteurs, pour les rares fois ou je souhaiterais graver à très haute vitesse en mode "raster". Ca a du sens...

J'ai relancé la découpe du fichier qui m'a servi à faire la platine dans Lightburn (toujours sans laser!!!), et tout avait l'air de se comporter normalement, avec d'assez jolis bruits mécaniques et sur les moteurs. C'est un peu plus bruyant qu'avec l'électronique d'origine, mais cela évoluera lors de la mise en place de drivers Trinamic (plus tard...). Au moins, "it works (tm)". Il est donc temps de raccorder le laser...

K40 + Lightburn avec pilotage du laser

Le raccordement du laser nécessite 3 fils, une masse, le LO (Laser On) totalement à droite sur l'alimentation, et le PWM. Ce dernier est pris en débrancheant la cosse raccordée sur le 5V de l'alimentation, et qui va à droite du portentiomètre de réglage de puissance. Ainsi le motentiomètre reste actif... et permet de mettre un talon sur la puissance Max admissible (18ma est une valeur qui semble faire l'unanimité sur une K40).

Pas de soucis particulier lors de la découpe. J'ai du adapter la hauteur de trait en mode raster à la largeur de mon faisceau, et activer le surbalayage :

Le surbalayage a pour intérêt de dépasser légèrement en mode raster de part et d'autre de la pièce de façon à laisser du temps à la mécanique de se stabiliser. En effet, j'ai noté que lors d'allers retours, une oscillation pouvait être visible à la loupe sur les traits au début. Celle ci disparait totalement en surbalayage. Voici ce que donne une prévisualisation d'un surbalayage. En rose, les déplacements sans laser et en gris avec. Si les dimensions de la zone rose changent, c'est pour s'adapter à la vitesse... Ceci est fait automatiquemetn par Lightburn :

Conclusion :

Du coup, j'ai passé la carte en prod, en démontant l'ancienne et en fixant la nouvelle via la plaque métallique verticale de fixation. Pour le moment, je n'ai pas encore modifié la face avant, car je ne suis pas sur que le LCD de Smoothie soit intéressant pour une découpe laser, lorsque l'on est connecté à Lightburn.

Il a fallu faire un petit cable USB type B male, vers embase type B femelle et un adaptateur en impression 3D pour fixer le type B femelle dans le trou ou il y avait l'entrée USB de la précédente carte. Rien de bien méchant. Ceci dit, pour les feignants (et patients...) cela existe tout fait que Aliexpress à moins de 1 euro :

Voici une vue d'ensemble montée :

Le couple Lightburn + Smoothieware, c'est très spectaculaire.... Rien à voir avec le logiciel d'origine. Avec la Bigtreetech SKR 1.4, il est possible de faire cette upgrade pour moins de 100 euros tout compris (logiciel aussi), ce qui en fait une modification imbattable. De toute façon je n'aurais pas mis les 250 USD de la carte Cohesion, ou les 250 euros de la Smoothieboard + accessoires auxquels il fallait encore ajouter le logiciel. C'est peut être pas très fair play pour les développeurs de Smoothieware, mais vu les rapports que j'ai eu avec eux, j'ai vraiment pas eu l'envie d'alimenter leur business.