Elegoo Neptune 4 Pro + OpenNept4une : le reflash d’eMMC qui change tout

Voilà un peu plus d’un an que mon Elegoo Neptune 4 Pro tourne à la maison. Une excellente imprimante 3D pour le prix, mais avec un défaut bien connu de toute la gamme Neptune 4 : un firmware d’usine fermé, limité, et pas franchement taillé pour qui aime mettre les mains dans le cambouis. En décembre 2025, je me suis enfin lancé dans le reflash complet de l’eMMC avec OpenNept4une. Verdict : un sacré plan galère sur le moment, mais une machine transfigurée une fois de l’autre côté.

Pourquoi reflasher une imprimante qui fonctionne déjà ?

Le Neptune 4 Pro n’est pas une imprimante 3D « bête » : sous le capot, sa carte mère — une Makerbase MKS-Pi, avec un SoC Rockchip RK3328 (ARM Cortex-A53 quad-core) — fait tourner un vrai petit Linux embarqué, avec Klipper comme firmware d’impression — pendant qu’un microcontrôleur STM32F401 séparé (cadencé à 84 MHz, relié en série) s’occupe de la partie temps réel (pilotage des moteurs X/Y/Z, régulation des chauffes). Sur le papier, livrer Klipper de série est une bonne nouvelle : c’est un firmware open source puissant, avec une interface web (Mainsail ou Fluidd), une API (Moonraker) et de solides capacités de calibration. Le problème, c’est qu’Elegoo livre ce Klipper… en cage : version figée et impossible à mettre à jour, Moonraker modifié avec des fonctions propriétaires, accès root restreint ou inexistant, certains plugins Klipper bloqués ou absents, interface Mainsail repeinte avec des menus Elegoo, et des mises à jour qui ne passent que par le canal OTA maison du fabricant. Le matériel est bon ; c’est le logiciel qui est en cage.

OpenNept4une est un projet communautaire open source qui remplace ce firmware d’usine par un environnement Klipper « normal » et entièrement ouvert, construit sur Armbian (un Debian pour cartes ARM) : Klipper officiel mis à jour par simple git pull, Moonraker et Mainsail non patchés, KlipperScreen sur l’écran tactile d’origine, Crowsnest pour la webcam, accès SSH root complet, et surtout la possibilité de mettre à jour chaque brique indépendamment — et d’installer n’importe quel plugin de l’écosystème Klipper — plutôt que d’attendre le bon vouloir du fabricant.

Le cœur du problème : l’eMMC

Sur cette carte MKS-Pi, le système ne tourne pas depuis une carte SD classique mais depuis une puce eMMC. Et c’est là qu’Elegoo a eu la bonne idée : contrairement à beaucoup de cartes similaires où l’eMMC est directement soudée (rendant tout reflash nettement plus hasardeux, voire impossible sans repasser par un mode de récupération USB bas niveau type FEL), celle du Neptune 4 se trouve sur un petit module amovible, au format proche d’une carte eMMC/microSD — un peu comme sur un Raspberry Pi Compute Module. Pour y installer OpenNept4une, il n’y a donc pas besoin de fer à souder : il suffit de sortir ce module de la carte mère, de le flasher depuis un PC via un adaptateur USB dédié, puis de le remettre en place. J’en ai d’ailleurs profité pour changer le module au passage : l’eMMC d’origine du Neptune 4 Pro ne fait que 8 Go, franchement juste une fois Klipper, Mainsail et quelques logs installés — je l’ai remplacée par un module de 32 Go, histoire d’avoir de la marge pour la suite.

C’est précisément là que ça se corse :

Démontage physique : panneau du bas à retirer, vis minuscules faciles à perdre, nappes à débrancher avec précaution.
Emplacement peu évident du port microSD servant à flasher le firmware du contrôleur moteur (MCU) : sur le Neptune 4 Pro, pas besoin de démonter toute la façade avant comme sur d’autres modèles de la gamme — il suffit de dévisser les vis qui maintiennent la carte mère et de la soulever légèrement pour accéder au lecteur SD en dessous, sans tout démonter.
Adaptateur spécifique requis pour connecter le module eMMC en USB sur un ordinateur (lecteur eMMC/microSD, une petite dizaine d’euros, mais encore faut-il l’avoir sous la main avant de démonter quoi que ce soit).

Le conseil que j’aurais aimé lire avant de commencer : sauvegardez votre configuration avant de toucher à quoi que ce soit. Une fois l’eMMC reflashé, tout repart de zéro — y compris les calibrations. Klipper expose tout via Moonraker, donc tout est récupérable en SSH ou depuis l’interface web : printer.cfg (la configuration principale — pins, steppers, thermistances, endstops, cinématique CoreXY, macros, sans lequel l’imprimante ne démarre même pas), moonraker.conf, saved_variables.cfg, le dossier .moonraker_database/ (historique des impressions), et toutes les données de calibration (bed_mesh, input_shaper, pressure_advance, z_offset, PID). Une simple archive tar czf backup_neptune_$(date +%Y%m%d).tar.gz ~/printer_data/config/ ~/printer_data/database/ suffit à tout mettre de côté avant de flasher.

Le déroulé, une fois le module en main

Dans les grandes lignes, la procédure suit ce schéma :

Flasher l’image OpenNept4une correspondant exactement au modèle (Neptune 4, 4 Pro, 4 Max et 4 Plus ont chacun leur propre image) sur le module eMMC, via balenaEtcher ou un bon vieux dd sous Linux.
Remettre le module en place, rebrancher, démarrer — l’écran tactile ne répond généralement pas encore à ce stade, c’est normal, la vraie interface n’est pas encore installée dessus.
Se connecter en SSH (ou en console série si le réseau ne répond pas) pour lancer le script d’installation OpenNept4une à proprement parler, qui met en place Mainsail, KlipperScreen et la configuration de base.
Flasher séparément le firmware du MCU (la carte qui pilote directement moteurs et chauffes) via la carte microSD accessible en soulevant légèrement la carte mère, une fois ses vis de fixation retirées.
Étendre le système de fichiers pour exploiter toute la capacité du nouveau module eMMC — passer de 8 à 32 Go ne sert à rien si l’image flashée, elle, reste calée sur la taille d’origine.
Tout recalibrer : niveau du lit, décalage de buse, PID des chauffes, input shaping si la carte le permet.

Rien d’insurmontable pris étape par étape, mais la combinaison « démontage mécanique minutieux + manipulation bas niveau d’un support de stockage + recalibration complète » fait que la première tentative prend clairement plus de temps qu’annoncé — d’où le « sacré plan galère » du début de cet article.

Après le premier boot : sept erreurs, une par une

Le flash en lui-même est la partie facile — écrire l’image sur l’eMMC ne prend que quelques minutes. Le vrai travail commence après : OpenNept4une démarre avec une configuration générique pour le Neptune 4 Pro, une base propre mais qui ne connaît rien des réglages propres à cette machine précise. Les erreurs sont arrivées dans cet ordre, et chacune s’est réglée avant de pouvoir passer à la suivante :

Incompatibilité de firmware MCU : le Klipper qui tourne sur la carte MKS-Pi et le firmware installé sur le STM32F401 (la carte qui pilote moteurs et chauffes) n’étaient plus à la même version après le flash. Il a fallu recompiler le firmware Klipper pour ce STM32 précis (make menuconfig puis make) et le reflasher via la procédure DFU/carte SD du MCU.
Thermistance non reconnue : le Neptune 4 Pro utilise des thermistances spécifiques (NTC 100k avec une table propre à Elegoo) ; si le sensor_type exact n’est pas renseigné dans printer.cfg, Klipper refuse tout simplement de chauffer, par sécurité.
Décalage du palpeur (CR Touch) : le z_offset et les coordonnées du palpeur dépendent du montage physique exact — recalibration complète via PROBE_CALIBRATE puis SAVE_CONFIG.
Input shaping à refaire : la compensation de résonance s’appuie sur une mesure physique prise avec l’accéléromètre ADXL345 intégré ; les valeurs de l’ancienne configuration ne sont pas transférables — nouvelle mesure via SHAPER_CALIBRATE.
Carte de nivellement invalide : le bed mesh est lié à la géométrie réelle de la machine, impossible de le reporter d’un flash à l’autre — BED_MESH_CALIBRATE depuis zéro.
Macros absentes ou incompatibles : les macros Elegoo (START_PRINT, END_PRINT) ont une syntaxe maison — il a fallu les réécrire en Klipper pur plutôt que de compter sur celles fournies par le slicer habituel.
Services qui ne démarrent pas : webcam et timelapse restaient silencieux au premier boot, faute des bonnes permissions ou d’un service systemd pas encore activé.

Dans chaque cas, Klipper a l’avantage d’afficher des messages d’erreur explicites et bien documentés dans ses logs — ce qui transforme un dépannage qui pourrait être angoissant en une liste de cases à cocher, une par une.

Le résultat : une autre imprimante

Depuis, la différence est nette. L’interface Mainsail en fait une machine qu’on pilote vraiment, avec un suivi en temps réel de l’impression, des réglages d’input shaping accessibles sans bidouiller des fichiers cachés, et surtout la liberté de mettre à jour Klipper, Mainsail ou KlipperScreen indépendamment, au rythme des projets communautaires — plutôt que d’attendre une improbable mise à jour officielle Elegoo.

Et maintenant : la liste des prochaines étapes

Avec une base saine, quelques idées restent sur la liste pour la suite : versionner printer.cfg dans un dépôt git privé pour garder l’historique de chaque réglage changé ; activer le plugin Exclude Objects (nativement supporté par Klipper) pour pouvoir exclure une pièce ratée en cours d’impression sans tout arrêter ; mettre en place le timelapse automatique via Moonraker ; brancher des notifications de fin d’impression (Telegram ou ntfy.sh, toujours via Moonraker) ; et peut-être essayer Orca Slicer à la place de Cura pour profiter des macros Klipper plus avancées. Le multi-matériau avec un MMU reste une option, si le besoin se présente un jour.

Si vous avez un Neptune 4 (Pro, Max ou Plus) qui dort sur son firmware d’origine, le jeu en vaut clairement la chandelle. Pour la procédure exacte et à jour — les images et scripts évoluent régulièrement — direction le wiki officiel du projet OpenNept4une, bien plus fiable qu’un article figé dans le temps sur les commandes précises à taper.