Closed scorpiawilding closed 1 year ago
adamzxtan
commented
3 years ago I'm having the same issue. My printer is Ender 3 V2, after updating my Cura from 4.7.1 to 4.8.0 same issue happen. The printer will stop in the middle of print randomly and my extruder will stop extruding at the same time. The printer screen just hang there, nothing happens even though I tried pressing my rotary knob.
GregValiant
commented
3 years ago Every three seconds Cura (and Pronterface too) send M105 to check the temperature of the hot end. If the buffer in the printer is almost full the M105 gets truncated to "M1" which is a stop command and sends "Waiting for user" to the LCD. From what I've read, the Cura Team (very busy at the moment) has not updated the USB Printing function because Ultimaker doesn't make any printers that use it and so it is low priority. Sending Gcode at the exact speed that the printer is using it (to avoid over-flow and under-run) is tough. If you need a remote Print Server then Octoprint/Raspberry PI is the alternative. At any rate, that's what I've come across. adamzxtan - does that printer have a TFT screen instead of an LCD? Then you also have a firmware problem that will cause the printer to stop, but it can't display the "waiting for user" message on the TFT so it hangs. M117 probably doesn't work and Cura Pause at Height (M0) won't work either. That one I'm still chasing down. It's a Creality problem. It's possible that a firmware upgrade will fix M117 and M0, but the problems with printing over the USB will persist.
fieldOfView
commented
3 years ago If the buffer in the printer is almost full the M105 gets truncated to "M1"
I had not figured out that was the mechanism the causes the pause; I had been looking for a buffer overrun detection that then triggers a pause, but M105 being truncated to M1 makes a surprising amount of sense.
GregValiant
commented
3 years ago I should start keeping track of my references. I read it around here someplace. I don't know python but this seems to be involved "self._timeout = 3" The variable is used in a few other places but this one seems significant: "if self._last_temperature_request is None or time() > self._last_temperature_request + self._timeout:
if not self._printer_busy: # Don't flood the printer with temperature requests while it is busy
self.sendCommand("M105")
self._last_temperature_request = time()"If "self._last_temperature_request + self._timeout:" was "self._last_temperature_request + 30:" the variable would be left alone to do it's bit elsewhere. Every three seconds is a serious sampling rate.
GregValiant
commented
3 years ago Someone from the Cura Team (it was either Nallath or Ghostkeeper) was aware of this. I asked if it might be some sort of over-temp safety and he said it wasn't because the printer was expected to handle that. I wondered at the time why Cura (or Pronterface) would need to keep such close track of the temperature considering the overhead of two way communication on the USB. At any rate I'm pretty sure there is at least one other bug report on the "sudden stop when USB printing".
adamzxtan
commented
3 years ago adamzxtan - does that printer have a TFT screen instead of an LCD?
@GregValiant I think its a TFT display, they didn't really specify in the printer specs sheet. At least I can't find that info.
But anyhow, I downgraded my CURA back to 4.7.1 and seems to have "fix" the problem. I also changed a new SD card for saving my gcode from Cura. My printer doesn't hang anymore. So, it might be the SD card that I was using was corrupted, causing the printer to hang in the middle of print.
GregValiant
commented
3 years ago It's funny how fussy the printers are regarding the SD card. Good that you found out what was going on. This other issue remains though. I'm starting to think that when Creality was running out of parts they just grabbed whatever mainboard they had laying around a used a quicky patch for the firmware and missed the target. Not good. The newer machines apparently don't show the problem.
Ghostkeeper
commented
3 years ago Can someone explain why it has to be so time consuming to report a bug with cura? having to create a github account, mess with the crappy dice test to then be asked to write an essay for something that is a simple bug is sub par at best and encourages people to not post the problems they may have. Adding the feature to directly report a bug with an included log would be extremely useful.
Because we really can't fix bugs that we can't reproduce. Before the template existed, we pretty much always had to ask for a project file. We've been getting issues that just say CuraEngine stops working or something which is obviously not the case for the developers / in every slice, or we'd not have released it. So we need more specific reproduction steps. The project file is an extremely useful tool, and so are the reproduction steps itself. Essentially all bugs need either a log file or a project file, and although we'll not complain if one of them is missing and it's not relevant, many more bug reports die out due to not having enough information if we don't have that template.
Ghostkeeper
commented
3 years ago As far as I'm concerned this is a duplicate of https://github.com/Ultimaker/Cura/issues/5989 . However since this thread now seems to contain more information than the other one, I'll close the other one and make this the main thread to not interrupt the discussion here.
The cause back then was found to be Windows turning off the serial port after a certain amount of time to save power. Still doesn't really make sense to me. If that is the issue there may be something we can do to instruct Windows to not be annoying. But it'll be very hard to fix. We can't spend time on debugging USB cable printing since it's not something we can realistically maintain if none of Ultimaker's printers support this any more.
Someone from the Cura Team (it was either Nallath or Ghostkeeper) was aware of this. I asked if it might be some sort of over-temp safety and he said it wasn't because the printer was expected to handle that. I wondered at the time why Cura (or Pronterface) would need to keep such close track of the temperature considering the overhead of two way communication on the USB. At any rate I'm pretty sure there is at least one other bug report on the "sudden stop when USB printing".
As far as I'm aware this update timer has two functions:
We could probably change it to update every 5 seconds if necessary.
Cura indeed has no temperature "safety" constraints other than a temperature limit of 300 degrees in its settings. If the printer reports that its nozzle is 9000 degrees, Cura will happily show "9000" at the nozzle temperature field, although the thermal radiation from the nozzle may be blacking out your monitors.
obiben
commented
3 years ago The cause back then was found to be Windows turning off the serial port after a certain amount of time to save power. Still doesn't really make sense to me. If that is the issue there may be something we can do to instruct Windows to not be annoying.
I can at least comment I've tested turning off any type of power-saving feature related to USB and the issue kept occurring. A truncated command seems like a good fit for an explanation, but it seems unlikely. If that was the case then surely other commands would get truncated and prints would fail in a myriad of unexpected ways.
GregValiant
commented
3 years ago "...other commands would get truncated and prints would fail in a myriad of unexpected ways." And they might be. The clue was "Click to Resume..". It is sent by M1 so in that specific case there is a trail of breadcrumbs. And as has been noted, it is M105 that is constantly being sent by Pronterface and Cura to check the temp.
Ghostkeeper
commented
3 years ago Most commands that Cura outputs start with either M1, G1 or G0. Of those, M1 is the only one that does anything if it's not provided any parameters. The only other common command I can think of is G92 which could be truncated to G9 but the G9 command doesn't exist so it would be ignored by the printer.
Cura's USB printing only sends the next g-code line to the printer if it receives an ok response via the serial port. I'd expect that the printer only sends the ok response if it's ready to receive another command. But maybe it still sends ok responses even if its serial buffer is full?
GregValiant
commented
3 years ago When I first looked around at this, I came across a nice description of the problem (I don't know if it was correct, but it was a nice write-up). I wasn't able to find it this time. I did come across other comments. This old one on StackExchange Cura Issue 3994 Cura Issue 4329 This appears to be an ongoing problem and isn't limited to Cura. Prusaslicer, Simplify3D, and Pronterface are all mentioned as having the same sort of issue (Octoprint was mentioned once as well). One suggestion was using M155 since it would only need to be sent once, but there would only be one "ok" returned.
mydevpeeps
commented
3 years ago This started happening to me today after I rearranged my start code in cura. I am printing from SD, but have pronterface open. I will test more tomorrow...
Ghostkeeper
commented
3 years ago Did your continued tests result in any new insight as to what causes this?
mydevpeeps
commented
3 years ago You can see from the attached image, the slicer or "printer host" is trying to get the temp via M105 while the printer is busy heating up.. eventually the RX buffer fills up and the last command you see there is what? M1M105.. as in.. M1.. as in pause. This happened to me while printing from an SDCARD, but connected via serial/usb from pronterface. No, it's not cura. No, it's not a usb print.. and yes it still happens.
Based on what I saw from various older posts the theory was that the serial buffers were getting full and turning some commands into M1. Once I increased the buffer sizes to 256 RX/TX ALL of my "unknown command: M1M105, MM105" etc that randomly appeared went away. My theory, as well as others, is that because my bed takes so long to heat up (its 500mm using a 12V stock pad with glass)) and the BUSY_WHILE_HEATING is enabled in the firmware, pronterface is just flooding the buffer with M105 commands until it's done heating and then this fires that M1 that was suspected.
So what can be done about this from a cura standpoint? Well, that depends on how your firmware is compiled. Some are different than others, but if you are using marlin then I would ask these questions:
I have seen a lot of statements about "usb printing" being bad or horrible in cura and I have also seen a lot of people who tweak their firmware settings to accommodate for serial printing (such as buffer sizes) and have 0 issues with it. And then there are people I personally know who have never tweaked anything or even customized their printer (ender 3 pro) and it works perfectly 100% of the time both in prints and using usb print in cura.. I'm sure there are other variables in here.. I just don't know what they are. I hope this helps somehow. There are things cura, and other slicers, can do to minimize serial noise during prints, and there are things you can do like customize your firmware to increase buffers to gain more stability.
Ghostkeeper
commented
3 years ago I can answer some of those questions:
If the marlin config is set to BUSY_WHILE_HEATING and sends a "busy" notice via serial to cura, does cura recognize that and stop sending commands?
It should. It's not sending temperature commands while busy:
busy is recognised as response here:
If the marlin config is not set to BUSY_WHILE_HEATING does cura send an M105 (if it's not using M155) every second expecting a response if it doesn't get this host busy message?
If Cura doesn't get a response after 3 seconds it'll assume the USB connection is severed. However it appears that the printer in this case still sends ok responses to Cura. If the connection is (supposed to be) severed, Cura won't try to send M105 commands any more.
If the marlin config is set to AUTO_REPORT_TEMPERATURES does cura use M155 Sn once instead of sending an M105?
If the marlin config is not set to AUTO_REPORT_TEMPERATURES does cura run it anyway and see what it gets back as a response?
If the marlin config is set to EXTENDED_CAPABILITIES_REPORT does cura read the value at startup that tells it M155 is enabled?
No, Cura doesn't integrate with this feature and never sends M155 commands. Implementing this could resolve the issue for some firmware.
github-actions[bot]
commented
1 year ago Hi 👋, We are cleaning our list of issues to improve our focus. This bug seems to be older than a year, which is at least three major Cura releases ago. It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.
If this is still a problem for you in the current version of Cura, can you please leave a comment? We will have a fresh set of eyes to look at it.
If it is not a problem anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.
github-actions[bot]
commented
1 year ago This issue was closed because it has been inactive for 14 days since being marked as stale. If you encounter this issue and still experience this to be a problem, you are welcome to make a fresh new issue with an updated description and screenshots.
Can someone explain why it has to be so time consuming to report a bug with cura? having to create a github account, mess with the crappy dice test to then be asked to write an essay for something that is a simple bug is sub par at best and encourages people to not post the problems they may have. Adding the feature to directly report a bug with an included log would be extremely useful.
Tried using the search bar for my specific issue but unsure if keywords were actually being used and nothing revelent came up.
cura 4.8.0 using usb connection
Windows 10, 3700x, 1660ti
Ender3
The specific issue is that the printer will randomly stop and will sometimes say "waiting for user", once the dial is pressed it resumes printing and changes the text to "resuming print". I have not included any pause at height or filament change as i regulary use these extentions and check before slicing each time. Also its normally half way through the first few layers and will be mid way through doing the infill on a layer when it pauses and also sometimes happens on the purge line cura uses at the beginning, it stops after completing the first line but then doesnt return and the printers button has to be pressed for it to continue. This obviously leaves a blob of plastic and ruins the entire print.
This has been happening on the last 3 versions of cura including the current that im using of 4.8.0 and can also happen multiple times on a larger print but mostly happens on the infill of the first few layers. Only once or twice has it been half way through the print and then pauses.
Unfortuanly it is not specific to anything i am trying to print, it is just randomly occuring on different projects that i have and seemingly randomly too. The only fix that i can find is to save it to file instead and use a sdcard which then prints perfectly fine without any pauses which makes no sense as it should be the exact same g code.
Im sorry but having to search on how to upload the log is not user friendly, have looked through the dropdowns within cura and nothing regarding logging, this should be as simple as clicking a button to be included within the report a bug button but unfortuantly its just a hyperlink to github.
Please let me know if there is anything else i need to provide apart from the log until its been made user friendly. Have been looking at ultimakers printers to buy but worry if the software cant even be fixed after multiple updates then what will the printer itself be like. I hope that this is simply something to do with the printer itself and not cura but i am unsure and havent experienced the problem with other slicers but prefer cura to the rest so would like to be able to reliably use as its otherwise an extremely good bit of software.
Any help and or suggestions would be greatly appreciated as im at a loss to what is causing this issue so randomly and is time consuming having to watch the initial part of the print incase it decides to pause itself.
Thank you very much for any help and taking the time to read this,