Jump to content
UltiMaker Community of 3D Printing Experts

Oddities when slicing for vase mode


Bracer
 Share

Recommended Posts

Posted · Oddities when slicing for vase mode

Hi all, scratching my head on this one and was hoping others might have seen the same (and have an easy solution!)

 

Using the same settings in cura 4.0 when printing in vase mode (spiralize..) I get different results on different models but don't understand why.  The attached pics show the difference in smoothness - the first is a low polly skull and the second was a start of a vase.  The only thing I've noticed is that the ones that don't work come out as much larger file sizes and (even though cura says e.g 2 hour print time), octoprint will start and say something like 12 hours.  When printing it sounds like the printer is making loads of little steps that ultimately create the unwanted texture you can see in the second pic.  Slicer settings are not changed between the two prints (other than on this occasion I tried the 'surface mode only' setting to see if it fixed the problem but clearly didn't.  I've tried rotating the models and reslicing and turning on and off other options but I still can't figure out why one prints fine and the other doesn't.  It happens randomly with models (not just this one) so I've had to start looking at the file size before I upload otherwise I know I'll get a poor print.

 

Any ideas?

20190414_123420.jpg

20190414_123437.jpg

Spiralvase2SurfaceModeandSpiral.gcode

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode

    You didn't say what printer you have, but I'm guessing a hardware problem and not a problem with the settings. Check if all your axes are ok, have no play and are slightly oiled.

     

    It's hard to see on the photo, but I don't think it's under extrusion, or do you have holes in it?

     

    What might also help is to print slower.

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode

    Hi Smithy - thanks for your reply.  The printer is a CR10S-Mini running the stock firmware. I think it's unlikely to be a hardware problem as other prints all come out fine (as do many of the vase mode models I've done).  There is a huge discrepancy between file sizes on prints that come out as expected and those that don't - the second picture model is very rough to the touch, almost like it is trying to fill a space rather than create a single shell.  Typically those that print properly will be a few hundred kb in size but those that don't will be eg. 20mb which is why I suspect slicer issues over hardware (I did do some maintenance on the printer last night to be as sure as I could be about it).  It's difficult to explain, but the print head sounds like its making a lot of micro-movements in a print like in the second picture, but will move smoothly in a successful print like the first picture.  

     

     

     

     

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode

    Can you try to print the same object which is not working, without vase mode? Just to see how it behaves. A few layers are enough, just to see if there is a difference. And maybe you can upload the STL here, then we can cross check it. 

     

    When you have sliced the object and check it in layer view, do you see any similar issues there?

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode

    I *think* I may have found a possible reason..

    I decided to limit the toolchain as much as possible so put the gcode directly onto the sd card rather than upload via octoprint - my printer seems to be happily vasing the mode 🙂

    I'm guessing it's possible that there is either a conversion or corruption of some kind happening when it uploads remotely if it's over a certain size.  I'm using a file that I've not used before so will go back to one that didn't work previously in a couple of hours when this is done and confirm or deny..

    Layer view always looked clean when I had checked it in the past, this was one of the head scratchers that was confusing me..

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode

    So after running a few tests, it does appear that octoprint is the culprit.  The same files on the sd card vs uploaded remotely have massive differences how the printer actually prints the model.  Thanks for you replies Smithy, appreciate the quick responses - figured I'd update this incase anyone else has a similar issue in the future.  Right, off to the octoprint forums!

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode

    Thanks for the feedback!

    I am not really using Octoprint, just tested it some time ago, but I heard that USB cables and/or the performance of your Raspberry (or whatever you use) can make a huge difference. So, for example, a Raspi Zero will work but not always because it can be too slow sometimes. Just a hint, if you want to dive deeper in your issue.

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode
    On 4/15/2019 at 3:22 AM, Bracer said:

    So after running a few tests, it does appear that octoprint is the culprit.  The same files on the sd card vs uploaded remotely have massive differences how the printer actually prints the model.  Thanks for you replies Smithy, appreciate the quick responses - figured I'd update this incase anyone else has a similar issue in the future.  Right, off to the octoprint forums!

    Did you ever figure out WHY Octoprint was corrupting it, and what it was doing?

     

    This would be really vital information. A lot of us could have such problems and not know it.

  • Link to post
    Share on other sites

    Posted · Oddities when slicing for vase mode

    Hey All,

    I had to ask around a little since I'm not familiar with using Octoprint but I believe this behavior is more likely to be related to settings in the slicer.  If the segments per second is too high there will be buffer underrun. To improve this you'll have to tweak the Maximum Resolution.

    Other causes for this behavior could be:
    A. Using a Rasperry Pi that has outdated hardware (For example a first gen RPi0w)
    B. Faulty cabeling (please keep an eye out for transparent blue ones) 

  • 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
     Share

    • Our picks

      • Here it is. The new UltiMaker S7
        The UltiMaker S7 is built on the success of the UltiMaker S5 and its design decisions were heavily based on feedback from customers.
         
         
        So what’s new?
        The obvious change is the S7’s height. It now includes an integrated Air Manager. This filters the exhaust air of every print and also improves build temperature stability. To further enclose the build chamber the S7 only has one magnetically latched door.
         
        The build stack has also been completely redesigned. A PEI-coated flexible steel build plate makes a big difference to productivity. Not only do you not need tools to pop a printed part off. But we also don’t recommend using or adhesion structures for UltiMaker materials (except PC, because...it’s PC). Along with that, 4 pins and 25 magnets make it easy to replace the flex plate perfectly – even with one hand.
         
        The re-engineered print head has an inductive sensor which reduces noise when probing the build plate. This effectively makes it much harder to not achieve a perfect first layer, improving overall print success. We also reversed the front fan direction (fewer plastic hairs, less maintenance), made the print core door magnets stronger, and add a sensor that helps avoid flooding.
         

         
        The UltiMaker S7 also includes quality of life improvements:
        Reliable bed tilt compensation (no more thumbscrews) 2.4 and 5 GHz Wi-Fi A 1080p camera (mounted higher for a better view) Compatibility with 280+ Marketplace materials Compatibility with S5 project files (no reslicing needed) And a whole lot more  
        Curious to see the S7 in action?
        We’re hosting a free tech demo on February 7.
        It will be live and you can ask any questions to our CTO, Miguel Calvo.
        Register here for the Webinar
          • Like
        • 13 replies
      • UltiMaker Cura 5.3.0-Alpha 🎄 Tree Support Spotlight 🎄
        Are you a fan of tree support, but dislike the removal process and the amount of filament it uses? Then we would like to invite you to try this special release of UltiMaker Cura. Brought to you by our special community contributor @thomasrahm
         
        We generated a special version of Cura 5.2 called 5.3.0 Alpha + Xmas. The only changes we introduced compared to UltiMaker Cura 5.2.1 are those which are needed for the new supports. So keep in mind, this is not a sneak peek for Cura 5.3 (there are some really cool new features coming up) but a spotlight release highlighting this new version of tree supports.  
          • Like
        • 17 replies
      • New here? Get ahead with a free onboarding course
        Hi,
         
        Often getting started is the most difficult part of any process. A good start sets you up for success and saves you time and energy that could be spent elsewhere. That is why we have a onboarding course ready for
        Ultimaker S5 Pro Bundle, Ultimaker S5, Ultimaker S3 Ultimaker 2+ Connect.   
        They're ready for you on the Ultimaker Academy platform. All you need to do to gain access is to register your product to gain free access. 
        Ready? Register your product here in just 60 seconds.
          • Like
        • 14 replies
    ×
    ×
    • Create New...