Octoprint seems to fail when printing to RepRapPro Tri-color Mendel

[krolco]

Octoprint reports a serial communication error when printing starts.
Also, the temperature monitoring doesn't seem to work -- the temp line returned from M105 is different on multi-material RepRapPro and I don't think OctoPrint understands the format yet.
RepRapPro firmware says it has a race condition that means that frequent M105 can causes errors. We might need a way to disable or throttle M105.

Serial log is here:

http://pastebin.com/BpxHp7Er

[foosel]

I've done a quick fix that should make the temperature monitoring work, could you please try this out?

Regarding the race condition, do you have any link for me regarding this? Is this some bug report somewhere? I'm a bit stumped that the firmware wouldn't be able to cope with a M105 every 2sec. Can you tell me what exactly changed here?

2014-01-08 23:07:10,145 - SERIAL - DEBUG - Send: M105
2014-01-08 23:07:10,166 - SERIAL - DEBUG - Recv: ok T0: 209.4/210.0 T1: 24.5/-273.1 T2: 30.1/-273.1 B:86.2 /100.0 @:44
2014-01-08 23:07:12,173 - SERIAL - DEBUG - Send: M105
2014-01-08 23:07:14,178 - SERIAL - DEBUG - Send: M105
2014-01-08 23:07:16,185 - SERIAL - DEBUG - Send: M105
2014-01-08 23:07:18,190 - SERIAL - DEBUG - Send: M105

Before 23:07:12,173, it responded as expected, after that it just stopped. Since the log doesn't indicate a change to the printing state until 23:41:38,924 I guess it wasn't you hitting the print button that caused the responses from showing up.

[krolco]

Odd, I thought I left comment here already... I must not have posted it. Sorry!
So a couple of things. First, you are correct that the firmware stopped responding to M105 before I started the print. I don't really know what happened there. I have had a bunch of problems with the multi material firmware.
I think I misrepresented the problem as a race condition. Here is a link to the RepRapPro folks discussing the M105 problem:

http://www.reprappro.com/documentation/RepRapPro_Multimaterials#Hints_and_tips_for_multimaterial_printing

I tried out the changes you committed on devel. They seem to work well with three extruders. I'll try to get a screenshot.

[krolco]

So there are still a bunch of issues that OctoPrint experiences, that I don't seem to get on Pronterface.
The first is that sometimes the firmware stops respoding to M105 commands. You noticed that in the trace, and I don't know why it occurs, but it seems to happen. I haven't had the problem on Pronterface, and I don't understand this part yet.

The second issue is that issue during a toolchange, the firmware outputs temperature lines while the newly selected tool is heating up, and they don't match the format the M105 command. So it looks like the temperature graph gets confused again. I'll try to get you a sample of that output. It just reports "T:" instead of "Tx:" on the toolchange, which would mean that OctoPrint would have to keep track of selected tool state to report that correctly. That's pretty janky, and I think it's a bug in Marlin, but that's the currently released state of it.

The third issue is that I'm still getting the communication timeout errors when actually trying to print. Still not sure what's causing that -- I'll try to get more sample output.

Thanks for all your help!

[mrongen]

I recently upgraded my RepRapPro Mendel to Tricolor and am experiencing the same problem. If you need any further debug infos, I am happy to do some testing.

[krolco]

I am wondering if OctoPrint waits for "ok" before sending the next M105?

[foosel]

Sorry that it took so long to get back to this, it's kinda difficult sometimes to keep track of all these tickets.

I just pushed ca87796 which allows you to configure a custom interval for temperature queries during printing. I plan to make it so that if you enter 0 here it won't query the temperature at all (should mitigate that race condition thing), however I have to take a closer look at how i'll make sure you don't get continuous timeouts then (since the regular temperature update right now is basically what's keeping the connection alive). I don't think there's a "no-op" GCODE that would be just perfect for this...

Now, regarding the other issues:

1. My hope would be that this is actually caused by the issue you linked to
2. A sample output would be helpful here. OctoPrint actually does track the current tool already (if possible only of course -- printing from SD will make this impossible as of right now)
3. Any more samples regarding the timeout at the start of the print job?

[krolco]

No worries. I switched back to Pronterface for now; I will try to get this up and running again. There isn't a GCODE no-op; however, I was talking to the MatterControl guys, and they said they wait until the printer responds "ok" before enqueuing the next M105. I don't know if OctoPrint does that, but it might help in the case where it's not disabled. In any case, I disable the temp graphs in Pronterface when printing now. Unless the printer is broken, they aren't that useful to me.

I'll see if I can get this going on Octoprint again and see what I can capture. Thank you for looking at this!

[krolco]

I re-read your comment just to make sure: a value of 0 for the interval is expected to disable monitoring, but that isn't implemented yet?

[foosel]

Right now entering 0 will make it query the temperature continuously, however it would make sense to read this as a "don't query at all" setting in the future, that isn't implemented yet though yet since I first have to solve some issues in order for this to work.

[krolco]

Some output, truncated for PasteBin size.
There isn't much to see here, just the communication timeouts when attempting to send a line. Octoprint sends M105, and the printer responds, but once I try to print, all I get are these communication timeouts.

http://pastebin.com/fA3GXc4K

There wasn't anything interesting surrounding this, but I have the rest of the file.

Note that this output was taken after I had updated to the dev branch and the temperature timeout to 0; it was still pinging the printer. Is that expected behavior on timeout 0? I thought that was a disable.
Thanks for looking at my mysterious issue!

Hope this helps a bit.

[foosel]

@krolco Quoting myself: "Right now entering 0 will make it query the temperature continuously". So no, currently 0 won't disable it.

2014-03-10 23:59:26,742 - SERIAL - DEBUG - Recv: /k T0: 25.0/-273.1 T1: 24.5/-273.1 T2: 25.0/-273.1 B:99.7 /100.0 @:0
2014-03-10 23:59:41,766 - SERIAL - DEBUG - Communication timeout during printing, forcing a line

There appears to be some signal loss issue here, and since OctoPrint never sees an ok from your printer due to that, it doesn't try to send another M105 (or anything else for that matter) before it runs into the timeout, triggering another M105. Could you give me a log excerpt right from the beginning of a print? Set the temperature timeout to something like maybe 10s.

[foosel]

Haven't heard back from this one in a while, considering it closed.

[krolco]

Hi Gina,

Sorry about that. I downgraded my machine back to single color for a while and changed my toolchain, so I haven't been troubleshooting this. Will reopen if it comes back up.

Sent from my iPhone

On Aug 31, 2014, at 4:25 AM, "Gina Häußge" notifications@github.com wrote:

Closed #345.

—
Reply to this email directly or view it on GitHub.