Création de PCB avec une CNC (gravure à l’anglaise)

Nous y voilà, ma petite CNC étant maintenant 100% opérationnelle, je peux enfin m’attaquer à la gravure de PCB (circuits imprimés) « à l’anglaise ».

Avant d’entrer dans les détails, voici les grandes étapes du processus :

  • Conception du circuit électronique avec un outil de CAO
  • Modélisation de l’implantation des composants, toujours avec un outil de CAO
  • Export des pistes du circuit au format GERBER et du plan de perçage au format EXCELLON
  • Chargement des fichiers exportés dans FlatCAM, génération des géométries, génération des fichiers pour la CNC
  • Gravure du PCB avec un logiciel de pilotage de CNC (Candle)

(suite…)

Ma petite CNC est arrivée !

J’y pensais depuis quelques temps, j’ai franchis le pas et j’ai commandé une petite CNC !

CNC signifie Computer Numerical Control, ce qui, en français, donnerait machine-outil à commande numérique, ou plus littéralement « commande numérique par calculateur ».

Alors qu’une imprimante 3D dépose de la matière en partant du bas de l’objet, la fraiseuse CNC va retirer de la matière en partant du haut de l’objet. Mais si souvent on y fixe une fraise pour faire de l’usinage, on peut aussi y attacher un foret pour réaliser des perçages très précis, ou encore un laser pour « dessiner » sur du bois ou du liège, voir découper certains matériaux.

On peut aussi l’utiliser comme graveuse (sur bois, plexi, alu…). Et l’un des usages qui m’intéresse le plus : la gravure de PCB ! Je ne réalise pas souvent des PCB, mais à chaque fois, avec la gravure chimique, c’est tout un chantier dans la salle de bains, les produits perdent leur efficacité avec le temps, on ne peux pas s’en débarrasser simplement, bref, la gravure m’ira très bien pour mes besoins 🙂

(suite…)

Un bureau virtuel (ou page d’accueil auto-hébergée)

En général, quand on est sur un PC, on a toujours à peu près les mêmes onglets ouverts. Pour gagner du temps, on peut les ouvrir automatiquement quand le navigateur se lance. Après être tombé sur quelques sites ou des gars expliquaient comment ils avaient créé leur page d’accueil personnalisée, ça m’a donné envie d’en faire autant (voici un exemple).

Les intérêts sont multiples :

  • Productivité : une seule page d’accueil qui donne accès à tout ce dont on a quotidiennement besoin
  • Accessibilité : il suffit d’un navigateur et d’une connexion internet
  • Indépendance : on gère soit même ce « portail », on est pas dépendant d’une plateforme spécifique (comme Netvibes) qui peut fermer ou modifier ses conditions d’utilisation
  • Évolutivité : on y ajoute tout de dont on peut avoir besoin et les possibilités sont vastes (grand choix d’applications Open Source ou gratuites, possibilité d’ajouter ses propres développements…)

Bien sûr, ça demande un peu plus de temps et de travail, mais au quotidien, c’est du bonheur. Une petite remarque aussi concernant la sécurité : comme on peut être amené à installer un grand nombre d’applications de sources diverses, je préfère ne rien stocker de critique sur ce portail et l’accès est très restreint.

Avant de rentrer dans le détail, voici une capture d’écran de l’ensemble de ma page d’accueil, qui finalement est devenue un bureau virtuel (cliquer pour la voir en grand) :

On retrouve les services suivants :

  • Recherche multi-moteurs (dev perso)
  • Un accès rapide à mes différentes messageries/Facebook
  • Gestionnaire de To Do List (myTinyTodo)
  • Météo (affichée via un widget de meteocity)
  • Widget Deezer pour écouter de la musique
  • Plusieurs panneaux de liens, pour un accès rapide à mes sites/services favoris
  • Les flux RSS du Monde et 01net, pour un aperçu rapide de l’actalité
  • Une calculatrice,
  • Le site mobile Sytadin dans une Iframe (la version mobile affiche la carte en plein écran)
  • Un outil de prise de notes avec un éditeur de texte avancé (les notes sont sauvegardées sur le site) (dev perso).
  • Le programme TV de la soirée (widget Télé-Loisirs affiché dans une iframe)
  • Les flux RSS Allociné pour les films de la semaine et les films à venir
  • Un accès vers mon blog (WordPress)
  • Un agrégateur de flux RSS (j’en ai testé pas mal, mais pas encore convaincu), un jour…
  • Un forum (phpBB), dont je suis le seul utilisateur et que j’utilise pour prendre des notes, m’organiser, classer des liens, bref un fourre-tout
  • Un Wiki (Dokuwiki) pour organiser des informations utiles
  • Un gestionnaire de favoris (Online-bookmarks), il est un peu vieux, pas très sexy mais correspond à mon besoin
  • Différents outils : pastebin-like (Stikked), raccourcisseur d’urls (YOURLS), des outils d’encodage, calcul de hash etc…, des proxys (miniProxy et oranjeproxy), un lien vers Code Beautify
  • Un gestionnaire de fichier Web (eXtplorer), un must pour pouvoir modifier les fichiers du site sans devoir passer par un client FTP !
  • Un client FTP Web (Monsta)
  • Un outil de partage de fichiers comme wetransfer (Jirafeau)
  • Une galerie photo (MiniGal Nano)
  • Une bibliothèque pour accéder à mes PDF, via Encode Explorer

Quelques images en plus :

Tout ça c’est bien, mais je voulais aussi que ça ne soit pas trop moche, sans devoir y passer trop de temps, et c’est là qu’intervient AdminLTE. C’est une interface d’admin de démo basée sur Bootstrap (donc responsive : qui s’adaptera aux écrans de différents préiphériques). Elle contient un maximum de contrôles, et graphiquement, c’est plutôt réussi ! Je l’ai donc utilisée pour construire mon portail, moyennant quelques petites modifications.

Pour terminer, j’ai organisé tout ça dans une petite application PHP, histoire d’avoir un mini Framework MVC (basique), gérer l’authentification, les cookies etc. Il a fallu bidouiller pas mal des applications listées ci-dessus pour contourner leur authentification (et qu’il vérifie la connexion au portail à la place). J’ai parfois du tricher de manière assez moche, mais ça fonctionne 😀

Le tout est hébergé chez OVH, avec un nom de domaine très court. Soit une vingtaine d’euros par an. C’est le prix de l’indépendance 😉

LuxDimmer : gérer simplement la luminosité de l’écran

Depuis plus d’un an, le blog n’était plus mis à jour, alors que j’étais sur un projet passionnant (R.I.P.E.R.). J’ai dû mettre ces activités en suspend pour le boulot : j’avais une certif à préparer et ça m’a demandé beaucoup de temps (CEH).

Fraîchement certifié, me revoilà ! Dès le début de mes révisions, j’ai été confronté à un problème : la lecture de centaines de pages de cours sur l’écran, ça fatigue. Et devoir constamment modifier les réglages de luminosité sur l’écran, c’est toujours contraignant, surtout si on doit le faire plusieurs fois dans la journée. A noter que sur un ordinateur portable, cela ne pose pas de problème car Windows permet de modifier directement la luminosité de l’écran. Sur un écran fixe, c’est une toute autre histoire.

J’ai testé différents logiciels, comme f.lux qui semble une référence dans le genre (il permet d’ajuster la luminosité/colorimétrie de l’écran en fonction de l’heure du jour). Mais finalement, pas moyen de trouver un logiciel simple (et pas gavé de spy/ad-wares), qui permet de modifier la luminosité de l’écran à un instant T avec un simple curseur.

Je m’y suis donc collé. C’est très simple, le logiciel se lance et se place dans la barre des tâches. En cliquant sur son icone, un menu s’affiche permettant de modifier la luminosité des écrans connectés au PC. Voilà ce que ça donne :

Je me suis vite aperçu qu’il n’était pas possible de modifier directement la luminosité de Windows quand l’écran est « externe » (et non intégré à un portable). L’astuce consiste tout simplement à ajouter un calque qui se superpose au bureau et reste tout le temps au premier plan sans empêcher la souris d’accéder aux éléments graphiques sous-jacents. Il suffit ensuite de faire varier l’opacité de ce calque pour diminuer la luminosité 🙂

Voici le bout de code magique qui permet de gérer la « transparence pour les clics de souris » :

public static class WindowsServices
{
    const int WS_EX_TRANSPARENT = 0x00000020;
    const int GWL_EXSTYLE = (-20);

    [DllImport("user32.dll")]
    static extern int GetWindowLong(IntPtr hwnd, int index);

    [DllImport("user32.dll")]
    static extern int SetWindowLong(IntPtr hwnd, int index, int newStyle);

    public static void SetWindowExTransparent(IntPtr hwnd)
    {
        var extendedStyle = GetWindowLong(hwnd, GWL_EXSTYLE);
        SetWindowLong(hwnd, GWL_EXSTYLE, extendedStyle | WS_EX_TRANSPARENT);
    }
}

J’ai déposé les sources sur Github, si jamais ça intéresse du monde, l’exécutable est directement disponible également ici.

Ecran OLED SSD1306 128×64 SPI

Cet article fait suite à celui-ci.

En faisant le tour des différents périphériques i2c que je compte utiliser pour mon robot, j’ai eu la mauvaise surprise de voir que la boussole et l’écran OLED partageaient la même adresse sur le bus i2c (x3C). Aucun des 2 modules ne permet de modifier l’adresse comme c’est le cas pour certains périphériques.

J’ai donc commandé le même écran OLED, dont je suis très satisfait, mais dans sa déclinaison SPI afin d’éviter les conflits sur le bus i2c. Ca a été plus compliqué que prévu, d’où ce court article.

La première difficulté concerne le raccordement de l’écran à l’Arduino. Certains connecteurs sont nommés de manière peu éloquente : Gnd, Vcc (jusque là, ça va), D0, D1, RES, DC, CS.

Voici les bonnes correspondances, écran –> Arduino :

  • GND –> GND (masse)
  • VCC –> 3.3V à 5V (alimentation)
  • D0 –> SCK
  • D1 –> MOSI
  • RES –> un pin digital (c’est pour le reset)
  • DC –> un pin digital (data/command)
  • CS –> SS

Second problème, logiciel pour changer. J’utilise toujours la librairie U8glib dont je suis très content. Par contre, les constructeurs proposés dans les différents exemples de code ne fonctionnent pas : il faut passer au constructeur le numéro du pin RESET ! J’ai utilisé le constructeur suivant dans mes tests (avec un Arduino Nano) :

U8GLIB_SSD1306_128X64 u8g(13, 11, 10, 9, 4);

// SW SPI Com: SCK = 13 (D0 sur oled), MOSI = 11 (D1 sur oled), CS = 10 (CS sur oled), A0 = 9 (DC sur OLED), !!RESET = 4 (RES)!!

HALO : démo de mon Ambilight DIY

00_halo_demo

De retour après une longue absence. Mon système Ambilight a bien avancé, bien qu’il ne soit pas terminé, l’essentiel y est pour une première démo ! Je le poste donc tel quel parce que je vais me lancer sur autre chose ! Le détail des étapes précédentes (électronique, impression du boitier, intégration…) est disponibles dans les articles précédents).

Au menu :

  • Un logiciel permettant de piloter l’Arduino  nano, qui lui-même pilote le ruban de LEDs
  • Le logiciel se lance au démarrage de Windows et se charge dans la barre de notifications pour un accès rapide

01_halo_icon

  • Quand on clique sur l’icone, 3 modes sont disponibles :
    • Ambiance, qui permet de définir une couleur fixe ou une animation de couleurs
    • Ecran, pour analyser la couleur aux bords de l’écran et la transmettre aux LEDs associées (3 méthodes d’analyse sont disponibles : GDI, DirectX 9 et DirectX 11, la première étant la plus stable mais la moins performante sur les films par exemples)
    • Son, pour analyser le son de l’ordinateur et animer les LEDs en conséquence (ce mode est pour l’instant très expérimental, il ne se base que sur le niveau sonore). J’ai utilisé la librairie NAudio.

02_halo_menu

  • Le bouton « Configuration » permet d’accéder à de nombreux paramétrages, à commencer par le choix de l’écran équipé du ruban de LEDs, la configuration de la communication avec l’Arduino et le mode de démarrage du logiciel.

03_halo_settings

  • Un écran spécifique est disponible pour permettre un placement facile des LEDs (on peut en ajouter, en supprimer, les déplacer, définir la surface de couverture et d’analyse etc.)

04_halo_settings

  • D’autres options de configuration permettent de calibrer la puissance des LEDs, corriger les couleurs etc.

Et pour illustrer le tout, rien de tel qu’une vidéo :

Quelques remarques :
  • Tout n’est pas terminé :
    • L’analyse de l’écran marche bien, mais dans les films, la moyenne des couleurs tend souvent vers des gris, l’algo d’identification de la couleur dominante d’une zone est à ajuster.
    • La méthode de capture d’écran classique (GDI) induit de micro-ralentissements, presque imperceptibles, mais qui restent présents.
    • L’utilisation de DirectX (9 ou 11) fonctionne très bien pour les vidéos, mais  posent quelques autres problèmes (lorsque de la souris bouge par exemple)
    • La partie analyse du son est une ébauche, il est possible d’aller beaucoup plus loin : analyser séparément les canaux gauche/droite, analyser le spectre (aigus, médiums, graves) au lieu de se baser sur le volume etc.
    • Exposition d’un service pour que des applications tiers puissent piloter les LEDs
    • Ajout de modules de notifications (e-mails, facebook etc.)
  • Mon Arduino Nano vient de Chine et utilise vraisemblablement une puce FTDI « not genuine ».  L’année dernière FTDI a déclenché un petit scandale en publiant un driver qui modifiait le PID des puces contrefaites (le driver a depuis été supprimé de Windows Update). Bref, si vous êtes confrontés à un problème de communication avec votre Arduino, vous pouvez jeter un oeil ici (plus d’infos en vidéo ici, ici ou encore ).

Premiers pas vers un système Ambilight DIY

Après une petite trêve, il est temps de se remettre au boulot : réalisation d’un système Ambilight maison. Philips intègre cette technologie à certains de ses écrans depuis plusieurs années. Le principe est de diffuser un halo lumineux autour de la télé, en fonction des couleurs affichées sur les bords, pour une meilleure immersion.

Je voudrais intégrer un système similaire, mais pour mon PC et aller plus loin : en profiter pour les films, mais aussi les jeux, la musique, pouvoir définir des ambiances, gérer des notifications etc.

Il y a une ou deux semaines, j’ai trouvé ça dans ma boite aux lettres :

OLYMPUS DIGITAL CAMERA

C’est l’élément clé : il s’agit d’un ruban de LEDs adressables. Comparés aux rubans de LEDs classique, l’avantage énorme de ces rubans, est qu’ils ne nécessitent que 3 ou 4 fils pour être contrôlés, grâce à des petits contrôleurs embarqués (chaque LEDs ayant une adresse). Il en existe différents types, j’ai opté (peut-être un peu rapidement) pour un modèle basé sur chipset SPI : WS2801. Ce n’est pas trop cher (15€ le mètre) et ça devrait faire l’affaire.

Le chipset de LEDs qui a le vent en poupe en ce moment semble être le WS2811 (ou 2812 / 2812B / Neopixel). Il s’agit d’un chipset 3 câbles, contrairement au SPI.

La chose importante à s’assurer lors du choix du chipset, est qu’il soit géré par la librairie FastLED pour Arduino. La liste des chispsets supportés est disponible sur le Wiki du projet.

Mon ruban sera donc piloté par un Arduino Nano. Parce que j’en avais un qui traînait, que ça ne coûte pas cher (2-3€) et que ça ne prend pas trop de place 🙂

OLYMPUS DIGITAL CAMERA

Pour le WS2801, nous aurons besoin de 4 cables : +5V (IN/OUT), 0V (GND),  SPI Clock (CK) et SPI Data (SD).

OLYMPUS DIGITAL CAMERA

Remarque importante, qui m’a fait perdre un peu de temps : les rubans ne sont utilisables que dans un seul sens. Sur certains modèles, une flèche indique le sens. Ce n’était pas le cas sur le mien. J’aurais dû m’apercevoir plus tôt que d’un côté il était marqué « IN 5V » et de l’autre « OUT 5V » pour déterminer le sens.

La connexion sur le Arduino est très simple, il suffit d’utiliser les pins SPI CLOCK et SPI MOSI (pin digitaux 13 et 11 sur le Nano).

OLYMPUS DIGITAL CAMERA

Après un premier loupé, j’ai fini par souder un connecteur sur mon ruban de LEDs pour avoir quelque chose de propre, solide et facilement raccordable à la platine de tests.

OLYMPUS DIGITAL CAMERA

Pour mes premiers tests, j’ai travaillé avec un ruban de 6 LEDs. Ce n’est pas obligatoire, mais pratique pour la phase de calibrage. De plus, cela évite les problèmes liés à une alimentation insuffisante.

Après cette première partie concernant le matériel utilisé, passons au logiciel et au calibrage. Tout d’abord, il faudra se procurer la libraire FastLED (hyper optimisée et très complète).

Je copie/coller une remarque importante issue du site de FastLED :

IMPORTANT NOTE: If you are building for AVR based systems, please do not use any version of the arduino IDE 1.5.7 or later yet. It messes with some of the asm output which will cause you problems.

En clair, pour Arduino, s’assurer de ne pas avoir une version trop récente de l’IDE (j’utilise la 1.0.5-r2).

Une fois FastLED installé dans les librairies de l’IDE Arduino, nous pouvons ouvrir l’exemple « RGBCalibrate ».

Indiquer le nombre de LEDs utilisées :
#define NUM_LEDS 6

Modifier les pins utilisés :
#define DATA_PIN 11
#define CLOCK_PIN 13

Ajouter les LEDS qui correspondent au chipset utilisé (WS2801 dans mon cas) :
FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);

Le code est prêt à être chargé, et testé ! Normalement, les LEDs devraient s’allumer. Si on constate de que la première LED est rouge, les 2 suivantes vertes et les 3 dernières bleues, alors tout est bon, les couleurs sont envoyées dans le bon ordre : Rouge, Vert, Bleu. Si ce n’est pas le cas, il faudra modifier la ligne d’ajout des LEDs pour identifier l’ordre des couleurs à utiliser pour votre ruban. Dans mon cas, RGB ne correspondait pas, je suis passé en BGR, en modifiant la ligne (ne pas hésiter à tester toutes les combinaisons jusqu’à tomber sur la bonne) :
FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, BGR>(leds, NUM_LEDS);

OLYMPUS DIGITAL CAMERA

L’étape suivante a consisté à tester la communication entre le PC et la carte Arduino pour piloter le ruban. J’ai écrit 2 petits programmes:

  • un pour le Arduino Nano, qui écoute les ordres du PC et contrôle les LEDs en fonctions des messages reçus
  • un pour le PC (en .NET C#), qui permet d’envoyer des ordres au Arduino pour piloter les LEDs.

Le programme pour le Arduino Nano est dispo ici. Le principe est très simple : on écoute sur le port série. Si des données arrivent, on lit le premier octet, qui contiendra un caractère. Si ce caractère est un A, alors on lit les octets qui suivent (3 octets pour chaque led, correspondant au code couleur RGB). Si le premier octet est un B, C ou D, on passe en mode « amibiance » (le Arduino génère en boucle une animation pour les leds).

Côté PC, il s’agit d’un petit programme écrit en C# (application WPF). Les sources sont dispos ici. Attention, c’est pas un chef d’oeuvre, juste une bricole de test, pas de MVVM etc. Mais ça reste simple.
Rien de particulier à ajouter, si ce n’est que la communication avec le Arduino se fait grâce à la classe System.IO.Ports.SerialPort du Framework .NET et le composant graphique ColorPicker provient du Extended WPF Toolkit.

05_programmeTestLeds

Toutes les actions depuis cette fenêtre, à part les « Ambiances », envoient explicitement à l’Arduino l’état RGB de chaque LED. L’Arduino ne servant qu’à les faire suivre aux LEDs. Ainsi, les scénarios sont intégralement pilotés par le PC, contrairement aux ambiances qui sont calculées par l’Arduino.

Voici une vidéo qui illustre le fonctionnement de l’ensemble :

Modélisation 3D et correction .STL

Pour le moment, j’arrive à me débrouiller avec Sketchup, qui est assez facile à utiliser.

Mais il est parfois capricieux et les STL générés posent des problèmes d’étanchéité par forcément facile à détecter. J’utilise donc plusieurs outils pour me faciliter la vie :

  • Tout d’abord, indispensable : le plug-in d’export au format STL, disponible ici.
  • Plug-in Clean : il permet de nettoyer le modèle de tout ce qui est inutile ou pourrait causer des problèmes.
  • Plug-in Curviloft : permet de créer facilement des formes complexes à réaliser sans ce plugin.
  • Plug-in Joint Push Pull : permet de faire des push/pull plus avancés.
  • Enfin, un outil en ligne très pratique : Netfabb en ligne. Il permet de réparer les STL. Il règle notamment les problème d’étanchéité. De ce que j’ai pu tester jusqu’ici, il est plutôt efficace. A essayer si vous n’arrivez pas à corriger un fichier STL.

Les joies de l’étalonnage

Deux semaines plus tard, me revoilà. J’avais réussi a obtenir des impressions très belles. Mais j’ai très vite déchanté quand il s’est agit d’imprimer des pièces de précision : les objets imprimés n’étaient pas aux bonnes dimensions ! Par exemple, pour une boite de 20 mm x 20 mm x 10 mm, j’obtenais une boite de 21.4 mm x 20.6 mm x 10 mm.

J’ai fait pas mal de tests…

OLYMPUS DIGITAL CAMERA

Plusieurs choses à retenir :

  • lors du calibrage, j’avais beaucoup trop resserré mes courroies
  • Mes courroies étaient HS. Je ne sais pas s’il s’agissait de courroies de mauvaise qualité, ou si je les ai abîmées en les tendant trop. En tout cas, j’avais un peu de colle a bois qui avaient coulé sur celle de l’axe X et génait un peu les déplacements, et celle de l’axe Y présentait des marques de pliures douteuses. Bref, j’ai remplacé les 2, je ne les ai pas trop tendues et les résultats ont été beaucoup plus précis !
  • Un pied à coulisse digital est indispensable pour bien étalonner l’imprimante

OLYMPUS DIGITAL CAMERA

Une fois la mécanique fiabilisée, il restait quelques écarts, les dimensions n’étaient pas encore tout à fait parfaites. L’étape suivante consiste donc à étalonner l’imprimante en mettant à jour son firmware pour lui dire, pour chaque axe, combien de pas moteur sont nécessaires pour un déplacement réel de 1 mm. J’ai perdu beaucoup de temps à trouver comment se faisait l’étalonnage. J’ai tatônné et obtenu de très bons conseils via le forum francophone RepRap. Aussi je ne détaillerai pas tout le processus ici et me contenterai d’un lien vers un excellent article qui explique tout cela très bien :

Le blog de Jean-Philippe Abraham, que je remercie chaleureusement 🙂

Au final, ce qui reste peut-être le plus simple est d’imprimer quelques grandes pièces pour faire des mesures précises et calculer les nouvelles valeurs à entrer dans le firmware de l’imprimante. Voici quelques pièces qui m’ont aidé à étalonner et calibrer ma RepRap.

OLYMPUS DIGITAL CAMERA

Pour finir, le soulagement, enfin des dimensions correctes ! Contrairement à la photo, le meilleur endroit pour prendre des bonnes mesures est de se positionner sur les dernières couches imprimées.

OLYMPUS DIGITAL CAMERA

Préparer un fichier à imprimer avec Slic3r

Pour imprimer un objet, l’imprimante à besoin d’un fichier qui lui dit exactement quoi faire. Il contient du GCode, c’est ce fichier que nous allons devoir créer.

Pour ce faire, on utilisera Slic3r, intégré à Pronterface (via le menu Settings / Slicing Settings). Ce petit logiciel va recevoir un fichier 3D en entrée, au format .STL. Il va ensuite utiliser tous les paramètres que nous lui aurons fournis pour découper en plein de tranche l’impression 3D et les transformer en lignes de commandes pour l’imprimante.

Au premier démarrage, Slic3r pose un certain nombre de question pour ajuster les paramètres. Pour le moment, je ne rentre pas dans les détails, je travaille encore aux ajustements. Mais il faut au moins répondre aux questions de bases posées par le logiciel.

On charge ensuite un fichier .STL (le Thingiverse est parfait pour cela, choisir un objet relativement plat et en contact au maximum avec le plateau) et on exporte le fichier au format GCode. Pour le nommage du fichier : maximum 8 caractères, une extension « .G » et le tout en majuscules.

De nombreux réglages sont possibles avant de découper le modèle 3D, j’y reviendrai plus tard (j’ai notamment augmenté la température de mon plateau chauffant, les pièces ne tenaient pas assez bien). Pour mon premier essai, j’ai utilisé des couches de 0.3 mm.