Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
krolco opened this issue Jan 11, 2014 · 13 comments

Comments

Projects
None yet
3 participants
@krolco
Copy link

commented Jan 11, 2014

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 added a commit that referenced this issue Jan 11, 2014

Couple of multi extruder related fixes
- also recognize such temperature reports that do not contain a "T:" but a "T0:" (should help with parts of #345)
- properly parse temperature commands to track target temp during slow heatup
- for the former point, also keep track of the currently selected tool
- simulate heatup and replies without "T:" in virtual printer (to test all this)
- also auto-caps T commands in terminal
@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 11, 2014

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

This comment has been minimized.

Copy link
Author

commented Jan 14, 2014

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

This comment has been minimized.

Copy link
Author

commented Jan 16, 2014

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

This comment has been minimized.

Copy link

commented Feb 8, 2014

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

This comment has been minimized.

Copy link
Author

commented Feb 8, 2014

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

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 10, 2014

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

This comment has been minimized.

Copy link
Author

commented Mar 10, 2014

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

This comment has been minimized.

Copy link
Author

commented Mar 11, 2014

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

This comment has been minimized.

Copy link
Owner

commented Mar 11, 2014

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

This comment has been minimized.

Copy link
Author

commented Mar 11, 2014

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

This comment has been minimized.

Copy link
Owner

commented Mar 13, 2014

@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

This comment has been minimized.

Copy link
Owner

commented Aug 31, 2014

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

@foosel foosel closed this Aug 31, 2014

@krolco

This comment has been minimized.

Copy link
Author

commented Aug 31, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.