Jump to content

Feature Request: Z-OffSet (Post-Process?)


AbeFM

Recommended Posts

Posted · Feature Request: Z-OffSet (Post-Process?)

Oftentimes I'll have an issue high up on a print - and want to test it. I can drop the part into the bed, but often this will change the fill and crucially the supports.

 

I would like to have a post-processing step which takes the finished model, and subtracts a uniform Z-value from the whole gcode, and cuts out all the lines which are now below the bed.

 

image.thumb.png.4ebfeaacd4c3ea1900bcdef815d297f7.png

 

I know this isn't a great example, but you can see how the supports are different left to right (ignore the circle). It's the same parts, merely translated in Z, and I get different support. This is more of an issue with gradual infills, etc, where things going on down below effect what is above.

 

Not sure if I'm explaining it well, but it seems like you could just keep the set up, delete all lines till z = z_requested, then subtract z_requested from all z's - or something similar

  • Link to post
    Share on other sites

    Posted · Feature Request: Z-OffSet (Post-Process?)

    As OP says, that changes the layers. OP does not want an initial layer, bottom layers or anything, but exactly the stack of layers from a certain height.

     

    A plugin could be created that does that, but I wonder how usefull it would be; bed adhesion would be horrible.

  • Link to post
    Share on other sites

    Posted · Feature Request: Z-OffSet (Post-Process?)
    On 2/25/2018 at 1:27 AM, ahoeben said:

    A plugin could be created that does that, but I wonder how usefull it would be; bed adhesion would be horrible.

    Yeah, I was thinking that same thing. I still think it would be a learning tool, but I think a reasonable compromise would be a raft, then as described.

     

  • Link to post
    Share on other sites

    Posted · Feature Request: Z-OffSet (Post-Process?)

    Ah, but adding a raft would make the plugin/script a whole lot more complex, because it would need to analyse the new first layer and create a raft from that "geometry". Rafts are normally created in CuraEngine (written in C++), and plugins/scripts are written in Python. So the code to create a raft cannot just be copied, but needs to be reimplemented from scratch.

  • Link to post
    Share on other sites

    Posted · Feature Request: Z-OffSet (Post-Process?)

    I could live with the raft that would normally be generated, but the only big place I need it is tracking down the weird slicing issues I see (missing lines, blobs, etc).

     

    Really is that gets fixed, I admit, maybe it's just not worth doing. :-)

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • Introducing the UltiMaker Factor 4
        We are happy to announce the next evolution in the UltiMaker 3D printer lineup: the UltiMaker Factor 4 industrial-grade 3D printer, designed to take manufacturing to new levels of efficiency and reliability. Factor 4 is an end-to-end 3D printing solution for light industrial applications
          • Thanks
          • Like
        • 3 replies
      • UltiMaker Cura 5.7 stable released
        Cura 5.7 is here and it brings a handy new workflow improvement when using Thingiverse and Cura together, as well as additional capabilities for Method series printers, and a powerful way of sharing print settings using new printer-agnostic project files! Read on to find out about all of these improvements and more. 
         
          • Like
        • 26 replies
    ×
    ×
    • Create New...