Affichage du numéro de la couche en cours

[cams08]

merci pour votre réponse 

 

sur marlin RC8 je viens d'essayer mais apparemment on ne peut inscrire qu'a partir de la 16 ème ligne en hauteur sur toute la longueur de l'écran

au dessus impossible 

 

pour info sur ma Delta sous marlin RC7 ça fonctionne

Modifié (le) Mars 11, 2017 par cams08

[DPE]

Bonjour,

En suivant ce sujet je vois que vous êtes des pros de l'affichage sur l'écran, j'ai deux petites questions:

- la plus simple, comment obtenez vous le numéro de ligne dans Arduino, je n'ai pas trouvé d'info dans l'aide (certes en anglais).

- la plus compliquée (Dago a pourtant essayé de me répondre malgré un écran pas acheté chez eux):

Mon écran se décale progressivement. Il se divise en 2 colonnes dont la largeur évolue au fil du temps. (photo 20mn après la mise sous tension). Si quelqu'un a une idée de la cause... car je ne voudrais pas changer d'écran si ca vient du soft.

Amicalement,

[cams08]

bonjour

pour le numéro de ligne dans arduino

il faut aller dans fichier puis préférences et la tu coches la case  afficher les numéros de ligne

pour l'autre problème je ne sais pas du tout

[cams08]

dans marlin RC8 il y a deux zone ou on ne peut pas écrire

une photo de l'écran avec marlin RC8

 

 

et avec RC6 tout est blanc

 

peut être une chose a creuser

Modifié (le) Mars 13, 2017 par cams08

[Narayan1986]

@DPE Vraiment bizarre ton problème d'écran ! si c'est avec le soft d'origine non modifié alors oui il est bel et bien défectueux... Si t'as touché au firmware essaie de reflasher la version de base dispo chez dagoma

[DPE]

Bonsoir,

C'est le FW de base Dago, je n'ai rien modifie.

C'est un écran que j'ai acheté sur Banggood dans  le but de remplacer l'OLED a l'évoque ou j'avais une Melzy. Y aurait il une bibliothèque différente des écrans Dago? 

[Narayan1986]

Non ils sont strictement identiques, tu as bien inversé les connecteurs ?

Modifié (le) Mars 13, 2017 par Narayan1986

[DPE]

Il y a 7 heures, Narayan1986 a dit :

Non ils sont strictement identiques, tu as bien inversé les connecteurs ?

Bonjour et merci,

Malheureusement ça ne donne rien. Ayant parcouru les sujets du forum concernant l'écran, j.ai tout de suite pensé à ça et fait une permutation circulaire des nappes.

J'aussi essayé un reset par le bouton poussoir de l'écran: pas mieux.

J'ai également pensé à un composant qui dériverait avec la T° Car à la première mise sous tension l'eçran reste stable plus longtemps, j'ai donc mis un coup de bombe a froid. Toujours pareil.

La seule chose qui réinitialise l'affichage c'est un Arrêt/Marche et la dérive de l'écran évolue plus ou moins vite selon que je ne touche à rien, que je manipule les menus d'écran ou que j'imprime. J'en suis même arrivé à un écran tout bleu apres plusieurs heures d'impression. C'est pour cela que je me suis rabattu sur le soft, mais n'y connaissant pas grand chose dans ce domaine je suis un peu à la peine quant à la logique de l'architecture du système (j'essaie d'apprendre mais c'est long et pas facile...)

Le canard est toujours vivant...

[Narayan1986]

C'est pas un problème de soft, c'est le contrôleur à l'interieur de ton écran qui part en bibe ! il te reste qu'a en acheter un autre j'ai bien peur ...

[DPE]

Ok et merci de cette confirmation. La perte ne sera pas trop conséquente, env 14$ chez Banggood

Amicalement

[smx71]

Juste une petite question, est ce que l'écran avec les menu & co est compatible Discovery avec une carte Melzi ?

Modifié (le) Mars 25, 2017 par smx71

[cams08]

bonjour

je crois que oui mais il faut un adaptateur pour pouvoir brancher l'écran 

[Fyx]

ca marche niquel, merci aux codeurs

[Arcueild]

Plop, je viens de faire la modif et ca marche très bien (Marlin RC6), merci à vous tous ^^

[Baroudeur]

@Narayan1986

Bonjour, ta modification est super, ça m'intéresse. Mais je suis un newbee ici et je découvre tout juste l'impression 3D et Arduino.

Pourrais tu dire quels fichiers sont impactés pour les modifs dans Marlin car je n'ai pas retrouvé où mettre tes lignes de code. J'ai une DiscoEasy 200, ça ne devrait pas poser de problème.

Merci encore pour tes trouvailles !

[cams08]

bonjour

toutes les lignes sont a mettre dans le fichier ultralcd_impl_DOGM.h

je suis sous marlin RC8

ultralcd_impl_DOGM.h

[Baroudeur]

Le 11/06/2017 at 15:00, cams08 a dit :

bonjour

toutes les lignes sont a mettre dans le fichier ultralcd_impl_DOGM.h

je suis sous marlin RC8

ultralcd_impl_DOGM.h

Et en plus il donne le fichier modifié ! Merci !!!

Je vais mettre le RC8, je suis en RC6 depuis l'achat de la machine. Merci encore.

[Stephane Dago DE200]

Bonjour

 

Super interessant. 

Par contre jen'ai pas ce fichier dans le firmware original

 

j'ai ULTRALCD_IMPLEMENTATION_HITACHI_HD44780_H qui ressemble

 

Dagoma Discoeasy 200 Dernier firmware dagoma en ligne

 

merci et encore bravo

[ServNer]

Bonjour tout le monde

D'abord merci @Vivion91 pour ce tuto fort sympathique

La modif fonctionnait jusqu'à ce que j'essaye de modifier des trucs moi-même J'ai voulu garder l’affichage de base de @Vivion91  mais avec le dessin sans l'animation ( enfin je crois que c’est une animation ) et depuis j’ai le numéros de couche 3 fois sur la même ligne.

Voici mon code dans dogm_lcd_implementation :

static void lcd_implementation_status_screen() {
  u8g.setColorIndex(1); // black on white
 // numero de couche
    if (z_en_cours > current_position[Z_AXIS]) // test si extrudeur est redescendu
    {
        nb_couche = 1; // impression première couche
        z_en_cours = current_position[Z_AXIS];
    }
    // test du changement de niveau de la couche
    if (z_en_cours != current_position[Z_AXIS])
    {
        nb_couche++;// incrementation du nombre de couche
        z_en_cours = current_position[Z_AXIS];
    }
//affichage du numero de la couche  
    u8g.setPrintPos(50, 28); 
    lcd_print(ftostr32sp(nb_couche));
    
    u8g.drawBox(62,0,6,7);
    u8g.drawBox(64,7,2,2);
    u8g.drawBox(57,9,5,2);
    u8g.drawBox(57,12,15,2);
    u8g.drawBox(57,15,15,2);
    u8g.drawBox(57,18,15,2);
    
    char buf[5];
    itoa(nb_couche, buf, 10);
    lcd_print(buf);

Est-ce que quelqu'un aurais une idée de la cause du problème ? (Désolé si la cause est évidente je suis un gros noob )

Merci d’avance à ceux qui prendront le temps de me répondre

 

J'ai  trouver le problème : j'avais 3 fois cette ligne :

  lcd_print(ftostr32sp(nb_couche));

Modifié (le) Novembre 5, 2017 par ServNer

[DPE]

Bonjour,

Je me suis enfin décidé à faire cette belle amélioration, VRAIMENT UN GRAND MERCI A TOUS.

J'apprends sur le tas et jusque là j'étais trop "frileux" pour oser rentrer sans le FW, j'ai d'ailleurs un peu galéré, d'où mon intervention qui pourra peut être aider un peu ceux qui sont dans mon cas.

-  Une fois lu et relu les 4 pages je suis perdu. Mon interrogation: où je trouve les lignes correspondantes et qu'est ce que je modifie?

D'abord trouver Dogm_ LCD implementation (Ca aidera peut être Stephane Dago): quand on est dans config h, il  se trouve dans le menu déroulant sou la flèche complètement à droite en haut. Ne pas hésiter à descendre dans le menu et à interpréter car le nom et pas tout à fait identique en RC6 et RC8

Puis j'ai édité le fichier de Cams08 qui m'a permis, en le comparant avec le mien (d'origine) de retouver les lignes semblables (lui en RC8 moi en RC6) . Ligne 430 dans mon FW qui est devenue 480 après la modif.

J'ai comparé avec les modifs initiales deVivion91 pour confirmer

J'ai enfin fait du copier collé à partir du fichier de Cam08 .

Puis j'ai fait une verif et là...planté ! il me manquait la bibliothèque xxxxx.

Retour à la case départ ==> recherche de la signification du message ==> aide précieuse du forum ==> miracle j'ai compris, j'ai fait, j'ai vérifié et ça marche.

Après le téléversement, tout est parfait.

Pour vous qui êtes des pros, je passe peut être pour un "Bolosse" mais vous m'avez fait progressr

ENCORE UN GRAND MERCI A VOUS TOUS QUI AVEZ LES IDEES ET LES CONNAISSANCES

[xpj45]

Bonjour.

Merci pour toutes les infos, j'ai appliqué les modif (avec un peu de mal, je connais pas arduino) mais cela fonctionne.

Par contre, à l'utilisation, je me rends compte qu'il y a de gros écarts sur le n° de la couche. Je pense que cela vient de la logique de calcul:

    // test du changement de niveau de la couche
    if (z_en_cours != current_position[Z_AXIS])
    {
        nb_couche++;// incrementation du nombre de couche
        z_en_cours = current_position[Z_AXIS];

en partant de ces lignes de codes, dés que la position Z est différente de celle préalablement enregistrée, on incrémente la couche, mais parfois lors de changements de zones, la tête monte un peu, puis redescend pour faire la couche ailleurs, au bout d'un moment, cela fausse le calcul. Serait il possible de ne tenir compte des Z que si l'imrpimante dépose du fil ? SI oui, avez vous une idée du comment, ? l'extrudeur peut il estre interrogé comme l'axe Z en utilisant quelquechose du genre current_position[E_AXIS] ?

Je n'ai jamais codé en arduino, et mes notions de programmations sur plûtôt restée sur du basic et du C.

 

quel est votre avis ? A moins qu'il soit possible de lire le n°de layer du code G, mais s'agissant d'un commentaire, je suppose que c'est pas possible

 

xpj

[Skaarian]

il y a 10 minutes, xpj45 a dit :

Bonjour.

Merci pour toutes les infos, j'ai appliqué les modif (avec un peu de mal, je connais pas arduino) mais cela fonctionne.

Par contre, à l'utilisation, je me rends compte qu'il y a de gros écarts sur le n° de la couche. Je pense que cela vient de la logique de calcul:

    // test du changement de niveau de la couche
    if (z_en_cours != current_position[Z_AXIS])
    {
        nb_couche++;// incrementation du nombre de couche
        z_en_cours = current_position[Z_AXIS];

en partant de ces lignes de codes, dés que la position Z est différente de celle préalablement enregistrée, on incrémente la couche, mais parfois lors de changements de zones, la tête monte un peu, puis redescend pour faire la couche ailleurs, au bout d'un moment, cela fausse le calcul. Serait il possible de ne tenir compte des Z que si l'imrpimante dépose du fil ? SI oui, avez vous une idée du comment, ? l'extrudeur peut il estre interrogé comme l'axe Z en utilisant quelquechose du genre current_position[E_AXIS] ?

Je n'ai jamais codé en arduino, et mes notions de programmations sur plûtôt restée sur du basic et du C.

 

quel est votre avis ? A moins qu'il soit possible de lire le n°de layer du code G, mais s'agissant d'un commentaire, je suppose que c'est pas possible

 

xpj

Une piste à explorer... un regex sur le gcode du fichier. Je crois que le numéro de la ligne est écrit ( ;Line xx ).

[xpj45]

Il y a 4 heures, Skaarian a dit :

Une piste à explorer... un regex sur le gcode du fichier. Je crois que le numéro de la ligne est écrit ( ;Line xx ).

heu c'est quoi un regex ? les couches sont définies par (;LAYER:n), mais je n'ai aucune idée de comment récupérer cette info.

Je n'ai rien trouvé sur le net pour le moment, si c'est possible, il suffira alors d'aller chercher le chiffre après le (;LAYER:)

[Skaarian]

Regex = Rechercher une expression régulière

C'est beaucoup utilisé en PHP. Après, quel langage est utilisé pour arduino ?

[Skaarian]

Il y a 15 heures, xpj45 a dit :

heu c'est quoi un regex ? les couches sont définies par (;LAYER:n), mais je n'ai aucune idée de comment récupérer cette info.

Je n'ai rien trouvé sur le net pour le moment, si c'est possible, il suffira alors d'aller chercher le chiffre après le (;LAYER:)

J'ai regardé vite fait. Tu as déjà toutes les class qu'il faut. Dans ultralcd.cpp.

Il faut lire le fichier, créer une boucle pour récupérer le numéro de la ligne via un regex (;LAYER:) puis récupérer la position Z de la ligne suivante et les encapsuler dans un tableau (array) : N°Ligne/Position en Z.

Il n'y a plus qu-a comparer l'axe Z en cour à ceux stockés dans le tableau pour afficher le n° de la ligne.

Je pense que c'est vraiment une piste à explorer.