Marlin : conseils et bonnes pratiques pour créer ou modifier des codes Mxxx

[electroremy]

Bonjour,

 

J'avance bien dans la modification du firmware de ma MK2s

 

J'en arrive à une situation où je met en place des fonctions qui ne sont pas prévues de base dans le Marlin, ou qui différent du comportement initial de ces fonctions.

J'aimerais que le nouveau firmware respecte les standards en vigueurs, donc à la recherche de bonnes pratiques si je dois créer des codes M personnalisés :

- quelles numéros de codes utiliser ?

- éventuellement, utiliser des codes existants avec un paramètre optionnel ?

 

Le but "idéal" serait :

- que l'imprimante reste compatible avec les slicers du commerce, 

- que mes GCODE restent compatibles avec les autres imprimantes non customisées

 

Voici un exemple concret :

J'ai utilisé deux broches d'entrée/sorties disponibles pour :

- piloter une alarme externe (état haut = normal, état bas = alarme)

- piloter un circuit externe qui mettra l'imprimante hors tensions avec un relais (état haut = normal, état bas = demande d'extinction)

Dans MARLIN, le code M81 permet d'éteindre l'imprimante. Mais j'ai trouvé préférable de faire la chose suivante :

- quand l'imprimante reçoit un M81, elle définit à true la valeur d'une variable "TURN_OFF_AFTER_PRINT"

- l'imprimante termine son impression

- ensuite, dès que l'impression est terminée, elle met à l'état bas la broche d'alarme

- une fois que la température de l'extrudeur est suffisamment basse pour que le ventilateur de la hotend s'arrête, alors l'imprimante met à l'état bas la broche d'autoextinction

Ce comportement me semble plus respectueux de l'imprimante, mais il diffère du code M81 original qui stoppe une impression en cours, coupe les actionneurs et éteint aussitôt l'imprimante. 

 

Autre exemple, moins critique : pouvoir changer l'état de la broche d'alarme dans le GCODE

Ce que j'aimerais c'est un code M qui met en route l'alarme, avec une action manuelle de l'utilisateur qui doit intervenir pour stopper l'alarme, sans pour autant que l'impression s'arrête.

Le but de ce code est de prévoir, en plus des codes de pause et de changement de couleur, la possibilité de "demander" à l'utilisateur de venir regarder l'impression à un moment particulier.

Il y a le code M300 qui fait un beep, ou encore le M240 qui déclenche un appareil photo, mais là aussi ce n'est pas la même chose.

 

A bientôt

 

[pommeverte]

Salut,

Je pense que le Gcode M42 (change l'état d'une sortie) répond à toutes tes questions.

Pour arrêter l'imprimante, tu pourrais avoir à la fin du Gcode de fin:

M104 R50; attend que la température de la buse soit à 50°C
M42 Pxx S0 ; mets la sortie xx à 0

Pour ce qui est de l'alerte, tu montes une sortie qui sera mise à 0 via l'action de l'opérateur sur l'écran.

Pour que ce soit plus convivial pour l'opérateur, tu peux ajouter un script post-production qui génère automatiquement les séquences précédentes

Modifié (le) il y a 2 heures par pommeverte

[electroremy]

il y a 29 minutes, pommeverte a dit :

Je pense que le Gcode M42 (change l'état d'une sortie) répond à toutes tes questions.

Le M42 (ainsi que le M43) c'est dangereux car on peut facilement piloter une pin qui n'est pas disponible ou réservée à un autre usage, en paramétrant mal le slicer ou en utilisant par erreur un CGODE destiné à une autre imprimante. Cela pourrait même endommager l'imprimante.

Les codes M42 et M43 ont même un paramètre pour shunter les protections de MARLIN 

Il faut un code M qui soit interprété par le firmware de l'imprimante, et que ce soit dans le firmware que la broche d'entrée/sortie correspondant à la fonction soit définie.

Ou alors, brider ces M42 et M43 pour que seules certaines pins soient acceptées, mais ce serait plus propre qu'un code Mxx pilote une fonction de l'imprimante 3D, et pas directement le hardware (je sais bien avec une imprimante 3D on est loin des 7 couches du modèle OSI mais autant bien faire )

D'ailleurs, je pense que je vais carrément désactiver les codes M42 et M43 dans ma version du firmware.

< MODE PARANO >

Des hackers mal intentionnés pourrait diffuser des GCODE avec des M42 ou M43 pour endommager des imprimantes, ou plus sournoisement apporter une modification à un slicer open source qui ajouterait ces instructions de sabotage selon certains critères. Il y a déjà eu des précédents de backdoors et codes malveillants ajoutés en douce dans des projets open source :

https://fr.wikipedia.org/wiki/Attaque_de_XZ_Utils_par_porte_dérobée

https://www.kaspersky.fr/blog/malicious-code-in-github/22611/

Je ne dis pas que les logiciels propriétaires sont mieux. Au contraire : impossible de savoir ce que les fabricants ont pu faire dedans.  Si vous avez une BambuLab, le PC Chinois vous observe 

Tout ceci aurait fait un bon épisode de X Files ou de Black Mirror

< / MODE PARANO >

 

Modifié (le) il y a 2 heures par electroremy

[pommeverte]

Honnêtement, j'ai du mal à te suivre . Tu es en train de développer un firmware que tu seras le seul à utiliser et avec du matériel que tu seras le seul à posséder.

<mode chambrage  >

Donc à moins que vous soyez plusieurs dans ta tête et que vous ne vous parliez pas , je ne vois pas vraiment les risques.

</mode chambrage>

Comme je l'ai écrit, le risque de se tromper dans l'utilisation du Gcode M42 peut être limité avec l'emploi de scripts. 

[Kachidoki]

Salut,

Comme tu le dis, tu es en mode parano. C'est comme vouloir empêcher l'utilisation la pédale d'accélérateur parce que quelqu'un pourrait par erreur (ou volontairement) appuyer dessus à fond jusqu'à claquer le moteur.

Un G-Code, c'est comme un .exe, on est pas censé utiliser du code machine provenant de n'importe où. Il y a certes quelques garde-fous dans le firmware, on peut même imaginer des anti-virus pour G-Codes à l'image de ce que fait Printables, mais le mieux reste toujours d'obtenir les sources et de le compiler le STL/STEP et de le slicer soi-même.

C'est quand même plus sympa d'avoir un maximum de contrôles possible pour ne pas être limité par le firmware, même si c'est à toi de faire attention aux paramètres que tu utilises dans ton slicer, octoprint ou tout autre système capable d'envoyer des commandes à la machine.

Pour l'extinction automatique, les imprimantes modernes possèdent des APIs permettant des intégrations sympa dans la domotique, dans Home Assistant par exemple : https://www.reddit.com/r/prusa3d/comments/1gh5qnr/finally_satisfied_of_my_home_assistant_dashboard/?show=original

Avec ça tu peux non seulement éteindre la machine en utilisant n'importe quelles conditions qui te plaisent, mais aussi la rallumer à distance pour lancer un préchauffage automatiquement. Pour faire ce lien tu peux utiliser un RPi avec PrusaLink, il est marqué compatible MK2.5 avec liaison USB, je suis presque sûr que ça fonctionne sur MK2 aussi en adaptant un peu le code. Ce sont quelques idées.

[electroremy]

il y a 11 minutes, pommeverte a dit :

Tu es en train de développer un firmware que tu seras le seul à utiliser et avec du matériel que tu seras le seul à posséder.

Alors justement, j'aimerais publier ce firmware.

 

L'imprimante fonctionne correctement même si les fonctionnalités suivantes ne sont pas câblées sur les entrées sorties :

- commande du chauffage de l'enceinte et mesure de la température de l'enceinte (il suffit simplement que le GCODE ne contienne pas les commandes liées au chauffage de l'enceinte, l'imprimante fonctionnera sans se mettre en sécurité tant que la consigne de température de l'enceinte reste à zéro)

- alarme externe, c'est juste une sortie, et les messages d'erreurs continuent à s'afficher sur l'écran et à faire beeper l'imprimante

- broche de mise hors tension, c'est juste une sortie

- broche pour watchdog externe, c'est juste une sortie qui change d'état 6 fois par seconde à chaque fois que l'imprimante vérifie le bon fonctionnement des CTN et l'absence d'anomalie thermique (et à la limite on peut juste câbler une LED avec une résistance sur cette entrée pour surveiller de loin)

- capteur de filament, il suffit de shunter l'entrée à la masse

 

En plus de ces fonctionnalités optionnelles, ce firmware apporte des améliorations :

- utilisation d'une sonde SUPERPINDA

- détection rapide de la rupture du câble d'une CTN et arrêt de la chauffe (ce que l'imprimante ne faisait pas avant, elle se mettait en surchauffe).

- après une détection d'une anomalie thermique (coupure d'une CTN, court-circuit d'une CTN ou bien surchauffe), le ventilateur de la hotend reste allumé (alors qu'avant il ne se déclenchait pas ou bien il ne se mettait en route que brièvement)  

 

La seule modification physique obligatoire pour installer ce firmware sur l'imprimante c'est le remplacement de la PINDA V1 par une SUPERPINDA

Je peux aussi faire une version qui fonctionnera avec la sonde PINDA V1 d'origine

 

Ce firmware pourrait intéresser quelques personnes. Lors de mes recherches sur Internet je suis tombé sur plusieurs posts en anglais de personnes

- cherchant à installer une SUPERPINDA sans devoir faire toute la mise à jour vers la MK2.5s+

- se plaignant de la mauvaise voire de l'absence de détection des défaillances des CTN, avec à la clef des imprimantes qui ont pris feu

Alors oui, il est probable que depuis, tout ces utilisateurs de MK2 ou MK2s aient acheté une autre imprimante... Mais pour ceux qui les ont gardé, ou les étudiants ou associations désargentés qui en ont récupéré une pour pas cher, ce serait possiblement utile.

 

C'est aussi dans le principe de l'open source. Ce serait un peu égoïste de garder ces modifs pour moi tout seul. En utilisant cette imprimante j'ai bénéficié des apports de la communauté open source, il est légitime que si je trouve des améliorations, qu'elles soient partagées.

 

Enfin, un de mes passe-temps favori est de rénover des objets anciens comme du vieux matériel HiFi, des outils mécaniques anciens. Même si ma MK2s est dépassée elle fonctionne encore et mérite elle aussi une mise à niveau 

Je me suis bien amusé ces derniers jours en modifiant mon imprimante

 

il y a 20 minutes, Kachidoki a dit :

Un G-Code, c'est comme un .exe, on est pas censé utiliser du code machine provenant de n'importe où. Il y a certes quelques garde-fous dans le firmware, on peut même imaginer des anti-virus pour G-Codes à l'image de ce que fait Printables, mais le mieux reste toujours d'obtenir les sources et de le compiler le STL/STEP et de le slicer soi-même.

C'est quand même plus sympa d'avoir un maximum de contrôles possible pour ne pas être limité par le firmware, même si c'est à toi de faire attention aux paramètres que tu utilises dans ton slicer, octoprint ou tout autre système capable d'envoyer des commandes à la machine.

Je pense que l'imprimante doit être intrinsèquement protégée au maximum contre les fausses manip.

Si le firmware est bien fait, on peut avoir à la fois une imprimante sécurisée et des fonctionnalités complètes. C'est un peu plus long à faire mais c'est plus intéressant aussi.

Même si je suis le seul utilisateur, je suis comme tout le monde, je fais des erreurs, c'est mieux pour moi  

 

Par exemple, heureusement que j'avais prévu un code "parano ceinture et bretelles" pour garder des copies "n-1" et "n-2" de la base de données de mon site photo perso, car j'ai failli tout écraser plus d'une fois  et j'aurais jamais eu le courage de tout refaire depuis zéro.

Pour ce qui est du bricolage mécanique, des précautions à priori superflues ou ridicules m'ont déjà évité de perdre des doigts ou un œil.   

 

Bref c'est important... de se protéger contre soi-même. Les fois où je me suis retrouvé le plus en danger c'était de ma faute, pas celle des autres ni de la nature.