Closed VanessaE closed 1 year ago
ChrisTerBeke
commented
6 years ago I don't think this is something Cura can fix. If the OS doesn't give Cura enough resources when sleeping, Cura can't send lines fast enough. This is one of the many reasons why USB printing is strongly discouraged.
ChrisTerBeke
commented
6 years ago @ianpaschal @Ghostkeeper agree?
VanessaE
commented
6 years ago But if Pronterface doesn't have a problem, doesn't that mean that the underlying system is fine?
ChrisTerBeke
commented
6 years ago I think it comes down to how a program (or the used language) integrate with the underlying OS. There's a lot of possible issues in that area. Given that we don't really support USB printing, I don't think it'll get fixed by Ultimaker developers.
VanessaE
commented
6 years ago Mind you, the system is not in any way "sleeping". Just the monitors turn off (DPMS I guess). Everything is at full capacity otherwise.
ChrisTerBeke
commented
6 years ago Is DPMS using a lot of CPU at that moment? We have some machines in the office as well with an external display dock and the Linux drivers for that are really really bad and slow down the system a lot (rendering even code editors unusable).
VanessaE
commented
6 years ago No. There is no significant CPU usage while the screens are powered down, other than those brief (milliseconds-long), periodic spikes that I assume are coming from Cura.
ChrisTerBeke
commented
6 years ago You have any logs from this time interval? Without the actual same hardware setup it'll be hard to reproduce in any case, but maybe those give some insight.
VanessaE
commented
6 years ago Nothing relevant in dmesg, /var/log/syslog, /var/log/messages, /var/log/Xorg.0.log, nor any other system logs that I can think of, for what I think was the right time.
I'll wait for the current print to finish (later this evening), attempt to repeat the problem, and see what Cura's logs say. There's nothing relevant there since I wiped everything related to Cura short of the Appimage, and started over from scratch (nothing of value was lost, since I've only been using Cura for several days).
ianpaschal
commented
6 years ago Hmm, if it really is a matter of the display being off then I'd agree that Cura should not behave that way and there's some bug going on.
My bigger concern is that with these kind of very specific hardware related questions that there's a 1% chance we're able to recreate the bug, which makes it basically impossible to code a fix. 🙁
But let us know.
VanessaE
commented
6 years ago I doubt my hardware has anything to do with it; I'm more inclined to believe it's just a bad interaction between Cura and XFCE. I wish there were an efficient and safe way (== no passwords or other secure info) to share a copy of my OS/desktop.
VanessaE
commented
6 years ago Sorry it took so long to get back to you, but I finally got a chance to reproduce this. stdout is blank, and stderr contains nothing relevant for the time in question. Here it is, nonetheless:
Ghostkeeper
commented
6 years ago We send out the g-code on our main thread which is indeed dependent on rendering. If rendering takes a long time, the buffer on the printer could deplete. We should run the USB printing on a separate job.
ianpaschal
commented
6 years ago @VanessaE Hi Vanessa, we've discussed this at a team and unfortunately we've decided we won't be taking the time to make a fix.
We do consider it a bug and it's true that a large portion of our user base prints via USB, but to our recollection, no one else has reported it.
In this case there's a very easy work-around which is simply to set your computer to not go on sleep. Since that functionality is built in and stable in virtually every OS, we can't justify spending time adding that functionality to Cura (like movie players in full screen) or messing about with the threads.
VanessaE
commented
6 years ago Not sleep mode, @ianpaschal. Plain old DPMS screen suspend-only, triggered by the screensaver. The PC is still 100% awake.
ianpaschal
commented
6 years ago No I know, but that's what I mean. Prevent display from sleeping (as we did in the old days before most media players did this automagically) while watching a movie, for example. All OS has functionality built in to prevent the display from sleeping/screen savering (?, saving its screen?).
Again, it's possible to fix by moving it to another thread so it's not affected by the screen's rendering (or lack thereof) but it's a lot more work for a problem we've only heard of once.
VanessaE
commented
6 years ago Well, to be blunt, whose bright idea was it to put the send-gcode routines on the display rendering thread? This is still a bug, and it sharply highlights a poor design decision (I'm not implying this is your doing, @ianpaschal). It also highlights a potential bug in XFCE.
In any case, my workaround was to stop using Cura.
Oh, and I would have to say that the vast majority of Cura users print over USB, because from what I've seen, most cheap hobby-level printers don't even have LCD/SD.
ianpaschal
commented
6 years ago Well, to be blunt, whose bright idea was it to put the send-gcode routines on the display rendering thread? This is still a bug, and it sharply highlights a poor design decision (I'm not implying this is your doing, @ianpaschal). It also highlights a potential bug in XFCE.
Could check the commits but it's sort of irrelevant now. As I said though we don't deny it's a bug. Only that despite the vast majority of our users using USB, no one else has encountered the problem. We try to work by a "20/80 rule" where we fix 20% of the bugs which solve 80% of our users problems/reports. This is more of a 20/000.1 case. It's not that your issue isn't important to us, but we have to prioritize or else lose our sanity and get nothing done.
In any case, my workaround was to stop using Cura.
That's unfortunate. I hope to see you back in Cura land at some point though.
VanessaE
commented
6 years ago I don't mind if something's just too much of a corner case to not be worth worrying about, but closing the bug and suggesting that I keep my monitors on all the time (which costs electricity and hence, money) is absolutely the wrong thing to do (I can't just switch them off, either, one of them serves as a hub for my keyboard and mouse, and a hard power-off at the switch resets my keyboard settings).
A bug doesn't get fixed if the report for it is closed.
ianpaschal
commented
6 years ago This is true. But a ticket system with a backlog of 800 tickets most of which we either do not intend to or never will be able to fix is not a useful or usable system. Sometimes we have to say, "No."
marcan
commented
5 years ago So this is why my long prints break when I leave them printing overnight. Um, yeah, this is a pretty bad bug. It can be triggered on my system simply with xset dpms force off. The print immediately stalls and starts jumping around once per second.
At least, knowing the underlying cause, I just found a workaround. Minimizing cura while printing makes it immune to this issue. Nothing to render, doesn't stall on rendering. I'm using KDE on Gentoo Linux, FWIW.
If you don't have the time to fix it that's fine, but please reopen the bug. It's a problem and it isn't fixed. No other app has problems with DPMS sleep mode like this. It's not just about rendering, this suggest a deeper underlying bug in the interactions between the UI and printing. Closing the bug is shoving the problem under the rug.
yodor
commented
5 years ago I'm in the same boat as @marcan . I was forced to create a new activity in KDE where dpms is not used so I can leave the printer on during long prints. I would love to see this fixed too
SwiftNinja
commented
5 years ago Chiming in here because the comments from @ianpaschal implies that this is an isolated incident with @VanessaE. It is not. I experience the same frustrating bug and it has ruined more "away" print jobs than I'd care to admit, on the days where I forget to disable DPMS screen save.
The issue has happened to me on Ubuntu 18.04, 18.10, and now Cosmic (19.04). I am running a machine with an AMD Radeon 580 and an Intel Processor on an ASUS motherboard. Using the stock repos - nothing special. A simple power save on the monitor (while the rest of the machine is running at full capabilities) completely wrecking a print job is ridiculous.
I (and I'm assuming all others affected by this, which I suspect is a much larger audience than you think - maybe most people just don't bother signing into GitHub to report it) would really appreciate some action/traction on fixing this - it definitely is not isolated as there are other people chiming in here as well such as @yodor and @marcan. My Desktop Environment (DE) is KDE. Specifically, the distro I'm running is Kubuntu 19.04, Kernel 5.0.0-15.
Please, please fix this. There's really no excuse for a MONITOR (not CPU) powersave to ruin a print job.
marcan
commented
5 years ago I'm curious as to whether the minimizing workaround works for the other affected folks. In the face of the apparent zero interest from the developers in fixing this, it at least makes it tolerable... as long as you don't forget to do it before leaving a long print running.
It's silly and this bug should still be fixed though.
FWIW, I'm going to go ahead and guess that the problem here is that 1) USB printing is done in the UI thread, and 2) the UI thread is trying to do v-synced rendering when the window is visible, but there is no v-sync in the DPMS off state, so wait for v-sync calls stall until a one second timeout or so, and 3) the g-code sending routine is dumb and only sends a max of one g-code command per main loop iteration (i.e. rendered frame); making it fill the send buffer would at least mitigate this by allowing a large batch of g-code to be sent each second.
SwiftNinja
commented
5 years ago @marcan - I would guess that minimizing it may work around it, because I have never been able to pinpoint why sometimes it buggers up the job with power save, and other times it doesn't. I've probably minimized it or at least not had it in the foreground from time to time, and those may be the times it fixes it.
Regardless - the core problem here is that I don't always remember that I have to do some voodoo nonsense to get a print job out. I have a friggin' big label on my monitor saying 'disable power save before print', and I still forget to do that sometimes. So it's equally likely that I will forget to minimize this from time to time.
Devs: The bug needs to be fixed. To suggest that USB printing isn't supported and we should just "not do that" is completely ridiculous. That's like saying I shouldn't be able to use my laser printer while it's connected to Ethernet, and that I should always have to transfer my document to USB and then hot-plug the USB into my LaserJet printer just to get a print job off. Let's be real here. Sometimes, the attitudes of devs on OSS projects is really frustrating as an end user -- and I say that as a career software developer.
nallath
commented
5 years ago Well, the issue is that 95%> of the development is paid for by Ultimaker. Since there are essentially no Ultimaker printers that still use USB printing, there is little reason for us to fix this. That doesn't mean that we don't understand (or acknowledge) that this is an issue, just that we have better things to spend our time on (from the perspective of Ultimaker that is).
All that being said; Pull requests are always welcome. I would love to skew that 95% of the development that's now being paid/done by Ultimaker to a lower number. I can help people out with getting started with the project if that's something that would drag anyone over the line.
marcan
commented
5 years ago I have a USB-only Ultimaker. I also find USB printing a lot more convenient than copying files around, even if I did have an SD module, which I don't.
marcan
commented
5 years ago FWIW, I checked the USB printing code. It does print from a thread, but it also posts progress to the UI every single GCode line written. So I'm guessing the issue is that either the hanging vsync thing I mentioned as the likely culprit is holding the GIL (thus blocking all Python threads), or at least holding some kind of lock that is contended by posting the current print progress.
A good start would be breaking up that progress thing into a condition variable and shared state, avoiding any direct calls from the USB printing thread into the UI. That way the only other thing to worry about is the GIL.
marcan
commented
5 years ago It's a GIL issue, since the delays happen in random places inside the USB print thread. Strace shows the USB thread poll()ing for a reply from the printer, and when the poll() returns, it start spinning on some futex calls every 5ms (which is what take_gil() does), until some other thread gets a message on fd 3 (I assume that's the X11 display connection), then pokes a futex that the main thread is waiting on, which then releases the GIL.
This might mean this is primarily a PyQt5 issue, since the GIL isn't being released around a call that takes a long time.
marcan
commented
5 years ago Oh this is cute.
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x5619978607d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x561990492c68, cond=0x5619978607a8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x5619978607a8, mutex=0x561990492c68) at pthread_cond_wait.c:655
#3 0x00007f15f5285f02 in ?? () from /usr/lib64/libxcb.so.1
#4 0x00007f15f5287a0a in xcb_wait_for_special_event () from /usr/lib64/libxcb.so.1
#5 0x00007f15f548b78b in glPrimitiveBoundingBox () from /usr/lib64/libGL.so.1
#6 0x00007f15f548b8d8 in glPrimitiveBoundingBox () from /usr/lib64/libGL.so.1
#7 0x00007f15f548cace in glPrimitiveBoundingBox () from /usr/lib64/libGL.so.1
#8 0x00007f15f548d9bc in glPrimitiveBoundingBox () from /usr/lib64/libGL.so.1
#9 0x00007f15e9620fc3 in ?? () from /usr/lib64/dri/i965_dri.so
#10 0x00007f15e9621725 in ?? () from /usr/lib64/dri/i965_dri.so
#11 0x00007f15e961cb24 in ?? () from /usr/lib64/dri/i965_dri.so
#12 0x00007f15755d2919 in ?? () from /usr/lib64/python3.6/site-packages/PyQt5/_QOpenGLFunctions_4_1_Core.so
#13 0x00007f15f6b3968b in _PyCFunction_FastCallDict () from /usr/lib64/libpython3.6m.so.1.0Note that the glPrimitiveBoundingBox thing is a red herring because I don't have full symbols. This is probably some kind of vsync call from cura. I need to see if I can get a python backtrace out of this.
marcan
commented
5 years ago As I expected it's a vsync thing. vblank_mode=0 cura fixes it, so an easy fix is to just edit your desktop shortcut or add a shell alias to do that.
SwiftNinja
commented
5 years ago @marcan: Sweet! I'll try it out. Thanks for your efforts into looking into this, and @nallath - thanks for acknowledging re-opening the ticket!!
Ghostkeeper
commented
5 years ago So as I understand from your investigation, PyQt is most likely not releasing the GIL while updating the screen render, but the screen render is blocked by the power management disabling the screen. I'd indeed expect PyQt to release the GIL during that update but I suspect that there is a good reason why it's not. In order to update the screen, Qt may request a bunch of properties from all the QML items that have changed. Some of these properties arrive from the Python bindings that we create, and so PyQt is going to need to execute some Python code in order to update the screen. It's probably not releasing and re-acquiring the GIL for each of these bits of Python for performance reasons.
Maybe that vblank_mode is something that we can set by default? It could introduce some tearing I suppose...
Ghostkeeper
commented
5 years ago It doesn't look like PyQt has a cross-platform way to turn off vsync. Googling around brings up techniques to do that with Qt but those don't seem to be exposed in PyQt, or I just couldn't find them in their docs (those docs are not the easiest to navigate).
marcan
commented
5 years ago I haven't had a chance to get symbols for Python to be able to get a proper stacktrace in gdb yet; the call comes from python through Qt5's OpenGL bindings, so I'm not sure if it's something inside PyQt triggering the vsync or something directly in Cura. Either way the GIL ought to be released around that call, but it might be something that can be worked around by changing the code in Cura.
silver65
commented
5 years ago So.... I was wondering why my printer was printing jerky and ultra-slow when I checked on it after a print overnight ...... (It should have been long finished)
And, then I swished my mouse which disabled the screensaver and it went back to normal......By then the print was ruined.
I am running Cura 4.3 and Linux Mint 19 with the Cinnamon Desktop .
So as I understand it - the engine sending g-code to the printer hangs up because the gui renderer can't update the screen because the screen is off?
Brilliant. That's like saying that the engine in a car should only work when the radio is on....
Who ever uses SD cards to print? What a mission.....
Anyhow, I suspect this bug is far more widespread than the number of me 2's would suggest.
For now, I shall just make sure that I include the vblank thing or minimise Cura before leaving a print to itself....
Ghostkeeper
commented
5 years ago So as I understand it - the engine sending g-code to the printer hangs up because the gui renderer can't update the screen because the screen is off?
Brilliant. That's like saying that the engine in a car should only work when the radio is on....
Almost. All of Cura hangs because the GUI framework that Cura uses seems to lock up all Python code while the screen saver is on. From what we've seen, this is an upstream bug in PyQt5 that only occurs in Linux.
Our user base for printing via USB on Linux is about 0.08% of our total user base (by number of prints). Since this is an upstream issue it's more or less out of our power to do something about it. Maybe there are workarounds possible, but we can't warrant investing time on investigation now. When this ticket was re-opened, it should've been put on deferred to make that more clear.
SwiftNinja
commented
5 years ago @Ghostkeeper : I'd be real cautious about using your quoted statistic of 0.08% as "factual".
First - how are you realizing those usage metrics? Phone-home in the software? If so, there are a lot of forks of Cura (Like Lulzbot and Prusa), that likely do not phone home to provide you those metrics in the first place. Going based on 'number of clicks for download on Ultimaker.com'? See previous point. And what about users who have devices on their network to filter tracking, such as a PiHole? (which I happen to be a user of). My point is, I extremely doubt your usage stats are factually complete and correct. You likely get more stats from Windows users because, in my experience, Windows users don't know any better to know how to stop prying eyes.
Second - Third party tech, such as the Mosaic Palette 2 and OctoPrint, operate entirely on the USB printing interface to communicate to the printer. Take USB printing away, those tools, devices, and other such tangible market value adds stop working.
Third - Discounting Linux in 2019 is, respectfully, an asinine thing to do. The entire world is moving to Linux, whether it's immediately obvious or not. Android? Linux fork. Mac? BSD fork (basically Linux). Windows? More and more direct inline support for running Linux-in-Windows is being added daily - why do you think that is? Windows Azure? Their entire server offerings now recommend Linux over Windows for back-end servers. Servers that power the internet? Linux. Your router that is feeding you your internet? Linux. Your managed switches? Linux. Your smart watch? Linux variant. Your smart refrigerator? Linux based. Your in-car infotainment system? Linux. The developers who work on Marlin and Cura? Running Linux!!! Embedded systems and servers all use Linux - as do actual shops - not tiny shops running Creality cheapo printers.
Linux is here to stay - pretending it isn't or that it's niche is a very fool-hearty mistake to make. And I'd argue that industrial users of 3D Printers are largely only using Linux - because, you know, they have actual work to get done :)
As a developer myself, I understand your position, and I'd normally agree with you - but in this case, I think you're very wrong in your usage assessment.
smartavionics
commented
5 years ago I haven't read any of this thread so feel free to completely disregard this comment.
Why don't you just save the gcode that Cura produces into a file and then use something like pronterface or some other program whose sole purpose in life is to squirt gcode at a tty?
SwiftNinja
commented
5 years ago @smartavionics : Well, for starters, part of their argument is that USB based printing isn't supported and shouldn't be used, which is a huge mistake. It breaks things like the Mosaic Palette and Palette 2, it breaks things like OctoPrint, it would destroy the entire way that I use my printer.
Second - that's fine as a workaround. There are workarounds provided in this thread - workarounds are fine as a short term workaround. People here are asking for the core issue to be fixed, and the devs are basically saying 'No'.
Cheers,
smartavionics
commented
5 years ago I guess it comes down to your expectations. For me, Cura is a slicer, it takes models and produces gcode. That's it, job done. It does slicing, why does it also need to do non-slicing related functions?
Sorry, I side with the devs on this one. But, remember, if someone comes up with a PR that fixes the problem it will be considered for adoption. As long as it doesn't break existing functionality and abides by the house coding standards, there's a good chance it would be accepted.
SwiftNinja
commented
5 years ago @smartavionics : If I accept your argument (which I don't, but digressing...) -- Than why does Cura offer a Printer Control Interface and Print via USB functionality?
If Cura was just a slicer, it would operate like Slic3r.
It's not just a slicer, and that's a choice the devs made when Cura was born. If Cura wants to be a slicer only, than remove all of the other stuff and call it a slicer. And then users like me who don't want to screw around with 4 pieces of software to just get a darn print done will dump Cura and find something else to use, like Simplify3D.
Also, it's important to remember, that just because you only use it as a slicer, that does not mean that the other 99% of people who use Cura are using it the same way. Lulzbot, for example, recommends Cura as the 1 stop shop. I would imagine other print vendors do the same.
smartavionics
commented
5 years ago Lulzbot, for example, recommends Cura as the 1 stop shop. I would imagine other print vendors do the same.
Then why don't they fix the USB printing and contribute something back to Cura instead of just using other people's work for nothing. That's freeloading and is not how open source works best.
Anyway, I've nothing useful to add to this conversation so I'm leaving. I wish you good luck!
SwiftNinja
commented
5 years ago @smartavionics : Regarding Lulzbot - they're having their fair share of ... challenges... at the moment, in what appears largely to do with mismanagement. Externally, it sort of seems like they're about 2 weeks away from having their doors closed forever. So expecting them to do anything about it is highly unlikely, and, unfortunately, Lulzbot didn't seem to have a lot of horsepower on hand in terms of actual devs. I think they had one (marcio) and he seemed to be very good, but there's only so much one guy can do. I personally wish they had been much more on top of their software game, but they weren't, so we go back to the key owners - Ultimachine.
As for fixing the core problem, if I could - I would.
Cheers,
fieldOfView
commented
5 years ago I'm curious if misinterpreting what people say and ranting like this ever work for you. Noone is discounting Linux here. They're discounting Linux users that use the USB Printing feature. To a greater extend, they are discounting USB Printing for all platform.
Do you know how percentages work? Yes, there's an opt out for the statistics, and there are forks of Cura (I don't think Prusa has a Cura fork though; they prefer Slic3r). But unless you think the Linux users that want to use USB printing are very different in their behavior than the other users of Cura, you have to realise that these other users of Cura also have the option to opt out or to use a fork. So the percentage of Cura users that use USB Printing on Linux is not affected much by either of these factors. But even Linux users that use USB Printing are twice as much inclined to opt out than all the other users of Cura (which I doubt), we are still talking about less than 0.2% which logically means other issues should get priority.
Now, a better point to make would have been that there are so few Linux users that use USB Printing in Cura because it is apparently somewhat broken. I'll give you that.
I don't see how OctoPrint furthers your point. OctoPrint is its own host, and there's a plugin that interfaces it with Cura. There are other 3d printers hosts too, like Printrun (pronterface). Like @smartavionics said, Cura is a slicer first and foremost; You can always use a different print host.
All said and done, I'll probably get an argumentative response, which I'll end up ignoring like so many threads on the subject. I'm working on a plugin to replace the USB Printing functionality in Cura with a version that uses the core of Printrun (the same code pronterface uses): https://github.com/fieldOfView/Cura-SerialConnection. But frankly I don't look forward to finishing that plugin and being on the receiving end of rants like this. You're not the first one, and likely won't be the last one.
nallath
commented
5 years ago Also, it's important to remember, that just because you only use it as a slicer, that does not mean that the other 99% of people who use Cura are using it the same way. Lulzbot, for example, recommends Cura as the 1 stop shop. I would imagine other print vendors do the same.
We're not recommending using Cura with USB printing. We're recommending using Cura with network connection or with SD card / USB stick. So if other manufacturers recommend something else, I'd say that the burden of ensuring that it works lies with them.
SwiftNinja
commented
5 years ago @fieldOfView : I'd argue you're looking for an argumentative response, simply by the tone of your response and baiting me with comments like "Do I know how percentages work". If you find you get a lot of argumentative responses that you have to ignore - perhaps you should look at how you're responding. I'm not going to engage further arguments here, because it drives this important issue woefully off topic.
I'm perplexed as to why, being able to print from CURA direct to the printer via USB, is something that the proverbial "we" want to consider, effectively, an unsupported feature. If you or others want to "discount Linux users that use the USB Printing feature", than so be it. But there are products on the market that would not exist today were it not for the ability to feed GCode to your printer in real-time over USB, and I don't see why CURA views this as such a niche requirement.
I'm using the workaround, and I shut my monitor off instead of power save, so from my perspective, I kinda don't really care at this point. I chimed back in on this thread to show support of the others like @silver65 and @VanessaE and others who are reporting similar problems and feeling similar frustrations, in the goal of bettering CURA. I personally found @marcan's investigation and responses to be very helpful. I'm not real sure what value the response of @fieldOfView adds here, but he wants to approach it with what I have experienced the typical open source dev attitude of 'I don't need it, and neither should you' attitude, no problem. If we want to follow that with the additional open source dev attitude of 'well, then, if it's that important to you, you fix it', so be it there, too. But don't expect software to get any better with those attitudes. I would happily fix it myself, if I had the know how, in the same way that I'm sitting here fixing my local copy of marlin - but I currently lack the know-how to contribute to core changes to Qt5 frameworks.
As for me, this will be my last comment on the situation. Fix it, don't fix it. Blame USB printing, don't blame USB printing. Blame me and my "rant" about Linux, or don't. At the end of the day, CURA, like any software, depends on listening to your user base to improve. I can actually quite appreciate the argument 'this isn't what the Ultimaker, the primary funder of CURA, views as important', and that's fine. The biggest argument for this actually comes from @marcan - if his investigation is correct, and this is a Qt5 bug, than it has noting to do with CURA and should have a case logged with the Qt Dev Team. It would be swell if the CURA team found a workaround, but that's band-aiding the problem. Regardless, my point was - it's possible that the assertion that USB printing is not an important feature may be fundamentally flawed.
Edit: Thinking about this more - maybe you guys should remove the USB Print control from CURA completely. If, genuinely, the mission of CURA is to be a slicer, and USB Printing is an unsupported afterthought, it shouldn't be there. It's frustrating for a user to get a 3d printer, sit down, learn it, get excited, start a print, go to sleep, wake up and find his or her print is toast because they used a feature that was in the product, and then when they take the time to report it, they're told 'Oh, don't be silly. You shouldn't be using that feature! No one does that!' . If the feature is there, there is a minimum expectation that it works. If it's the opinion of the primary funders of CURA that the feature is underutilized to warrant service, and considers the feature, effectively, obsolete - than they shouldn't offer the feature. Imagine going to use the brakes on your car, and when your radio turns off - so to does the ability of your brakes to function. You take the car in for service - they say 'oh, sorry sir/madam, people using brakes while listening to the radio only represent 0.08% of our use case, so we don't support it'. Than take the brakes away completely rather than creating the illusion and expectation of braking. (For the record - I don't think the feature should be removed - but if this genuinely is an unsupported feature, it has no business being there)
nallath
commented
5 years ago The feature does work for some people. Just not all of them. This specific bug happens with a very specific subset of users (As much as I hate it, 0.8% of the users uses linux and an even smaller part uses USB printing and of those people not everyone has the issue). Even if it was not working at 0.8% of the users, don't you think that removing the feature all together (so essentially breaking it for the remaining 99.2% of the users) is a bit overkill?
The additude that we have is simply a coping strategy. There are too many people demanding (yes, i chose that word intentionally) fixes from us, usually without providing anything in return. Is a response like "If you want it fixed, you do it" making the software better? Well, probably not. But actually fixing it is also not the best investment of our time (as there are other things we can do that affect more users).
As for the car analogy, it's also a bit skewed, since we're not selling Cura (nor is it a breaking issue as major as breaks no longer working).
risacher
commented
4 years ago As a data point - also happens for me on Ubuntu 20.04 with Gnome and Cura 4.4.1. Minimizing Cura does seem to prevent issue from being triggered on this platform.
Is there a related bug report for the issue in PyQt5?
Ghostkeeper
commented
4 years ago PyQt has no public bug tracker that I know of.
If I have a print going, and my desktop's power manager kicks in to blank the screens, Cura starts stalling out while sending data to the printer, causing the printer to hang and stall and otherwise fail to operate smoothly, until I wake the screens back up.
I do not mean the computer "goes to sleep", nor some effect from a regular screensaver (as I don't run one).
Note that the print doesn't actually stop. It just goes in dribs and drabs until the screens turn back on.
The printer is not connected through a hub, nor to any of the monitors (which have mini-hubs in them).
No appreciable disk activity while the screens are off, and when I wake them up, my CPU graph history shows no unusually high activity, however, it does show tiny little spikes about once every second or two, for the duration of the screens' off time.
I'm guessing Cura is querying something about the video system and falling over when it doesn't get what it wants, making it hang at 100% CPU for juuuust long enough to induce a stall and put a little spike on the CPU graph, repeating every second or two.
Pronterface (with Cura's USB plugin disabled, of course) does not exhibit this problem, so I assume the hardware, drivers, OS, etc. are all working properly.
My bot does not have SD/LCD, so that's out. I do not have any other computers or computing devices to run the printer from, so it's USB from my main PC, or bust.
Application Version
3.3.1
Platform
Debian 9.3, XFCE 4.12 as provided by the standard Debian repositories.
Printer
Prusa i3 clone, running a recent-ish copy of Marlin bugfix-1.1.x.
Steps to Reproduce
Configure your power manager to turn off the screens after say 5 minutes. Start a print that runs for rather longer than that. Wait and watch.
Actual Results
Printing...Printing... [screens turn off] Prin...t.... st...all.... pri...nt.... sta...ll... pr...int.... stal..l... :smiley:
Expected results
The print proceeds without interruptions, whether the screens are on or not, so there. :smiley: