M.A.J. Octoprint 1.2.14 sous Raspbian --> Pb de connexion

[Z122]

Une mise a jour d'Octoprint (1.2.14) est disponible... mais je vous la déconseille fortement.
Je l'ai installée 'automatiquement' (Raspberry PI 3 sous Raspbian Jessie)
et depuis la connexion se stoppe après la séquence des 4 points de mesure du palpeur,
quelque soit le fichier.gcode

Le message log est le suivant :

"Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1626
Changing monitoring state from 'Operational' to 'Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1626'
Connection closed, closing down monitor"

Octoprint déconnecte alors la Disco 200.
 

Ce problème a été remonté: https://github.com/foosel/OctoPrint/issues/1425
Et d'après ce post, des utilisateurs ont pu ré-installer la version 1.2.10.

Je ne sais pas comment revenir à la version 1.2.10
Si vous avez des idées, un grand Merci par avance pour votre aide.

Modifié (le) Juillet 28, 2016 par Z122

[sili40]

Le plus simple ne serait pas de réinstaller le système ? De mon côté aucun problème avec la nouvelle version... Pour l'instant

Envoyé de mon PLK-L01 en utilisant Tapatalk

[gisclace]

Pas de soucis non plus de mon côté.

Pour downgrader :

SURTOUT NE PAS ETRE EN SUDO :
 

cd ~/OctoPrint

source ~/oprint/bin/activate

git reset --hard <1.2.13>

python setup.py clean

python setup.py install

sudo service octoprint restart

[LeBress]

Bonjour,

Même problème que @Z122 pour moi également, je suis sous Rpi 3 Model B. @gisclace je suis entrain de tester ta méthode de downgrade mais à la ligne "git reset --hard <1.2.13>" j'ai une -bash: erreur de syntaxe prés du symbole inattendu  " newline ". Peux tu m'en dire plus.

Merci

Modifié (le) Juillet 29, 2016 par LeBress

[gisclace]

Essaies sans les < > autour de la version, ça devrait mieux fonctionner.

 

Et vérifies la version que tu veux downgrader.

Modifié (le) Juillet 29, 2016 par gisclace

[LeBress]

Merci ça à l'air d'avoir marché. Je vais maintenant voir si le problème à disparu.

[gisclace]

Parfait, tiens nous au courant, si ça peut aider les autres ;-)

[LeBress]

C'est bon, après les quatre points de mesure elle imprime normalement. Donc il y a bien un problème avec la 1.2.14.

Merci encore pour ton aide.

Modifié (le) Juillet 29, 2016 par LeBress

[Z122]

Merci beaucoup à @gisclace et à @LeBress pour votre aide et vos réponses !!

Je n'ai pas encore downgrader Octoprint en 1.2.13: ma Disco imprime des pièces (via la SD card) pendant  encore une dizaine d'heures,
et Octoprint me permet juste -pour le moment- de visualiser l'impression à distance...

J'avais trouvé ce lien : https://github.com/foosel/OctoPrint/wiki/FAQ#how-can-i-revert-to-an-older-version-of-the-octoprint-installation-on-my-octopi-image
qui indique la même procédure que celle de @gisclace.
Il y a juste un " Git Checkout Master" en plus, à la 3eme ligne. Est-ce important ou non nécessaire?

Encore Merci.

[gisclace]

Pas de quoi, un forum c'est fait pour ça

 

Non ce n'est pas utile dan ton cas de le faire. (à mon que tu aies joué manuellement avec les maj et les branches de github, mais si c'était le cas, tu aurais déjà fait le downgrad sans attendre mes lignes ;-) )

[Z122]

Effectivement, tu as raison @gisclace : je suis novice et pas du tout à l'aise dans ce domaine... pour preuve:

Je viens d'essayer de taper les lignes de code pour downgrader, et suis déjà bloqué à la deuxième ligne:

    pi@raspberrypi:~ $ cd ~/OctoPrint
    pi@raspberrypi:~/OctoPrint $ source ~/oprint/bin/activate
    -bash: /home/pi/oprint/bin/activate: Aucun fichier ou dossier de ce type

Je n'ai pas ce fichier ou dossier car, je n'avais pas installé l'image Octopy, mais avais installé Raspian Jessie, puis Octoprint via ce tuto, (car j'utilise l'écran tactile officiel) : https://github.com/foosel/OctoPrint/wiki/Setup-on-a-Raspberry-Pi-running-Raspbian

En regardant de plus près ce même tuto, les lignes qu'il me faut pour downgrader sont les suivantes avec "1.2.13" en lieu et place de <old_version>

 cd ~/OctoPrint/
 git checkout master
 git pull
 git reset --hard 1.2.13
  ./venv/bin/python setup.py clean
  ./venv/bin/python setup.py install
 

Je l'ai fait et suis bien revenue en version 1.2.13 ...

Pour découvrir ... après reboot un message comme quoi une nouvelle version 1.2.15 est disponible... grrr....
https://github.com/foosel/OctoPrint/releases/tag/1.2.15
Apparemment Gina Häußge a identifié et corrigé les erreurs de communication. Mais je vais attendre un peu avant de tester.

Modifié (le) Juillet 30, 2016 par Z122
erreur de comprehension

[gisclace]

Bon et bien c'est parfait si tu as réussis au final, comme ça tu apprends ;-)

[LeBress]

Après downgrade en 1.2.13, le problème de @Z122 est résolu, mais lors de mes essais, les impressions ne dépassaient pas plus d'une heure. Le pronlème est de nouveau apparue lors d'une impression de deux heures à 50% du temps. J'ai fait un essai avec la 1.2.15 est c'est pareil.

[gisclace]

Cela ne vient pas forcément d'octoprint, tu as déjà imprimé plus d'une heure par carte sd ?

[LeBress]

Bonjour @gisclace

Oui j'ai même fait des impressions de 4h00.

Pour info, j'ai réinstallé la version 1.2.10 d'Octoprint est plus de problème. Ce que je n'arrivais pas imprimer sous 1.2.13 ou 1.2.15 est passé comme une lettre à la poste.

Merci à toi.

[Z122]

Bonsoir @LeBress

Sous 1.2.13, j'ai fait une impression de 5 heures, qui s'est bien passée (Gcode de 7Mo).
(Néanmoins, l'affichage du temps restait "blanc", sans valeur. Puis il a commencé à s'afficher seulement au bout de 2h~2h30 d'impression... je n'avais pas remarqué ce type de symptôme auparavant, mais peut-être était-ce déjà là...)

(A noter que nous n'avons pas tout à fait les mêmes installations: je n'ai pas Octopy, mais Raspian Jessie sur lequel a été installé Octoprint)

Questions & hypothèse: quelle est la taille de ton Gcode qui n'imprime pas en entier? Quelle est la taille de ta carte SD et combien te reste-t-il d'espace libre dessus?
Pour info, j'utilise un carte SD de 32 Go et ai près de 23 Go de libre.
Si tu as une carte de 8Go, peut-être est-elle proche de la saturation?

[gisclace]

@LeBress, peux-tu nous donner tes logs ? Je persiste et signe, ce n'est pas forcément du à octoprint, ca peut venir du gcode, de ta melzi, de ton port usb...

 

Pour l'affichage du temps, c'est un bug connu et reconnu ;-)

[LeBress]

Salut @gisclace, 

Effectivement je dois avoir un des problèmes que tu as listé car hier impression en 1.2.10 d'une pièce qui prenait 17 mn et un peu avant la fin plantage.

Comment tester mon port usb ou ma melzi pour savoir si le problème vient de là. J'utilise depuis peu Cura 15.04.6 pour générer mes gcode. J'ai importé dans Cura standard via CuraProfilTransform les profil de CuraByDagoma.

Je vais tester Octoprint avec ma Dagoma en vitesse inférieur, genre 115200.

En pièce jointe je mets mes deux gcode qui mon posés problème et qui ont été générés par Cura 15.04.6.

Merci d'avance à toi pour ta précieuse aide.

Poulie_Guide_Fil.gcode

Boitier_Haut.gcode

[LeBress]

Alors pour mon problème, dans le fichier Poulie_Guide_Fil.gcode il a fallut que je supprime dans Cura standard ou Cura By Dagoma dans le end.gcode la ligne comme je n'ai pas de lit chauffant.

M140 S0        ;heated bed heater off (if you have it)

Par contre je ne comprends pas pourquoi avec Cura By Dagoma et la carte sd avec cette ligne tout ce passe bien alors qu'avec octoprint ça plante.

Pour l'autre fichier ça ne plante pas au même moment alors je reste sur le fait de la version d'octoprint était le problème pour le moment en attendant de trouver autre chose.

[gisclace]

Ca ne doit pas venir de là, le commandes sont lancée les unes après les autres, si une commande faisait planter (celle-ci) ton impression aurait planté à la fin de celle-ci (donc le ,modèle aurait été imprimé en entier).

 

Tu as quoi dans les logs ?

[LeBress]

Bonjour @gisclace ,

Pour les logs d'octoprint, je fais un copier / coller des commandes qui apparaissent dans la fenêtre terminal ou il y a une autre méthode ou je récupère un fichier quelque part.

@+  

[gisclace]

Soit tu vas dans les logs en ssh, soit tu copies/colle le contenue du fichier htm dispo dans paramétres -->log

[LeBress]

@gisclace, Ok mais lequel je prends il y en a plusieurs des fichiers logs. Ne sachant pas je joins les deux.

Enfin quand je dis plante, je m'exprime peut être mal, avec mon fichier Poulie l'impression s'arrête avec la tête au dessus de ma pièce attend un certain temps puis la tête va en home. L'attente correspond à une alarme dans le terminal "Warn: Not sending "M140 S0", printer profile has no heated bed Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves."

Alors qu'en supprimant cette commande la pièce se fini et la tête va directement à home.

Il est vrai que dans les deux cas on peut dire que la pièce est fini. Mais je ne comprends pas le warm alors que je n'ai pas coché dans octoprint le fait d'avoir un lit chauffant.

octoprint.htm

octoprint.log.htm

Modifié (le) Aout 4, 2016 par LeBress

[gisclace]

oula, tu mélanges les problèmes la. En page précédente, tu avais des plantage en milieu d'impression, là en gros c'est à la fin.

 

Je te confirme que tu peux avoir ce code en clôture, ne pas avoir de lit chauffant et ne pas planter pour autant. Tu as bien décoché le lit chauffant et n'a rien coché dans les propriétés ?

[LeBress]

Oui tu as raison je n'ai pas été assez précis, désolé.

Dans Settings -> Profils imprimante j'ai bien décoché Plateau chauffant, par contre je ne comprends pas ce que tu veux dire "dans les propriétés ?"