Firmware MARLIN Standard pour Trigorilla

[Murdock]

Bonjour à tous.

Ce petit sujet à pour but de servir de repère à tout ceux qui souhaite collaborer au paramétrage d'un MARLIN "standard" pour les cartes Trigorilla de chez Anycubic sans polluer d'autres sujets.

[kropernic]

Chef !  J'suis volontaire chef !

Sauf j'sais pas encore comment ça marche ^^

[Murdock]

Il y a 1 heure, kropernic a dit :

Chef !  J'suis volontaire chef !

Bienvenu à bord ! lol Mais il n'y a pas de Chef juste des curieux qui veulent voir comment cela fonctionne ...

[.AleX.]

Allez, en avant !

On à déjà avancé et vu quelques trucs, mais c'est pas évident de travailler à plusieurs dans ce cas.

Un partage Github, c'est peut-être un peu lourd pour le moment, une framapad pourrait être pas mal, mais il faut vraiment vraiment vraiment que tout le monde prenne soin de commenter un max !

On peut tenter sur https://semestriel.framapad.org/p/Trigorilla_Board et voir comment ça se passe

[.AleX.]

Huuummm j'explore, je farfouille... et dans un 'pack' nommé I3MEGA_V100, le fichier Trigorilla.h précise des petites choses intéressantes...

//    #define Y_MIN_PIN          14//d14 as uart3 pin
#define Y_MIN_PIN          42
    #define Y_MAX_PIN          43
    #define Y_MAX_PIN         -1   // 15 d15 as uart3 pin

Bon, c'est clairement fait n'importe comment, mais ça sous entend qu'ils ont utilisé le connecteur UART3 pour autre chose... c'est à coté des connecteurs EXP1/EXP2 utilisés sur la version de base pour LCD/Encodeur/SD

Je trouve pas de photo de cette satanée carte pour au moins prévoir les broches utilisées avec l'afficheur TFT d'Anycubic

[kropernic]

Il y a 13 heures, Murdock a dit :

Bienvenu à bord ! lol Mais il n'y a pas de Chef juste des curieux qui veulent voir comment cela fonctionne ...

Ok chef !

@.AleX. : T'as trouvé ça où ?  Y a des décompilateurs en c++ ? o_0

[.AleX.]

La décompilation est un art qui me serait bien inaccessible !

Non, c'est juste de la collecte à droite à gauche pioché dans différentes sources que je me suis synthétisé dans un tableau et une fois que j'ai assez de 'confirmations', j'injecte les valeurs dans une structure de base fournie avec Marlin (en l’occurrence, le pins.h pour RAMPS)

En fait, je refait un peu le travail qu'a fait Anycubic lorsque qu'ils ont fait la Trigorilla, sauf qu'ils l'ont fait en écrasant les valeurs du fichier RAMPS plutôt que d'en refaire un dédié et propre, du coup, dans ce qu'ils produisent, selon les machines, le fichier est 'bidouillé' différemment.

Ce petit travail que j'ai entrepris vise 2 buts :

• avoir un fichier Trigorilla.h plus lisible et utilisable sur plusieurs machines (y compris sur une machine montée en DIY)
• que le fichier soit compatible avec les dernières mises à jour de Marlin, et donc, bénéficier des derniers raffinements

Personnellement, je n'en ai pas besoin, mais une partie sur laquelle par contre je ne pourrais faire avance les choses que si d'autres participent, c'est de faire un peu de reverse engineering sur les version Mega V1 et V2 pour savoir ou sont branchées tel ou tel chose. Par exemple pour la modif 'double capteur Z', j'ai trouvé l'info sur le forum, c'est en pin 42 du connecteur AUX, mais pour l'écran+tactile+carte SD, ça passe pas une carte fille que je n'arrive pas à trouver en photo pour au moins savoir quelles sont les pins utilisées pour la brancher sur la Trigorilla

[kropernic]

J'suis au boulot là mais j'ai ceci en stock.  J'sais pas si ça aide...

Ca date de quand j'avais des soucis de température et anycubic me montrait quoi checker.

Les photos sont pas tops mais c'est p-e un début.  

[.AleX.]

C'est un début, je regarde en rentrant du boulot ce soir (tard).

On voit pas tout, mais au moins on peut suivre les pistes. Visiblement, pour la SD, c'est juste un 'transfert' d'un connecteur EXP de la Trigorilla vers un petit ZIF pour nappe.

Fil vert/bleu branché sur T1 donc, c'est l'extrudeur ?

[kropernic]

Je pense bien que oui.  Vu qu'ils me disaient de vérifier ça quand j'avais problème de température de buse.

[thsrp]

Pour toutes les photos de la carte fille et de la carte mère je pourrai en faire quand je rentrerai de vacances car une nouvelle carte trigorilla et carte fille m attendent en remplacement de la trigorilla défectueuse. Je vais donc tout decabler pour recabler les pièces de rechange. Je pourrai faire à ce moment toutes les photos que tu veux.

[.AleX.]

il y a 3 minutes, thsrp a dit :

la trigorilla défectueuse.

Défectueuse comment...?

Parce que pour certains points, sortir la mienne qui fonctionne très bien de ma delta, ça m'arrange moyen...

Tu serais en mesure de me la revendre pour une somme symbolique ?

[thsrp]

Défectueuse car il y a deux pannes: plus de son ni de fan0 celui qui refroidit la pièce. Ces derniers temps je connectais directement via le connecteur du ventilateur une alimentation 12V lorsque j imprimai du pla.... Pour le son je m'en passais aisément puisque cela ne concerne que le jingle quand on allume la machine ou que l on insert la prise usb. Je n ai plus non plus évidemment de bips quand je fais l auto level du bed mais je règle avec la led rouge du capteur cela revient au même c est même plus simple et précis je trouve.

Après de nombreux tests avec le sav  il a été convenu que l on changeait les deux cartes..

[.AleX.]

Ben si tu peux me la céder une fois que tu auras remis ta machine en état, ça me facilitera la vie (et tu en profitera pour nous faire des jolies photos sous toutes les coutures de la carte fille et toutes les connections sur la Mega !)

[Murdock]

Le 03/08/2017 at 00:08, .AleX. a dit :

La décompilation est un art qui me serait bien inaccessible !

Alors cela aiderait mais pas tant que cela. Pour l'avoir à de nombreuses reprises utilisée je peu vous dire que dans le meilleur des cas et en admettant que l'on retrouve un prog c++ valide du premier coup (c'est rarement le cas) il n'aura pas grand chose à voir avec les sources originales. Le programme compilé en "langage machine" ne conserve pas de traces de la structure originale du programme. La décompilation, dans le meilleur des cas te sortirait des méthodes, variables, constantes que le le soft de décompilation jugerai utile de créer à la vue du résultat à obtenir.

Souvent quand on dé-compile par exemple une application développée par exemple en VB ou C# il est impossible de recompiler le code fournit par la décompilation tellement il est pourrit ...

Donc aussi séduisante que paraisse cette piste, elle est à oublier à mon sens.

Le 02/08/2017 at 00:20, .AleX. a dit :

Huuummm j'explore, je farfouille... et dans un 'pack' nommé I3MEGA_V100

Ouep c'est d'un pack du genre que venait le premier fichier que je t'ai fournit. Par contre outre le fait que les fonctions de levelling assisté ont déjà été supprimées, on ne peut  ne peut pas non plus exclure que quelqu'un ne l'a pas bricolé.

Bon c'est le week-end à partir de ce soir je m'y remet sérieusement.

[Murdock]

Le 01/08/2017 at 23:33, .AleX. a dit :

Un partage Github, c'est peut-être un peu lourd pour le moment, une framapad pourrait être pas mal, mais il faut vraiment vraiment vraiment que tout le monde prenne soin de commenter un max !

Ouep surtout que l'on ne connait pas encore les habitudes de codage de chacun ... D'ici quelques temps et si on se met bien d'accord sur la façon de gérer les "commits" je pourrais créer un petit dépot SVN sur mon serveur.

[Murdock]

#define HEATER_0_PIN       10   // EXTRUDER 1
#define HEATER_1_PIN       45
#define TEMP_0_PIN         13   // ANALOG NUMBERING
#define TEMP_1_PIN         14   // ANALOG NUMBERING    
#define TEMP_2_PIN         15   // ANALOG NUMBERING
#define TEMP_BED_PIN       14   // ANALOG NUMBERING
#define HEATER_BED_PIN   8

Tout et son contraire j'adore !

[Murdock]

Bon eh bien cela avance pas trop mal tout cela !

J'ai du effectuer un peu de modifs pour caser des spécificités de la mega sans causer trop de redondance.

Regardes si cela te convient. 

[.AleX.]

Huummm y'a des trucs qui coincent

On va faire bloc par bloc pour pas trop se mélanger

a mon avis, ce que tu as ajouté est pas au bon endroit

#ifdef DUAL_Z
#define Z2_STEP_PIN       36 // Murdock from unidentified Mega's firmware.
#define Z2_DIR_PIN          34 // Murdock from unidentified Mega's firmware..
#define Z2_ENABLE_PIN  30 // Murdock from unidentified Mega's firmware..
#define Z2_CS_PIN           -1  // Murdock from unidentified Mega's firmware..
#else
#define Z_STEP_PIN         46 // AleX Delta Configuration, from pins.h provided with my Kossel
#define Z_DIR_PIN          48 // AleX Delta Configuration, from pins.h provided with my Kossel
#define Z_ENABLE_PIN       62 // AleX Delta Configuration, from pins.h provided with my Kossel
#define Z_CS_PIN           -1 // 40 // AleX Delta Configuration, from pins.h provided with my Kossel
#endif

parce qu'en dessous, on à ça qui vient ré-écrire dessus :

// AleX - potentiellement, à supprimer car reporté dans la configuration Double Z, voir au dessus
#define E1_STEP_PIN        36 // A vérifier, fonction commentées dans  pins.h de la  Kossel d'AleX
#define E1_DIR_PIN         34 // A vérifier, fonction commentées dans  pins.h de la  Kossel d'AleX
#define E1_ENABLE_PIN      30 // A vérifier, fonction commentées dans  pins.h de la  Kossel d'AleX
#define E1_CS_PIN          44 // A vérifier, fonction commentées dans  pins.h de la  Kossel d'AleX

Dans le firmware de la delta, ces lignes sont commentées, mais par rapport à ce que tu as trouvé, ça confirme bien que c'est le pilotage du moteur E1, qui est utilisé en 'Z2'

Mais là ou je pige plus, c'est que pour moi, dans la modif 'double Z', vu que le moteur d'origine est déplacé sur E1 et que le moteur '2' est mis en Z, ça devrait être quelque chose du genre

#ifdef DUAL_Z
  #define Z_STEP_PIN         46 // moteur '2' qui prend se branche en Z
  #define Z_DIR_PIN          48 // moteur '2' qui prend se branche en Z
  #define Z_ENABLE_PIN       62 // moteur '2' qui prend se branche en Z
  #define Z_CS_PIN           -1 // moteur '2' qui prend se branche en Z
  
  #define Z2_STEP_PIN        36 // Moteur '1' qui prend se branche en E1
  #define Z2_DIR_PIN         34 // Moteur '1' qui prend se branche en E1
  #define Z2_ENABLE_PIN      30 // Moteur '1' qui prend se branche en E1
  #define Z2_CS_PIN          -1 // Moteur '1' qui prend se branche en E1

#endif

 

ou sinon l'inverse...

#ifdef DUAL_Z
  #define Z2_STEP_PIN         46 // moteur '2' qui prend se branche en Z
  #define Z2_DIR_PIN          48 // moteur '2' qui prend se branche en Z
  #define Z2_ENABLE_PIN       62 // moteur '2' qui prend se branche en Z
  #define Z2_CS_PIN           -1 // moteur '2' qui prend se branche en Z
  
  #define Z1_STEP_PIN        36 // Moteur '1' qui prend se branche en E1
  #define Z1_DIR_PIN         34 // Moteur '1' qui prend se branche en E1
  #define Z1_ENABLE_PIN      30 // Moteur '1' qui prend se branche en E1
  #define Z1_CS_PIN          -1 // Moteur '1' qui prend se branche en E1

#endif

 

En gros, j'arrive pas à piger quel est le moteur correspondant à Z2.. 

Remarque, après avoir rédigé ces cas de figure, j'en arrive à la conclusion qu'il faudrait que je regarde le tuto pour savoir quel fil doit être bougé de ou à ou plus précisément.

[.AleX.]

Bon, après avoir reparcouru le tuto, c'est tout sauf clair....   parce que sur les illustration c'est marqué de croiser Z et E1, mais d'origine, les moteurs sont déjà en Z/E1 ou est-ce que les 2 moteurs de Z sont sur le même driver avec sortie en parallèle Z et Z'  ???

Y'a des photos de détail ou on peut presque lire la marque des vis, mais pour se situer, c'est hyper pas facile

le endstop d'origine reste a sa place, et reste branché sur limit Z- ?

on ajoute un endstop, mais sur le moteur de gauche ou sur celui de droite...? (quand on est face à la machine)

le second endstop se connecte en D42 (du coup, c'est celui correspondant au Z2)

Donc, le moteur associé au capteur branché en D42, il est connecté en Z ou en E1 ?

[Murdock]

il y a 25 minutes, .AleX. a dit :

Bon, après avoir reparcouru le tuto, c'est tout sauf clair....   parce que sur les illustration c'est marqué de croiser Z et E1, mais d'origine, les moteurs sont déjà en Z/E1 ou est-ce que les 2 moteurs de Z sont sur le même driver avec sortie en parallèle Z et Z'  ???

Oui ils sont déjà comme cela (Z et E1),  mais si tu ne croise pas les moteurs, le endstop de droite coupe le moteur de gauche et inversement.

[.AleX.]

Et le reste...?

Après modif, capteur en D42 est à droite ou à gauche de la machine ?
Après modif, le moteur mis en E1 est à droite ou à gauche de la machine ?

 

[Murdock]

il y a 28 minutes, .AleX. a dit :

le endstop d'origine reste a sa place, et reste branché sur limit Z- ?

Ca c'est la question à 100€ on peut pas savoir les end_stops sont connectés sur la "carte de transfert" et celle ci est raccordé au connecteurs des endstops de la carte mère.

 

il y a 29 minutes, .AleX. a dit :

on ajoute un endstop, mais sur le moteur de gauche ou sur celui de droite...? (quand on est face à la machine)

Gauche

 

il y a 30 minutes, .AleX. a dit :

le second endstop se connecte en D42 (du coup, c'est celui correspondant au Z2)

Ouep mais il va y avoir du changement si on laisse ces noms de constantes il va falloir changer des truc directement dans le code de Marlin et c'est pas le but. J'ai un firmware qui tourne presque. Quand je serais certain de mon coup je mettrai a jour le fichier unifié.

il y a 32 minutes, .AleX. a dit :

Donc, le moteur associé au capteur branché en D42, il est connecté en Z ou en E1 ?

E1 

[Murdock]

Pour mes tests j'ai tout remis dans un fichier qu'avec la version mega. Plus simple a debuger car moins d''interactions involontaires voulues. Pour l'heure cela donne ceci.

pins_TRIGORILLA.h

Modifié (le) Aout 5, 2017 par Murdock

[.AleX.]

Oki c'est bon pour moi.

Pour le capteur d'origine qui est relié à la carte fille, je suis sur que ça ne fait que transférer ses connections sur la Trigorilla, c'est juste pour avoir un bornier plus facile/accessible qu'ils l'on fait passer par là. A la limite, tu pourrais confirmer ce que ça dit avec M119 en appuyant sur l'un ou sur l'autre

Modifié (le) Aout 5, 2017 par .AleX.
fil^fille