search

intelligent-agent / redeem

Firmware for Replicape
http://wiki.thing-printer.com/index.php?title=Redeem
GNU General Public License v3.0
36 stars 44 forks source link

Redeem doesn't recover from cancelling a print #96

Open cwhinton opened 6 years ago

cwhinton commented 6 years ago

Using the 2.1.x branch. Cancelling a print causes Redeem to consume ~94% cpu and close connection to OctoPrint. OctoPrint is unable to reestablish the connection. Steppers are powered off but the heaters continue to activate, indicated by lights on the replicape and temperature measurements taken with IR thermometer. I've let the printer set for 10 minutes in this state without Redeem recovering. Rectified by restarting Redeem with systemctl.

I've triggered the behavior with both the 'normal' cancel button as well as OctoPrint addins that issue M112.

goeland86 commented 6 years ago

@cwhinton stupid question - do you have a similar issue if you use print from SD and use the cancel button then? I think it issues M25 instead of M112 in that case.

cwhinton commented 6 years ago

I've not attempted any printing from SD.

Szeker commented 6 years ago

@goeland86 - do you refer to the "emulated" printing from an SD card - introduced in 2.1.2 ?(Link: http://wiki.thing-printer.com/index.php?title=Print_from_sd)

If so, than I have the same experience with "printing form SD": after cancelling the print I have to restart and reconnect to Redeem (or even Octoprint, I'm not sure) to make it running again.

As I do not have all conditions in my mind - at which exact conditions the issue happened - I will re-check it and give feedback on it here.

goeland86 commented 6 years ago

@Szeker yes I am. Hrm. This is frustrating. I feel almost lucky that the release isn't done yet as it gives us time to fix it.

BTW any idea if there's a correlation with the OctoPrint settings? (please don't reply on that particular problem, this is just to know if you've modified the OctoPrint settings or not) https://github.com/foosel/OctoPrint/issues/2575

cwhinton commented 6 years ago

I've not adjusted my OctoPrint settings but my M114 response looks like

Send: M114
Recv: ok C: X:5.0 Y:5.0 Z:29.3 E:-1.0 A:0.0 B:0.0 C:0.0 H:0.0

so should be parsed by OctoPrint according to the notes in the linked issue.

Wackerbarth commented 6 years ago

Well, we made a change to put X,Y,Z toward the front. My question has to do with the C: just after the ok. I don't think that it should be there.

troy-jacobson commented 6 years ago

@cwhinton Are you using M574 command anywhere in your print?

cwhinton commented 6 years ago

I'm not using M574 in my prints.

I tested again tonight and I'm not able to repeat my original post with the 'stock' cancel button. After Redeem finally clears its queue and stops printing, the heaters shut off as expected. CPU remains normal as well.

However, when testing the response to the 'Simple Emergency Stop' plugin that issues M112 to cancel the job, part of the issue is reproducible at will. The high cpu use isn't occurring tonight, but OctoPrint is unable to reconnect to Redeem and Redeem continues to maintain the heaters. The hot-end does seem to be in a very slight decline whereas my heated bed slope is upwards.

The details are in the attached file, but on my test print the heat targets are: Tool: 195C Bed: 75C

M112 Issued at Apr 29 02:47:30 Redeem Restarted and OctoPrint reconnected at Apr 29 02:51:50 In 04:20 the Temperatures were: Tool: 190C Bed: 80.6C

As can be seen in the attached file, both the tool and the bed cool off more quickly than what was achieved in that 4 minutes.

syslog-Annotated.txt