Open .3mf-file, crash after slicing #7845
Comments
|
This sounds like #7681. Can you please retest in PrusaSlicer 2.4.1-beta1. Thanks. |
|
Thank you for your prompt reply. |
|
Thanks. I reproduced the problem (in fact, I got a hard crash on Linux in 2.4.1-beta1). We will look into it. |
|
@Speedy-McCat If you can still reproduce it, could you please ZIP your configuration folder (top menu -> Help -> Show Configuration Folder) and send it to lukas.matena * prusa3d (cz)? Can you also please tell full path where the 3MF is stored and where you are uploading the GCode? Does it contain some special (presumably German) characters such as ß or umlauts? Thanks. |
|
|
I was able to download the PrusaSlicer-2.4.1-beta1+linux-x64-GTK3-202202010927.AppImage and slice a complicated model. But I have to start the slice and not touch anything until its done slicing. I can export the gecode but I if I start moving the slider on the z index it will lock up and crash the entire OS. It then renders like *see image in link here: https://freeimage.host/i/0hyUnS. I have an AMD ATI Radeon RX 5600 OEM/5600 XT / 5700/5700 XT and an NVIDIA GeForce RTX 2070 SUPER but the AMD is my display and I have the AMD-PRO drivers built on top of the mesa-git drivers. Its fine if I just slice it, not move any mouse or tinker, then export. But I cannot slide the axis's or it crashes. *I want to note that I cannot build the https://aur.archlinux.org/packages/prusa-slicer-git#comment-851252 package either. *I want to note that the reason this package was not building was the build uses "Ninja" build system and the settings were so it consumes the hell out of resources. I was able to get it to not use up all the RAM and cpu but it breaks on something else. |
|
@joeybronzoni |
"Invalid type" may mean that you did not provide any extension to your gcode. This was also the reason why PrusaSlicer 2.4.0 final release crashed, while the 2.4.1-beta1 does not crash. There seems to be something wrong with file names / paths handling on Windows build of PrusaSlicer, see #7681. I suppose if you used a non-latin7 character (German, Czech, Russian...) then in some specific scenario this character gets mangled and this then caused the "Send to OctoPrint" dialog to fail. However we were not able to reproduce the issue, thus we only fixed the crash, not the mangling of file names / paths. The project name is displayed in application title and as reported in |
What do you mean? No user space application shall be able to lock up and crash the entire OS. If that happens, then there is something wrong with your operating system or hardware. |
|
@enricoturri1966 Yes sure. Here it is(I don't have th 3mf file but here's the folder and the .stls -I could save and get the 3mf later after work): And @bubnikv What I mean is the system crashes just as I put it. I slice the model and the slice renders stringy as in the picture attached in my previous comment then the 4 monitors turn to black and then sometimes a couple monitors will turn back on and freeze. And you are wrong -there is nothing wrong with this hardware(> a year old and top quality all brand new) and I've run a mountain of tests. This is the ONLY thing that does this to my system and I do a lot on this system like 3drendering, blender, gaming, streaming, ffmpeg processing, etc. Its not the system. This only happens when rendering complex models and it only started recently -quite recently. Its the prusa-slicer. |
|
@joeybronzoni |
Yep -and for the record again I'll mention that I'm on Arch Linux with the AMDPro drivers built on top of the mesa-git drivers(for the Radeon 5700 XT) and Nvidia driver(for Geforce RTX 2070 Super) . I'll create the project and attach the .3mf files lateer after I get some work done.Then I could close some windows and run it. |
Yea @enricoturri1966 ,maybe try importing the .stl files and bumping the infill to 100% -I cannot get the .3mf files. Every time I slice something like the models I've attached by importing the .stl files and slicing at above 70% infill it crashes. Just crashed now. Again I'll mention that I am running Arch Linux with the AMDPro dirvers built on top of the mesa-git drivers for the AMD Radeon 5700 XT GPU and the latest Nvidia drivers for my Nvidia Geforce 2070 RTX Super GPU. I"ve gotten it to slice at 70% but that's 1)useless and 2) I have to slice it, not touch the mouse or anything come back minutes later and then I cannot move the index slider I simply can ONLY export the gcode. But that's not useful. |
|
Ah. And Yea I downloaded the PrusaSlicer-2.4.1-beta1+linux-x64-GTK3-202202010927.AppImage and I have 100% infill on that model attached above and its seems to be working without issue. It still renders the model stringy just like the attached photo here: https://freeimage.host/i/slice-bad.0hyUnS but it re-renders clean after a few moments. This works for me. Still have to do some more testing later after. |
|
@lukasmatena I ran the 2.4.1-beta1 version from the AppImage there in releases and it worked fine. But I wanted to mention that I was finally able to get the prusa-slicer-git package built on my system and I am currently running that version 2.5.0-alpha0 and it feels fast and smooth. <-- I lied. |
|
I want to note that I've installed the arch linux prusa-slcier-git package and ran that for a day. Its sliced the model that I've linked to earlier in this thread. But then I tried slicing some other models and it started crashing the same as before. That prusa-slicer-git package is on version: prusa-slicer-git-2.5.0.alpha0. So I still get no issues with the: PrusaSlicer-2.4.1-beta1+linux-x64-GTK3-202202010927.AppImage but with the 2.5.0.Alpha I'm back to getting crashes. **I am testing some things here. I just updated my system -rebooted, ran prusa-slicer-git and same crash. I updated and rebuilt my mesa-git drivers and my amd-pro drivers and rebooted. Now the slicer seems to be working. Again I want to mention about the stringy render when first slicing and then moments later it fixes itself upon finishing the slice. See here: https://freeimage.host/i/0hyUnS I'll continue to test this but wanted to get the comment in before I crash. If I crash. There were some libmesa, lib-vulkan-radeon and other updates found when running my system upgrade which is why I decided to rebuild the other packages related(mesa-git amd-pro). I won't pretend to know what's going on under the hood of the prusa-slicer but so far rebuilding those packages and running the slicer seems to work. I'm happy if I can just get the model sliced and exported. I just want to dump whatever info I can here. To be continued. |
Just FYI. 2.5.0-alpha0 tag is on master branch, which is currently under development, it is expected to be HIGHLY unstable, it may produce completely broken G-Codes, break configuration, produce 3MFs not compatible with any other version, etc. It is also not build the way we recommend and test, much older wxWidgets 3.0.5 are used instead of our patched 3.1.4. So I'm not surprised you have issues. @Salamandar I believe you are the maintainer of that package, right? I am quite curious about the arch packaging philosophy and I was wondering if you may shed some light on it for me. I already understood that all Linux enthusiasts hate static linking and enforce dynamic linking of system libraries, even in cases when the developers of the application claim that it is not recommended, tested, that the system libraries are old, lacking important patches etc. I never understood the reason, but anyway. The arch packages take it even further and seemingly package anything, despite the fact that it is under development and not guaranteed by the authors to work at all. Now the question: Are the "normal" users who install that package aware of that? We invest quite a lot of time and effort into testing to make sure that the versions that we release are stable. On the other hand, we absolutely do not guarantee that a random commit on master branch will work at all, not to mention that it is linked against different set of deps versions, which is not only untested, but known to cause issues. If your users have these issues, do they know it could have been caused by the way it is packed, or will they storm the social networks claiming that "PS is crap, the official package crashes for me"? I don't care if anyone packages anything (although IMHO it makes no sense), but it would be great if everyone knew that it is something the authors of the software did not plan to release and that they don't recommend the way it was built nor test it. Thanks for the answer. |
|
@lukasmatena For the record I completely get that the prusa-git package(or ANY package labeled "<package_name>-git") on Arch Linux is Alpha and is best used by people willing to deal with any unstable behavior. Maybe I shouldn't have added that information -I did not want to confuse the issue here so that's on me. |
|
Ok I've been running a marathon of tests today between the slicer and the actual printers and mmu2s. I was able to get models sliced but if it was a complex slice with 100% infill I would get that crash more often than not but not always. So I decided to swap out the Nvidia card I have with a Radeon 6900xt. So now I have the two Radeon cards with the pro drivers and mesa-git bleeding edge version installed. So far the slicer is noticeably smooth. No crashes. No stringy renders. Its all good. So I guess the combination of thee two cards and their drivers might cause some of these issues I've faced. I'll edit this comment should this change but I am confident this is smooth not. |
I suppose you're not familiar with the concept of the AUR repository. This is not an official package repository and is not supposed to be reliable nor stable. This is all built from source on the user's machine from the official sources (tarballs or git repositories). Anyone (yes, really anyone) can add a package in this repository, this is as open as Github. This is not officially maintained by the Arch devs but by "external" contributors (such as me: i'm not official Arch staff at all). Also, the package you linked (yes, i'm the maintainer) is named prusa-slicer-git. This special The packages that don't have this kind of suffix are supposed to be build on releases of the upstream software. They are not official either, but they are supposed to be stable. For example there is a prusa-slicer-gtk2 package on the AUR. The official Archlinux package repository contains a "fixed release" of PrusaSlicer, found here: https://archlinux.org/packages/community/x86_64/prusa-slicer/ Sometimes I'm reporting upstream issues on your issue tracker when the build break (because IMHO master should always be working, and branches should always be merged when functional). Often, the issue is already reported by someone else. I have 2 patches on my side (well, only one now, because you fixed #7809) tl;dr: Don't consider this package as official, because it is not. Users that install it should be aware it's not a stable one (and it's more often broken than working). EDIT : Also the package version is based on the latest tag on your repository, so for now it's |
|
@Salamandar Thanks for the detailed explanation. Now when I read my previous post, I realize it might sound a bit harsh and offensive, which was not the intent. All I wanted to make clear is that PrusaSlicer does not do "rolling releases" and that master branch is often in a sorry state as a result. If that is made clear and there is no way of confusing it with the final versions, all is fine. And yes, I was not completely aware of the difference between the classic packages and the way it is advertised to the end-user. Thanks again for the clarification.
I know that you report things now and then and we are grateful for that. Yes, master should be always at least buildable, but sometimes platform-dependent issues or conflicts between developers break it. Especially when building against system libraries, where there is an endless number of combinations of various library versions on various distros. That's why we only make our static builds, so we at least know what to test and what issues and bugs we need to workaround. We are no longer fixing bugs that do not appear in our static build. Regarding the actual issue that @joeybronzoni is having. If it is fine in 2.4.0 and broken in current master, it may be caused by an OpenGL code overhaul that is currently in progress. There are spurious issues like that reported even in older versions, we will see how many of them will disappear after the upgrade. I would suggest to report it again later (in a separate issue) if it does not go away. Regarding the original issue from @Speedy-McCat - I believe that it is be fixed for good in 2.4.1-rc (will be released shortly). |
|
The original issue was fixed with b4c11df |
|
@bubnikv I see what you are saying but I never open files via the file manager by drag-n-drop or double clicking. I use Ctrl-I then with my arrow buttons move to the file I want and then click the open button. I guess sometimes I hit enter but I never double click or drag-nm-drop. I mentioned above that the issue has litterally disappeared once I removed my Nvidia card and replaced it with an AMD Radeon 6900xt. Makes me believe that the drivers were fighting with each other and there was something going on there. @lukasmatena Thanks. So far no issues with AMD cards. It was the mix that was causing this and that makes sense that it had to do with OpenGL. |
No prob :)
Well to be fair it's not really often !
Yeah, I know what you mean…
Please do, at least when you have a pull request fixing it for you ;) |
|
@joeybronzoni Can you please confirm that the issue is fixed in PrusaSlicer 2.5.0-alpha2? Thanks. |
|
No response, original issue is fixed. Closing. |
Version
Version: 2.4.0+win64
Build: PrusaSlicer-2.4.0+win64-202112211614
Operating system type + version
Edition: Windows 10 Pro
Version: 20H2
3D printer brand / version + firmware version (if known)
Anicubic Vyper
Firmware: V2.4.5p2_1a
Anycubic_Vyper_Chainlink_Cover_6x.zip
Behavior
I opened an STL file, made some changes to the filament and printer settings, and copied the object 5 times to print 6 objects. Slicing done and the file transferred to the OctoPi and printed out. So far everything OK. I then saved the project as *.3mf. If I call up this project now and all the data is transferred correctly, it's still good so far. Now when I start slicing I get the attached error messages and the PrusSlicer closes.
Sorry for my English, I use google translator.
Project File (.3MF) where problem occurs
3mf-File, Anycubic_Vyper_Chainlink_Cover_6x.zip Uploaded
The text was updated successfully, but these errors were encountered: