CuraEngine - Zero print time, zero filament used, Stopping process because there are no non-empty layers.
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- cli, computer-graphics
Research direction
Start by reproducing the reported CuraEngine CLI behavior on Linux/Raspbian with the affected STL file, then compare the same file's result on Windows. Investigate why the CLI reports no non-empty layers despite the model slicing successfully elsewhere. Done means the affected STL produces non-empty G-code with nonzero print time and filament usage.
Written by the indexing model from the issue text.
Description
Hey guys, i have problem with CuraEngine CLI. Im using it for quite a while now and im still unable to find out what is the reason behind my problem.
Problem is that some STL files (maybe like 1 in 50) im unable to get proper gcode, it always output empty gcode with zero time printing and used filament
It look like this
.
.
.
Stopping process because there are no non-empty layers.
.
.
.
End of gcode header.
Print time (s): 32
Print time (hr|min|s): 0h 0m 0s
Filament (mm^3): 0
Im pretty sure that STL is not damaged because i can properly open the exact same STL file it in my Cura slicer on Windows and it slice just perfect as it is in Fusion 360 with all polygons etc, so no problem with STL fle
Application Version
CuraEngine 5.8
Platform
Linux - Terminal version of Raspbian
PyQt
5.5.12
Display Driver
Im using only CuraEngine in CLI
Steps to Reproduce
I can send you a STL file if necessary
Actual Results
Expected results
I expect proper gcode
Additional Information
Output gcode:
https://prnt.sc/se3nqG3eljRr
Same STL fle in CuraEngine on Windows:
https://prnt.sc/WkF3ko378FNA
- Dominant language
- C++
- Stars
- 1.9k
- Forks
- 933
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 10
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Ultimaker/CuraEngine
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Ultimaker/CuraEngine#2329 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Ultimaker/CuraEngine#2268 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
Ultimaker/CuraEngine#2265 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Ultimaker/CuraEngine#2262 ·
-
Status: Needs Info
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Ultimaker/CuraEngine#2245 · 3 comments ·
All issues in Ultimaker/CuraEngine
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LadybirdBrowser/ladybird#12123 ·