Cannot move part in Z direction

[faboaic]

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

STL/Config (.ZIP) where problem occurs

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

cannotmoveZ.zip

[HatemRT]

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.

I utterly do not agree to close this request. What you have shown is just a trick, a workaround, not a true solution. What we a re asking for is to be able to set a positive Z value for an object. Full stop.

[paynterf]

I do not think it should be closed either. This is the typical lazy programmer's response "Well, there IS a way to do it (no matter how counter-intuitive or roundabout), so PROBLEM SOLVED!" PS is a very powerful and intuitive slicer - don't muck it up by ignoring a big blemish

[traderhut]

What I find interesting about this project, as compared, say to nearly any other, is that simple changes are requested, that would take a very short time to implement - in this case, I expect it might be as easy as commenting out code that forces the Z to be back on the plate. This might be as easy as adding // to one line of code, hard to say. So unlike other projects where the push back is 'that would take too much effort to implement' when a feature is requested. Here we get "I don't wanna!"

How can one argue against that? What could be done about it? The answer is, don't bother trying to argue, and maybe the best solution is to spin off another Source Repo, and make the change and push out another version of the slicer based on Prusa, and give it options people are asking for, such as this one or the prompt if you are about to wipe out all your settings because you are loading an old file. (Another request, with the same kind of response, no not hard to do, just don't wanna)

As a Software Architect of 4 decades of experience, I can tell you this wouldn't cut it in a professional environment. You would get requests from customers, they would go through review and be presented as things that the programmers need to implement. But, in this case, the customer advocates are missing in the picture, and we are talking directly to the developers, and you can get a 'don't wanna' response that is pretty pointless to argue against.

BTW: There is a simple solution to this as a work around that I figured out, it works, and I'm able to work around the defective software. (Defective software is defined as software that doesn't do what the users want it to, NOT doesn't do what the developers want it to. Something that takes a while for developers to learn...)

I would like a feature to be able to snap one part to another one, including X,Y and Z, so when I try to move a part I don't have to do it by hand, and I know that it has exactly been placed where it should be. This would be good for creating inlays, where part 1 has a cutout in the top (think of a coaster) and part 2 is the letter you want in the center of the part (which you do in a different extruder and boom! Cool coaster with two colors... and one part is floating about 5mm up in the air..)

The point of writing software is to make it as easy as possible for users to do exactly what THEY want to do.

As for the argument I saw in a previous message, which I laughed at, "I work at a university, and think this could cause people to mess up" (or something like that.) You can't write software with idiots as the target audience, or only an idiot would want to use it. Also, how bad could it be if someone printed something that was up 1 cm in the air before it started printing... OMG! It would move to Z = 10 and start air printing... and then the guy would stop the print and fix it... wasting $0.001 worth of plastic... and causing an end to the world, or at least the town... They would be cleaning that up for days... Yeah, no. They would see their failing, and they would fix it. or, if support was turned on, it would (one would assume) create support under it all the way down to the bed and would end up working fine - except for wasting the support (maybe) - depending on what the person wanted to do.

[paynterf]

I'd be willing to help with a fork. I actually tried to do this some time ago when I was working on a config for the Flashforge Creator Pro 2 IDEX printer, but couldn't get the system to compile using VS2022 on my Win 10 box.

On Mon, Apr 4, 2022 at 4:24 PM traderhut @.***> wrote:

What I find interesting about this project, as compared, say to nearly any other, is that simple changes are requested, that would take a very short time to implement - in this case, I expect it might be as easy as commenting out code that forces the Z to be back on the plate. This might be as easy as adding // to one line of code, hard to say. So unlike other projects where the push back is 'that would take too much effort to implement' when a feature is requested. Here we get "I don't wanna!"

How can one argue against that? What could be done about it? The answer is, don't bother trying to argue, and maybe the best solution is to spin off another Source Repo, and make the change and push out another version of the slicer based on Prusa, and give it options people are asking for, such as this one or the prompt if you are about to wipe out all your settings because you are loading an old file. (Another request, with the same kind of response, no not hard to do, just don't wanna)

As a Software Architect of 4 decades of experience, I can tell you this wouldn't cut it in a professional environment. You would get requests from customers, they would go through review and be presented as things that the programmers need to implement. But, in this case, the customer advocates are missing in the picture, and we are talking directly to the developers, and you can get a 'don't wanna' response that is pretty pointless to argue against.

BTW: There is a simple solution to this as a work around that I figured out, it works, and I'm able to work around the defective software. (Defective software is defined as software that doesn't do what the users want it to, NOT doesn't do what the developers want it to. Something that takes a while for developers to learn...)

I would like a feature to be able to snap one part to another one, including X,Y and Z, so when I try to move a part I don't have to do it by hand, and I know that it has exactly been placed where it should be. This would be good for creating inlays, where part 1 has a cutout in the top (think of a coaster) and part 2 is the letter you want in the center of the part (which you do in a different extruder and boom! Cool coaster with two colors... and one part is floating about 5mm up in the air..)

The point of writing software is to make it as easy as possible for users to do exactly what THEY want to do.

As for the argument I saw in a previous message, which I laughed at, "I work at a university, and think this could cause people to mess up" (or something like that.) You can't write software with idiots as the target audience, or only an idiot would want to use it. Also, how bad could it be if someone printed something that was up 1 cm in the air before it started printing... OMG! It would move to Z = 10 and start air printing... and then the guy would stop the print and fix it... wasting $0.001 worth of plastic... and causing an end to the world, or at least the town... They would be cleaning that up for days... Yeah, no. They would see their failing, and they would fix it. or, if support was turned on, it would (one would assume) create support under it all the way down to the bed and would end up working fine - except for wasting the support (maybe) - depending on what the person wanted to do.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-1087979718, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6T327TIBGBOSIQIHWU6RTVDNFYJANCNFSM4GMD77OQ . You are receiving this because you commented.Message ID: @.***>

-- G.Frank Paynter, PhD OSU ESL Research Scientist (ret) EM Workbench LLC 614 638-6749 (cell)

[traderhut]

Yeah, compiling the software was a bit of a bit...h, I got it to compile with VS 2019, which I think is the target compiler, there are parts of the scripts that are run that specifically stating 2019, so if you were trying with a newer version, then you would have to update the scripts (at the least) to get that to work.

I got it to compile, and made a change to set the Z Axis after a tool change, which is critical if you want to use the software with a E3D Tool changer - as the tool change leaves the Z at +5mm and, although you could change that to be 0, doing so makes it will zoom across the print at the same level that some things were printed (if, this was the 2nd color on that layer), and you hear a lot of smacking around if your two extruders are EXACTLY the same in the Z Axis (can't be 0.05mm off or it will cause a lot of issues, instead of minor ones). I had previously fixed that by writing some software to post-process the gcode that was created and perform the updates to set the Z - but that wasn't correct because it really needed to do a move back to where it is about to print at Z+5, and THEN move Z-5 (or technically set Z to the current layer height) to continue printing. However, there is code in the app to not emit the Z if it is already at that height, which I'm sure is designed to reduce the output... And my change is a horrible hack that I don't think is even 100% handled correctly. (It creates an extra Z move that isn't needed on some tool changes - which doesn't cause any harm, but it does add extra gcode.)

Honestly, I don't have any great desire to do a fork, would rather see a change in the attitude. Maintaining this code looks to be pretty nightmarish... as it has been hacked on a lot. - For example, it was really hard to get it to generate a Z move gcode, and even making the hidden method that shouldn't be checking for current height and just emitting the move, seemed to return blank, which, rather than tracking that down I just hard coded a G1 Znnn in the code as I wanted to see if it solved it, and wanted to see that quickly..)

If I had the hours to spend on it, I'd think about a conversion to C# C++ has been pretty dead except for embedded programming and maintaining existing code for about 25 years (I stopped using it in 1995), and it would be good to update the design. C# would compile in seconds instead of "go get a cup of coffee" but that would be a huge effort...

(and before every screams that C++ is alive and well, Yes, people still use it, but it is more expensive to maintain. And yes, some people love it and continue to praise it and will die still writing that code... just like the C guys I know, oh, and I know someone who swears that assembly language is the only way to go because he can do it better than a compiler can - and my brother worked on one of the compilers that would beat the pants off this guys code.. but that is really off topic)

[paynterf]

Yeah, I'd like to see that too - the reason I tried to fork it the first time was that the 'new printer config' construction instructions were so confusing that I thought I'd be better off working with the source code - not!

Frank

On Mon, Apr 4, 2022 at 6:06 PM traderhut @.***> wrote:

Yeah, compiling the software was a bit of a bit...h, I got it to compile with VS 2019, which I think is the target compiler, there are parts of the scripts that are run that specifically stating 2019, so if you were trying with a newer version, then you would have to update the scripts (at the least) to get that to work.

I got it to compile, and made a change to set the Z Axis after a tool change, which is critical if you want to use the software with a E3D Tool changer - as the tool change leaves the Z at +5mm and, although you could change that to be 0, doing so makes it will zoom across the print at the same level that some things were printed (if, this was the 2nd color on that layer), and you hear a lot of smacking around if your two extruders are EXACTLY the same in the Z Axis (can't be 0.05mm off or it will cause a lot of issues, instead of minor ones). I had previously fixed that by writing some software to post-process the gcode that was created and perform the updates to set the Z - but that wasn't correct because it really needed to do a move back to where it is about to print at Z+5, and THEN move Z-5 (or technically set Z to the current layer height) to continue printing. However, there is code in the app to not emit the Z if it is already at that height, which I'm sure is designed to reduce the output... And my change is a horrible hack that I don't think is even 100% handled correctly. (It creates an extra Z move that isn't needed on some tool changes - which doesn't cause any harm, but it does add extra gcode.)

Honestly, I don't have any great desire to do a fork, would rather see a change in the attitude. Maintaining this code looks to be pretty nightmarish... as it has been hacked on a lot. - For example, it was really hard to get it to generate a Z move gcode, and even making the hidden method that shouldn't be checking for current height and just emitting the move, seemed to return blank, which, rather than tracking that down I just hard coded a G1 Znnn in the code as I wanted to see if it solved it, and wanted to see that quickly..)

If I had the hours to spend on it, I'd think about a conversion to C# C++ has been pretty dead except for embedded programming and maintaining existing code for about 25 years (I stopped using it in 1995), and it would be good to update the design. C# would compile in seconds instead of "go get a cup of coffee" but that would be a huge effort...

(and before every screams that C++ is alive and well, Yes, people still use it, but it is more expensive to maintain. And yes, some people love it and continue to praise it and will die still writing that code... just like the C guys I know, oh, and I know someone who swears that assembly language is the only way to go because he can do it better than a compiler can - and my brother worked on one of the compilers that would beat the pants off this guys code.. but that is really off topic)

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-1088059201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6T3243QZWSBW5M2KK5SYTVDNRXDANCNFSM4GMD77OQ . You are receiving this because you commented.Message ID: @.***>

-- G.Frank Paynter, PhD OSU ESL Research Scientist (ret) EM Workbench LLC 614 638-6749 (cell)

[lukasmatena]

@traderhut

What I find interesting about this project, as compared, say to nearly any other, is that simple changes are requested, that would take a very short time to implement

What I find interesting is how many people with no knowledge of the codebase know exactly what is simple and what is not.

Here we get "I don't wanna!"

No, if you'd bother to read the thread before writing your rant, you'd see that it is in fact not what you get (e.g. https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-952048965). It would be more constructive to react to what the other part actually says, not what you put into their mouth.

As a Software Architect of 4 decades of experience, I can tell you this wouldn't cut it in a professional environment. You would get requests from customers, they would go through review and be presented as things that the programmers need to implement.

Did you never reject a feature request in those 4 decades? What software you worked on and how many people used it? Isn't the main difference in the fact that the process is usually not public?

I would like a feature to be able to snap one part to another one

That's another feature request that we are aware of and considering. But I'm surprised that as a software architect with four decades of experience you only see the "I would like a feature" part.

The point of writing software is to make it as easy as possible for users to do exactly what THEY want to do.

They? There is quite of lot of PS users and each wants something else. But I'm just repeating what I have already written in the above post.

C++ has been pretty dead except for embedded programming I stopped using it in 1995 If I had the hours to spend on it, I'd think about a conversion to C# C# would compile in seconds it would be good to update the design don't bother trying to argue, and maybe the best solution is to spin off another Source Repo

To be honest, if you are seriously suggesting to rewrite everything into C# to cut down on compilation times, I'm struggling to believe your claims about being a software architect. Anyway, we are not porting PrusaSlicer to C# (there are reasons, imagine them as "we don't wanna" if you like). If you think it gives an advantage over the competition and it is a hole in the market, I wish you luck in filling it.

Regarding your last paragraph. The shocking revelation that modern C++ compilers optimize well is probably not surprising for people using C++ even after 1995. We are lucky that developers of compilers spend so much time on a language that is "pretty dead" for several decades. They also rolled some "minor" updates since then. But that is really off-topic.

[paynterf]

I'm sure we would all be delighted to hear why the requested changes are impractical. We all have our own coding ideologies and histories, but I suspect we are all united in wanting to have Prusa Slicer be the best it can be, and responsive to user input. That is, after all, the whole idea of open source software, is it not?

Maybe it really is impractical/too difficult to implement the ability to move objects in the Z-direction, and I, for one, don't think the answer should be "re code from the ground up using [insert language here]". However, fundamental issues like this do need to be addressed, as they aren't going to go away anytime soon.

Maybe some consideration should be given to making the codebase easier to compile, so knowledgeable users can contribute pull requests that address these (and possibly other) issues, hopefully reducing the workload of the maintainers?

Can we all get back to talking about how best to solve this?

TIA,

Frank

On Tue, Apr 5, 2022 at 2:26 AM Lukáš Matěna @.***> wrote:

@traderhut https://github.com/traderhut

What I find interesting about this project, as compared, say to nearly any other, is that simple changes are requested, that would take a very short time to implement

What I find interesting is how many people with no knowledge of the codebase know exactly what is simple and what is not.

Here we get "I don't wanna!"

No, if you'd bother to read the thread before writing your rant, you'd see that it is in fact not what you get (e.g. #1513 (comment) https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-952048965). It would be more constructive to react to what the other part actually says, not what you put into their mouth.

As a Software Architect of 4 decades of experience, I can tell you this wouldn't cut it in a professional environment. You would get requests from customers, they would go through review and be presented as things that the programmers need to implement.

Did you never reject a feature request in those 4 decades? What software you worked on and how many people used it? Isn't the main difference in the fact that the process is usually not public?

I would like a feature to be able to snap one part to another one

That's another feature request that we are aware of and considering. But I'm surprised that as a software architect with four decades of experience you only see the "I would like a feature" part.

The point of writing software is to make it as easy as possible for users to do exactly what THEY want to do.

They? There is quite of lot of PS users and each wants something else. But I'm just repeating what I have already written in the above post.

C++ has been pretty dead except for embedded programming I stopped using it in 1995 If I had the hours to spend on it, I'd think about a conversion to C# C# would compile in seconds it would be good to update the design don't bother trying to argue, and maybe the best solution is to spin off another Source Repo

To be honest, if you are seriously suggesting to rewrite everything into C# to cut down on compilation times, I'm struggling to believe your claims about being a software architect. Anyway, we are not porting PrusaSlicer to C# (there are reasons, imagine them as "we don't wanna" if you like). If you think it gives an advantage over the competition and it is a hole in the market, I wish you luck in filling it.

Regarding your last paragraph. The shocking revelation that modern C++ compilers optimize well is probably not surprising for people using C++ even after 1995. We are lucky that developers of compilers spend so much time on a language that is "pretty dead" for several decades. They also rolled some "minor" updates since then. But that is really off-topic.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-1088314161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6T32Z4VG4N7UKO2DIZ2QLVDPMHVANCNFSM4GMD77OQ . You are receiving this because you commented.Message ID: @.***>

-- G.Frank Paynter, PhD OSU ESL Research Scientist (ret) EM Workbench LLC 614 638-6749 (cell)

[bubnikv]

@paynterf

Please read my responses in this thread of what are the issues with enabling lifting the objects up.

Compilation on Windows could not be much simpler, just run build_win.bat.

[traderhut]

I read (most) of the thread, I did miss the above comment... I think I read 2017-2019 and skipped to late 2021/2022.. Didn't read the entire 5 years worth of the thread.

In reference to it being hard to implement - I had not see any of the comments (I read pages of them at the start, and read the ones at the end) that said, that it would be hard, and it does seem like it shouldn't be that hard - I did look through the source code briefly after making this post briefly, didn't have much time to look at it though and haven't found where it would be changed. And yeah, it is very possible that the design makes it challenging to update. (but it sure seems like one would have to add nn to all the z coordinates for all the points in that mesh (worst case) (Best case, the code already is designed with an object that has an offset.

It works if you create a stl file with at least one triangle at z=0, and a gap, and then the rest of it at z=whatever you want, so the approach of updating all the points would work as a brute force solution (assuming it doesn't have a design of the object having a z offset that already works), I did see something about doing an 'add part' as a solution

As for did I ever reject a change, sure, if it does in fact take too much effort, the don't wanna comments were 1. assuming that it was a simple change, which it appeared to be - the arguments I was hearing were not about it being hard, but about it not being a good thing to add. (Again, missed the post last October), And, to be fair, als thinking about the 'MessageBox()' call that would be required in order to do the other change - the popup asking if you want to reset settings, in any reasonable design, there would be a point where those settings are being loaded from the file, and before that is done, you would simply need an 'if' that checks the return value of a messagebox (or, other UI dialog, if you don't want to use a MessageBox API), and then don't load the values. (Ideally, of course, the best solution would be to show the values that are being changed, which there is already UI for, and ask if one wants to update it, but that is off this topic)

In reference to C++ being largely dead, OK, that was an overstatement, it has its uses (which I did say), doing Windows Apps isn't really one of them, but the app is already written, and it is a LOT of work to convert it... The major change to C# vs C++ comes in readability, and speed of adding changes. However, I agree that my statement was more out of frustration than anything... And also, what language to use is always a 'holy war' among developers.. Often for those who don't know a lot of languages (I know over 30 at this point) - which gives me a bit of a different perspective. There are advantages of C++, Often Speed is quoted as the top one (which is often wrong, as I proved once during a language selection board with 12 people, who started out 10 vs 2 wanting managed C++, and ended up 12 to 0 on C# when it was done... Guess who was one of the people suggesting C#? - All of the reasons to use C++ got shot down during the discussion, including test benchmarks that were written about various things that were 'slow' in C#... ) but no, clearly, it wouldn't be worth converting it to C#, there is too much code to make it worth the conversion... And for what it's worth, I stand corrected on the comment about conversion/C++

In reference to 'it is easy to compile, just run this batch file' - I posted a message about it not compiling when I did that, and someone responded with 'here is the script that I use to compile' and that script worked fantastic, and I got a good compile. No, every attempt at running the build_win.bat failed.

On top of that, the 'master' branch had a compile error, so I had to roll back to a previous commit in order to get it to build once I had a working script.

Once I had the script, and ran it, I was able to go into VS2019 and build it and that worked. The original script (build_win.bat) create a folder in the ..\ directory (the _deps folder) which was unexpected, I didn't expect it to leave the folder that the repo was fetched into, the new script doesn't do that, which I like a lot better. From what I can tell, the new script should replace the build_win.bat, but I'll leave that to the devs. (Who said they didn't expect people to run their script, they were using it as an example..)

[traderhut]

Also, I understand that there can be code that behaves weirdly due to assumptions that programmers make about objects. Who knows, maybe that is why in the test that I printed the infill didn't connect to the outside of the object? Because something was floating above it? Could be.

(But that is another bug report that I've not yet filed...)

[paynterf]

If allowing Z-axis moves is too difficult, then please at least make it obvious that moving in +Z is not possible, by graying out the Z-axis value and/or removing the visual Z-axis indicator from the plater view. If you indicate something is possible, but it really isn't, then you get a lot of angry users, as indicated by this thread.

If there is a new 'script for compilation for windows' available, that would be good news - I tried compiling with VS2022 and got nowhere; after several tries I gave up.

[traderhut]

I don't think the code is updated for 2022 yet, it compiles with VS 2019, and the other / new script also referenced 2019 directly

[paynterf]

@paynterf

Please read my responses in this thread of what are the issues with enabling lifting the objects up.

Compilation on Windows could not be much simpler, just run build_win.bat.

So much for that explanation. Apparently none of the devs are running anything past VS2019. If you expect us to believe what you write, you should be expected to believe what we write. I reported that I was unable to compile on my Win10 PC running VS2022, and you apparently didn't bother to read it. So, why should I believe you when you say "couldn't be simpler - just run build_win.bat"?

[lukasmatena]

@traderhut Just shortly. We have just created a manual page that summarizes everything that people don't have time to look for in this thread. It describes why "we don't wanna" "comment out code that forces the Z" and describes current workarounds. I believe that it will help in explaining the situation. You may not agree with everything, but maybe it will help to keep the discussion on topic and not run in circles.

C++ vs C# would definitely be an interesting and fruitful discussion, but it should not be done here. It is off-topic and irrelevant, PrusaSlicer is and will stay in C++.

The build script issues shall also be discussed elsewhere. I doubt that the issue reported in #8112 is caused by build_win.bat itself, but I don't have time to look into it now.

[traderhut]

For what it's worth, the batch file that worked for me, and didn't create a ..\PrusaSlicer_dep folder! is attached, however, there is a line of code -G .. that clearly is saying Visual Studio 16 2019, which I assume at the least, would have to be 17 2022 (guessing here),

Also, it is critical that this be in a folder: c:\dev to work

mkdir \Dev cd \dev (copy the file here) prusaSlicer_noob_build.bat

And it will build the project, or at least, it did for me... and the deps folder will be in the build\deps instead of ..\ where you would least expect it and you end up with a nice PrusaSlicer_Release folder that you can run it out of...

---- OK, uploading a bat file isn't supported, so I'm going to just paste it after this line

@echo off

REM ECHO I'm going to CLONE the PrusaSlicer repository - ready? REM ECHO Best, if you're curently in c:\dev (or similar short path) REM ECHO Also make sure you got at least 15 GB of free disk space available REM ECHO. REM ECHO Press CTRL+BREAK if you want to cancel. REM PAUSE REM ECHO Are you sure??? Shall I continue? REM PAUSE

git clone https://github.com/prusa3d/PrusaSlicer.git --recursive

cd PrusaSlicer SET "thisPATH=%CD%" echo Building in %thisPATH%

cd deps mkdir build cd build

cmake .. -G "Visual Studio 16 2019" -DDESTDIR="%thisPATH%"

REM This will take a loooong time! Go get some coffee... msbuild /m ALL_BUILD.vcxproj

cd "%thisPATH%" mkdir build cd build cmake .. -G "Visual Studio 16 2019" -DCMAKE_PREFIX_PATH="%thisPATH%\usr\local" -Wno-dev -Wno-error=deprecated

msbuild -ds -nologo PrusaSlicer.sln -t:rebuild -m -p:Configuration=Release -verbosity:normal

[traderhut]

(Messages crossed, script provided to help the person who couldn't get it to build, agreed- it is off topic for this thread)

[paynterf]

Your ' prusaSlicer_noob_build.bat' didn't work for me - it dl'd the files ok, but then just quit. No clue what screwed up.

Frank

On Tue, Apr 5, 2022 at 4:46 PM traderhut @.***> wrote:

(Messages crossed, script provided to help the person who couldn't get it to build, agreed- it is off topic for this thread)

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/1513#issuecomment-1089325630, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6T32ZSFVGVB3WYAVRSM43VDSRCDANCNFSM4GMD77OQ . You are receiving this because you commented.Message ID: @.***>

-- G.Frank Paynter, PhD OSU ESL Research Scientist (ret) EM Workbench LLC 614 638-6749 (cell)

[TomaszSzt]

I would like to add my grain of salt to this discussion.

Example task which needs Z-move upwards

I was trying to print a part which is made of a large block with some tiny regions which needs to be hell accurate (0,05 layer height). I did prepare a model made of some separate, closed volumes representing a main block and those regions and then exported it as a single STL file. I did import it to slicer.

Up to that moment everything went ok.

Then I split it to PARTS.

And here is the problem. You can't assign different layer heights to different PARTS of the same OBJECT. The reason behind it is reasonable and the same as for a lack of "mesh layer height modifier". I do understand that.

I thought then: fine, no problem, I can use height range modifier on separate OBJECTS to make them print with different layer height. It is enough to have those objects in right places, right?

Thinking like that I did split it to OBJECTS and then and all the parts representing those small accurate regions dropped to the bed.

Fine, I can lift them up....

It looks that I can't, they always kept dropping down even tough I was allowed to move them up. It was hell confusing, so I looked and looked and could not find any option to disable it, even tough there is an icon in right down corner close to "Z" coordinate of an object telling to drop it or, I supposed, to not drop it.

So I had to find a way to "cheat" the program.

Cheating and working around the limitations

The work around was to add a 0,1mm diameter "support sticks" to the meshes representing regions I need to be accurate. Those sticks do start at zero and are up to the detailed region so the detailed regions do have a proper height. The 0,1 diameter is not printable so I thought I would be now at home because object will be "supported" at right height and with disabled auto-centering it will stay at correct location.

Except the error "There is no extrusion at zero layer" which prevented code generation.

So I had to add at the zero level a one layer thick tiny blob to print.

Fine, no problem with that.

Now I can generate G-Code and up to now it looks right.

Of course there are problems with supports and some collisions at a build plate, but my model is not using any supports and I did took care to make them in right size and at a right place.

I did not print this part yet, but from results on screen I can't see any fault in it. I suspect, that the those regions may not "stick together" to main block very well, but I will give it a try.

I suppose this is a legitimate reason why Z-move upwards in the air and disabling auto-drop on a bed should be allowed.

Enhancement request

Please re-consider to let an expert-mode to have options:

• "Configuration->Preferences->Disable Auto drop on bed" and
• "Configuration->Preferences->Allow free Z movement of objects"

and have added from Super Slicer expert mode:

• "Print Settings -> ....-> Allow empty layers"

Keep up good work, this is a superior software anyway.

Version: 2.4.1+win64 Build: PrusaSlicer-2.4.1+win64-202203101054

[gargan26]

Can someone PLEASE fix this stupid problem already? Sheesh!

[estrangedwrenches]

I posted here on this thread awhile ago and haven't tried it again since but probably still works:

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._

[FkYeahScience]

what is the status on this issue?

My issue is that with Arachne I cannot use "perimeters loop" feature, I like to use it for first layer with very fine details in XY (<1mm extrusions)

The options to solve this would be: A) 'fix' (?) Arachne to be able to use "perimeters loop" (as a height range modifier) B) add "Arachne perimeter generator" / "no Arachne perimeter generator" to "height range modifier" options C) cut the part at the deisred height, stack them at same XY at desired height with the desired options from @TomaszSzt

BUT @estrangedwrenches method does NOT work for this application

best regards,

thank you for your amazing work

[GithubUser99999999]

After so many years, this is still a problem. Why can't we just stack objects on top of each other ffs. So infuriating...

[pyro9]

I just posted a draft pull request #11452 that makes everything float. You can still put an object on the bed by clicking the "Drop to bed" button for the object

It may need PR #11299 that makes exceptions about an object with no extrusions on layer 0 into a warning.

[Dweinbach]

I've read this thread, and I am amazed that the inability to move an object it the Z axis is being (a) defended on theoretical grounds and (b) defended as "too hard" to implement.

Let's dispense with (b) first - it is ALREADY implemented -in the sense you CAN move the object in the Z plane, and it renders as such - but when you release the mouse it "snaps" back to ground. so no code is required to allow the move - just need the the ability to toggle that snap feature - perhaps some coding is required on the slicing soide - but I'm skeptical. We just need a "keep the nanny out of it" feature. kind of like when you have snap to grid on a drawing program, there is usually a way to override it temporarily (shift key or whatever).

More surprising to me is the "theoretical basis"argument, which is bunk. Many in this thread have already de-bunked it with examples, but here is mine (a real part for a model airplane):

The assembly consists of the hub, ring, and qty 3 arms. So there are 3 STL's, but I need three of Arm.stl. When I import the 3 STL's as parts of an assembly, everything is positioned correctly. But when I import the Arm.stl again as shown, I cannot raise it up into position.

Obviously, this would need supports regardless of orientation, but why won't PS allow me to position and slice it so supports can be generated?

[GithubUser99999999]

The easy go-to workaround is to group objects in PrusaSlicer by using "add part" and then loading all the sub-parts of a print. This way you can stack stuff and adjust z-height as you wish.

[filcuk]

I often need to slice an object in half to then scale only one side (e.g. a duct with a base). The current workflow is:

1. Slice object to parts
2. Duplicate object
3. Remove base part in the duplicate
4. Export as stl
5. Remove duplicate object
6. Import stl as new part on original object
7. Align imported part to the original object x & y
8. Finally enter the wanted z pos & scale

Really hoping that pull request gets some attention :)