Problème Steps par mm

[Murdock]

il y a 7 minutes, vap38 a dit :

Question est-elle compatible pour le LCD en 4.3 pouce ? pour la mise à jour; je serai curieux de voir la différence.

4.3 ?? c'est l'écran standard ? En tous cas tu as les firmwares des écrans TJC et DWIN qui sont à ma connaissance les seuls qui sont montés par Tenlog. 

[methylene67]

Merci.

[methylene67]

Salut @Murdock,

Petite question, au lieu de flasher le firmware, est-ce qu'un G92 Y 80.18 en début de gcode permet de forcer le gcode de la machine ?

Ou bien le home de début d'impression (G28) reset-il le G92 ?

Et si tel est le cas, n'est-il pas possible de placer les G92 après le G28 ?

Modifié (le) Avril 10, 2021 par methylene67

[Murdock]

il y a 3 minutes, methylene67 a dit :

Salut @Murdock,

Petite question, au lieu de flasher le firmware, est-ce qu'un G92 Y 80.18 en début de gcode permet de forcer le gcode de la machine ?

Ou bien le home de début d'impression reset-il le G92 ?

Hello !

Alors, la question est pertinente. Déjà pour fonctionner la commande doit être après le G28 dans le script de démarrage. Cependant je n'ai pas vérifié dans les dernières versions mais sur la 1.0.10 et antérieur c'est certain, dès que tu envoies une comme G92 ... la machine fais un m500 derrière pour que les changement opérés par l'écran soient immédiatement stockés. Bon ils aiment se faire mal car sur la validation d'un paramètre il suffisait  d'envoyer deux commande G92 ... puis M500 mais à la place ils ont modifié le comportement du G92 dans marlin. Tu vas me dire ou est le problème ? Eh bien c'est qu'une eeprom à un nombre max de cycles d'écriture. Bon ok il est assez élevé mais tout de même le nombre de lancement de prints combiné au nombre de changements volontaires de paramètres cela va faire grimper les cycles. Donc sachant qu'une toute petite intervention dans la source corrige le problème, je préfère le faire proprement. Cela dit cela fonctionnera. Tant qu'un nouveau G28 n'est pas envoyé, la valeur sera bonne.

Pour voir si le firmware réagit toujours dans les dernières versions de la façon citée plus haut, c'est facile. Tu connecte ta machine à un ordinateur, et en terminal tu envoies une comme G92 Y80 par exemple. Si dans la réponse tu as un truc du genre "settings stored" c'est que c'est encore le cas.

[methylene67]

Merci pour ta réponse.

Dans mon Gcode de démarrage sur mon ender3, je change mes steps de cette façon mais sans enregistrement dans l'Eeprom (pas de M500). Ces valeurs sont juste utilisées pour le print (et en soi c'est comme si c'était dans l'Eeprom sans écriture vu que c'est dans le code de démarrage de chaque print).

Effectivement, ta modification est largement plus propre, mais pour le moment je n'ai pas encore eu le temps de mettre à jour le firmware (parce qu'il va falloir avant de le flasher que je sauvegarde mes firmwares d'origine en cas de bug, et ça je ne sais pas faire, il faut que je regarde sur internet, si on peut "téleverser l'Eeprom dans un dossier de sauvegarde").

Donc inverser la ligne G28 avec les M92 serait une solution (même que le M92Y je dirais même).

Révélation

 

; Ender 3 Custom Start G-code

M92 X80.1 ; steps moteur axe X

M92 Y80.1 ; steps moteur axe Y

M92 Z400.2 ; steps moteur axe Z

M92 E94.92 ; steps moteur Extrudeur

M203 E70 ; Vmax Extrudeur

G28 ; Home all axes

M140 S{material_bed_temperature} ;Start heating bed

M190 S{material_bed_temperature} ;Wait for bed to reach temp before proceeding

G29;

M104 S{material_print_temperature} ;Start heating extruder

M109 S{material_print_temperature} ;Wait for extruder to reach temp before proceeding

G1 Z1;

G1 Z15 F6000 ; Z @15mm ;Prime Extruder

G92 E0 ; Reset Extruder

G1 F200 E3;

G1 Z5.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed

G1 X0.1 Y20 Z0.3 F5000.0 ; Move to start position

G1 X0.1 Y200.0 Z0.3 F1500.0 E15 ; Draw the first line

G1 X0.4 Y200.0 Z0.3 F5000.0 ; Move to side a little

G1 X0.4 Y20 Z0.3 F1500.0 E30 ; Draw the second line

G92 E0 ; Reset Extruder

G1 Z5.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed

 

Modifié (le) Avril 10, 2021 par methylene67

[Murdock]

il y a 1 minute, methylene67 a dit :

Dans mon Gcode de démarrage sur mon ender3, je change mes steps de cette façon mais sans enregistrement dans l'Eeprom (pas de M500). Ces valeurs sont juste utilisées pour le print (et en soi c'est comme si c'était dans l'Eeprom sans écriture vu que c'est dans le code de démarrage de chaque print).

Oui voilà dans un firmware "standard" pas de soucis. 

il y a 6 minutes, methylene67 a dit :

'il va falloir avant de le flasher que je sauvegarde mes firmwares d'origine en cas de bug

pour la carte mère oui c'est possible de le faire avec un petit script (C'est pas hyper hyper complexe mais tout dépend de tes compétences en informatique) cependant, vu le peu de choses qui ont changées dans le firmware tu n'auras pas de bug.  Pour l'écran c'est plus compliqué. J'ai quelques versions d'origine de chez tenlog qui trainent sur mon serveur dis moi quelles sont tes versions d'origine de carte mère et écran je regarderai si je les possède et si c'est le cas je te les enverrai.

[Murdock]

il y a 14 minutes, methylene67 a dit :

Donc inverser la ligne G28 avec les M92 serait une solution (même que le M92Y je dirais même).

Tu mets le G28 tout en haut.

Modifié (le) Avril 10, 2021 par Murdock

[methylene67]

il y a 2 minutes, Murdock a dit :

Tu mets le G28 tout en haut.

Oui c'est bien la méthode pas propre.

Merci.

Mes compétences en informatiques, je me débrouille en dehors de la programmation (sauf un peu de vbnet et de vba, et quelque base en html, et css).

Full capteurs optiques. Par ailleurs est-ce possible de compiler ton firmware modifié sans le bug du G28 avec Arduino (le configuration h avec marlin puis de l'enregistrer et le transférer à la carte mère via le logiciel de Tenlog (Tenlog Firmware Burner) ? J'imagine que oui.

Pour mes versions de firmware les voici :

[Murdock]

il y a 19 minutes, methylene67 a dit :

Pour mes versions de firmware les voici :

 

Non je n'ai pas cela. Je peux te fournir un script pour extraire le firmware de la carte mère, mais pas celui de l'écran donc vu que les deux vont ensembles ... Ca n'aidera pas des masses.

Avant sur le drive de tenlog il y avait toutes les versions, mais ils ont tout viré ...

il y a 27 minutes, methylene67 a dit :

Par ailleurs est-ce possible de compiler ton firmware modifié sans le bug du G28 avec Arduino (le configuration h avec marlin puis de l'enregistrer et le transférer à la carte mère via le logiciel de Tenlog (Tenlog Firmware Burner) ? J'imagine que oui. Dans le menu croquis 

Bien que je ne vois pas l'avantage car arduino peut tout a fait téléverser dans la carte mère, oui (je n'ai jamais utilisé leur outils mais un autre (xloader) mais si celui de tenlog prend les fichier hex normalement pas de pb pour ce faire dans le menu croquis d'Arduino tu cliques sur "Exporter les binaires compilées" Cela te créra un fichier nommé "Marlin.ino.maga.hex". Tu pourras uploader ce fichier.

[methylene67]

Il y a 9 heures, Murdock a dit :

Non je n'ai pas cela. Je peux te fournir un script pour extraire le firmware de la carte mère, mais pas celui de l'écran donc vu que les deux vont ensembles ... Ca n'aidera pas des masses.

Avant sur le drive de tenlog il y avait toutes les versions, mais ils ont tout viré ...

Bien que je ne vois pas l'avantage car arduino peut tout a fait téléverser dans la carte mère, oui (je n'ai jamais utilisé leur outils mais un autre (xloader) mais si celui de tenlog prend les fichier hex normalement pas de pb pour ce faire dans le menu croquis d'Arduino tu cliques sur "Exporter les binaires compilées" Cela te créra un fichier nommé "Marlin.ino.maga.hex". Tu pourras uploader ce fichier.

En effet je cherche un peu beaucoup à me compliqué la vie.

Oui en effet, il faut le demander maintenant par mail il y a plus rien sur leur drive (je viens de leur envoyer un mail).

Pour ton script, comment je le fait fonctionner ? Un simple Exe (ce serait trop simple et puis si je ne récupère pas le firmware de l'écran .. ne te casse pas la tête du coup) ?

Par contre en relisant ton post initial, j'avais loupé ça :

Si je comprends bien, un M92 stock de base dans l'EEprom (même sans M500) ? Combien de cycle de stockage sur la carte mère ?

D'où l'utilité de flasher la mise à jour de ton firmware modifié ...

[Murdock]

Il y a 2 heures, methylene67 a dit :

En effet je cherche un peu beaucoup à me compliqué la vie.

T'inquiètes pas, je suis champion pour ça donc je comprends.

Il y a 2 heures, methylene67 a dit :

Pour ton script, comment je le fait fonctionner ? Un simple Exe (ce serait trop simple et puis si je ne récupère pas le firmware de l'écran .. ne te casse pas la tête du coup) ?

Bhen tu es pas loin. En fait j'ai créé un simple fichier bat qui utilise "avrdude" dans une invite de commande tu appels le bat en passant en argument le numéro du port com de ton imprimante. Par exemple si le script s'appel "ReadMobo.bat" et que ton imprimante est sur le com6, tu appels :

ReadMobo.bat 6

et c'est tout.

Cela te crée un fichier hex qui contient la flash et un second pour le contenu de l'eeprom. Bon le second tu t'en fou un peu. Mais quand j'avais créé ce script j'en avais besoin.

Il y a 2 heures, methylene67 a dit :

Si je comprends bien, un M92 stock de base dans l'EEprom (même sans M500) ?

Oui sur les version plus anciennes du firmware tenlog c'était le cas. Je ne sais pas si c'est encore le cas sur le versions supérieur à la 1.0.16, car ayant corrigé le pb du Y je ne m'en souciait plus. (Et en ce moment je ne suis plus sur un firmware dérivé de celui de tenlog donc je ne peu vérifier pour le moment.)

Il faudrait vérifier.

Il y a 2 heures, methylene67 a dit :

Combien de cycle de stockage sur la carte mère ?

La réponse n'est pas vraiment précis en gros atmel (le constructeur de l'atmega 2560) garanti que chaque bloque de la mémoire peut être écrit minimum 100 000 fois. (ce qui est à la fois beaucoup est peu)

Donc ce bloc pourra "mourir" à 100 001 ou 150 000 ...

Une bonne gestion de la mémoire doit vérifier si la valeur à changée avant de l'écrire pour ne la changer que ci c'est nécessaire (Si la valeur est différente en gros) et dans ce cas cela n'est plus trop un problème. Mais honnêtement je n'ai pas regardé si cela était correctement géré dans leur firmware. Et encore une fois, il vu qu'il suffisait d'une correction mineure pour solutionner proprement le problème je n'ai pas cherché de palliatifs "dégradé" pour corriger un truc qui pouvait l'être proprement.

Modifié (le) Avril 11, 2021 par Murdock

[methylene67]

Salut @Murdock

Aurais-tu finalement testé et corrigé la version 1.0.20 du firmware ? Je devrais flasher l'écran et la CM ce week-end car je vais réouvrir le boitier (et installer la rallonge de carte), il fallu que j'en fasse un pour ma rallonge qui était une rallonge SD et non une micro SD (car le fichier que tu m'avais fourni était du coup trop petit).

Par ailleurs, saurais-tu si on peut activer le réglage du PID du bed, car de base ce n'est pas possible, fran6p le disait dans un poste Tenlog je ne sais plus lequel (le M303 tourne en boucle si j'ose dire), et chez moi les buses sont stables mais le bed oscille de 0/+5° (bon je vais poser une plaque de liège ce week-end ça devrait déjà diminuer cet effet).

[Murdock]

Hello @methylene67désolé pour cette réponse tardive. Non je n'ai pas testé mais @vap38 à reporté la modif dans le programme et semble satisfait.

Il y a 11 heures, methylene67 a dit :

Par ailleurs, saurais-tu si on peut activer le réglage du PID du bed

Oui dans le fichier configuration_xy.h il doit y avoir une ligne dans ce genre :

 

//#define PIDTEMPBED

II suffit de la transformer en :

//#define PIDTEMPBED Cependant sur des vieilles versions de marlin comme celle-ci je ne me rappel plus si elle était parfaitement au point. A tester donc avec prudence !

[methylene67]

Réponse tardive réponse tardive ... c'est un forum d'entraide et il n'y a pas d'urgence, donc nullement besoin de t'excuser. On est pas au travail, et je peux t'assurer qu'au boulot beaucoup sont bien moins réactifs que toi !

C'est donc déjà gentil de répondre, et puis tardive quand tu réponds après 12h j'appelle ça plus que correct .

Du coup la modification pour les steps du Y c'est aussi dans le configuration.h si j'ai bien compris. Je relirai ton post initial ce weekend.

[Murdock]

Il y a 11 heures, methylene67 a dit :

Du coup la modification pour les steps du Y c'est aussi dans le configuration.h si j'ai bien compris.

 

Si tu veux "patcher" la 1.0.20 pour le problème du y, je te joint les instructions simples envoyées à @vap38, c'est très simple en ligne 2793  du fichier marlin_main.cpp tu as ceci :

int Y_step_per_unit = axis_steps_per_unit[Y_AXIS];

tu le modifies en ce ci :

float Y_step_per_unit = axis_steps_per_unit[Y_AXIS];

Et c'est tout. Il faudra bien sur recompiler.

Bons prints,

[merlinx]

Je viens de lire ce post car je suis les mains dans ce camboui les step/mm.

Si ça fonctionne comme tu décris Murdock, si je mets 80.32 dans mon Y et que je fais un G28 ensuite ça remet 80 dans mon Y. Si j'avais mis 81.39 ça m'aurait remis 81.

Donc en faisant un M503 pour afficher les param je devrais voir ce problème ?

[Murdock]

Il y a 3 heures, merlinx a dit :

Donc en faisant un M503 pour afficher les param je devrais voir ce problème ?

hmm bonne question et je n'ai plus ce firmware pour tester. De prime abord j'aurais été tenté de dire oui  car dans les versions actuelles de marlin le M503 lit la "SRAM" je dirais oui. Mais dans cette version je n'en suis pas certain. Pour être certain que cela ne fonctionne pas je n'avais trouvé que deux options :

- Tu fais un print, tu mesures la dimension en y, tu modifies de quelques dixième (sans passer à l'arrondi supérieur) la valeur des steps/mm en y tu reprint et tu vois que la dimension n'a pas bougée.

- Tu places un instrument de mesure le long de l'axe y, tu fais un déplacement de par exemple 10mm, tu regardes le déplacement réel tu modifies de quelques dixième (sans passer à l'arrondi supérieur) la valeur,  tu remesure le déplacement de 10mm (sans refaire de g28) tu vois que cela semble avoir fonctionné et à sans remodifier tu fais un g28 et tu refais ta mesure. et hop tu reviens à la valeur mesurée initialement.

En fait tant que les steps/mm que tu rentre sont entre 80 et 80.99 la valeur retenue sera 80, puis tant que c'est 81 à 81.99 c'est 81 et ainsi de suite.

Pour que ce soit parlant, j'ai reproduit dans un petit prog la séquence de homing de l'axe Z en injectant à chaque fois une valeur de steps/mm incrémentée de 0.01 et j'ai fais s'afficher a chaque fois la valeur utilisée au départ (en float) et la même après le passage en int. J'ai injecté le tout dans atmega 2560. (identique à la tenlog)

Cela illustre parfaitement mon propos.

Modifié (le) Avril 16, 2021 par Murdock

[merlinx]

il y a 8 minutes, Murdock a dit :

- Tu places un instrument de mesure le long de l'axe y, tu fais un déplacement de par exemple 10mm, tu regardes le déplacement réel tu modifies de quelques dixième (sans passer à l'arrondi supérieur) la valeur,  tu remesure le déplacement de 10mm (sans refaire de g28) tu vois que cela semble avoir fonctionné et à sans remodifier tu fais un g28 et tu refais ta mesure. et hop tu reviens à la valeur mesurée initialement.

C'est pour ça que je me suis retrouvé dans ce post. J'ai utilisé la solution du pied à coulisse numérique pour mesurer mes déplacements. Et je ne comprenais rien aux résultats que je trouvais. Un coup ça bougeait, un coup non, un coup dans le mauvais sens ... Bref je me suis arraché tous les cheveux !

Maintenant, te dire si je faisais un home avant ou après avoir modifié mes paramètres, je ne me souvient plus puisque je ne pensais pas que ça pouvait influer sur le résultat. Je sais que je faisait un home à chaque mesure pour remettre mon Y à 0 automatiquement mais avant ou après la modif du paramètre ???!? j'en sais rien. Maintenant je suis bon pour refaire des essais en faisant attention à tout ça.

MERCI !

Modifié (le) Avril 16, 2021 par merlinx

[Murdock]

il y a 14 minutes, merlinx a dit :

C'est pour ça que je me suis retrouvé dans ce post. J'ai utilisé la solution du pied à coulisse numérique pour mesurer mes déplacement. Et je ne comprenais rien aux résultats que je trouvais. Un coup ça bougeait, un coup non, un coup dans le mauvais sans ... Bref je me suis arraché tous les cheveux !

Maintenant, te dire si je faisais un home avant ou après avoir modifié mes paramètres, je ne me souvient plus puisque je ne pensais pas que ça pouvait influer sur le résultat.

C'est exactement ce qui m'a poussé à jeter un œil dans le firmware de chez tenlog. Et là quand j'ai vu cette erreur    J'ai tout compris !

Et comme tu dis quand on fait plein de tests on finit par ne plus savoir ce que l'on a fait avant, après ... Et on en revient à la bonne vielle méthode pragmatique on reprend tous les test en notant sur un papier à chaque fois tout ce que l'on fait. De cela, ont peu enfin en tirer une théorie que l'on vient vient confirmer par une nouvelle série de tests ... 

il y a 14 minutes, merlinx a dit :

Je sais que je faisait un home à chaque mesure pour remettre mon Y à 0 automatiquement mais avant ou après la modif du paramètre ???!?

Surement après je dirais. (Comme moi) et c'est après en refaisant les tests sans faire de home que je me suis aperçu que cela fonctionnait. Donc le problème était forcément dans le G28...

Comme je le dis souvent à mon équipe de développeurs pour trouver un bug, pas le choix il faut tester, tester et encore tester. (En ayant une approche pragmatique) 

Modifié (le) Avril 16, 2021 par Murdock

[merlinx]

Il y a 4 heures, Murdock a dit :

Donc en faisant un M503 pour afficher les param je devrais voir ce problème ?

Bingo !! Je viens d'essayer.

Je mets 80.39 dans le Y steps.

Je fais un M503 : tout va bien j'ai bien ma ligne :    Recv: echo: M92 X80.35 Y80.39 Z792.00 E102.00

Je fais un home (ou un G28)

Je refais un M503 : tout va mal j'ai :    Recv: echo: M92 X80.35 Y80.00 Z792.00 E102.00

Grrrrr : j'ai pas envi de flasher mon firmware juste pour ça d'autant plus que je devrais aussi faire l'écran et donc ouvrir l'imprimante !! Galère.

[methylene67]

Dans ce cas tu peux faire comme j'ai dit plus haut, Gcode de démarrage :

M92 X80.35 Y80.39 Z792.00 E102.00

Ou 

M92 X80.35

M92 Y80.39

M92 Z792.00

M92 E102.00

Et surtout à place après le dernier G28 du gcode de démarrage.

C'est la méthode pas propre d'un point de vue programmation, mais ça évite de flasher.

Modifié (le) Avril 16, 2021 par methylene67

[merlinx]

Oui mais je suis sensible au nombre limite de sauvegarde d'une EEPROM. Ca va me stresser d'avoir ça à chaque print.

Je vais plutôt essayer de l'intégrer dans mon slicer ... c'est guère plus propre mais bon, je suis en train de chercher la petite bête puisqu'il faut que je mette 100.50% sur la compensation sur Y. Je vais tester ça.

[Murdock]

il y a 10 minutes, merlinx a dit :

Grrrrr : j'ai pas envi de flasher mon firmware juste pour ça d'autant plus que je devrais aussi faire l'écran et donc ouvrir l'imprimante !! Galère.

Au pire profites-en pour monter un lecteur externe sur l'écran... Comme cela tu pourras changer à volonté sans démonter. Et comme cela tu seras prêt pour quand marlin 2.0.7.x sera parfaitement au point !

[merlinx]

il y a 5 minutes, Murdock a dit :

Au pire profites-en pour monter un lecteur externe sur l'écran... Comme cela tu pourras changer à volonté sans démonter. Et comme cela tu seras prêt pour quand marlin 2.0.7.x sera parfaitement au point !

Vi je sais, mais je ne suis pas un fan des upgrades à tout va, donc pour moi c'est secondaire sauf lorsque ça apporte un vrai plus. Mon anet A8 a un firmware qui a au moins 5 ans ! et elle tourne comme un montre.

Comme j'utilise Octoprint la plupart des fonctions de pilotage de la machine sont dans Octoprint et non sur l'écran pour moi. Donc la couleur des icones, le réglage possible des ventilos ... c'est secondaire (pour moi je précise).

Peut-être pour Marlin 2. Mais finalement ça va m'apporter quoi Marlin 2.0.7.x ?

[Murdock]

il y a 10 minutes, merlinx a dit :

Peut-être pour Marlin 2. Mais finalement ça va m'apporter quoi Marlin 2.0.7.x ?

Pour l'utiliser maintenant depuis quelques semaines, je peux te dire que la qualité d'extrusion n'est tout simplement pas comparable. C'est comme si c'était une machine complètement différente. Je dirais qu'avec la 2.0.7.2 la finesse d'extrusion donne une qualité visuelle avec des couches de 0.2 facilement équivalente à des couches de 0.16 voir 0.12 avec le firmware d'origine. 

(Et [ModeTeasing = true] le nouveau firmware de l'écran déchire ...   [ModeTeasing = false])

Modifié (le) Avril 16, 2021 par Murdock