Description of problem: Printer stutters, quality stops poor. A couple of times a second head stops as if commands are not delivered promptly enough, then resumes. Every time it stops, there's a bit of an anomaly in print. So, cylindrical details get edges running along all the approximation facets. Version-Release number of selected component (if applicable): cura-lulzbot-3.6.21-3.fc32.noarch CuraEngine-lulzbot-3.6.21-3.fc32.x86_64 How reproducible: Unknown Steps to Reproduce: 1. Print something round 2. 3. Actual results: Printer stutters, poor quality Expected results: No stuttering, printing as in Fedora 31 Additional info: See video. This may be upstream bug, but thus far I'm unable to figure out what the upstream for Cura is, if any.
Created attachment 1687007 [details] video of the stuttering
Created attachment 1687008 [details] snapshot of top(1) The overall load is not too much, but Cura consumes a lot CPU more in F32. This may be related to graphics, actually, but it still burns it even when minimized.
There is an update here, could you test with that please? https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2789530c4
I can test with the plain Cura, yes. Is the Cura-lulzbot going to be discontinued going forward?
Actually, none of Lulzbot printers appear to be in the list of supported printers of Ulti-something Cura, as referenced by comment #3. Is there something I can do about it? Maybe a plugin or something?
Oh sorry, this is my mistake, I have not discovered this bugzilla is for Cura Lulzbot. Cura Lulzbot is not going to be discontinued. But eventually, it gets fixed form the real Cura. However, I am not sure what's the best way to test plain Cura with Lulzbot printers. Tom?
It is not clear if the new owner of Lulzbot has any plans to update/bugfix their fork of Cura. All of my contacts there were laid off and not rehired when their offices moved to North Dakota. I have not tried using the Ultimaker Cura on a Lulzbot, one of the major changes in the Lulzbot fork was to add support for material softening temps, so that the starting gcode could do the clean/calibrate routine without making a mess, and that functionality does not exist in Cura (last time I looked, which was a few months ago). Prusa Slicer claims to have some support for the Lulzbot TAZ (no version given), but I have not tested it. ***** Pete, does the behavior change if you're on Wayland vs Xorg?
(In reply to Tom "spot" Callaway from comment #7) > I have not tried using the Ultimaker Cura on a Lulzbot, one of the major > changes in the Lulzbot fork was to add support for material softening temps, > so that the starting gcode could do the clean/calibrate routine without > making a mess, and that functionality does not exist in Cura (...). Well, I was looking for a fun project. > Pete, does the behavior change if you're on Wayland vs Xorg? It runs in X11 mode. If I run "cura-lulzbot -platform wayland", it's not displaying properly.
Just a data point: everything works perfecty when displaying remotely. Logged in with ssh -Y and ran cura-lulzbot. It burns a lot of CPU at fist, but then settles down as it prints top - 18:42:12 up 16 days, 7:14, 4 users, load average: 5.61, 4.55, 2.49 Tasks: 212 total, 1 running, 211 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.5 us, 9.5 sy, 0.0 ni, 70.4 id, 0.0 wa, 1.2 hi, 3.3 si, 0.0 st MiB Mem : 7868.5 total, 4783.9 free, 873.6 used, 2211.0 buff/cache MiB Swap: 8028.0 total, 8028.0 free, 0.0 used. 6561.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32993 zaitcev 20 0 3036588 360216 125344 S 90.0 4.5 13:29.43 cura-lu+ 31965 zaitcev 20 0 13960 5572 4044 S 9.6 0.1 1:37.43 sshd 10 root 20 0 0 0 0 I 0.3 0.0 0:22.32 rcu_sch+ 31824 root 20 0 253052 30492 8968 S 0.3 0.4 0:32.84 sssd_kcm 33207 zaitcev 20 0 219224 4000 3360 R 0.3 0.0 0:00.09 top top - 18:54:38 up 16 days, 7:27, 4 users, load average: 0.21, 1.07, 1.81 Tasks: 213 total, 1 running, 212 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.4 us, 11.2 sy, 0.0 ni, 66.3 id, 0.0 wa, 1.4 hi, 3.7 si, 0.0 st MiB Mem : 7868.5 total, 4785.1 free, 871.8 used, 2211.6 buff/cache MiB Swap: 8028.0 total, 8028.0 free, 0.0 used. 6563.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32993 zaitcev 20 0 3038136 362480 125344 S 104.3 4.5 26:22.68 cura-lu+ 31965 zaitcev 20 0 13960 5572 4044 S 9.3 0.1 2:58.17 sshd 10 root 20 0 0 0 0 I 0.3 0.0 0:23.00 rcu_sch+ 31824 root 20 0 253052 30492 8968 S 0.3 0.4 0:34.73 sssd_kcm 33319 zaitcev 20 0 219224 3904 3264 R 0.3 0.0 0:00.05 top So at least we have some kind of a workaround.
I am having problems with Cura and the AppImages for Cura under F32. It seems to have started with a kernel update about 5 kernels ago. Cura or Cura appimages begin to load, but instead of displaying the cura screen, they display the background image in the cura window. Then everything begins to run slow and after repeated clicks of the X on the windows, cura will close. Some of my newer computers have begun running it again with newer kernels (I think this began when kernel 5.7 was loaded), but my older computers still will not run Cura even after reinstalling F32. These computers were running the appimages just fine for years. (Same versions and newer versions, I have copies of 2.7 to 4.61 and they all do the same thing, as does the installed cura from the repository.)
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.