Impression en 2 couleurs ou plus !

[inteloide]

·         Bonjour à tous,

 

J’étais à la recherche d'une solution pour imprimer un objet en 2 couleurs avec la Dagoma Discovery 200 Beta, je voudrais partager avec vous mes avancées dans mes recherches.

 

Voici ce que j'ai pu faire :

 

Le problème avec notre disco, c'est qu'il n'y a qu'une seule buse, donc pour changer de couleur à l'impression, il faut changer de filament durant l'impression.

Des solutions existent, je suis à la recherche de la plus facile.

 

Dans Cura version standard (pas Cura by Dagoma), il y a la possibilité d'ajouter des plugins qui permettent de rajouter des fonctions. Le plugin pauseAtZ (https://github.com/philtgarner/pauseAtZprb) permet de faire une pause. Il s'arrête à la hauteur voulue et dégage la tête quelques minutes, le temps de changer de filament.

 

Il reste néanmoins 3 problèmes de taille :

Problème 1 : Il faut rester à proximité de l'imprimante pour être là au bon moment pour changer le fil, sinon l'imprimante continuera sans avoir changé de fil.

Problème 2 : Il faut passer par la version standard de Cura (pas forcément le plus facile)

Problème 3 : Déterminer à quelle hauteur changer de fil peut s'avérer un peu complexe parfois.

 

 

Pour les trois points, je propose une solution :

 

Problème 1 :

Un autre plugin de Cura permet de ne relancer l'impression qu'après appui sur un bouton de l'afficheur LCD...mais la dagoma n'a pas d'écran LCD...raté.

Je propose une mise à jour du firmware qui va permettre de relancer l’impression en appuyant sur la butée de l’axe X : au moins même si on n'est pas à proximité, on a le temps pour changer de filament.

La mise à jour consiste à modifier l’instruction M226 qui permet d’attendre qu’une des entrées change d’état. En effet, le firmware par défaut bloque le contrôle des fins de courses pour cette fonction (pourquoi ?)

Pour ce faire, il faut prendre le dernier firmware (que vous avez dû téléchargé pour mettre le capteur inductif de l’axe Z par exemple) et modifier un fichier.

Le fichier à modifier : Marlin_main.cpp (dans le répertoire Marlin)

 

Lignes à modifier : le bloc qui démarre vers la ligne 2246 (ça peut dépendre de votre fichier), il faut ajouter les deux lignes avec les symboles /* et */ comme ci dessous :

 

case 226: // M226 P<pin number> S<pin state>- Wait until the specified pin reaches the state required
            {
      if(code_seen('P')){
        int pin_number = code_value(); // pin number
        int pin_state = -1; // required pin state - default is inverted
        if(code_seen('S')) pin_state = code_value(); // required pin state
        if(pin_state >= -1 && pin_state <= 1){
/*

          for(int8_t i = 0; i < (int8_t)(sizeof(sensitive_pins)/sizeof(int)); i++)
          {
            if (sensitive_pins[i] == pin_number)
            {
              pin_number = -1;
              break;
            }
          }
*/

          if (pin_number > -1)
          {
            st_synchronize();
            pinMode(pin_number, INPUT);
            int target;
            switch(pin_state){
            case 1:
              target = HIGH;
              break;
            case 0:
              target = LOW;
              break;
            case -1:
              target = !digitalRead(pin_number);
              break;
            }
            while(digitalRead(pin_number) != target){
              manage_heater();
              manage_inactivity();
            }
          }
        }
      }
    }
    break;

 

Voilà, ne reste plus qu’à mettre à jour le firmware dans la carte, pour cela, il suffit de suivre la procédure de Dagoma : http://www.dagoma.fr/tutoriels/mise-a-jour-de-la-carte-electronique/

 

Problème 2 :

En passant par Cura by Dagoma, on peut, en affichant les couches savoir à quelle couche changer de couleur. Il suffit d’afficher l’affichage par couche et de glisser le curseur jusqu’à la couche voulue.

Donc, en ouvrant le fichier Dagoma0.g sur votre carte SD, vous pouvez modifier le fichier en insérant le code suivant au bon endroit.

Le code à ajouter :

;AJOUT D’UNE PAUSE POUR CHANGER DE FILAMENT
G91                                       ; On met l'imprimante en coordonnées relatives 
M83                                       ; On remet l'extruder en coordonnées relatives
G1 E-5.000000 F6000                       ; On retire le filament
G1 Z15 F300                               ; ON Remonte la tête d’impression (attention à ne pas être trop en haut)
M226 P18                                  ; On attend que l’utilisateur appui sur le capteur de l’axe X 
G1 Z1                                     ; On fait un petit mouvement pour informer l'utilisateur c'est pris en compte
G1 Z-1
G4 P5000                                  ; On fait une pause de 5 secondes histoire de ne pas tamponner l'utilisateur
G1 E5.000000 F6000                        ; On remet du filament
G1 E-5.000000 F6000                       ; On retire le filament
G1 Z-15                                   ; On revient à la position avant la pause
G1 E5.000000 F6000                        ; On remet du filament
G1 F9000                                  ; On remet la vitesse (à adapter)
M82                                       ; On remet l'extruder en coordonnees absolues
G90                                       ; On remet l'imprimante en coordonnees absolues

 

  

Où le mettre :

voici un exemple où l'on doit faire la pause avant l'impression de la 7ième couche. Il faut repérer la ligne «;LAYER:7» et modifier ainsi (remplacer le « ICI » par le code ci dessus) :

…

G1 F1620 X23.850 Y192.285 E38.66160

;LAYER:7

M106 S155

ICI

G0 F3000 X22.990 Y192.817 Z0.560

;TYPE:WALL-INNER

…

 

 

Problème 3 :

J'ai corrigé le plugin trouvé sur internet pour l'adapter à la discovery D200 et à la pause par appui sur le fin de course axe X 

Je l'ai traduit au passage et j'ai rajouté la possibilité de choisir le numéro de la couche pour le changement de couleur (plutôt qu'une hauteur)

 

Vous pouvez le télécharger ici :pauseAtZinteloide.py

PAR CONTRE je ne l'ai pas encore testé sur une impression, car je n'utilise pas Cura en version standard : si quelqu'un peu s'en charger...

 

Sinon, je sui en train de développer aussi un plugin dans SketchUp qui permet de lire le fichier Dagoma0.g et qui dessine l’objet et qui permet de savoir très rapidement à quel numéro de couche appartient une ligne imprimée. Je suis en train de finaliser le plugin SketchUp pour qu’il modifie directement le fichier. Je le posterai plus tard si ça intéresse quelqu’un.

Voici un aperçu :

 

Voilà !

Bon amusement !

 

 

Modifié (le) Décembre 27, 2015 par inteloide
Modification des images

[Weiling]

Ouch, du beau travail!

J'ai déjà quelques idée d'impression pour essayer ça, j'attends avec hâte le dernier plugin pour tester ça, merci pour le partage en tout cas!

[Tircown]

Super boulot.

[delirium07]

super boulot et super tuto , ca me donnerai presque l'envie d'acheter une Dagoma  

 

[Picaboubx]

Impressionnant !!

Questions :

- La partie "Problème 1" est applicable à Cura By Dagoma ou uniquement au Cura de base ?

- On est d'accord que la MàJ du firmware ainsi modifié fait sauter la garantie !?

- Je n'y connais pas grand chose (même rien ;-) ), mais j'ai lu quelque part sur ce forum que le palpeur n'était plus utilisé après le paramétrage de niveau en début d'impression. Par conséquent, ne serait-il pas possible de mettre en parallèle du palpeur, un interrupteur (du type de ceux supprimés sur Z au moment de la mise en place du palpeur par exemple dans mon cas) et qui ferai le même travail que ta solution sur l'inter en X ?

- Le fichier Dagoma0.g ne peut-il pas être directement généré avec les motifs nécéssaire ? (je n'y connais rien je le répète, donc c'est surement naïf comme question)

 

Super idée en tout cas, et perso je preneur du plugin Sketchup pour le Dagoma0.g

[inteloide]

Réponses:

- La partie "Problème 1" est applicable à Cura By Dagoma ou uniquement au Cura de base ?

=> Non, applicable au deux : en fait on modifie la façon dont la carte interprète les codes de déplacement qui sont dans le fichier Dagoma.g; peu importe quel logiciel a écrit le fichier.

- On est d'accord que la MàJ du firmware ainsi modifié fait sauter la garantie !?

=> Pour moi non, il suffit simplement de remettre l'ancien firmware en cas de problème. Je suis même pas sûr que Dagoma le verrait ;o) La modification du firmware ne concerne que le code M226 qui n'est pas utilisé par Cura by Dagoma, donc pas de risque de "casser" l'imprimante en faisant une impression classique. Le seul risque est de faire le changement de couleur en haut d'un grand objet car dans mon code je remonte la tête d'impression de 15mm, donc on peut taper sur le haut de l'imprimante. Mais vous pouvez changer ce point, mettre 10 ou 5  ou seulement changer les coordonnées X et Y ou changer les trois : c'est free ! Suffit de changer les "G1 Z15" et "G1 Z-15" en "G1 X5 Y5 Z5" et "G1 X-5 Y-5 Z-5" pour tout décaler le 5 mm seulement !

- Je n'y connais pas grand chose (même rien ;-) ), mais j'ai lu quelque part sur ce forum que le palpeur n'était plus utilisé après le paramétrage de niveau en début d'impression. Par conséquent, ne serait-il pas possible de mettre en parallèle du palpeur, un interrupteur (du type de ceux supprimés sur Z au moment de la mise en place du palpeur par exemple dans mon cas) et qui ferai le même travail que ta solution sur l'inter en X ?

=> oui tout à fait, il suffit de les monter en parallèle (en branchant le capteur sur les mêmes bornes que le capteur de l'axe X). Attention simplement à ne pas appuyer dessus lors de la mise en référence de l'imprimante.

- Le fichier Dagoma0.g ne peut-il pas être directement généré avec les motifs nécéssaire ? (je n'y connais rien je le répète, donc c'est surement naïf comme question)

=> Il faut pour cela utiliser le plugin que j'ai cité dans mon post ainsi que le logiciel Cura "standard". Seulement l'impression reprendra après une temporisation. Je peux modifier le plugin pour prendre en compte l'appui sur l'axe X. J'y regarde

[inteloide]

Je viens de rajouter dans le premier post une version modifié du plugin trouvé sur internet.

Mises à jour :

1- adapté à la discovery D200 et à la pause par appui sur le fin de course axe X 

2- traduit en Français

3- ajouté la possibilité de choisir le numéro de la couche pour le changement de couleur (plutôt qu'une hauteur)

[inteloide]

Allez, pour le fun j'ai modifié le firmware pour faire clignoter la Dagoma le temps de changer de fil.

Voir la vidéo : 20151228_155911.mp4

 

Dans le gcode vous pouvez personnaliser le clignotement :

M226 P18 I2000 D500 B27 ; Toutes les 2000ms, on allume 500ms la led sur la sortie 27
M226 P18 I5000 D1000 B27 ; Toutes les 5 secondes, on allume 1 seconde la led sur la sortie 27 (valeurs par defaut)
M226 P18 ; ça marche aussi : Toutes les 5 secondes, on allume 1 seconde la led sur la sortie 27 (valeurs par defaut)

Pour ceux qui veulent, voici le code à mettre dans Marlin_main.cpp, toujours dans le même "bloc"

	case 226: // M226 P<pin number> S<pin state>- Wait until the specified pin reaches the state required
	{
      if(code_seen('P')){
        int pin_number = code_value(); // pin number
        int pin_state = -1; // required pin state - default is inverted

        if(code_seen('S')) pin_state = code_value(); // required pin state

        if(pin_state >= -1 && pin_state <= 1){
/*
          for(int8_t i = 0; i < (int8_t)(sizeof(sensitive_pins)/sizeof(int)); i++)
          {
            if (sensitive_pins[i] == pin_number)
            {
              pin_number = -1;
              break;
            }
          }
*/
          if (pin_number > -1)
          {
            st_synchronize();

            pinMode(pin_number, INPUT);

            int target;
            switch(pin_state){
            case 1:
              target = HIGH;
              break;

            case 0:
              target = LOW;
              break;

            case -1:
              target = !digitalRead(pin_number);
              break;
            }

//------------------------------------------------------------------------------
			// Déclaration des variables - valeurs par défaut
				unsigned long currentMillisBeeper = 0; // Top de depart pour le chrono
				unsigned long previousMiliBeeper = 0;  // Précédent top
				int etatBeeper = LOW;                  // Etat du beeper
				long intervalBeeper = 5000;            // Intervale entre chaque beep (en ms)
				long durationBeeper = 1000;            // Durée du beep (en ms)
				int pinBeeper = 27;			           // Pin pour le beeper

			// On récupère les paramètres
				if(code_seen('I')) intervalBeeper = code_value(); // Intervale entre chaque beep (en ms)
				if(code_seen('D')) durationBeeper = code_value(); // Durée du beep (en ms)
				if(code_seen('B')) pinBeeper = code_value();      // Pin pour le beeper

			// On active la sortie
				pinMode(pinBeeper, OUTPUT);                       // pour mettre la pin en mode sortie
				
			// Boucle d’attente
				while(digitalRead(pin_number) != target){
					// On gère l'attente
					manage_heater();
					manage_inactivity();
					
					// on fait aller le beeper
					currentMillisBeeper = millis();
					if ((etatBeeper == LOW) && (currentMillisBeeper - previousMiliBeeper >= intervalBeeper)) {
						previousMiliBeeper = currentMillisBeeper; // On garde le moment où on a changé d'état
						etatBeeper = HIGH;                        // On change l'état du beeper
						digitalWrite(pinBeeper, etatBeeper);      // On applique le nouvel état = on fait sonner
					}
					if ((etatBeeper == HIGH) && (currentMillisBeeper - previousMiliBeeper >= durationBeeper)) {
						previousMiliBeeper = currentMillisBeeper; // On garde le moment où on a changé d'état
						etatBeeper = LOW;                         // On change l'état du beeper
						digitalWrite(pinBeeper, etatBeeper);      // On applique le nouvel état
					}
				}

			// Finalisation de la boucle d'attente
				digitalWrite(pinBeeper, LOW);  // pour remettre au niveau bas  (0V)  après la boucle d'attente
				pinMode(pinBeeper, INPUT);     // pour remettre en entrée qui est la valeur par défaut
//------------------------------------------------------------------------------
			
/*			
            while(digitalRead(pin_number) != target){
              manage_heater();
              manage_inactivity();
            }
*/
          }
        }
      }
    }
    break;

 

Prochaine étape : brancher un buzzer pour avertir l'utilisateur.

[inteloide]

Bonjour,

Pour ceux qui ne l'aurait pas vu j'ai créé un nouveau post avec le plugin SketchUp.

Sachez qu'il existe aussi un site sympa qui permet d'analyser un gcode : http://gcode.ws/

 

[Stouf]

Très franchement et étant dans le métier de la conception hardware/software (arduino y compris), je doute qu'ils puissent réellement faire sauter la garantie en cas de mise à jour du firmware de la carte : elle est faite pour ça. Il n'y a qu'a la regarder et localiser les 2 jumpers "auto-reset" et "alimentation" pour s'en rendre compte.

L'autre solution aurait été qu'ils créent leur propre carte avec firmware verrouillé, mais ce n'est pas le cas, ils préfèrent certainement garder la possibilité de faire des corrections sur le firmware facilement.

C'est exactement comme si la garantie d'un arduino sautait quand on le programme... C'est totalement aberrant.

Y'aurait-il un juriste dans le coin, pour nous apporter ses lumières ?

Modifié (le) Décembre 30, 2015 par Stouf

[Picaboubx]

@Stouf Pour rappel voici ce qui est indiquer en préambule de la page Tuto de MaJ du Firmware sur le site de Dagoma :

[Stouf]

Oui je sais bien, après, chacun est libre de marquer ce qu'il veut sur ses conditions d'utilisation, ça n'en fait pas quelque chose de légal (comme les CLUF abusifs de logiciels / services online).

J'ai beau marquer sur mon site web que je n'ai aucune responsabilité envers les maintenances que j'opère (je ne le fais pas !!!), au tribunal, je perdrai fatalement...

Faire peur marche assez bien, mais n'a aucune base légale. Comme les lettres de "mise en demeure" d'avocats... Zéro valeur, sinon faire peur...

 

Dans ce cas précis, on pourrait même, limite, faire jouer une caducité sur la forme, grâce aux fautes de français

Modifié (le) Décembre 30, 2015 par Stouf

[Guest flykiller]

.

Modifié (le) Décembre 31, 2015 par flykiller

[Stouf]

Tout à fait. Refuser d'assurer le support parce que la Melzi n'a pas le firmware d'origine, c'est logique. Rien n’empêche de remettre le firmware d'origine pour prouver que le firmware n'est pas le coupable.

Faire péter toute la garantie pour la même raison, c'est abusif.

[inteloide]

Raisonnablement, je pense que si une modification du firmware viendrait à abimer des parties de l'imprimantes alors on ne pourrait pas se retourner vers Dagoma en disant que c'est de leur faute ou demander le remplacement d'une pièce.

Exemples :

- on modifie le firmware dans la partie réglage du Z (au démarrage de l'impression) et l'imprimante vient taper et déformer le plateau.

- on modifie le firmware pour limiter le ventilateur...qui du coup ne rempli plus sa fonction et la buse fait fondre une des pièces.

 

=> Donc ça reste très limité, pour peu qu'on modifie intelligemment le firmware.

Dans tous les cas, il suffit de remettre le firmware d'origine et dire "c'est pas moi !". Bon techniquement c'est pas fairplay...

[Stouf]

Casser la garantie pour une mise à jour du firmware qui n'a rien à voir avec des dégâts sur la bécane, c'est pas fair-play non plus, et pas terriblement dans l'esprit open-source. Mais tu as raison sur l'argumentation, on soulève ici un point critique et toujours débattu du système open-source / libre, question hardware.

Mon avis, c'est que si tu optes pour du hardware open-source dans ton design (pour des questions de coût généralement), tu t'exposes à ce genre de dilemmes, et le mieux dans ce cas, même si le doute existe, est de donner raison à l'utilisateur. Si tu veux éviter ce genre de souci, tu dev ton propre matos (le firmware d'un ATmega / arduino, ca peut se verrouiller en écriture, quand on est sûr de son code)...

Modifié (le) Décembre 30, 2015 par Stouf

[azerpoiuyt]

sauf qu'elle est pas open source  cf. https://www.lesimprimantes3d.fr/forum/topic/1280-licence-d200/?page=4#comment-12794

[Stouf]

Mais la Melzi l'est, et on peut pas "réduire" ou limiter une licence qui ne nous appartient pas  http://reprap.org/wiki/Melzi

Théoriquement, si on respecte scrupuleusement et débilement les licences, la propagation des licences pourrait faire de la D200 une vraie machine open-source, puisqu'elle utilise un composant principal sous licence open... Mais c'est vague, pour le moment, et ils le savent. L'open-source made in france, c'est généralement pas de l'open source, et encore moins du libre (la première vraie licence open pour le hardware, et super récente, c'est la licence CERN, à coté de chez moi... ici on connait un poil le sujet...)

Modifié (le) Décembre 30, 2015 par Stouf

[inteloide]

Donc, si on veut faire des évolutions de firmware, le mieux serait de passer par Benjamin avant de le mettre dans son imprimante, ou du moins avant de les proposer au "grand public". Je ne suis pas sûr que Dagoma soit prêt à ça.

Il faudrait une plateforme pour que les utilisateurs déposent leurs améliorations et que Dagoma puisse les valider (peut être même comme une sorte de plugin...à réfléchir)

De cette plateforme, le grand public pourrait télécharger des firmwares officialisés.

Maintenant, je ne sais pas s'il y a beaucoup de monde en capacité un firmware (je ne dis pas ça parce que j'en propose une version modifiée) mais plus parce que les :

- programmeurs français

- ayant une Dagoma

- voulant la modifier

- ayant le temps de le faire

- ayant une idée de modification

- voulant partager leurs modifications

ça doit faire une poignée de personnes pas plus.

[azerpoiuyt]

la melzi, ce n'est que la carte électronique. Et si Dagoma ne la garantie pas, le fabriquant d'origine le fait peut-être. Maintenant, c'est l'éternel problème du firmware. Entre gens de bonne volonté, si un problème est complètement décorrélé d'une mise à jour du firmware, le constructeur peut assurer la garantie. Mais si un utilisateur est "débile" ou de mauvaise foi, c'est déjà plus délicat. Les exemples de Inteloide sont pertinents à ce titre

Je suis quand même surpris du nombre de participants du forum qui semblent prêts à engager des poursuites ou à se battre sur un terrain juridique. De toute façon, quelle est la valeur juridique en droit français du terme open-source, et d'une licence et d'un site de référence rédigés en anglais ?

 

[Stouf]

Non, ne te trompes pas, s'il te plait. Je suis la dernière personne, en tant que concepteur de matos open-source, à vouloir aller en justice pour une question de licence. Combien de tribunaux en France sont compétents en la matière ? None, je perds à tous les coups.

Je parle seulement en termes de "principes", si on respecte scrupuleusement les termes des licences (ce que j’aimerai, en france).

La Melzi, c'est juste un Arduino customisé/spécialisé, rien de plus.

Des Arduino customisés/spécialisés, il y en a plein dans ton PC et dans un éventail de matos grand public que tu n'imagines pas. Mais leur firmware est verrouillé, a la grande différence du firmware de la Melzi, qui est fait pour être modifié...

Verrouiller le firmware Dagoma de la Melzi, c'est hyper facile. Ils ne le font pas pour une bonne raison : ils ne sont pas surs des évolutions de la D200, et donc, ne peuvent casser la garantie sur uniquement une modif du firmware.

Modifié (le) Décembre 30, 2015 par Stouf

[La Bidouille]

@Stouf

Tout à d'accord (en plus avec quelqu'un qui a un Archos )

Une Melzi ca vaut 30€ ! et le reste des pièces détachées ne vaut pas très cher (on explose pas la totalité de la machine en cas de fausse manip)

Autant en prendre une autre (carte) pour faire des bidouilles (ou au cas où) et puis "la remettre dans sa culotte" en cas de Pb.

Perso, par exemple, j'ai bonne qté de carte type "arduino" et quand je change des versions de GRBL (CNC) je ne le fais pas sur contrôleur qui tourne correctement.... après quand tu te lance faut avoir la main pas trop loin de l'arrêt d'urgence.

Sinon faut prendre une machine packagée avec extension de garantie 5 ans sur site  (qui n'est  jamais respecté)

 

[La Bidouille]

Oups ... hors sujet !

[Stouf]

Ouep, totalement hors sujet nous sommes... ça mériterait un vrai sujet, non ?

(ou t'as vu un Archos chez moi ? pas possible, c'est trop de la gnognote, et trop fermé à mon gout. Autour de ma D200, ya que des Raspberry/Banana/autres /Arduino et leurs écrans. Archos, pour moi, c'est l'exemple typique de french-tech super moisie (dommage ils étaient bien, avant) qui essaie de jouer sur le terrain des chinois, mais qui se foire totalement, comme Wiko)

N'est pas chinois qui veut !!

Modifié (le) Décembre 31, 2015 par Stouf

[sylphide]

Vous avez fini de pourrir tout les post ??