prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.5k stars 1.9k forks source link

Bed size limits maxed out at 1200 mm #6072

Open staffert opened 3 years ago

staffert commented 3 years ago

Version

Version 2.3.0+win64

Operating system type + version

Windows 10 build 1909

3D printer brand / version + firmware version (if known)

Custom 3D printer being built....bed size to be 1000x2000

Behavior

When creating a profile for our printer, we bump into the issue of PrusaSlicer not allowing more than 1200mm of bed size in any direction. Can this be corrected/added as a new feature?

Project File (.3MF) where problem occurs

n/a

foreachthing commented 3 years ago

Quick search (for "1200") gave me this: https://github.com/prusa3d/PrusaSlicer/blob/b7ae342e8e43bb7c35619518b2d6e223509b44a8/src/slic3r/GUI/BedShapeDialog.cpp#L99. And then: https://github.com/prusa3d/PrusaSlicer/blob/b7ae342e8e43bb7c35619518b2d6e223509b44a8/src/slic3r/GUI/BedShapeDialog.cpp#L107

Maybe you"ll need to adjust some more values in this function. But this could get you started.

bubnikv commented 3 years ago

There is a hard limit due to the use of 32bit fixed point arithmetic with the resolution of 1e-6mm. As of now this is a hard limit, but we may consider decreasing the scaling factor somehow, maybe 2x, 4x, 5x or 10x. The scaling factor is somehow arbitrary and decreasing the resolution would likely not break anything.

st 17. 2. 2021 v 22:50 odesílatel Gilbert notifications@github.com napsal:

Quick search (for "1200") gave me this: https://github.com/prusa3d/PrusaSlicer/blob/b7ae342e8e43bb7c35619518b2d6e223509b44a8/src/slic3r/GUI/BedShapeDialog.cpp#L99 . Maybe you"ll need to adjust some more values in this function. But this could get you started.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/6072#issuecomment-780877666, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSIZGUCHECE2MBNVL2GTS7Q23TANCNFSM4XZA2FKA .

staffert commented 3 years ago

I appreciate the insight, but I am not at this point capable of doing any real coding to correct this. (maybe soon?) My only suggestion is that given the size of the machine, a scaling factor would probably be a good idea as we do not expect to be dealing with high precision detail models as the nozzles are in the 1-10 millimeter ranges by design. Large quick parts, with reasonable accuracy.

fiveangle commented 3 years ago

@bubnikv, as you point out, with increasing bed size comes a natural expectation of decreased need for resolution. I would imagine adjusting the resolution scaling factor by (int DESIRED_BED_SIZE/int 1.2M) would be fine for everyone, as long as current resolution at build platform size <1.2m is unchanged.

[I'd imagine future iterations of SL1 would not want resolution decreased even from current levels, for oversampling/nyquist sake of bumping up against possible outlier moire effects as physical printer resolution naturally increases in the future]

fiveangle commented 3 years ago

Quick search (for "1200") gave me this:

https://github.com/prusa3d/PrusaSlicer/blob/b7ae342e8e43bb7c35619518b2d6e223509b44a8/src/slic3r/GUI/BedShapeDialog.cpp#L99

From what @bubnikv mentioned, it really is a limitation of the storage allocated for the scaling factor vector:

https://github.com/prusa3d/PrusaSlicer/blob/05a6cfeaeaca3365f455445a9b986673752309ab/src/libslic3r/Geometry.hpp#L443

but I haven't checked the intermediary math to see if arbitrarily setting a larger BedShape auto-scales to within the allocated storage domain of m_scaling_factor. Could try, but wouldn't be surprised if there were exceptions lost in translation 🤷

vmario89 commented 3 years ago

i am looking forward to see PrusaSlicer accepting larger values again. I use PrusaSlicer for our HangPrinter whichs deails with ~2500 mm of max height.

i agree to loose some model detail because we use a 1.8mm nozzle to have more output than usual desktop size printers

damaged1285 commented 1 year ago

Thank You for this information. I would also like the ability to max out the the slicer print volume to 1500 cubed. Please give it some consideration. The Prusa Slicer is superior to most and I would like to use it for both my Prusa MK3S and my custom "abomination" :)

highfreq commented 1 year ago

Any chance to have the 1200mm limit removed anytime soon?

Thanks

atas80 commented 11 months ago

I managed to replace the data in the printer settings in a text editor

https://disk.yandex.ru/i/7OtqvhA9bzemHw

Strings from GCode: ;TYPE:External perimeter G1 F3600 G1 X1349.4 Y275.6 E1046.33488 G1 X1349.4 Y474.4 E1061.52526

viz-n commented 11 months ago

Making a custom printer 10000x10000 Please update the max settings

bubnikv commented 11 months ago

Making a custom printer 10000x10000 Please update the max settings

best solution for you is to parametrize everything in slicer in centimeters.

eneene commented 10 months ago

500x500x1500 here! Just posting to show the demand! Some loss in resolution would be perfectly acceptable too!

foreachthing commented 10 months ago

(Silly) Question: Since I like to do certain things in post, would it be possible to scale everything up? Example: You have a (10 Meter )^3 printer. You set that up to be (1000 mm)^3 and scale your gcode 10 times. Your nozzle diameter, in PS, would have be a 1/10 th of the real nozzle, of course. Same goes for layer height, speed, volumetric flow, etc. Does anybody think that this could actually work????

eneene commented 10 months ago

the coordinates would probably be fine. volumetric limits, speeds and feeds may be more complicated, i think... not sure.

thijstriemstra commented 5 months ago

Sad to see this has been open for nearly 3 years. I build a 1600 x 1200 printer and now this.. 😨 Looks like SuperSlicer fixed this bug so I'll give that a try. OrcaSlicer also supports it.

viz-n commented 5 months ago

Centimeters is not an option. The prints are used to create moulds used to create dies for metal casting and need mm level precision.

SoulWager commented 1 week ago

There is a hard limit due to the use of 32bit fixed point arithmetic with the resolution of 1e-6mm. As of now this is a hard limit, but we may consider decreasing the scaling factor somehow, maybe 2x, 4x, 5x or 10x. The scaling factor is somehow arbitrary and decreasing the resolution would likely not break anything.

Why is the precision set this fine? The accuracy of the process is only around 0.1mm, so if we add another two orders of magnitude of precision, we can calculate to 0.001mm precision and still scale the build volume to a couple kilometers while staying within the limits of a signed 32 bit number.

Speaking of what fits in 32 bit numbers, if the least significant bit is 1e-6mm, why is the limit 1200mm instead of 2147 or 4294mm? Where does it actually break? Does it break in different places for xy vs z?

SoulWager commented 1 week ago

I increased the limits to see what happens. I was able to get a 2 meter cube to slice, but only if I control the settings such that it doesn't try to draw a straight path crossing the long diagonal. Performance issues aside I think increasing the limit to 1500x1500x2147 is probably okay. 1600x1200 should be okay too as the longest diagonal is still only 2 meters.

There were 3 places to change things: src/libslic3r/PrintConfig.cpp
src/slic3r/GUI/BedShapeDialog.cpp src/slic3r/GUI/ConfigWizard.cpp

Naturally this was just a couple hours of testing, so assess for your own needs. Though it is enough that I'm willing to go ahead with building my 600x600x1900 w/ a toolchanger. Do any slicers officially support both the bigger build volume and multiple extruders?

thijstriemstra commented 1 week ago

There were 3 places to change things:

Could you create a PR for these changes? Maybe Prusa's interested in implementing it..

SoulWager commented 1 week ago

I'm not entirely sure what limit to suggest for such a PR. Should it be the largest that can slice with any settings, or one smaller than anything that fails? Should it just be a square bed, or dynamically check if a non-square bed can work?

I don't really expect everything to work even at 1200^3. Some infill types run out of memory way before that.

It's also a bit difficult for me to properly test, as I haven't built the printer yet.

My suggestion would be to set the hard caps to 2000 for x and y, 2147 for z, with a couple levels of warning below that, based on where a little stuff starts breaking, and a lot of stuff starts breaking. I'll let whoever wants to implement those warnings submit the PR.