Cannot move part in Z direction

faboaic commented 5 years ago

Version

Slic3rPE-1.42.0-alpha1+win64-full-201812231738

Operating system type + version

Win10 x64

Behavior

Describe the problem

I can move part in X and Y direction with the new function. If I move it in Z direction up or down it instantly goes back to default position.

Steps needed to reproduce the problem

Use move symbol in x , y and z direction.

Expected Results

Z works like X and Y. I would need to lower the part below the bed (like with not-so-comfortable cut function) so that lower part is not printed. Or need to lift a part up in the air if you want to continue a failed print... or just do some tests with support function...

Actual Results

Does not work...

Screenshots from Slic3r preview are preferred

cannotmovezbefore

cannotmovezafter

STL/Config (.ZIP) where problem occurs

Upload a zipped copy of an STL and your config (File -> Export Config)

cannotmoveZ.zip

bubnikv commented 4 years ago

We will likely implement 1) Collision detection on the plater. We already have the infrastructure in PrusaSlicer for that. 2) Collision of supports from different objects.

Once we have that, we may enable lifting the objects up, because the user will get a meaningful feedback if the print is not printable.

Yosoy-Ed commented 4 years ago

@CADPAT

Not even sure how “people might break their printers” is an argument

Could you please point me to the place where anyone from Prusa Research used this argument as a reason to not implement this? The reason was explained many times and this is not it.

Other slicers allow it and I dont see forums blowing up with issues relating to that feature.

I'm sorry, but the difference between PrusaSlicer and "other slicers" was explained here many times. Unless you are familiar with our actual reasons, the discussion can hardly lead anywhere. I'm not saying that you must agree with the reasons, but this is going in circles. Please, try to stay on topic and at least read the arguments of the other side.

I'm still waiting for an answer to why the current solution is inadequate and forbids the advanced users from doing anything. I don't see how talking about microwaving cats will help me to see the problem. Thanks.

Problem is not only being able to lift is also going down the plate. Somethings me, and I guess other users do it for different reasons. Merging doesn't solve it. I know the alternative is using cut, but still it's not the best approach, it damages the model and then we should reload the file or undo which would be a hassle if there are more than one piece in the buildplate.

Simply by choosing some -z direction, slice, review slicing, changing z again is simple and fast.

CADPAT commented 4 years ago

@lukasmatena

Could you please point me to the place where anyone from Prusa Research used this argument as a reason to not implement this? The reason was explained many times and this is not it.

I was responding to the people in the thread that were discussing this as an issue?

I'm sorry, but the difference between PrusaSlicer and "other slicers" was explained here many times. Unless you are familiar with our actual reasons, the discussion can hardly lead anywhere. I'm not saying that you must agree with the reasons, but this is going in circles. Please, try to stay on topic and at least read the arguments of the other side.

I'll make it simple. It is a feature I have used and find useful elsewhere, so it is a feature I expect. Yes there are workarounds, but I don't find them intuitive, or they are extra steps that I would rather not have to do because time matters. The reasons Collaborators are providing are things like "You should not need to move the object up in Z." or "Just use [other function] to do what you want". but the very fact we're having the disucssion is proof that the solutions/workarounds are counterintuitive. So what now? I and other people want the feature despite the reasoning you've provided. Yes the conversation is circular but only because more and more people are asking for it and you just keep giving the same reasons that, to be honest, don't help the situation. There are plenty of examples in this thread of situations where people believed that would solve the problem, and didn't instantly find the solution so they posted here. That is an indication that there is some sort of problem.

You think that's stupid? Fine. Close the thread and say you're never going to make it happen. Or make it happen and everyone will shut up. It's not complicated, but until you do one of these two things, the conversation will probably never end so it's kind of silly to complain about circular disucssion.

lukasmatena commented 4 years ago

@MrEdd88 Thanks, that is a scenario that actually makes sense.

@CADPAT

Close the thread and say you're never going to make it happen. Or make it happen

https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-712159946 has already answered that. We will remove the reason why we don't want to make it happen and then make it happen. That's probably all worth saying.

nicw commented 4 years ago

@nicw Just out of curiosity, why is it such a problem to merge the objects into one (simple in 2.3.0-alpha1) and then do the thing at the level of parts? I fully understand the reasons why people want to do A, what I don't understand is why it has to be done by B and not by C, when we have reasons not to allow B. The scenarios mentioned by you are both solvable this way and it takes just few extra mouse clicks, so I don't understand the part about limiting power users. Please don't take this as pouring more petrol in the fire, that's not my intention at all. I really just want to understand what is insufficient about this.

None taken. :) In my scenario (complex 200+ hour print) I am trying to match the size of one part to another, so I need to scale / undo / rescale as I compare one part to another. I tried laying them all on their side, but the parts are irregular, and where the parts need to fit together aren't the same z-height. If I merge them, then I cannot rescale one part to fit the other. I imagine Fusion360 allows me to do this arranging in free-space, but I was trying to avoid such large software for just planning out a 200+ hour print. Maybe I won't be able to.

I fully acknowledge that my scenario isn't something common, except that's the arena of the power user: doing things that don't always come up, and seeking to have the tool that meets that scenario. This is the second time I've done very large prints that have many parts that must fit together, so I am looking to reduce mistakes during the planning phase.

carlosjln commented 4 years ago

@nicw your scenarios are not uncommon, it's similar to the issues I have with my delta printer. It fails because It uses magnetic arms and they disconnect rather easy, also might have some layer shifts and in both cases I want to do this:

abort the print
let the extruder cool down, home and jog it down until it touches the printed object to get the current position.
then I could reopen the project I saved in prusa slicer, cut the model at the specified height without it dropping to the build plate.
generate the gcode and save what would have been a failed print.

meutzitzu commented 4 years ago

Ok so think about this: the main recommended way for sometome to recover from a failed print is to edit the gcode manually.

I know the Mk3 is more or less immune to this, but there's still a lot of Mk2(S) users out there, not to mention the loads of people who prefer the Prusa Slic3r for their non-prusa printers.

I think you are exposing your users to much more potential danger in terms of damage to their printers, etc etc if you keep this restriction, as there's a lot more that can go wrong when you're editing Gcode.

if you simply lift a part off the print bed, as a beginner to intermediate user, you at least understand what you are doing. going ahead and deleting chunks of gcode ... not so much.

so again, put it in edit mode, put all the restrictions and big pop-ups saying "don't do it unless you know what you're doing", but please DO add the option to bypass this restriction. because the alternative is just much worse of an experience in all possible cases.

bubnikv commented 4 years ago

BTW in PrusaSlicer 2.3.0-alpha1 you can do the following: https://www.youtube.com/watch?v=NAW2JR-D_QU&feature=youtu.be&t=54m6s

d4mer commented 3 years ago

This is just a case of devs egos getting in the way of creating a good product. The more users complain about this, the more the devs dig in and refuse to implement the FIX to a horrible, useless feature

spagatticode commented 3 years ago

Another use case is Flex-Filament (TPU). You can put Objects with infill inside Objects with a soft outer shell and generate selective stiffeners inside. i.e. this Plug: grafik (Note: in fact this is closed at the Top. Limited Layer Display, so that you can take a look inside)

Printed in TPU its outer Shell will squeeze easily in radial direction so it can be inserted in a fitting hole. The center Cylinder with infill works as an end-stop for the squeeze and for stiffness along the Z-Axis (and for build support to the Top Layer of course)

To achieve this, you have to place the inner cylinder on top of the bottom layers of the outer object.

You can not merge this into a single object, because it will only generate a boolean combine of the outer surfaces, so the inner object will be incepted and has no effect.

If you use the inner cylinder as Modifier:Infill it will have no shells.

A separate object cylinder will automatically be moved to the Build-Plane, so the bottom layers of outer and inner object will intersect each other

My workaround was to generate a second merge-object with the cylinder and a empty Box (size = 0) so that i can move the cylinder to a Z-Offset on top of the bottom layers of the outer part. Some warnings appear, but it prints as expected

estrangedwrenches commented 3 years ago

First time contributing here, created an account for this article; this may have already been stated but wanted to post my workaround as well. I recently upgraded to an MMU2S with my MK3S. I am printing some truck tires for my nephew that have separate tires and rims. I was trying to lift Z up to put the rims higher than the tires, that way the MMU didn't have to do several hundred color changes during the print, it would just do the tires up to a certain layer and then switch filaments one time and then do the rims on higher layers. I thought it would be easy to lift the rim up and slice it with supports, but it wasn't straight forward. The workaround was

Import STL's normally, not combined
right click the rims/part you need higher; click add part; click add cylinder
modify cylinder to an extremely small size with scale
place cylinder next to object, or anywhere you want really, close to the bed
drag cylinder up in scale making it longer without making it wider, once the cylinder contacts the bed, it will start lifting the rest of the parts/the part up into the air.
Slice with supports enabled.

Hope this randomly helps someone, because now that I've figured this out I may be combining a lot of single color prints more in the future to crank stuff out while I'm at work.

hassium123 commented 3 years ago

Jumping to say that yes, this is still a needed feature that we want. No we still do not appreciate being treated like children.

quetzalcoatl commented 3 years ago

@hassium123 Please be a bit more specific. Right now, your comment can be both understood as a comment from a slicer dev who felt hurt by i.e. comment from d4mer's or similar, or could be understood as a comment from an angry user who feels their opinion is ignored. Either way, not a healthy situation, but still, it'd be nice to be able to discern which of that it is :)

bubnikv commented 3 years ago

PrusaSlicer 2.4.0-alpha1 will support moving the object below the print bed, thus only the part of an object above the print bed will be printed.

As mentioned before, allowing the objects to levitate requires some additional effort from our side to make the feature safe for a general public.

HatemRT commented 3 years ago

PrusaSlicer 2.4.0-alpha1 will support moving the object below the print bed, thus only the part of an object above the print bed will be printed.

As mentioned before, allowing the objects to levitate requires some additional effort from our side to make the feature safe for a general public.

Hi, S3D or Cura are safe for general public and do have this option. I have moved to PrusaSlicer for everything but when I need to print an object on top of another object. For instance, is very attractive to embed a red pattern or text (just one or two 0,15mm layers) 0,2mm inside a transparent material. I can do it in S3D, why not in PS???

bubnikv commented 3 years ago

@HatemRT

I will ask our content team to describe the differences between PrusaSlicer and S3D/Cura. For example, Cura does not support different variable layer height per object, PrusaSlicer does. To support different workflows, different slicers take different routes.

In PrusaSlicer you can stack objects by loading them as volumes of the same object. There is a menu item "merge objects into a single object" in the object selection pop-up menu.

bubnikv commented 3 years ago

Our Mikolas Zuza created a following manual page https://help.prusa3d.com/en/article/how-to-lift-object-from-the-print-bed_245192

HatemRT commented 3 years ago

Our Mikolas Zuza created a following manual page https://help.prusa3d.com/en/article/how-to-lift-object-from-the-print-bed_245192

Thanks Bubník for your reply. Unfortunately, I think this is not the feature I was searching for as I need to slice (and print) those objects separately.

mikolaszuza commented 3 years ago

@HatemRT Out of curiosity and if you don't mind sharing, what's your use case, that you need to print separately sliced objects levitating above the heated? Are you printing on top of existing prints clamped down to the heated or something like that?

terribleperson commented 3 years ago

In my case I wasn't trying to print on top of a previous print, but another object clamped to the printed bed. Having to adjust g-code every iteration was a pain.

ssill2 commented 3 years ago

I'm curious why you wouldn't just add the second object as a part to the first. You could then move it up and down as you're suggesting.

wavexx commented 3 years ago

On Tue, Aug 03 2021, terribleperson wrote:

In my case I wasn't trying to print on top of a previous print, but another object clamped to the printed bed. Having to adjust g-code every iteration was a pain.

So you're using the first object as "fixed support" essentially right?

That's an interesting approach. I guess this is a flat part, since there's no collision avoidance.

It's currently possible set an object as "hidden", but it currently doesn't work on parts. If that attribute would work on parts, then you could merge them and mark "support" as hidden while lifting the first off the bed.

This would work similarly to "show but don't print" attribute we have in regular documents.

HatemRT commented 3 years ago

@HatemRT Out of curiosity and if you don't mind sharing, what's your use case, that you need to print separately sliced objects levitating above the heated? Are you printing on top of existing prints clamped down to the heated or something like that?

No need for clamping as I print over the previous object. For instance, I want to embed a text inside a "transparent" material. I print a thin layer as 1st object, the text or pattern in a different material as the second object on top of the first. This second object is very thin (0,2-0,4mm) as the third one will print over and around this second object.

estrangedwrenches commented 3 years ago

Nice!

simoonvance commented 3 years ago

Nice! Matt Simmons www.mattsautoshop.com 130 Annaron Ct. Raleigh, NC 27603 919-827-4705 | fax: 919-827-4708 @. … On Tue, Aug 10, 2021 at 1:02 PM simoonvance @.> wrote: If it hasn't already been mentioned, I was told in a reddit thread this issue has just been finished, and that it will be implemented into prusaslicer 2.4, alpha coming out in 1-2 weeks. Say goodbye to workarounds, great work on the dev team. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1513 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATQFYCDT7RNO6ZUTH2BVERLT4FLTLANCNFSM4GMD77OQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

I deleted the comment, apparently the dev that told me misread me and thought I was asking when parts could be lowered into the bed.

estrangedwrenches commented 3 years ago

Well shit! Lol.

HatemRT commented 3 years ago

Nice! Matt Simmons www.mattsautoshop.com 130 Annaron Ct. Raleigh, NC 27603 919-827-4705 | fax: 919-827-4708 @. … On Tue, Aug 10, 2021 at 1:02 PM simoonvance @.> wrote: If it hasn't already been mentioned, I was told in a reddit thread this issue has just been finished, and that it will be implemented into prusaslicer 2.4, alpha coming out in 1-2 weeks. Say goodbye to workarounds, great work on the dev team. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1513 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATQFYCDT7RNO6ZUTH2BVERLT4FLTLANCNFSM4GMD77OQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

I deleted the comment, apparently the dev that told me misread me and thought I was asking when parts could be lowered into the bed.

Oooooooooooooh :(

kenour commented 3 years ago

The only reason I want to do this, is I like to put a PETG base down before I print ASA. I haven't had to do it in a while, but am currently in the process of replacing my MK2 extruder with the new MK3 parts.

So I want to print a new fan shroud, in ASA. I thought to myself, oh joy of joys, I can print a PETG base like I usually do, but now, I CAN IRON IT! I would normally make the top two layers 0.4 which would give it a nice flat surface to print on, but I was super keen to try ironing...

Then I remembered I had to deal with this nonsense!!! PrusaSlicer trying to be too clever... For the USE A RAFT club, I wish it was that simple. I actually wish I could use a solid raft, with ironing enabled, and specify a different material. What I have noticed from my experiments is that if I put a layer of PETG down first before printing ASA, the bed doesn't need to be as hot, as a lower heat keeps the PETG sticky enough to hold the ASA. Then when cool, both pieces release easily. The part from the base, and the base from the bed.

So if you guys don't fix this issue, you must hate the planet... All that wasted power to hold an ASA part down to a warmer PEI bed, for shame! How many llamas have to die because of climate change before you guys take action 😭

If anyone has an easy fix, please let me know!

EDIT: This is as far as I've gotten, merged the models to 'trick' it into printing 0.8mm off the bed. Loaded another version of the base, set the parameters I wanted, but the bloody thing wants to print it as if it's one object. I don't want it to bridge, I want it to print on the PETG like it's the bed. Also I would like to be able to set a different material for each part... There's probably an easy way to do this, haven't done it in the past because PETG and ASA is close enough, I just turn down the bed temp in the ASA profile.

AbuMaia commented 3 years ago

@kenour Have you tried loading your ASA part, and telling PrusaSlicer to add a box (or cylinder) to it. Set the dimensions of the box how you want, then in the layers view, pull the top view knob down to one layer from the bed, and click the + to add a color change. That will let you print the flat box in PETG, then it'll eject the PETG filament and let you load the ASA filament to complete the print. You can then tell it to use different temperatures for different layers in the custom gcode section.

emeyedeejay commented 3 years ago

Holy smokes - this goes back 3 years! C'mon Prusa you can surely surely fix this.

I was really realy really hoping this would have been resolved by the time I reached the current comments.

paynterf commented 3 years ago

Holy smokes - this goes back 3 years! C'mon Prusa you can surely surely fix this.

I was really realy really hoping this would have been resolved by the time I reached the current comments.

Me too! ;)

mroek commented 3 years ago

I had really hoped that this would have been fixed by now. The arguments about safety is in my opinion quite dumb. People not knowing what they are doing can always get into trouble, and that is no different if the slicer could just allow for slicing objects off of the bed (to print on top of something that is already there).

Now that S3D is basically completely abandoned, it would have been great if the perhaps biggest contender could allow this quite powerful technique. I don't know if the developers of PS just disagree it is useful, or if they deem it too difficult to implement.

It seems weird though, because I can get PS to create toolpaths (at least shown in the preview) in mid air, but when trying to export the G-code, it doesn't write the file (there'a an error about there being a object with no extrusions in the first layer):

ps_slice_air

There seems to be no viable workaround for this, and that's a pity.

kulberda commented 3 years ago

For what it's worth I'm still waiting on a solution to this myself (I've been on this one for 2 years now). Now that I'm aware of the problem I am able to account for it in my own models (for the most part) but for combing existing models that could otherwise easily be done in PrusaSlicer itself (either directly or using cut and other built in tools) it's very inconvenient to have to resort to extra steps in an external modeler. This is particularly problematic when I'd like to apply variations to a print in PrusaSlicer without having to export multiple complete models when the only changes are to the arrangement of parts being printed on top of a base model.

mroek commented 3 years ago

So I found a workaround for the use case where you want to print on top of another object (for example to fill in letters and details with a different color), and that is to use sequential printing and print a very small sacrificial (like a helper disc from the gallery) object first (typically close to the origin). A manual edit (to lift the toolhead in Z) of the G-code is still needed, but it's quite easy.

It does not work in the official 2.3 release, but I got it to work in 2.4-beta1. There is still a warning, but the G-code does export.

Note that this method does not allow for printing it all in one go, it means printing one file first (the base), then the next one (which prints on top of the base). Hopefully this method will still work going forward.

emeyedeejay commented 3 years ago

I'm pretty blown away that this is still a thing and that people who want to start a print of something from layer 27 or height 6.77736353553mm are not able to without workarounds and kludges.

On Tue, 26 Oct 2021 at 13:04, mroek @.***> wrote:

So I found a workaround for the use case where you want to print on top of another object (for example to fill in letters and details with a different color), and that is to use sequential printing and print a very small sacrificial (like a helper disc from the gallery) object first (typically close to the origin). A manual edit (to lift the toolhead in Z) of the G-code is still needed, but it's quite easy.

It does not work in the official 2.3 release, but I got it to work in 2.4-beta1. There is still a warning, but the G-code does export.

Note that this method does not allow for printing it all in one go, it means printing one file first (the base), then the next one (which prints on top of the base). Hopefully this method will still work going forward.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-951824375, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBF5B2YM35JBFYIYRHMAZTUI2KNFANCNFSM4GMD77OQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

mroek commented 3 years ago

@emeyedeejay I completely agree, but the developers of Prusaslicer appears to be of a different opinion. Admittedly, this is perhaps not the most important thing in the world, but there's no doubt that many people need it from time to time, and would like to not have to switch to a different slicer to get the job done.

emeyedeejay commented 3 years ago

Agreed - not a major issue but at the same time, probably a walk in the park to implement. Surely it's just to start exporting gcode from the layer that's on the build plate? What am I missing?

On Tue, 26 Oct 2021 at 13:19, mroek @.***> wrote:

@emeyedeejay https://github.com/emeyedeejay I completely agree, but the developers of Prusaslicer appears to be of a different opinion. Admittedly, this is perhaps not the most important thing in the world, but there's no doubt that many people need it from time to time, and would like to not have to switch to a different slicer to get the job done.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-951835875, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBF5B474FRT55PZAIB5FGLUI2MGZANCNFSM4GMD77OQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

mikolaszuza commented 3 years ago

@emeyedeejay Moving objects in the Z-axis below the build plate has been in the latest releases for over two months, please check the release notes to learn more.

"Moving the object below the print bed #1513 We are newly allowing an object to be moved below the print bed to print just the part of the object above the print bed. Arguably this was already doable with the "Cut" tool, but the new way is much simpler to use and very handy for example if one just needs to flatten the bottom of an uneven object to be printable without a raft. We do not allow the object to be lifted above the print bed: Elevated objects are not printable without a raft and supports. If an object is not flat, raft shall be enabled for the object by the user.

An object is either on the print bed or below the print bed. If an object is on the print bed, the software behaves as before: After rotating and scaling, the object Z position is adjusted to touch the print bed. On the other hand, if an object is partially below the print bed, scaling and rotation does not change object's Z position as long as the object is not elevated above the print bed. If an object is elevated above the print bed, it is again lowered to touch the print bed. There is also a new button "Drop to bed" at the object manipulation panel to move the object back to the print bed, however the same action may be done just by elevating the object above the print bed with the move gizmo and letting it drop back to the print bed.

If the object is partially below the print bed, a white contour is drawn along the object - print bed intersection to indicate where the object will be trimmed. When manipulating the object with a move / rotate / scale gizmos or when hovering over the object with a mouse cursor, the white intersection contour is drawn not clipped by the object to make it easier to flatten an uneven bottom of an object.

When in painting gizmo, the part below the print bed is being clipped and painting on the print bed clipping plane is not allowed.

Moving objects below print bed is not allowed in SLA mode for now as it would make the placement of SLA supports confusing. Thus when switching from an FDM printer to a SLA printer, all objects below the print bed are being lifted to touch the print bed."

emeyedeejay commented 3 years ago

That's fantastic news - thanks for letting us know 👍

One less reason to drop to Cura every now and then!

On Tue, 26 Oct 2021 at 14:43, mikolaszuza @.***> wrote:

Moving objects in the Z-axis below the build plate has been in the latest releases for over two months, please check the release notes to learn more. [image: image] https://user-images.githubusercontent.com/23498906/138880687-65f76bcf-dd8a-4fc3-8a28-b7cf0e8244d8.png

"Moving the object below the print bed #1513 https://github.com/prusa3d/PrusaSlicer/issues/1513 We are newly allowing an object to be moved below the print bed to print just the part of the object above the print bed. Arguably this was already doable with the "Cut" tool, but the new way is much simpler to use and very handy for example if one just needs to flatten the bottom of an uneven object to be printable without a raft. We do not allow the object to be lifted above the print bed: Elevated objects are not printable without a raft and supports. If an object is not flat, raft shall be enabled for the object by the user.

An object is either on the print bed or below the print bed. If an object is on the print bed, the software behaves as before: After rotating and scaling, the object Z position is adjusted to touch the print bed. On the other hand, if an object is partially below the print bed, scaling and rotation does not change object's Z position as long as the object is not elevated above the print bed. If an object is elevated above the print bed, it is again lowered to touch the print bed. There is also a new button "Drop to bed" at the object manipulation panel to move the object back to the print bed, however the same action may be done just by elevating the object above the print bed with the move gizmo and letting it drop back to the print bed.

If the object is partially below the print bed, a white contour is drawn along the object - print bed intersection to indicate where the object will be trimmed. When manipulating the object with a move / rotate / scale gizmos or when hovering over the object with a mouse cursor, the white intersection contour is drawn not clipped by the object to make it easier to flatten an uneven bottom of an object.

When in painting gizmo, the part below the print bed is being clipped and painting on the print bed clipping plane is not allowed.

Moving objects below print bed is not allowed in SLA mode for now as it would make the placement of SLA supports confusing. Thus when switching from an FDM printer to a SLA printer, all objects below the print bed are being lifted to touch the print bed."

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-951900952, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBF5B4UBTZYIWUBONRGX43UI2V7BANCNFSM4GMD77OQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

emeyedeejay commented 3 years ago

May have celebrated too soon there. Still can't move an item off the build plate...

Still great news about going below the bed,

mroek commented 3 years ago

@mikolaszuza But moving objects below the bed does not in any way address this issue. That's a completely different thing (also a useful feature).

The point is to be able to print on top (and even into shallow cavities) of something that is already on the build plate, for example text or other details. Look at this STL, for example:

test.zip

(Split it to parts after loading)

If I want to print this upright and fill in the letters in a different color, that is not possible in Prusaslicer (well, I found a workaround in the latest beta, but it is a little tedious), while in for example S3D it's a breeze. This is a simple example to illustrate the problem, and the solution is not to flip it so the letters go towards the bed (because even if that is possible for this particular example, it isn't generally true).

emeyedeejay commented 3 years ago

Yeah sorry folks - that was me mixing drinks and confusing things.

lukasmatena commented 3 years ago

@mroek If you want to print your example, it is possible to pretend that your printer has two extruders and set M600 as a toolchange g-code. This will also take care of all problems associated with that solution, such as whether the recess is shallow enough, if there are no collisions during printing etc.

If you absolutely insist that it must be printed the way you suggest, then add one more part to the object, scale it down, put it to the bed and then delete the "main" body. This solves most of the issues reported in this thread. I enclose a 3mf of both these cases. (Of course that requires to strip the custom g-code so it does not home z etc.) flying_1.zip flying_2.zip

I don't know if the developers of PS just disagree it is useful, or if they deem it too difficult to implement.

That is a fair question, I'll try to answer. The developers think that it is too difficult to implement given the added value, given that it is not a feature many people need and given that there are workarounds for most (if not all) use cases. I know that everyone here thinks that the problem is a stubborn programmer who refuses to turn some checkbox "on", just to feel the power he has over the users of the software. It is not exactly so. The problem is that the assumption "objects are not floating" is present in many places of the codebase, and "just" allowing it is no longer an option. We allowed sinking the object below the bed in this release (which is much simpler than what you guys want), and the amount of bugs and weirdness it produced (and probably will produce) surprised even people working on the project for years. The amount of work needed to implement lifting is hard to justify. Is it doable? Yes, anything is doable. it is time and priorities that are in the way.

So whenever we suggest a workaround to someone, it is not because we have a maniacal desire to make the puppets dance, but to show that there already is a solution to the problem and we would like to work on other problems that have no solution yet. I'm not saying that it will NEVER be implemented. But other things have priority right now, for the reasons above.

Put yet another way, if we make this a top priority, improving anything else will be delayed. The tree supports will be delayed, many other issues that are in the software for years (which other people also like to point out) etc. This will also make people angry. And we don't have resources to just do everything at once. Also, a change like this would quite likely make the whole software unstable for months, before all the hidden assumptions are discovered and fixed. That is more how things are. I don't think that the overall attitude against the "evil developers" is deserved. We put a lot into the software, so reading things like "why on Earth you waste time speeding up G-Code export twice when I want tree supports more" (which is the gist of a social network feedback) is quite tough.

See similar discussion here: https://github.com/prusa3d/PrusaSlicer/issues/7162#issuecomment-950662055. "Lift the object" is replaced by "use GitHub Actions", but the principle is the same. There is a similar group around tree supports, etc. What I (and @bubnikv in the other thread) have written is a general answer to that. I hope it makes sense and does not sound arrogant, ironic or in any other way inappropriate. It is not meant so, I just wanted to show a bit from the other perspective. Thanks if you read it all the way down here.

The only time when I chose to be slightly ironic is now (sorry): @emeyedeejay

probably a walk in the park to implement

Ok.

mroek commented 3 years ago

@lukasmatena Thank you for that writeup! You explained quite clearly the issues, and what is even better (for me at least): You taught me a better workaround than the one I had, and it basically solves the issue for the majority (maybe even all) of the cases where I need it (which isn't very often).

I knew about the trick with adding an extruder and using the toolchange g-code, but the issue with that is that I end up with swapping filaments much more frequently, and that is tedious. In the example the letter recesses are shallow enough that the nozzle can print into them without any problems, so I prefer that.

What I had missed (and that I now learnt) was that I could just add another object to the part instead of resorting to sequential printing (which gives me more or less the same result, but also means I must edit the G-code to lift Z before it travels to the main object). Your example will make the bottom-most layers (of the letters) treated as overhang perimeters (while in reality they are not overhangs since they are printed into the part on the bed), but that doesn't really matter.

I completely understand that you guys have to prioritize, and when it comes to the speedup, I for one really appreciate that. It is very noticeable.

lukasmatena commented 3 years ago

@mroek

Your example will make the bottom-most layers (of the letters) treated as overhang perimeters

You can turn off 'Detect bridging perimeters' if that was a problem. You can even do it for each part separately:

estrangedwrenches commented 3 years ago

I have floated objects before and the workaround I use isn't difficult and is probably completely mentioned here already so if this is redundant than please ignore. I am not 3d printing guru by any means but I found this with a simple search a year or two ago when I ran into this problem. I get emails about this chain so thought I'd chime in.

Import your object(s). Right click object, click add part, and click add a cylinder (or just add a cylinder and then merge the two). Make the cylinder almost nonexistently small. When you click on the group you can highlight just the cylinder in the pane to the right; do this and you can "drag" the cylinder as tall as you want with the scale tool. This lifts the other objects in the group up off the bed as you scale it. Takes only a couple seconds... now everyone tell me why this is stupid. :)

mroek commented 3 years ago

@lukasmatena Thanks! While not really a problem, it does make sense to do it.

If only it was possible to disable bridging altogether... If this example was printed the other way around (letters first, and on the build plate), then I don't want any bridging on top of the letters (again, the slicer doesn't know that there's something solid to print over), but typically this is what happens:

ps_bridge

A solid layer instead of that mix between bridge infill and solid infill would be much preferred. Turning off bridge detection altogether would achieve that. In S3D I can do that by just upping the "Unsupported area threshold" to a large value. Prusaslicer always wants to detect bridges (at least for infill), as far as I can tell.

emeyedeejay commented 3 years ago

@mroek If you want to print your example, it is possible to pretend that your printer has two extruders and set M600 as a toolchange g-code. This will also take care of all problems associated with that solution, such as whether the recess is shallow enough, if there are no collisions during printing etc.

If you absolutely insist that it must be printed the way you suggest, then add one more part to the object, scale it down, put it to the bed and then delete the "main" body. This solves most of the issues reported in this thread. I enclose a 3mf of both these cases. (Of course that requires to strip the custom g-code so it does not home z etc.) flying_1.zip flying_2.zip

I don't know if the developers of PS just disagree it is useful, or if they deem it too difficult to implement.

That is a fair question, I'll try to answer. The developers think that it is too difficult to implement given the added value, given that it is not a feature many people need and given that there are workarounds for most (if not all) use cases. I know that everyone here thinks that the problem is a stubborn programmer who refuses to turn some checkbox "on", just to feel the power he has over the users of the software. It is not exactly so. The problem is that the assumption "objects are not floating" is present in many places of the codebase, and "just" allowing it is no longer an option. We allowed sinking the object below the bed in this release (which is much simpler than what you guys want), and the amount of bugs and weirdness it produced (and probably will produce) surprised even people working on the project for years. The amount of work needed to implement lifting is hard to justify. Is it doable? Yes, anything is doable. it is time and priorities that are in the way.

So whenever we suggest a workaround to someone, it is not because we have a maniacal desire to make the puppets dance, but to show that there already is a solution to the problem and we would like to work on other problems that have no solution yet. I'm not saying that it will NEVER be implemented. But other things have priority right now, for the reasons above.

Put yet another way, if we make this a top priority, improving anything else will be delayed. The tree supports will be delayed, many other issues that are in the software for years (which other people also like to point out) etc. This will also make people angry. And we don't have resources to just do everything at once. Also, a change like this would quite likely make the whole software unstable for months, before all the hidden assumptions are discovered and fixed. That is more how things are. I don't think that the overall attitude against the "evil developers" is deserved. We put a lot into the software, so reading things like "why on Earth you waste time speeding up G-Code export twice when I want tree supports more" (which is the gist of a social network feedback) is quite tough.

See similar discussion here: #7162 (comment). "Lift the object" is replaced by "use GitHub Actions", but the principle is the same. There is a similar group around tree supports, etc. What I (and @bubnikv in the other thread) have written is a general answer to that. I hope it makes sense and does not sound arrogant, ironic or in any other way inappropriate. It is not meant so, I just wanted to show a bit from the other perspective. Thanks if you read it all the way down here.

The only time when I chose to be slightly ironic is now (sorry): @emeyedeejay

probably a walk in the park to implement

Ok.

Thank you for the very informative and very well presented write-up. Consider me put in my place! (Although to be fair, I was referencing objects below the build plate :D).

I think the frustration - actually let me not generalise - my frustration is that I would love to be able to use 1 tool and get to know it extremely well. I've been printing since July this year - I'm a nOOb of the highest order. PS scared the bejeepers out of me initially (I admit that I turned the "Expert" selection for setting on - who wouldn't!) and I got going with Cura.

Recently I dabbled in PS (sounds like black magic/voodoo .. not far off!) and got into it quickly ... certainly based on the Cura "experience" ... and it was a breath of fresh air.

I currently jump to Cura for one of the plugins "Auto orient" which uses magic to decide the best way to orient an item. Then it's back to PS to orient same.

Basically I'm being greedy - I want what I want and I want it ASAP... As you rightfully point out, I wouldn't have the foggiest notion in what may be required to make something like this happen! Please accept my most humble apologies ... I just want PS to be the one that rules them all!

Anyway - I love PS... and here's a heartfelt thank you to all the team involved.

Hermann-SW commented 2 years ago

This youtube video of "3D Printing Nerd" shows how to stack with PrusaSlicer (multi part, and adding "support enforcement"): https://www.youtube.com/watch?v=RAciAS1ssuc

Unmarking "Automatically drop models to the build plate" in preferences of cura is definitely much simpler:

Hermann-SW commented 2 years ago

Just learned from neophyl https://forum.prusaprinters.org/forum/prusaslicer/how-to-set-z-height/#post-588715

that "adding parts" is all that is needed, nothing more. Stacking with PrusaSlicer is now as easy as with cura, and in my eyes this issue can be closed because nothing is missing.

prusa3d / PrusaSlicer