I have a new issue when I set up a filament change in my slicer. Everything was going well until yesterday. When the print reach the layer to change the filament, all works accordingly: the filament gets ejected, I load the new one, purge a little more, but the I hit continue, the printer head goes toward the print and instead of starting to print it stall there and does not move. On the LCD it sais the printer is resuming/p[printing but nothing happens.
Only after a long wait (3 minutes) the printer starts printing again. But at this point, the nozzle melted a dot in my print (where is was parked), a blob of new filament is melted on top.
What did you already try to solve it?
Reading through the forum, I tried extending the communication times.
I did try to print from the SD card and all worked well.
Have you tried running in safe mode?
Yes, still same issue.
Did running in safe mode solve the problem?
No
Systeminfo Bundle
You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
I am unable to download systeminfo Bundle. this is what I get...
This site can’t be reached 127.0.0.1 took too long to respond.
Explain what you mean specifically when you say "I set up a filament change in my slicer". What slicer, what is the method the slicer is using to "do a filament change" what is the method that is used to tell the system/printer what to do once you hit resume ?
Does it have just the pause or does it include the motion instructions to send the head to a safe position?
Does it shut off the Hot end? I am surprised at how often this is part of the process. Not really but I do forget it does it almost every time I finish a roll mid print. It is done so that you don't have your hot end on while you are not able to come to the printer for hours. but is easy to forget when you are testing things.. It may be that you unloaded and loaded and never turned the hotend back on. This might account for your wait time before it starts to print. 3 min is a little long but maybe.
Thank you very much for answering my post. I am still bit new and learning, I am sorry I left important details out my description.
I use cura slicer. I use a post-processing (please see screenshot) command available to change the filament at a certain layer to change the colour of the print. In this case, I printed a black rectangle with white letters on top.
When the printer finishes the layer before the ones I set up the change for, the nozzle lifts, goes to the back corner of the bed, ejects the filament and "bips" to let me know to insert the next filament. After inserting it, I can chose on the printer to purge more filament to make sure the new filament is in and ready to extrude. To resume it all, I press "continue" and the print resumes.
Here is where the issue started happening. The nozzle moves to the point where the print was paused, the screen says it is resuming the print, but nothing happens - the nozzle stays at that position for a very long time. During that whole process (pause, filament change and resume) the nozzle stays at the same temperature I set in my slicer for the print.
When the print is supposed to resume (like the screen and octoprint says) but the nozzle is stuck at the position without resuming, I see the following message in the terminal:
"Communication timeout while printing, trying to trigger a response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves."
This started happening today. Few days ago, the print would resume instantly after hitting "continue" after the filament change.
HOWEVER, when the print with the SD card, all works perfectly. But of course, I really much prefer how things were before today
I was thinking it was just that OctoPrint did not know about the resume but because you have now said that it worked in the past, its likely something that has changed. Any thoughts on what you might have changed? Updated the build or firmware or cura version ? Anything? Are you running the same exact gcode file that worked in the past and now it just does not?
Would be good if you could turn on the serial log (debug) for a print and run the issue so I can see what is happening. The post your SystemInfo Bundle ? The entire bundle please.
I ran the print again, did the same thing. When I go to download the systeminfobundle, I had issues doing it, I was receiving TIME OUT errors form the address for download.
I am very new to all this side of octoprint/3d printing ingeneral. But I in the serial log, where it start saying "Printer signalled that it paused, switching state..." thats where the filament change started... and then when the nozzle is stalled at the resume position (but not doing anything) I start seeing the following message: "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."
Only thing I can see that is strange with your log is that it looks like it snaps out of its comm issue when OctorPrint sends: N2318 M105*31 on line 5730
The strange part is why was that sent. In my experiments using this feature today, that code is not something that shows up in my logs. Its not something that shows up in my gcode either. I am pretty sure that it is OctoPrint asking for the temps but why?
The printer is clearly sending data to Octoprint. OctoPrint is seeing the data. Its in the log.. It is the responses that the printer is sending every 2 seconds. This auto response is because OctoPrint sent this to ask it to send the temp data ever 2 seconds. M155 S2 on line 61 of your log.
The issue is clearly that OctoPrint is not getting the response it wants from the printer. I think it wants a response that includes an Ack(ok). Not sure why. I don't see it making any requests for something specific.
Could be just a simple comm issue. But I don't think so. I think OctoPrint thinks its not getting a response because it is looking for a specific response(the ack). I have a couple of guesses that might help.
Maybe you updated you OctoPrint build/software version recently? I am pretty sure this is not it since i tested it in both 1.9.x version and then updated to 1.10.3 and it worked fine in both.
Did you update your firmware recently? If yes, and you don't have a good reason why, go back to the older version.
If one of those do not send you in a direction, I would suggest that you could try using the Pause at height CPP script in Cura. It allows for you to set a layer to pause on. You will have to do more work to get this setup right but I use it and it works well for me. My thinking on this is if I am going to use OctoPrint to control the printer, I should avoid handing off a process to the printer closed loop if I can help it. Just an option if you really need to have this working in OctoPrint and you cant get this worked out.
I would be interested in looking at your gcode file if you want me to. Might be something interesting in how the filament change script section is created.
And lastly, maybe someone else that is following the thread has an idea on what is happening here.
Hello @jcassel , I appreciate the time you took to help me out. Thank ou for your help.
I do update Octoprint when it suggests an update. But I cannot remember when was the last one done (maybe a couple of weeks ago). Regarding my firmware, I did the upgrade (update) last November when I upgraded my ender3v2 neo to new fans, double axis, etc. I did upgrade to the new version of CURA about 2 weeks ago. During that time, I printed 2 small objects with filament change (including the one I'm doing now).
Like you mentioned, between line N2317 and N2318 (where the communication issue happen) I understand that octoprint is waiting for temp read from the hotend and the bed to resume, but octoprint does not receive the info. During the process of changing the filament, the temperatures are maintained (I'm reading the screen on my printer).
I RAN MORE TEST TODAY:
I printed the same project I did last week and it all worked fine (CE3E3V2_bed numbes test 8s)
I modified CE3E3V2_bed numbes test 8s to CE3E3V2_Bed number 4 test filament change in FUSION, sliced it in CURA (adding a filament change at layer 5) and it all worked flawlessly.
Like you mention at the end of your reply, the issue seems to be in the gcode CURA makes for the STL that is creating issues. (CE3E3V2_RYOBI LOGO BOX2.gcode)
EDIT: When I compare both Gcodes (problematic one and newer one that worked) when the change filament plugin ends, the problematic gcode has the following line that the other does not have:
M106 S255
M204 S400
Can it be that those lines are creating the issue?
