Prototype de contrôleur à base de carte SD pour Teacup

Salut!

Comme je l’expliquais dans mon précédent article, je suis passé sur Teacup et mon contrôleur LCD/SD d’origine n’est pas compatible avec ce firmware. Et je n’ai pas du tout envie que mon imprimante 3D soit dépendante d’un PC pour pouvoir fonctionner.

Teacup gèrerait a priori la présence d’une carte SD, mais visiblement il  faut envoyer du G-Code pour lister les fichiers (via un PC, donc…), et l’ensemble n’est pas vraiment documenté. Même chose pour l’affichage.

Alors je me suis lancé dans la conception d’un contrôleur qui discutera avec le firmware de la machine, quel qu’il soit. Rien que ça, mon pote!

Idéalement, il disposera d’une interface web (ESP8266 powaaa!), mais pour le moment j’ai fait un proof of concept avec une Teensy 3.2, un afficheur OLED SSD1306 et un lecteur de carte microSD. Et le pire dans tout ça, c’est que ça a l’air de marcher!

Voici le montage en mode breadboard:

A gauche, l’écran, au milieu le lecteur microSD, à droite la Teensy, et en haut l’Arduino Mega 2560 (avec Teacup). Au dessus de tout ça, un sacré bordel de fils. A gauche, une résistance de 220Ω qui n’a rien à faire dans le montage, mais oh, je suis encore chez moi, non?!

La communication entre mon petit bazar et Teacup se fait par port série. Après l’envoi de chaque commande, le programme attend l’acknowledgement du firmware (un bête « ok ») avant d’envoyer la commande suivante.

Pour le moment, j’affiche juste la ligne courante sur l’écran, mais je vais faire évoluer ça pour afficher les températures et l’avancement de l’impression.

Changement forcé de firmware sur l’imprimante 3D

Une nouvelle année s’ouvre à nous, et je vous la souhaite bien bonne!

Pour démarrer en beauté, j’ai commencé par « casser » mon imprimante 3D. Bravo champion!

L’histoire a commencé (enfin c’est ce que je pense) alors que je regardais jusqu’où je pouvais pousser mon plateau Y, dans l’idée d’imprimer une pièce assez grande (une pièce de quadricoptère, mais j’aurai tout loisir de revenir là-dessus dans les mois à venir!)

Bref, suite à ça, je vais pour imprimer une petite pièce en PLA, et là, paf! le plateau ne chauffe pas. Je contrôle la résistance du plateau, 1Ω et quelques (correct), mais à la sortie du RAMPS, j’avais 2 pauvres volts qui se couraient après pour alimenter le plateau (normalement on est à 12…)

Visiblement un fusible ou un Mosfet a grillé à cause d’un court circuit que je suppose provoqué par ma poussée un peu extrême du plateau (oui, les connexions sont artisanales…)

Alors je ne me démonte pas de souci, je remplace le RAMPS par un deuxième que j’avais en stock. Je rebranche tout mon petit bazar, j’allume, et là… j’ai plus rien compris au fonctionnement des moteurs. X et Y nickel, par contre Z et extrudeur ne tournaient plus. Ou si. Ah, et puis finalement non.

J’ai flashé l’Arduino avec la dernière version de Marlin, pas mieux. Alors après analyse, un des Pololus avait grillé, mais même en le remplaçant, j’avais un fonctionnement totalement aléatoire des moteurs Z et E…

Au bout d’une journée et demie d’agacement intensif et d’une envie (heureusement réprimée) de sauter dessus à pieds joints, j’ai décidé d’installer un autre firmware déjà essayé dans le passé sur une autre machine: Teacup.

Hé ben tu l’crois, tu l’crois pas: tout est rentré dans l’ordre. Les 4 axes fonctionnent, les endstops aussi, le plateau chauffant et la buse aussi, il n’y a plus qu’à tout recalibrer (depuis l’écriture ce cet article, c’est fait et ça marche nickel).

Des fois faut pas trop chercher… En tout cas pour moi, Marlin, c’est fini. Non Marlin, ne dis rien, je ne t’écouterai pas! Mais il va quand même que je trouve un palliatif pour pouvoir imprimer depuis une carte SD parce que là, je dois me brancher en USB depuis le PC…

Paramétrage de Teacup pour la gravure au laser

Pour envoyer mes impulsions PWM au module laser, j’utilise la commande M106 Px Sy de Teacup.

J’ai défini ma broche de commande du laser en tant que ventilateur dans Teacup, et cette broche envoie un signal PWM.

La section « heaters » dans ma configuration se présente comme ceci :

[code]

//DEFINE_HEATER(extruder, PD3,   0) //DEFINE_HEATER(bed,      PB4,   0) DEFINE_HEATER(fan,        PB3, 1) // DEFINE_HEATER(chamber,  PIND7, 1) // DEFINE_HEATER(motor,    PIND6, 1)

[/code]

J’ai désactivé l’extrudeur et le lit chauffant, inutiles pour ce que je fais. La broche PB3 correspond à la broche 11 de l’arduino uno.

Revenons à notre commande M106 Px Sy, qui prend deux paramètres:

  • P : l’index de la sortie dans la section « heaters », pour moi c’est 0 (je n’ai qu’une sortie heater)
  • S : la puissance du signal PWM, de 0 à 255

Lors des premiers tests avec une simple LED, j’ai réalisé que les commandes M106 n’étaient pas synchronisées avec les mouvements. En fait elles ne sont pas mises dans le buffer de commandes, mais directement exécutées. Alors Pour remédier à ça, il faut ajouter dans notre fichier de config :

[code]

define ENFORCE_ORDER

[/code]

Autre souci que j’ai eu: la commande M106 faisait planter Repetier-host (il arrêtait spontanément d’envoyer les commandes).

Je suis passé sur Pronterface, et là, plus de problème! Des fois, faut pas chercher…

Des barres, des roulements, des poulies et des ficelles : le Core XY avance

« Prendre des p’tits bouts d’truc et puis les assembler ensemble… »

J’ai enfin monté tout mon petit bazar, et voici l’histoire du Core(X,Y) fishing line édition! Enfin plutôt « butcher line » parce que c’est de la ficelle de boucher.

Core(X,Y) vue de dessus

En bougeant les moteurs à la main, tout a l’air bon, alors j’attaque l’électronique.

Au départ, je voulais utiliser grbl sur mon arduino uno, mais hélas il ne gère pas nativement le CoreXY. Alors j’ai opté pour Teacup, qui le gère et qui propose des sorties PWM (qui vont me permettre de contrôler la puissance de mon laser).

Les Pololu

Bon j’avoue, j’en ai un peu chié avec ces pololu. Au premier essai, j’ai consulté ce schéma, et j’ai laissé flottantes les broches ENABLE, MS1, MS2 et MS3. Mauvaise idée.

Pololu A4988 (https://www.pololu.com/product/1182)
Câblage du Pololu A4988 (https://www.pololu.com/product/1182)

Je vais vous donner la solution directement, c’est plus pratique:

  • ENABLE -> 0V de l’arduino
  • MS1, MS2, MS3 : leur combinaison donne la valeur du microstepping (voir lien au dessus)
  • RESET et SLEEP : les raccorder ensemble
  • DIR et STEP -> sur l’arduino (j’y reviendrai)
  • VDD : +5V de l’arduino
  • GND (celui du bas) : 0V de l’arduino
  • VMOT : +12V de l’alimentation de puissance (alimentation de PC dans mon cas)
  • GND (celui du haut) : 0V de l’alimentation de puissance
Joyeux bordel : arduino uno et pololu
Joyeux bordel : arduino uno et pololu

Teacup

Alors Teacup, c’est d’abord un poil de configuration. Il faut avant tout renommer l’un des modèles de fichiers de config en config.h. Dans mon cas, je n’ai pas de ramps, ni de gen7, ni quoi que ce soit : juste une arduino et deux pololu A4988 pour piloter mes deux moteurs. Je copie donc le config.default.h en config.h.

Pour que ça compile, il faut aussi renommer ThermistorTable.single.h en ThermistorTable.h. On n’utilisera pas de thermistance (enfin pour l’instant… hé hé) donc on s’en fout.

Dans le config.h, il y a un paramètre pour indiquer qu’on utilise une mécanique CoreXY:

[code]

define KINEMATICS KINEMATICS_COREXY

[/code]

Zoom sur l'entrainement
Zoom sur l’entrainement

Après, il faut calculer le nombre de pas par mètre (comme je suis gentil je vous ai fait un calculateur sur une page web), et indiquer les vitesses maximales; là, on peut y aller franco:

[code]

define    MAXIMUM_FEEDRATE_X        20000

define    MAXIMUM_FEEDRATE_Y        20000

define ACCELERATION 2500.

[/code]

Après avoir configuré Teacup, premier test avec les connexions par défaut:

Moteur A AIO0 : X_STEP_PIN (broche STEP du Pololu A) AIO1 : X_DIR_PIN (broche DIR du Pololu A)

Moteur B AIO3 : Y_STEP_PIN (broche STEP du Pololu B) AIO4 : Y_DIR_PIN (broche DIR du Pololu B)

Surprise : seul le moteur B tourne. Bon…

Je modifie les sorties du moteur A dans la config de Teacup (qui deviennent respectivement DIO2 et DIO3) et les deux moteurs tournent. Youpi!

Petit test de mouvement X et Y avec Repetier-host, et je constate que le X+ et X- sont bien, mais Y+ et Y- sont inversés.

J’intervertis les deux moteurs : Moteur A sur les pins Y, et moteur B sur les pins X. Ça marche!

Trop bien 🙂

Vue d'ensemble
Vue d’ensemble

Vitesse

Maintenant, petit test de vitesse et d’accélération en envoyant des commandes G-Code en direct.

Vitesse : 20’000 mm/min (soit 333 mm/s)

Accélération : 2’500 mm/s²

J’aime autant vous dire que ça envoie le pâté, comparé à ma CNC qui monte poussivement à 3 ou 3.5mm/s !

Débattement

  • Y : 300mm
  • X : 250mm, que je vais pouvoir augmenter en arrangeant mes attaches de ficelle.
Le chariot et ses attaches à la one again
Le chariot et ses attaches à la one again

Conclusion

Il me reste donc à arranger mon chariot pour que les fixations des ficelles soient à la même hauteur que les poulies.

Ensuite, faire un support pour le module laser, et contrôler la précision et la répétabilité selon la vitesse.

Enfin, réfléchir à un plateau Z et un support de moteur qui me permettrait de graver des circuits imprimés.

Et ajouter deux endstops pour la mise à zéro, ce ne serait pas un luxe.

Je viens de réaliser que contrairement à grbl et Marlin, Teacup ne supporte pas les arcs (G2 et G3). Dommage…