Im having the same issue when using Cura 4.6.1 with my CR 10 MAX.
Can do one print, not an issue, Next print can say "waiting" then "cooling" the randomness of it is baffling
Im having the same issue when using Cura 4.6.1 with my CR 10 MAX.
Can do one print, not an issue, Next print can say "waiting" then "cooling" the randomness of it is baffling
Jason, yes very odd on the randomness. Just came into the studio this morning and halfway through a 24 hour print. So far so good. David
Can anyone from Ultimaker jump in here for any advise? Most of my prints take between 8 and 24 hours. I really don't feel that sleeping in my studio waiting to press a button is a good way to go. Any solutions? Thank you.
Just happened again on a new file. So far 5 events in a 3 hour period. I would really like some direction on this problem! Current print will take 2 days. Is there a paid version of Cura that gets more support? Free software is great until it's not. I have this software as part of my business. I can't sleep in my studio pressing the "go" button to continue printing! Help me Obe Wan Kanobie, you're my only hope!
Hello all. Got back in the studio this morning and the printer was paused. I'm guessing I wasted at least 6 hours on a 2 day print. Does anyone have any ideas? This is starting to affect my projects.
It sounds very much like there's a post processing script enabled, but you said you've checked that already.
You can check your gcode in any text editor. Atom or Notepad++ are recommended.
There are some existing issues on our bug tracker that indicate it's a firmware bug.
See discussions here: https://github.com/Ultimaker/Cura/issues/4590
The "Wait for user input" thing happens when there is a buffer overrun in Marlin. Cura somehow sends gcode commands (such as eg temperature update requests) while the printer has not yet processed previous commands.
It's also caused on creality printers when the filename is too long, I've seen this when printing from an sd card, I've preheated the printer and the console just says "waiting". Reduce filenames to the old 8.3 convention and the error goes away
Edited by jasonhardingThank you all for the input. After this print, I'll give the shorter filename a try.
Also noticed that after the 1.5mm Z height, the issue goes away. EDIT 6/9/2020 I was wrong, it still did it later on in the print.
Thanks again,
David
Edited by dndemattiaStarted a new print this morning and made sure the file name was within 8 characters. After an hour, no pausing problems. So far so good. Thanks all for the help!
David
That's awsome glad to hear
I have the same (similar?) problem that dndemattia has. The "wait for user" error always occurs at the end of a print line during solid fill. It happens more often when the print head has to move further away from the bed center. It always results in a big blob of plastic where the nozzle pauses. I have a Creality CR-10s and Cura 4.6.0.
I did not have this issue at all with Cura 2 or 3.
Before you export the file to print in Cura, modify the file name to no more than 8 characters in the file name. Remember DOS?
That fixed it for me.
David
Thanks David! I've changed the filenames now. Haven't had a chance to try it out, but will soon.
I just wanted to follow up on this discussion. No printing problems since implementing the 8 character rule.
Thanks everyone!
David
Hi All, It's been doing it again! 3 times in a week on 9 hour overnight prints. I have a major project too finish and I can't have this.
Can anyone recommend another slicer?
3 hours ago, dndemattia said:another slicer?
You don't need another slicer, you just need another host; ie a program to send the gcode to your printer. You could try printrun/pronterface. Personally I am partial to using OctoPrint so I don't have to keep my main computer running and connected to the printer 24/7.
When printing via USB does Cura poll the printer for temperature with M105?
It does.
If that is part of a host-side thermal runaway precaution it would probably be hard to get rid of (lawyers being as they are).
While poking around the various cited threads I went back to Marlin and noticed this under M105
Some hosts may hide the reply from M105
.
A better way for hosts to get regular temperature updates is to use M155
(requires AUTO_REPORT_TEMPERATURES
and EXTENDED_CAPABILITIES_REPORT
). Hosts then no longer need to run an extra process or use up slots in the command buffer to receive temperatures.
It would seem that the printer would have to be queried to check if those options are enabled before M155 could be used successfully. Since Cura (and other hosts) must work with multiple flavors of firmware running on numerous models of printers I'm guessing that even if it were possible it would get really clumsy really fast.
I find this interesting because I use my own host program to run the printer (just VBA macros from within MSExcel). I tried to add USB printing and it worked...for specific models like a calibration cube. If the model had large meshes and/or any round features. I was unable to coordinate the data flow to account for how fast or slow the data was being processed by the printer. I put a lot of thought into the code and it all ended up in the toilet.
The SD card works well. I control SD printing from the host program rather than sending the Gcode line-by-line via USB. I understand that isn't an option for Cura, and some folk will always want to print via USB.
18 hours ago, GregValiant said:I put a lot of thought into the code and it all ended up in the toilet.
That is incidentally the situation with Cura and USB Printing. No printers since the Ultimaker 2 have officially supported printing over USB. As an effect, USB Printing has had no substantial work done to it since then.
Auto temperature reporting does not work with all printers, because it is disabled in many firmwares. I don't think there are any Ultimaker printers that support it out of the box. So realistically, there is no chance that Ultimaker is going to put work into supporting it in Cura.
18 hours ago, GregValiant said:If that is part of a host-side thermal runaway precaution it would probably be hard to get rid of (lawyers being as they are).
It isn't. It is used to show the temperatures in the monitor interface. There is no host-side thermal runaway detection in Cura (or any other host I know of). This should be handled by the firmware.
Thanks for the explanation. Once again I get confirmation that Everything effects Everything.
A person who knew absolutely nothing about Python or plug-ins might say something ignorant like "self._timeout = 30"
But then he/she would be neither aware of nor responsible for any of the possible ramifications of adding a single zero nor how many times the variable is used in the plugin nor what else it is used for.
Entropy always increases and ignorance is bliss.
Edited by GregValiant
Recommended Posts
dndemattia 1
Update: I uninstalled Cura, ran a registry cleaner then rebooted. Reinstalled Cura without the old configuration files. I received four "Wait for User Input " in a 10 minute period.
Link to post
Share on other sites