Jump to content

curasurf

Member
  • Posts

    153
  • Joined

  • Last visited

Posts posted by curasurf

  1. 30 minutes ago, nallath said:

    As far as I know a 60deg overhang is perfectly printable on an S3.

     

    @nallath   According to the recommended profile Ultimaker S3 / PLA 0.4 nozzle / Draft Fast 0.2mm, the picture would be:

     

    Layer height = 0.2 mm

    Line width = 0.4 mm

    Overhang angle = 60°

     

    Do you think it's ok?

    Image.png

  2. Hi @nallath   There seems to be no Z hoppig throughout the model. Thank you for your comment! 

     

    I just tested a simple cylinder, and also no Z hopping. It seems that Z hop does not work.

    Image.png

     

    @fvrmr Could you have a look at this issue? You can simply slice a simple cylinder to see whether it's possible to observe Z hopping. Thank you!

  3. I studied the recommended Cura profile of Ultimaer S3 / PLA 0.4 nozzle / Draft Fast 0.2mm:

                           Layer height: 0.2 mm

          Outer Wall Line Width: 0.4 mm

    Support Overhang Angle: 60°

     

    To my supprise, Support Overhang Angle is NOT a calculated value!

     

    My printer is Creality CR-10sp. In all its profiles Support Overhang Angle is calculated from a formula. My experiments also show that the formula is a sound choice. According to this formula, the Support Overhang Angle for the Ultimaer S3 profile should be calculated as:

     

    • Support Overhang Angle = atan(0.4×50% ÷ 0.2) ÷ 3.14159 × 180 = 45°

     

    So the recommended angle 60° for Ultimaer S3 would surely lead to failure. Hope to know what you think about this. Thank you!

     

  4. Because I often see retractions spending as high as 30% of print time, I try to understand why retractions happen.

     

    In the example below, A/B/C/D are 4  major travel moves (in the order of A >>> B >>> C >>> D) on layer 5. But only C is retracted. Why are A/B/D not retracted?

     

    Some clues, even very brief ones, are appreciated!

    Image.png

    Image.png

    ttt.3mf

  5. 1 minute ago, ctbeke said:

    Anyways, Cura is open source, so if you have ideas and/or abilities to write something that could solve this (for either modifier meshes or adaptive layers), feel free to do so!

     

    I believe that Adaptive Layers is a great idea. It automates and perfects the manual approach based on modifier meshes. It's absolutely a great idea. Thank you!

  6. 3 minutes ago, ctbeke said:

     

    The extruder motor (E values in G-code) only determines the speed component of that equation (again, this is the one with the physical delays caused by the distance between extruder motor and hot-end). 

     

    I'm sorry to say that I can't agree with you. I'm afraid that you have some misunderstanding about the extruder and the flow rate. If this is offending, I feel deeply sorry. Thank you!

  7. 14 minutes ago, ctbeke said:

    I'm not sure, I'm only reporting on what I experienced during testing. However I can imagine that because height, width and speed are implemented by different parts of the mechanical system, these 3 never align as perfectly as you want them. For example layer height has a very direct result (just move the Z-axis up), but speed has that delay between moving the extruder motor vs the actual extrusion at the hot-end caused by the physical distance between those two components. So all combined it's just a complex system that is hard to capture in a mathematical model that can be used to 'predict' the needed flow. Again, theory vs real-world conditions don't match up here.

     

    I'm sorry to say that I can't agree with you. In my rooted understanding, the command sent to the extruder is only the flow rate (height * width * speed), not the height alone, not the width alone, not the speed alone, but their product --- the flow rate. If I set it as Setting 1 and Setting 2 above, the extruder would operate under constant condition.

     

    The speed might have delay, and the width and the height might not be as the gcodes told, but the signals are definite. The signal received by the extruder is not based on the real speed/height/width, but based the clear message of gcode. If the signal to extruder changes, the extruder would have some delay in response, but if the signal is constant, the extruder works constantly.

     

    Anyway, thank you for your patience!

  8. 9 minutes ago, ctbeke said:

    So in a perfect world with no friction inside bowden tubes etc (and many other physics laws), the settings above would work. But in practice you always have that delay and you get visual artifacts in your printed part.

     

    I'm sorry to argue more, because this is related to my fundamental understanding of the fusion printing process.

     

    In my understanding, the extruder works ONLY on the FLOW RATE (=height*width*speed). If the flow rate is kept constant, the extruder would ALWAYS work in thhe same condition, completely NO delay, NO change. Is this not correct?

  9. @ctbeke  It seems that you didnot understand what I meant.  I mean, in changing from setting 1 to settign 2 (below), there should be no flow rate variation and so no extruder delay. Is this correct?

     

    Setting 1

    Layer Height = 0.3 mm

    Line Width = 0.4 mm

    Speed = 50 mm/s

    (Flow rate = 0.3*0.4*50 = 6 mm³/s)

     

    Setting 2

    Layer Height = 0.2 mm

    Line Width = 0.5 mm

    Speed = 60 mm/s

    (Flow rate = 0.2*0.5*60 = 6 mm³/s)

     

    If you are talking about the nozzle speed delay, then yes there can be some delay, but the speed delay seems to be trivial when compared to the extrusion delay.

  10. 33 minutes ago, ctbeke said:

    to me it seems in order to get a clean print when changing the layer height, you still want a consistent line width (otherwise you get 'banding'). To achieve this, when reducing the layer height, you want to extrude less material, so a lower flow rate.

     

    Don't you think it's good enough to increase the layer height while keeping ( height * width * speed = FLOW RATE) constant? Thank you!

  11. 52 minutes ago, nallath said:

    If you merge models the origin is set to be the same.

     

    Hi @nallath

     

    Two years ago, when I played with Cura to see how to position STL models, I found the workaround you mentioned. Merging two models can restore their relative positions, but as whole, the new group still forgets its original position. This is really very dissappointing.

     

    I never tried 3mf and obj files, because my modelling software does not export those formats.

     

    Anyway, thank you!

     

    And another thing again:

     

    When Cura command line is used to import an STL model, the models in current Cura window are LOST. This makes all the plugins for Cura to work with modelling softwares almost useless. Hope it can be fixed. In my personal opinion, it should be a very small project. (I might be wrong.) Thank you!

  12. 3 minutes ago, Smithy said:

    But there is a second way, the way you showed in your initial post:

     

    Don't use the tag, use the "Item prefix" below. But I am not sure if you can do it. But you can try if you edit your first posting, then you should get that screen.

     

     

    No, I can't do it.

     

    In most forums, only the original author can mark a post as solved. Here only "special" (?) user, but not the author, can mark a post as solved. This is a weird rule.

    Image.png

×
×
  • Create New...