cartes additionnelles Power loss recovery

[Metalzoid]

Salut à tous ! 

J'ai besoin de votre aide pour modifier le comportement de marlin !

Grâce au module Power loss recovery de @Janpolanton, il est possible de configurer un entrée de détection sur la carte mère de l'imprimante.

Donc, lorsque le 220V est présent, le module envoie environ 5v, et lorsque le 220V disparaît, il envoit 0V.

Grâce au une bank de condensateurs, on à quelques secondes de 12v pour faire faire des mouvements à l'imprimante.

Actuellement, j'ai testé sous marlin 1.1.9 et marlin 2.0, et le comportement ne corresponds pas à mes attentes. 

J'aimerais que, après détection et sauvegarde, envoyer un M125 (park head), et attendre.

Actuellement, il sauvegarde, mais reste sur la pièce et éteint l'imprimante. 

Merci pour votre aide !  

ps: Je pense que le problème viens de là : 

    // KILL now if the power-loss pin was triggered
    #if PIN_EXISTS(POWER_LOSS)
      if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE) kill(PSTR(MSG_OUTAGE_RECOVERY));
    #endif

[Tircown]

C'est effectivement le bon endroit pour rajouter les commandes.

   // KILL now if the power-loss pin was triggered
    #if PIN_EXISTS(POWER_LOSS)
      if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE){
      	enqueue_and_echo_commands_P(PSTR("M125"));
        enqueue_and_echo_commands_P(PSTR("M400"));
      	kill(PSTR(MSG_OUTAGE_RECOVERY));
    	}
    #endif

Pas sûr que ça fonctionne mais c'est déjà un premier test. Si ça ne marche pas teste en retirant la ligne avec M400 et la ligne avec le kill(...). Sans le kill il se peut que le print redémarre comme si ne rien n'était après le M125 alors garde le doigt sur le bouton d'arrêt, (comme d'hab quand on test) .

[Metalzoid]

Ok, merci je vais tester ça  

[fran6p]

@Tircown

La commande M125 n'est pas référencée sur https://reprap.org/wiki/G-code alors qu'elle y est sur http://marlinfw.org/meta/gcode/.

Éventuellement si tu es en Marlin 2, la commande M413 permettrait de stocker sur carte SD les positions de la tête au moment de la perte d'alimentation (pour reprendre l'impression ultérieurement si la coupure n'a pas été trop longue et que le plateau est encore suffisamment chaud).

[Metalzoid]

il y a 1 minute, fran6p a dit :

@Tircown

La commande M125 n'est pas référencée sur https://reprap.org/wiki/G-code alors qu'elle y est sur http://marlinfw.org/meta/gcode/.

Éventuellement si tu es en Marlin 2, la commande M413 permettrait de stocker sur carte SD les positions de la tête au moment de la perte d'alimentation (pour reprendre l'impression ultérieurement si la coupure n'a pas été trop longue et que le plateau est encore suffisamment chaud).

Oui, je suis sous marlin, et la commande M125 fonctionne sur Marlin 1.1.9 comme sur Marlin 2.0.

En fait, la sauvegarde se fait très bien, la reprise d'impression aussi.

Le seul problème, c'est la position de la buse lors de la coupure.

[fran6p]

il y a 6 minutes, Metalzoid a dit :

Oui, je suis sous marlin, et la commande M125 fonctionne sur Marlin 1.1.9 comme sur Marlin 2.0.

Oui.

Ce que je dis c'est que les deux sites que j'utilise pour connaître la signification des commandes gcode, pour l'un le M125 n'est pas dans la liste .

[Nenex]

Sur les prusa ils ont du ce limité a faire monter le Z de 2mm car la plupart du temps la tête n'a pas le temps de revenir en X min.

Modifié (le) Mai 1, 2019 par Nenex
Ajout source

[Janpolanton]

Il y a 17 heures, Metalzoid a dit :

Ok, merci je vais tester ça  

Il peut pas tester, il a mis le module en panne mdr 

Mais ça peut se tester sans, en mettant la pin 44 au 5V  avec une résistance de 10k et en simulant la coupure en mettant cette pin au niveau 0

[Janpolanton]

il y a 2 minutes, Nenex a dit :

Sur les prusa ils ont du ce limité a faire monter le Z de 2mm car la plupart du temps la tête n'a pas le temps de revenir en X min

Il est prévu une réserve d'énergie avec mon module...

[Metalzoid]

Salut tout le monde  

Bon, j'ai fait un code qui ne fonctionne pas. 

J'ai fait plusieurs essais, soit l'imprimante continue comme si de rien n'était, soit elle s'arrête sur place. 

Si quelqu'un à une idée de code. 

Voici plusieurs essais réalisés : 

  // If power-loss pin was triggered, write just once then kill
    #if PIN_EXISTS(POWER_LOSS)
     if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE){
      enqueue_and_echo_command_now(PSTR("G27"));
     ]
   else if (READ(POWER_LOSS_PIN) != POWER_LOSS_STATE){
   enqueue_and_echo_command(PSTR("M24"));
   }
    #endif 

  // If power-loss pin was triggered, write just once then kill
    #if PIN_EXISTS(POWER_LOSS)
     if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE){
      enqueue_and_echo_command_now(PSTR("G27"));
     }
      #endif 

[Tircown]

On va reprendre depuis le début si tu veux bien. Je n'ai pas de quoi tester sur mon imprimante alors je me base sur la doc:

Dans configuration.h as-tu bien décommenté #define NOZZLE_PARK_FEATURE? Sans ça G27 ne fera rien.

Dans configuration_adv.h as-tu bien décommenté  #define POWER_LOSS_RECOVERY? Y-a-t'il bien un M413 S1 quelque part au début de ton GCODE (> activation du power_loss_recovery)? sans ça pas de power_loss_recovery, M24 notamment est inopérant.

Maintenant sur ton code:

- M24 ne sert à rien: à partir du moment ou tout est bien paramétré l'imprimante enregistrera la position actuelle sur la SD soit chaque couche ou un délai maximum, soit comme pour toi au trigger du pin dédié (si c'est paramétré). Au redémarrage du microcontrôleur (passage par setup() ) elle cherche si il  a quelques chose à récupérer d'elle même. Tout est automatique a ce niveau.

- Sur le premier if l'accolade de fin n'est pas la bonne, bizarre que tu ais pu compiler avec ça. Supprime également ton else if, qui d'ailleurs correspond ici à un else simple: il peut avoir deux effets. En mode couche/délai il se produira TOUJOURS et fera redémarrer le print là ou il a été enregistré ( càd juste avant), donc au mieux c'est totalement transparent mais sollicite juste le microcontrôleur inutilement. En mode triggered il ne se produira (normalement) JAMAIS puisque le contenu de la fonction dans laquelle ce trouve cette condition ne s’exécute que si le pin est triggered.

Power_loss_recovery se charge d'enregistrer, récupérer toutes les infos. Effectivement G27 est mieux que M125.

Dans mon précédent post j'ai oublié, et c'est très important, de mettre M104 S0 et M140 S0 pour couper la chauffe car ça ne le fait pas tout seul.

On peut éventuellement rajouter M106 et G4 S240 après G27. M106 active la ventilation à fond pour protéger la tête et peut-être éviter un bouchage de buse (la chaleur ne remontera pas dans le heatbreak).

G4 S240 sert à mettre en pause en laissant finir les actions du G27 et sans en rajouter. Je te conseille dans tous les cas de mettre le kill juste après le dernier M400 ou G4 S240.

Si on ne met pas M400 ou G4 S240 l'imprimante s'éteint juste après avoir envoyé la commande sans attendre qu'elle ne se réalise.

Si on ne met pas le kill elle repart sur sont print après ces 240s (tête froide et plateau froid à la reprise).

  // KILL now if the power-loss pin was triggered
    #if PIN_EXISTS(POWER_LOSS)
      if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE){
      
      	// TEMP OFF
    	enqueue_and_echo_commands_P(PSTR("M104 S0")); // arrête la hotend
	enqueue_and_echo_commands_P(PSTR("M140 S0")); // arrête le heatbed
      
      	// NOZZLE_PARK
      	enqueue_and_echo_commands_P(PSTR("G27")); // range la tête
        //enqueue_and_echo_commands_P(PSTR("M400")); // attend la fin des mouvements de la tête, pas utile si on a G4 S240 après.
      
      	// HOTEND FAN
      	enqueue_and_echo_commands_P(PSTR("M106")); // ventilateur hotend à fond pour protéger la tête et éviter des bouchages.
	enqueue_and_echo_commands_P(PSTR("G4 S240")); // on laisse ventiler 4min sans rajouter de mouvements
      
      	kill(PSTR(MSG_OUTAGE_RECOVERY)); // on peut tout arrêter sereinement
    	}
    #endif

J'ai juste un doute si enqueue_and_echo_commands_P() exécute directement ou empile à la fin du GCODE. Plutôt que de chercher pendant des heures, le plus simple est de tester.

Bien sûr pour que le power_loss_recovery fonctionne correctement que si le microcontrôleur s'arrête et redémarre. Ce qui signifie que si le courant revient pendant ces 4min (avant le kill) il faudra forcer le redémarrage du microcontrôleur. Je t'aiderai aussi plus tard si tu veux corriger ce bout de code et pouvoir repartir sur le print si le courant revient à temps.

[Metalzoid]

Salut  

Merci pour ton aide ! 

Alors voilà, j'avais trouvé pour la commande "enqueue_and_echo_commands_P" pour exécuter le code demander immédiatement. 

Pour le reste du code, qui effectivement ne fonctionne pas, voilà en fait l'idée :

Si le pin est triggered, lancer la commande M25 (qui met pause à l'impression et park la tête vu que c'est configuré)

Si le courant revient avant le fin de la batterie, donc le pin redevient non triggered, relancer l'impression où  elle en était vu qu'elle était en pause. 

C'est sur cette partie que j'ai besoin d'aide maintenant.

Bien sûr, rajouter la coupe du chauffage etc, mais je pense que je peux le faire une fois que tout le code fonctionne.

Merci  

ps: pas besoin de la commande  M413 S1 dans le gcode, vu qu'il est activé en permanence.

Et pourquoi faire un kill, vu que la batterie éteindra d'elle même l'imprimante quand elle sera vide ?

 

Ou alors une autre idée, 

si pin triggerred, mettre en pause l'impression avec M25 (et park de tête), attendre tant de temps (le temps de la batterie + un rab), et si le minuteur arrive a terme, reprendre l'impression. Une idée ? ^^

Modifié (le) Mai 8, 2019 par Metalzoid

[Tircown]

Ok, M76 remplace effectivement avantageusement le M400 et G4 et permettra de reprendre plus facilement. Et garder le G27.

M25 n'est valable que pour les impressions par SD et nécessite d'activer PARK_HEAD_ON_PAUSE. Ce paramètre  induit d'autres choses pas forcément désirées par tout le monde. Si tu utilises octoprint ou debug avec pronterface ou équivalent tes modifications n'auront pas le même comportements qu'avec la SD. Bref j'éviterai.

Peut-être peux-tu envoyer tes fichiers configuration.h, configuration_adv.h et power_loss_recovery.cpp de tes récents tests. Une étourderie est vite faite et tu peux débugger ton code tant que tu veux tu ne trouvera pas. Si je peux apporter mon regard extérieur ça sera avec plaisir.

[Metalzoid]

ok  

Le problème, c'est que le power_loss_recovery ne fonctionne que par carte SD, pas autrement malheureusement. Donc obligé de passer par une carte SD. 

Ensuite, pour M25 et Park head on pause, on peux configurer ce qu'on veut comme comportement dans configuration_adv.h

Ensuite, je pense que pour le timer que je pense, on peux utiliser plutôt M226 S1 pour attendre que le pin que l'on veut configurer soit activé. Ce qui donnerait un truc comme ça : 

ps : je viens de tester ce code. Alors actuellement, lorsque je coupe le courant,  il ne fait pas le park. Par contre, dès que je remet, ça reprends automatiquement. 

Une idée ? ^^

     // If power-loss pin was triggered, write just once then kill
    #if PIN_EXISTS(POWER_LOSS)
      if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE){
      enqueue_and_echo_commands_P(PSTR("M25"));
      enqueue_and_echo_commands_P(PSTR("M226 P16 S1"));
      enqueue_and_echo_commands_P(PSTR("M24"));
      }
   #endif 

Modifié (le) Mai 8, 2019 par Metalzoid

[Tircown]

Oui effectivement ça ne marche que par SD actuellement, étourderie de ma part. L'enregistrement en EEPROM est prévu dans le futur.

Si effectivement la suite est prise en compte la seule chose que j'imagine encore c'est une étourderie dans la configuration du park_head. Si tu as un LCD tu peux éventuellement vérifier que c'est bien ces M226 P16 S1 et M24 qui sont interprétés en intercalant M117 +texte.

[Metalzoid]

Ah pas bête ! Je testerai ça demain [emoji23]

[Tircown]

S'il redémarre c'est normale que tout reparte comme prévu: c'est le fonctionnement du power_los_recovery et c'est possible qu'aucun des rajouts fait au code ne fonctionne. S'il ne redémarre pas c'est peut-être bien tes M226 P16 S1 et M24 qui fonctionnent et donc M25 qui a un problème. Il faut déjà être sur de quel cas de figure se présente, donc je mettrais un marqueur M117 au début du if, un après M25 et un après M24 avec des textes différents pour tester.  Le redémarrage du MCU peut être quasi invisible car instantané et il pourrait se produire évidement quand tu coupes le courant à la prise. Peut-être aussi lorsque le courant est remis dans la foulée et que ça bascule de la power bank à l'alimentation "normale". Peut être une baisse de tension momentanée qui provoque un reset MCU. Ce sont de simples suppositions et après tout ce n'est pas problématique car dans tous les cas ça reprend le print comme désiré. L'objectif est donc juste de savoir si tes commandes sont bien prises en compte.

[Metalzoid]

Salut  

Bon j'ai testé plusieurs fois, avec différents codes. 

Alors, lorsque j'ai les trois commandes "enqueue_and_echo_commands_P" à la suite, tout est traité d'affilé, et en fait, les premières commandes ne sont pas traités, juste la dernière. 

Ensuite, j'ai remarqué que lorsque "enqueue_and_echo_commands_P" est traité, il est traité en boucle. Je pense que cela peut poser problème pour le traitements des commandes. 

Est-ce que vous avez une idée des codes qui puissent être traités immédiatement, mais une seule fois ? 

Merci  

[Tircown]

Effectivement. Je n'étais pas allé chercher assez loin les infos sur les fonctions. Je n'ai trouvé aucune doc dédié mais le code de Marlin est assez bien documenté.

Dans Marlin.h de la version 1.1.X on a: (ligne 235-237)

bool enqueue_and_echo_command(const char* cmd);           // Add a single command to the end of the buffer. Return false on failure.
void enqueue_and_echo_commands_P(const char * const cmd); // Set one or more commands to be prioritized over the next Serial/SD command.
void clear_command_queue();

C'est donc tout à fait logique que ça soit la dernière commande de la liste qui soit exécutée en premier.

3 solutions pour corriger:

1. vider la file et la re-remplir avec les bonnes commandes: clear_command_queue puis utiliser enqueue_and_echo_command.
2. retourner tout l'empilement mais ce n'est pas du tout élégant.
3. mettre toutes les commandes dans 1 seul appel à la fonction: enqueue_and_echo_commands_P( PSTR("M25\nM226 P16 S1\nM24"))

 

Si tu veux être conforme au standard Marlin, c'est la solution 3 gérée comme ci-dessous et ça pourrait même faire l'objet d'un pull-request après validation:

•   déclarer une variable (ex: POWER_LOSS_SCRIPT) dans Configuration_adv.h au même endroit où tu déclares le pin (ligne ~596):

/**
 * Continue after Power-Loss (Creality3D)
 *
 * Store the current state to the SD Card at the start of each layer
 * during SD printing. If the recovery file is found at boot time, present
 * an option on the LCD screen to continue the print from the last-known
 * point in the file.
 */
#define POWER_LOSS_RECOVERY
#if ENABLED(POWER_LOSS_RECOVERY)
  #define POWER_LOSS_PIN   16     // Pin to detect power loss
  #define POWER_LOSS_STATE HIGH   // State of pin indicating power loss
  // Commands to execute after power-loss pin was triggered
  // as long as there is electrical power
  #define POWER_LOSS_SCRIPT "M25\nM226 P16 S1\nM24"  
#endif

• modifier power_loss_recovery.cpp ainsi: (ligne ~277):

// If power-loss pin was triggered, execute script, write just once then kill
#if PIN_EXISTS(POWER_LOSS)
  #if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE)
    #ifdef POWER_LOSS_SCRIPT 
      enqueue_and_echo_commands_P( PSTR(POWER_LOSS_SCRIPT));
    #endif
    kill(MSG_POWER_LOSS_RECOVERY);
  #endif
#endif

[Metalzoid]

C'est pas du tout bête comme idée  

Mais j'ai déjà testé "M25\nM226 P16 S1\nM24" et le problème est qu'il n’exécutes pas les commandes comme il faut. 

En gros, avec cette configuration, l'imprimante fait le park head, mais ne reprends pas. Je pense avoir trouvé la solution. 

Avec :

enqueue_and_echo_commands_P(PSTR("G1 X0 Z3\nM226 P16 S1\nG1 Z-3\nM24"));

Le X reviens à 0, Z monte de 3, puis attends l'état du pin configuré. Je pense que l'on peux réussir à insérré plutôt que M226 l'état du pin non égal. Je sais pas par contre comment faire. 

Ensuite, quand le courant reviens, redescend de 3 et reprends l'impression. Avec ceci, même octoprint (bon normalement, lui aussi se coupe, mais pour les essais non) reste en impression.

Je viens de tester le code ci dessus, il fonctionne correctement  

Modifié (le) Mai 10, 2019 par Metalzoid

[Metalzoid]

Ton code :

// If power-loss pin was triggered, execute script, write just once then kill
#if PIN_EXISTS(POWER_LOSS)
  #if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE)
    #ifdef POWER_LOSS_SCRIPT 
      enqueue_and_echo_commands_P( PSTR(POWER_LOSS_SCRIPT));
    #endif
    kill(MSG_POWER_LOSS_RECOVERY);
  #endif
#endif

Ne fonctionne pas. Il ne veut pas compiler  

[Tircown]

En fait si elle reprend probablement mais il y a le kill juste derrière. Pour éviter ça on reste l'état du pin après toutes les commandes.

// If power-loss pin was triggered, execute script, write just once then kill
#if PIN_EXISTS(POWER_LOSS)
  if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE){
    #ifdef POWER_LOSS_SCRIPT 
      enqueue_and_echo_commands_P( PSTR(POWER_LOSS_SCRIPT));
    #endif
    if (READ(POWER_LOSS_PIN) == POWER_LOSS_STATE) kill(MSG_POWER_LOSS_RECOVERY);
  }
#endif

et ceci en script: "G27 P2/nM226 P16/nM24"

MAIS ça pose soucis s'il y a vraiment coupure de courant (batterie vide ou kill). L'impression reprendra avec le Z trop haut.

Modifié (le) Mai 10, 2019 par Tircown
Debug syntaxe du code

[Tircown]

il y a 11 minutes, Metalzoid a dit :

Ne fonctionne pas. Il ne veut pas compiler  

Effectivement, j'ai corrigé ci-dessus. (je ne suis pas très à l'aise en C)

(je fais un double-post car j'ai édité alors que Metalzoid est sur la page)

Modifié (le) Mai 10, 2019 par Tircown

[Metalzoid]

Salut  

Comme je t'ai dit, il ne faut pas le kill je pense. 

[Metalzoid]

et ça ne veut toujours pas compiler à cause de :

   enqueue_and_echo_commands_P(PSTR(POWER_LOSS_SCRIPT));

Je pense qu'il ne comprends pas qu'il faut exécuter la variable "POWER_LOSS_SCRIPT"'