Unable to open any .stl files at all. #16249
Comments
bsaddresss
added
Status: Triage
|
Hey @bsaddresss, Welcome to the UltiMaker Cura Github 🚀 Your issue sounds super frustrating 😖 Could it be that our STL reader plug-in is disabled by accident? Can you let us know if that is your issue? |
MariMakes
added
the
Status: Needs Info
|
Hi, Thank you for your response!
I checked the stl reader and it was enabled. I disabled it, restarted CURA, re-enabled it, restarted CURA, tried to open a small .stl file (a cheps cube) and 4 minutes have gone by and finally about 4.5 minutes and it opened the file in CURA.
Suggestions are welcome!
On Jul 24, 2023, at 4:05 AM, Mariska ***@***.***> wrote:
Hey @bsaddresss <https://github.com/bsaddresss>,
Welcome to the UltiMaker Cura Github 🚀
Thanks for your report 👍
Your issue sounds super frustrating 😖
It reminds me of a similar issue we received earlier this week.
Could it be that our STL reader plug-in is disabled by accident?
If you go to the marketplace, click on the gear, and scroll down until you see STL Reader, you should be able to Enable it again from there.
<https://user-images.githubusercontent.com/40423138/255571025-102d8bf6-46c2-497a-93b2-abce5172cb40.png>
Can you let us know if that is your issue?
If that's not the case, just let us know we'll take another look. 👍
—
Reply to this email directly, view it on GitHub <#16249 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3SJ2ZLPUSDVVKD76BDDEILXRZJFZANCNFSM6AAAAAA2T437IY>.
You are receiving this because you were mentioned.
|
github-actions
bot
removed
the
Status: Needs Info
|
@bsaddresss |
MariMakes
added
Status: Under Investigation
|
I'll bring it up to the team to see what they can do to improve it. Fingers crossed 🤞 |
|
Quick update from our side 👋 This fix will probably help with with the plug-ins being disabled by accident. But they won't help with the workaround that requires you to disable the USB Printing plug-in, that still needs some more research. |
|
The Cura 5.5 Beta has been released 🎉 https://github.com/Ultimaker/Cura/releases/tag/5.5.0-beta.1 We are hoping it resolves some of the issues, but please let us know if that's not the case. |
|
I've had this same problem with every V5 release. To Test, I also just downloaded 5.4.0-beta.1 and this not opening .stl or project files either, is still here! What I have noticed, is that it either takes a long time, or if I launch OR I find that if I launch v4.8 and open the .stl, which appears instantly in 4.8, then, in 5.4.0, I can do file/new and then try to open the .stl... it won't open instantly like in 4.8, but after maybe 30 seconds, then it appears in 5.4.0. So what I'm wondering, is there any possibility that have several versions installed on the same Window 10 box could have them interfering with each other? However, to note, I don't have this problem in any version below 5.x.x. Only in V5.x.x To be sure, right now, I X'd out of 5.4.0 and launched 5.1 and same issue. The .stl doesn't load (or takes minutes to appear). I X out of 5.1, launch 4.8 and it opens the .stl instantly. Clearly, there's something in 5.x.x causing this problem and I sure wouldn't want to be the coder that has to try and locate the offending library or code or plugin or whatever is causing this. LOL Been there, done that.... I should have mentioned, once the .stl (or project) opens, then anything else opens fast and normal. |
Sadly, the beta did not work either. The .stl I tried to open, FINALLY opened after about 4 minutes, so that's faster at least. Now that something has finally loaded, I can now delete the object, open any other .stl I like without issue. It just appears instantly. So it's clear that upon initial launch, there's some library or something missing, that doesn't get loaded right away. But after waiting for xx minutes and the object finally opens, the library or something is now in memory. Thus, everything just works fine from then on, UNTIL next fresh launch. It might be interesting to put break points in the compiler to areas where loading happens and do a before/after list of modules loaded. Then, after the .stl finally appears, again, do the after list and compare what's missing. Once found, that could be added to the initial startup tables of modules to load. Just some thoughts. |
|
This is still unsolved in 5.6.0. I wait 4 minutes fot stl to load. What it's doing? |
|
Yup! I don't know why the devs can't find this. On first run of Cura and first load of a .stl, it appears to be stuck in some kind of loop. Only a loop could cause this long of a delay. I even put my Lab PC to sleep, which some programs have issues with, but Cura plays nicely. So coming out of sleep, with Cura having already been opened before sleep, it just works perfectly. STLs open instantly. Just closing Cura, reopening and loading a .stl triggers the loop. I'm at the point where I just don't care anymore. If I need to do some CAD design, I first load Cura and just load any old .stl and let it loop in the background. By the time I ready to slice what I'm working on, Cura is ready to go. |
|
I've been experiencing the same issue on arch. running "cura --debug" doesn't seem to show anything other than attempting to read file along with attempting serial communication with a printer followed by changing baud rates |
|
I don't have my printer connected to the computer, but perhaps I could do that to see if by there now being serial comms, that perhaps it loads faster. IF that is the case, then this is perhaps where devs might want to look in Cura's code. When Cura itself first loads, it should perhaps check if a printer is connected. If NOT connected, then Cura code should bypass any serial connection attempts. I may test this next week. This weekend isn't good for me. :) |
|
I'm experiencing a long delay to load an STL file on Nobara linux as well. An observation: it seems to load only when USBPrinting.AutoDetectBaudJob.run finishes. Here's an excerpt of the --debug output before opening the stl. Before it's just checking all of the tty ports. These errors also pop up when the file is loaded but I'm not sure how related they are |
|
It's interesting that USBPrinting.AutoDetectBaudJob.run seems to be involved. For one, I wonder if, at least as a test, adding to the code a JUMP to bypass USBPrinting.AutoDetectBaudJob.run and continue, might reveal that this is the problem. If so, then the USBPrinting.AutoDetectBaudJob.run code itself needs to be tightened up. Also, perhaps an option on Cura's Settings to disable that call would resolve it for those of us NOT printing via USB. ???? I still haven't tested by connecting my printer to USB to see if the auto detect just detects it quickly and moves on. It's still interesting that after the long delay and the 1st stl finally opens, that closing that .STL and loading a new one is instantaneous. I wonder if after the first major delay, if |
|
In the flatpak version of the app, I was able to edit the AutoDetectBaudJob.py file and commented out lines 55-76. This resolved the issue and might work as a temporary remediation for those who don't use the USB printing feature. |
|
I fixed this by disabling USB printing altogether (I've never had an USB printer to begin with).
|
|
gtollini YOU ARE PURE GENIUS! But I would never have thought to go into Marketplace and fine "USB Printing." So I disabled it as I NEVER use it nor ever would and after restarting Cura, a new .SLT file loaded instantly! Thank you so much for this. Perhaps now the Devs/coders can fix this issue for those who may use or not use USB printing. Now that you've confirmed this, the fix would be so easy to do. I hope that this gets picked up by the Dev team. Again, A HUGE THANK YOU! |
|
I've made a PR with a fix that works for me. It would be interesting for you guys to test it on your machines and report if it works for you as well 😄. It's here. As it turns out, it's not scanning each of our printers for USB. It's scanning each of our tty ports (in my case, 32) and trying to make a connection. It'll use a CPU core per port (in my case, 4), 15s per port, twice each. In my case, both in theory and in practice, this totaled 4 minutes between clicking "open" and the file actually opening. For some reason unbeknownst to me, this was only enabled on Linux/MacOS. My fix was simply disabling it for everyone, and hopefully a dev with better understanding of the project can add a setting like "Auto Detect USB Printers" or something that we can toggle on or off. |
|
Just for clarity and now I see that I wasn't clear before. When I said that it seems like it's scanning, I may have said USB ports, but I should have said COMM ports. That's what you have confirmed. I agree, I hope that the Devs do 2 things, actually. One, put an option in settings to configure Enable/Disable like you suggested above. But upon install of an upgrade apply the user's settings. On a new install, DISABLE this feature and perhaps have a pop up asking about it. Secondly, rather than the code doing a full scan of tty/COMM ports to try and find printers, the code should (in Windows for example) read the comm list to see if a printer is there. I'm not saying that right as I don't code in that area. What I mean is, that when someone connects a printer to USB, the drivers are installed (again, I use Windows for my examples as I don't do MAC or Linux) so the info is already there. This should be pulled and not an unnecessary long scanning of all ports. It really is redundant at the very least. In a case where someone does have a printer or more connected to USB, once Cura finds it/them I hope that it retains the data so that on next launch, it just launches without trying to find them all again. Either way, your find and work around is just perfect. I really appreciate what you've done here. Thanks again. |
|
There's something odd there. In theory, my fix wouldn't have a difference on Windows users. All I did was switch a It could also be an implementation failure on Also, if you don't mind sharing this information, which version of Windows are you running? |
|
This is on Windows 10 Pro, latest updates. |
|
I can confirm that this is still an issue with 5.7 on pop os, disabling the USB printing fixed it |
|
I haven't had time (or motivation, to be honest) to test this, but if one does have the printer connected to USB and powered on so the operating system "sees" it, does Cura, if USB printed left enabled, still do the xx minutes thing? Just curious. I joke about not having time to test. It's more that in order to connect the printer, I have to dig out the computer to connect the printer to a USB port at the back. |
|
I don't have an USB printer to test this out, but I'd guess it would still take a long time to open files. |
|
Ok. If I can find some time tomorrow and remember, I'll connect the printer and test. I'll have to also remember to enable USB Printing. If I get this done, I'll report back the results here. What I'm hoping, is that the coders had the sense to look first for an active port and if something found, then test for baud rate. |
Cura Version
5.4.0
Operating System
Mac Catalina
Printer
Cr-10S
Reproduction steps
Cura 5.4.0 beta and fresh installed 5.4.0 will not open any .stl files. I've tried at least 15 of them, and nothing ever appears on the virtual build-late. I've tried uninstalls, new installs, restarts, new .stl's from tinkercad, opening .stl's from inside cura, changing default app to Cura... all of the .stl's will still open on prusaslicer.
Actual results
No Stl will appear on the virtual print bed.
Expected results
stl should appear on print bed
Add your .zip and screenshots here ⬇️
na
The text was updated successfully, but these errors were encountered: