CURA delaying load of files due to almost endless check of /dev/tty*

Screak42 commented 6 months ago

Cura Version

5.6.0

Operating System

Pop!_OS 22.04 LTS

Printer

Ender 3 v2 Neo

Reproduction steps

1.) enabled usb & network modules (for me this is default enabled, but is done here to verify behaviour) 2.) quit cura 3.) start cura (double check that UM3 Network printing & USB printing is enabled) 4.) load simple amf file (known working and fast) 2024.04.02 08.35.40 5.) log shows almost endless check of Checking /dev/tty* many with a timout of 15. (check for lines like: Checking /dev/ttyS3 if baud rate 115200 works) (logfile attached)

Actual results

This results in a very long wait time until file is loaded (for me it seems the same on a fast gaming machine, or a simple intel NUC) in my case up to 5 or more minutes.

Expected results

Files should load fast, and this can be achieved by disabling the "networking" function in CURA.

a.) Click on marketplace > gearbox > scroll to UM3 Network printing & USB printing b.) disable UM3 Network printing & USB printing c.) quit cura d.) 2024.04.02 08.45 restart cura e.) no "tty log spam" present, .amf file loads right away.

FURTHER INFO: since a few days (no cura updates) my slicer is "stuck" in an almost endless loop of checking the tty. I'm unable to fingerpoint when this started, I update my systems every other day or so. I can verify this behavior in 3 computers. My main "designing machine" is not fast, but it gets the job done - never had this problem until a few days now.

My guess is that some OS update messed with how the tty, network and connectivity can be checked.

Once cura is done checking the tty (or has been disabled as described, no more "log spam", files process as normal)

system information: Pop!_OS 22.04 LTS Linux shoebox 6.8.0-76060800daily20240311-generic #202403110203~1711393930~22.04~331756a SMP PREEMPT_DYNAMIC Mon M x86_64 x86_64 x86_64 GNU/Linux Memory 16,0 GiB CPU Intel® Core™ i3-6100U CPU @ 2.30GHz × 4 GFX Mesa Intel® HD Graphics 520 (SKL GT2)

CURA installed via flatpak (UltiMaker com.ultimaker.cura 5.6.0 stable user)

Add your .zip and screenshots here ⬇️

Check logfile (2024.04.02_cura.log.zip) before 2024.04.02 08.45 to see log-spam at 2024.04.02 08.45 restart cura with networking disabled. file loads right away.

2024.04.02_cura.log.zip cura_fails

rburema commented 6 months ago

CURA installed via flatpak (UltiMaker com.ultimaker.cura 5.6.0 stable user)

While we'll take this along, we only really support the downloaded version, as we cannot guarantee what different package managers did to the application. While I see that the flatpack one is described as 'by UltiMaker', we didn't provide that version.

Screak42 commented 6 months ago

I actually did not know! Thanks! I'll have a look if I can see the same behavior in the downloaded version and update the issue here - or would it be better to close this and open a new one if I find the same behavior in the downloaded version? In all fairness, it could be related to some odd flatpak sandbox restriction (I have given it all permissions...but...)

rburema commented 6 months ago

@Screak42 I think it's fine if we continue this thread if you find it in the downloaded version. After all, it's basically just about narrowing down if we can actually help or not, or if you should ping other maintainers.

Screak42 commented 6 months ago

Hey! cool, I finally had some time to check this. The behavior is the same for me in the .Appimage linux download directly from https://ultimaker.com/software/ultimaker-cura/.

So it does not seem to be related to the Flatpak. Same behavior, disabling "networking" via marketplace > gearbox > scroll to UM3 Network printing & USB printing - files open right away. See attached logs Appimage - 2024.04.11 - 15.22.46.cura.log.zip.

logs Appimage - 2024.04.11 - 15.22.46.cura.log.zip

rburema commented 6 months ago

Hi, thanks for checking and getting back to us!

Unfortunately, in the meantime, we've also discussed this issue amongst ourselves, and we've chosen to defer it until we get more reports -- mostly because it has a clear workaround and is likely something related to the OS (like you already noted). -- The Cura-team is not too large at the moment, and we really have to choose what to focus on these days more so than ever.

Additionally, I did take a quick look at the code just now to see if it was maybe a quick-fix, and I found this snippet (in the chain of calls that eventually gets to the baud-detection code):

                    # We only limit listing usb on windows is a fix for connecting tty/cu printers on MacOS and Linux
                    port_list = self.getSerialPortList(only_list_usb=Platform.isWindows())

This means that fixing this would likely mean other people can't use their printer anymore. Properly fixing this then means overhauling the whole USB printing system, which is extremely unlikely to happen.

On the positive side, if you ever want to go through the whole rigmarole of rolling your own build (or running from source), you now know which variable to set to true.

fzechert commented 6 months ago

I just found this thread while searching for this exact problem. I have observed the same behavior on my Linux System.

Disabling the USB printing helped. Thank you for the workaround. Might be worth to mention this somewhere in the documentation if more people are searching for a solution to this problem.

ldoktor commented 4 months ago

Thank you, the marketplace > gearbox (icon) > scroll to UM3 Network printing & USB printing and disable both instructions are very helpful (Fedora 40, minutes vs. instant load)

mcli commented 4 months ago

I experienced the same problem (delayed model loading) on Fedora 40 running the AppImage downloaded from the official download link. Once I disabled Network and USB printing, loading files was immediate with no delay.

slyholborn commented 4 months ago

You saved my life!! Fedora 40 also

Pi-irate commented 3 months ago

Same, Also Fedora 40.

cobalt32 commented 2 months ago

You can use USBPrintingNG from the marketplace to bypass this issue. It allows you to manually set the baudrate and tty device using environment variables. Be sure to disable the old USB Printing package as stated by others above.

Below is what I added to my ~/.xinitrc so the variables are set at startup. The values may be different for you depending on your printer and system configuration.

# Cura settings
export CURA_BAUDRATE=115200
export CURA_COMPORTS=/dev/ttyUSB0

99991 commented 1 month ago

marketplace > gearbox (icon) > scroll to UM3 Network printing & USB printing and disable both

I could not find find "UM3 Network Printing" at first because the UI is a bit inconsistent.

You really have to click on the Gear Icon. It does not show up in the "Plugins" tab, even if you use Search.
The "Gear Icon" Tab does not have a search function like the "Plugins" and "Materials" tab.
I scrolled all the way to the bottom and then went up and did not find it between "Ultimaker TPU 95A" and "Vertex Delta ABS", because this menu actually shows two lists. I was looking at the second list, which only contains materials, but the correct list with plugins is the first list at the top.

Once I disabled both UM3 Network printing and USB printing, models load quickly again.

123

opensourcefool commented 3 weeks ago

Grateful for this advice, disabling these two extensions solved a problem where even very small, simple models would take over a minute to load. Cheers!

lvturner commented 2 weeks ago

Fedora 41 here -- disabled both USB printing and UM3 Networking, fixed my slow model loading issue

Tweekism commented 1 week ago

Disable "USB Printing" extension worked, the network printing extension makes no difference for me (Fedora 40).

Thank you to @Screak42 for the excellent troubleshooting.

Ultimaker / Cura