Jump to content

burtoogle

Expert
  • Posts

    1,529
  • Joined

  • Last visited

  • Days Won

    19

Posts posted by burtoogle

  1. 27 minutes ago, DivideByZero said:

    Ah, so even if a setting is not visible, it could still be doing something in the background - you just can't see the values.

     

    Correct.

     

    27 minutes ago, DivideByZero said:

    Is there a way to reset all the values to their defaults? Or is it a case of uninstall / re-install?

     

    Not sure that an uninstall will actually remove your settings. Someone who knows the Cura front end better than me needs to answer your question. It does seem somewhat of an omission that there isn't a "reset profile to defaults" option.

    • Like 1
  2. 16 minutes ago, DivideByZero said:

    If a setting is not visible, is it not in use? Or does it just run at the Cura default?

     

    No, a setting's visibility has no effect on whether it is used or not by Cura. All the settings have a default value which may or may not be suitable for a given print job.

    • Like 1
  3. Looking at the Kisslicer gcode, a big difference is that it generates a few layers of denser infill above the honeycomb which will support the skins better. By contrast, the Cura project you provided is using very low density gyroid infill which doesn't provide any support around a lot of the edges of the skin.

     

    Here's a suggestion for you to try, set the Extra Skin Wall Count to 0 and the Extra Infill Wall Count to 1. This will ensure that the skin lines will have something below them when they reach the walls and they may be able to grip that sufficiently to stop shrinking back which is what is happening.

     

     

    Screenshot_2019-02-22_20-56-15.png

  4. In your profile, the top surface skin speed is still 27.5 but the top/bottom speed is 15. Did you actually try the slower speed for the top layer?

    Screenshot_2019-02-21_08-07-31.png.c0adf389e27e67eb444e6100cfc07fb5.png

     

    Could you please attach the gcode created by the other slicer that prints OK, I would like to see what the difference is. Thanks.

     

  5. I think it may be possible to compile the back end (CuraEngine) for a 32bit architecture because when I started building releases I mistakenly compiled the Windows CuraEngine using the 32bit compiler and it seemed to work just fine. but I don't think the front end UI (Cura) can be built for a 32 bit machine.

  6. Thanks for the file. I see what you are saying. Well, that's the normal Cura behaviour. It always prints a part's outside walls in a CCW direction and prints the walls for the part's holes in a CW direction. There's nothing you can do to change that. The slicer could be changed to print all walls in the same direction and this has been discussed recently elsewhere. For most parts it doesn't make any difference but I can see for parts that have no infill between the outer walls and the walls around a single hole (i.e. a tube like your example) it would make sense to print all the walls in the same direction.

  7. 8 hours ago, joestefano said:

    What is the proper way to stay current with your Master version? Should the old version be uninstalled first?

    Is there anywhere that shows the version number? About Cura?

     

    The Linux AppImages are self contained and don't actually install the files release files anywhere.

     

    Configuration files are created when Cura is run and those should be compatible between releases although because my releases are based on the master branch it is always possible that the Ultimaker devs will have made some change to the configuration part of Cura that causes any existing configuration files to be incompatible or broken. It's always a good idea to keep a copy of you configuration just in case you have a problem. I keep all of my Cura configuration files in a .git repo and every now and again I commit a snapshot so that I can always get back to a previous working configuration if the new Cura has broken it.

     

    I don't use Windows so I don't know if my WIndows releases can be installed on top of a previous release. Perhaps a WIndows user could comment on this?

     

    There isn't anywhere in the UI that shows the version number but the last couple of releases include a comment in the gcode that shows the release date.

  8. Well, the model maybe looks uniform in cross section but, in reality, because it's made from lots of triangles, the shapes of the polygons that define where the walls, infill, etc. go varies with height. It only needs a small variation in outline to sometimes produce quite a different print.

     

    Here's an image showing a few of the triangles in your model...

     

    Screenshot_2019-02-14_15-55-18.thumb.png.06dbb3c3ce2f4cadcdb83fcddc606bde.png

  9. I think the problem is simply that what looks like a smooth curved edge to the naked eye can actually have very sharp corners and so one of those tiny (but sharp) corners gets chosen to be the sharpest corner in a given outline rather than the corner you were hoping it would chose.

  10. 1 hour ago, Link said:

    Are you aware of the sharpest corner issue being fixed ?

     

    Not sure what you mean there. I'm not aware of there being an open issue on github related to the sharpest corner z-seam method.

     

    It's probably working as intended and the real issue is that the sharpest corner on each layer of your model does not occur in the same x/y position. It only really works satisfactorily when the model is suitable (no tiny jagged edges and a uniquely identifiable corner). Perhaps it would work better if the outline was smoothed?

  11. 28 minutes ago, Link said:

    When you set the seam to user specified do you leave it to the default location it picks, rather than actually type co ordinates in ?

     

    I normally need to change the x/y values to steer the seam to where I want it. In this particular instance, the seam was positioned OK with the existing x/y values.

     

    Incidentally, I usually check the Z Seam Relative box and then the x/y values are treated as offsets from the centre of the part's bounding box.

     

    • Like 1
  12. Hi @Link, there's a few changes I would recommend:

     

    1 - don't use the sharpest corner z-seam flavour - it rarely does what you want. Better would be to go for user-specified as this will tend to lock the z-seam into a corner.

     

    2 - using an infill wall is OK but it looks like a bug that it always starts in the same location and doesn't match up with the z-seam of the walls. Personally, I never use an infill wall count > 0.

     

    3 - I think the gyroid infill will produce better results for this model, I normally use the connect infill lines option which kinda gives you an infill wall that covers 50% of the infill perimeter. You could probably reduce the infill density to 10% and still have a stronger print than using the grid infill.

     

    This picture shows the settings I changed. Hope this helps!

     

    Screenshot_2019-02-13_11-35-19.thumb.png.b42d6eb189d74f433dc9a8f30c218263.png

×
×
  • Create New...