Aller au contenu

GO Print

Priorité : firmware ou logiciel ?


Wanamoa

Messages recommandés

Bonsoir à tous,

Je remets les mains sur/dans ma Geeetech i3 pro B et j'ai toujours des questions sans réponse.

Contexte :

J'ai déjà modifié mon firmware et l'ai transféré vers l'imprimante. Jusqu'ici, j'ai toujours imprimé depuis l'ordinateur (Cura ou Repetier).

Des paramètres peuvent être fixés :

  • dans le logiciel
  • dans le firmware
  • via le lcd

Et c'est là que le brouillard s'épaissit... Je ne sais toujours pas quel mode a la priorité. Par exemple, hier j'ai imprimé via Repetier, et j'ai changé la vitesse d'extrusion en direct via Repetier, j'en ai vu l'impact.

Aujourd'hui, pour la toute première fois, j'ai tenté une impression depuis une carte SD. Comme d'habitude, je modifie sur le LCD le décalage en Z (qui n'est pas correct dans mon firmware, je dois le changer). Et là, cela ne semble pas avoir d'impact.

Habituellement, je tranche, je règle le décalage en Z via le LCD et je lance l'impression sans souci. Je précise que je ne sauvegarde jamais la configuration via le LCD.

Ce que je pense avoir compris sans certitude : lors de la modification du firmware sous Arduino et envoi vers la carte, il est chargé dans l'EEprom qui contient malgré tout une configuration d'usine. Lors d'une impression 3D en USB, les changements de paramètres apportés via logiciel ou LCD sont prioritaires sur le firmware.

Est-ce correct ? Quelqu'un peut-il éclairer simplement ma lanterne ?

Merci par avance !

Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, Wanamoa a dit :

Est-ce correct ?

Pas exactement ...

Tu a des paramètres  dans le firmware (ex Steps/mm pour chaque moteur), cela sont lue de l'eeprom (si tu en a une) au démarrage de la machine. Sinon il utilise les valeur en dure du firmware (se que tu a mis dans le Configuration.h ...)

En principe après une mise a jour de firmware il faut réinitialiser l'eeprom avec les valeur de paramètres en dure dans le firmware pour ne pas retrouver d'ancien valeur de paramétre qui ne sont peux etre pas adapté a se nouveau firmware. (un "reste factory" pour charger les paramètres d'usine / en dure du firmware  comme valeur de paramètre a utiliser (dans une mémoire volatile) suivie d'un "save eeprom" pour sauver les valeur des paramètres de cette mémoire volatil dans l'eeprom une mémoire non volatil) c-a-d les commande g-code M502 suivie de M500 )

  

Le 30/07/2020 at 17:01, fran6p a dit :

Bien qu'en anglais, cette vidéo explique un peu mieux ce qu'est un chargeur de démarrage (et accessoirement aussi ce qu'est une EEPROM) :

 

🙂

 

Le 31/07/2020 at 15:06, fran6p a dit :

Le M503 ne fait qu'afficher le contenu de la SRAM (mémoire de travail en gros)

Le M501 n'affiche rien, il récupère simplement les paramètres contenus dans l'EEPROM pour les mettre en mémoire de travail (SRAM)

La subtilité est que l'on peut très bien faire des modifications de paramètres (pour des tests par exemple), ces paramètres de «test» sont dans la RAM (pas la même chose que l'EEPROM). Tant que l'on n'enregistre pas ces nouvelles valeurs, le contenu de la RAM et de l'EEPROM sont différents. Un M500 permet l'enregistrement en mémoire non volatile (EEPROM).

Le M502 permet de récupérer les données du firmware (=paramètres usine (factory settings)) et les place en mémoire de travail. Pour réaliser une remise à zéro de la machine et les stocker dans l'EEPROM, on utilise la suite M502 puis M500 (où via l'écran avec l'option «Restore settings»),

🙂

 

Après via un trancheur, tu envoie des commande g-code et certaine commande g-code peuvent modifier les paramètres du firmware.

Si tu imprime en USB, quand tu modifie le débit, c'est surement le trancheur qui recalcule les extrusion a faire dans le "G1 ... E..." https://marlinfw.org/docs/gcode/G000-G001.html mais il peut aussi modifier la valeur du pourcentage du débit du firmware avec la commande g-code M221 https://marlinfw.org/docs/gcode/M221.html pour que se soit le firmware qui ajuste le débit ... mais alors tu devrait voir la valeur du flow via l'ecran de la machine ne plus etre a 100%.

Enfin, l’écran de l'imprimante au final sur nos machine grand public, c'est une interface qui ne fait qu'envoyer des commande g-code simple au firmware (un peux comme se qui passe par la connexion USB ... donc via l'ecran tu modifie aussi les paramétre du firmware ... )

 

Pour simplifier, au final c'est le firmware qui interprète les commandes g-code et qui a le dernier mot (mais un firmware en principe se trouve être du genre a faire se qu'on lui dit 🙂 ). mais si le trancheur adapte ses commande g-code (car impressions via un câble USB) forcement il semble prendre le dessus car il peut demander au firmware de modifier ses paramètres. Mais il passe toujours par le firmware.

 

J’espère ne pas t'avoir embrouillé et avoir bien expliqué ... sinon dit moi !

Modifié (le) par PPAC
Lien vers le commentaire
Partager sur d’autres sites

Salut @PPAC,

Merci pour cette réponse rapide.

Je vais aller regarder la vidéo mais je prends le temps d’abord de te répondre : certains points sont clairs’ d’autres moins pour être honnête.

Je joins un schéma de ce que je pense avoir compris, ce sera peut-être plus simple. Et je complète :

  • Sous Arduino, je modifie mon firmware puis je l’envoie vers la carte : est-il stocké en RAM jusqu’à ce qu’un M500 ne l’envoie dans l’EEPROM pour être définitivement sauvegardé comme configuration par défaut/usine ?
  • Depuis le trancheur, on modifie temporairement les valeurs en RAM ( à la volée).
  • Depuis le LCD, idem que pour le trancheur avec en plus la possibilité de sauvegarder ces paramètres modifiés dans l’EEPROM (comme si on re compilait un firmware).

Si tout cela est correct, lors d’une impression depuis la carte SD, tout changement via le LCD d’offset prend le pas sur celui stocké dans l’EEPROM ?

 

D0682452-6A80-461C-BAE8-FB812433A2B1.jpeg

Lien vers le commentaire
Partager sur d’autres sites

Je viens de regarder la vidéo que tu m’as conseillée : c’est beaucoup plus clair et je m’aperçois que mon schéma n’est pas tout à fait correct puisque je n’ai pas fait la distinction entre EEPROM et firmware en dur. Il y a donc 3 niveaux à considérer :

  • le firmware
  • la ram
  • l’eeprom

Merci pour ce lien qui me permet de mieux comprendre et de répondre à ma toute dernière question concernant le changement d’offset à la volée : oui, il devrait être pris en compte.

Correct ?

  • +1 1
Lien vers le commentaire
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...