La varible « impression en cours » evite d’éteindre l’imprimante instantéement lorsque on stoppe l’impression pour cause de problème (pas d’adhérence sur le bed par exemple)
Bonjour,
Le scénario et les déclencheurs me semblent OK comme ça.
N’hésitez pas à faire quelques tests avant pour valider, en particulier concernant le délai arbitraire de 3’ qui doit correspondre à un temps de descente suffisant en T° du bed en fonction de son coefficient d’inertie thermique.
En effet, sur un plan temporel, le scénario sera appelé à chaque changement de T° du bed (qui est un élément déclencheur), et donc le dernier bloc ‹ SI › sera répété toutes les 3’ + x secondes (x étant dépendant de la vitesse de décroissance de la T° du bed et du cadencement de l’envoi de cette info vers Jeedom), jusqu’à ce que la T° soit < à 50°C (arrêt de l’imprimante + variable à 0 => la condition #[Imprimante 3D][ENDER-3 KE][Statut] != « Printing » && variable (Impression_en_cours)==1 ne sera plus vraie à ce moment)(j’espère avoir été clair, mais sur un chronogramme c’est assez évident…).
Il faut donc éviter de saturer Jeedom…
A noter que cette remarque s’applique également lors de la montée en T°.
Bonjour
Cela ne fonctionne pas…
Le scenario se lance a chaque changement de la T° du BED, donc, je pense que la variable (impression_en_cours) reste a 0 a cause de la condition du SI
Qu’en pensez-vous ?
Merci
A+
Dans le « Sinon » tu as oublié un = ( !==« printing » ):
Ensuite ,pour la logique intellectuelle, tu ferais mieux de renommer ta variable « impression_en_cours » par « impression_terminée ».
Bonjour,
Non, rien à voir, avec != ou !== ca marchera très bien (voir un peu plus haut dans le fil, j’en parle déjà…) 
Bonjour,
Méa culpa, je crois que j’ai laissé passer ça en effet.
La condition dans le premier bloc DANS exécuté après 3’ d’attente n’est pas bonne :
C’est bien == qu’il faut mettre pour que ça fonctionne. C’est à dire que la variable ne sera mise à un que si l’imprimante est effectivement en cours d’impression.
Comme je le disais, comme l’un des déclencheurs est la T° du bed, à chaque variation lors de la montée en T°et signalement vers Jeedom (delta T ?) et jusqu’au passage à 1 de la variable (au plus tôt 3’ après donc), ce bloc sera programmé, puis exécuté puisque la condition sur le statut de l’imprimante ne devrait pas changer (printing).
De même, à la fin de l’impression pour le second bloc DANS.
Bonjour
En effet, j’ai modifié. Mais toujours un souci
Je pense avoir trouvé, mais ne comprends pas comment le resoudre
La condition n’est jamais vrai…pourtant Printing = Printing et 0=0 !!! Sauf qu’il y a des parentheses à Printing et pas l’autre
Une idée ?
Merci
A+
PS : il y avait des parentheses en trop que je ne voyait pas !!!
Bonsoir,
Je comprends que c’est OK maintenant ?
Le scenario se deroule…mais nouveau souci !!!
#[Imprimante 3D][ENDER-3 KE][Statut]# !== « Printing » && variable(impression_en_cours) ==1 est vrai , dans 3’ => #[Imprimante 3D][ENDER-3 KE][Statut]# !== « Printing » && #[Imprimante 3D][ENDER-3 KE][Actuelle bed]# < 50 si vrai arret de l’imprimante…Sauf qu’entre temps, la T° du BED continue de descendre et rebollote, de nouveau une tempo de 3’ !!!
Donc pas d’arret de l’imprimante
A+
Ok. Il faut mettre une instruction ‹ remove_inat › dans le dernier bloc DANS…, après l’affectation de la variable à la valeur 0 par exemple.
Ca va tuer toutes les exécutions programmées à venir.
cela ne va jamais dans le dernier bloc, il attends 3’ pour ensuite arreter l’imprimante, envoyer la notif et mettre la variable à 0, sauf qu’entre temps, la T° descend, donc le scenario se relance et de nouveau 3’ !!!
Il pourra aller dans le dernier bloc, que lorsque la T° ne bougera plus
Bonjour,
J’avoue que je ne comprends pas comment c’est possible.
Je viens de réétudier le mécanisme, qui, en ajoutant un ‹ remove_inat › dans le bloc de fin (où l’imprimante est stoppée) comme je le disais hier, devrait éliminer toutes les occurrences à venir des blocs programmés.
Ci dessous un schémas encore plus détaillé :
- à T1 : Le statut de l’imprimante passe sur ‹ ops ›. => on déclenche le scénario : le test ‹ imprimante au repos › (vrai) ET variable = 1 (vrai) est vrai => dans 3’, je lance le bloc.
- à T2 : variation de T° du bed => on déclenche le scénario : le test ‹ imprimante au repos › (vrai) ET variable = 1 (vrai) est vrai => dans 3’, je lance le bloc.
- à T3 : variation de T° du bed => on déclenche le scénario : le test ‹ imprimante au repos › (vrai) ET variable = 1 (vrai) est vrai => dans 3’, je lance le bloc.
etc…
-
à T1+3’ : le test imprimante au repos (vrai) ET T° du bed < à 50°c (faux) est faux => fin du scénario
-
à T2+3’ : le test imprimante au repos (vrai) ET T° du bed < à 50°c (faux) est faux => fin du scénario
-
à T3+3’: le test imprimante au repos (vrai) ET T° du bed < à 50°c (vrai) est vrai => j’exécute le dernier bloc: arrêt imprimante, notification, variable mise à 0, et exécution du remove_inat qui supprime toutes les occurrences des blocs ‹ DANS… › programmées par la suite.
-
à T4 : variation de T° du bed => on déclenche le scénario : le test ‹ imprimante au repos › (vrai) ET variable = 1 (faux) est faux => fin du scénario.
etc… jusqu’à ce que la T° du bed soit stabilisée à la T° ambiante.
Sur le principe, je ne vois pas ce qui cloche pour ma part, il y a quelque chose qui m’échappe…
Le scénario est bien en mode non synchrone, et pas de multi-lancement (les cases ne doivent pas être cochées) ?
Re-bonjour,
Je reviens sur le scénario, que j’ai testé ‹ en vrai › en simulant la montrée/descente de T° avec une variable et l’état de l’imprimante avec un bouton (bon, je ne vais pas entrer dans les détails…).
Au résultat, je vous propose d’effectuer deux modifs dans le scénario :
- Sortir le second bloc de test de la boucle SINON…
- D’empêcher dans le premier bloc SI de réévaluer les conditions s’il n’y a pas eu de changement.
Ca donne ça (c’est mon scénario de test, à adapter bien sûr avec les valeurs réelles)
Pour empêcher la réévaluation, il faut cliquer sur l’icône ici :
Les éléments déclencheurs restent les mêmes (statut + T° du bed).
D’après mes tests, ca donne :
Au début d’une impression :
- sur changement de statut de l’imprimante, on programme la tache d’affectation de la variable 3’ après.
- sur changement de T° du bed qui va monter, il n’y aura pas de répétition de la tâche programmée (même conditions initiales de test sur le statut + variable)
- 3’ après, passage de la variable à 1, et dès que le bed est à température, début de l’impression.
En fin d’impression :
- le statut de l’imprimante repasse à ‹ opérationnel ›, ce qui provoque la programmation de la tâche d’arrêt 3’ plus tard.
- Les changements de T° du bed, qui va redescendre, provoque la reprogrammation de cette tâche, et celle-ci sera repoussée dans le temps tant que la T° ne sera pas inférieure à 50°c.
- Dès que la T° passe en dessous de 50°c, le test du dernier bloc passe à VRAI et l’imprimante est stoppée+envoi de la notif+suppression de toutes les autres tâches programmées ensuite avec le remove_inat.
Alors ca marche bien avec mes propres tests, reste à voir ce que ca donne avec des données réelles…
Bonjour
Modification faite. Au passage j’ai aussi changé une condition. A savoir je ne prends plus la T° du BED mais celle de l’extrudeur. cela ne change en rien le scenario
Ne reste plus qu’a tester
Merci pour votre aide
Thierry
Bonjour
Le script fonctionne…merci beaucoup a vous tous !!!
Mon probleme de base, a savoir, la remontée d’info vers OCTOPRINT (temps, avancement) est toujours NOK…Tant pis tant que je peux couper l’imprimante !!!
Thierry
Bonjour,
Nickel ! 
Merci de penser à classer ce sujet comme résolu !
Je rebondis…
Pourquoi ne pas envisager d’installer une instance Octoprint sur un RPi3 dédié (ou un Orange Pi, Banana Pi,…) par exemple ?
Intégré à mon imprimante dans un boitier imprimé pour, il me permet d’avoir toutes les fonctions comme gérer la mise hors tension en fin d’impression, le monitoring vidéo en Wifi, la gestion de l’allumage d’une rampe LED, du changement de filament, etc… De plus, il y a pas mal de plugins plus ou moins utiles qui peuvent venir s’y greffer…
Bonjour
Classé le sujet comme résolé ? Oui et non car le probleme de base etait la remontée d’infos OCTOPRINT
Concernant octoprint sur RPI (ou autre), j’y ai envisagé, mais je n’ai pas de cable USB-USB pour relier le RPI a l’ecran de l’imprimante. Donc j’ai laissé tombé …J’ai vu qu’il fallait mettre un bon d’adhesif sur l’alim du cable pour eviter d’endommager le RPI ou l’imprimante
Je vais me repencher sur le sujet
Thierry
J’ai installé le plugin OCTOPRINT qui m’indique que mon systeme n’est peut-etre pas compatible (utilisation de jeedom avec un RPI4). Cela semble fonctionner, mais je n’est que le statut et les T° qui remonte comme infos.
N’étant pas le développeur de ce plugin, à part lui je pense que personne ne fera de miracles non plus… Mais comme c’est un plugin officiel, le dépôt d’un ticket sur le marketplace pourrait peut-être faire avancer les choses.
Juste pour ma gouverne, et je n’en demanderai pas plus parce qu’on sort un peu du cœur du sujet, installer Octoprint sur un RPi se résume à installer un serveur d’impression, accessible en Wifi via son @IP. Le RPi n’est connecté à l’imprimante que via la carte mère, c’est à dire la prise USB à gauche destinée à une connexion vers un PC.
Pourquoi vouloir le connecter sur l’écran ?
Sur mon imprimante ENDER3 KE, je n’ai pas de prise USB sur la CM. Les seules prises USB sont sur l’ecran