Jump to content

Cura - Bug and a question about printing resolution


janosch

Recommended Posts

Posted · Cura - Bug and a question about printing resolution

Hi

I am trying to print the Eiffel Tower - which is still teaching me a lot about my Ultimaker and CURA / NetFabb.

Several things:

How is CURA deciding what it will print, and what is left out.

Is there any option to define a minimum detail / line length?

Printing the eiffel tower at 100% will lead to failed structure in the upper part,

printing in about 165% (="scale object to machine size") the part below the third platform will be left out. because the structures below are too small.

Unfortunately my Ultimaker has no anti gravity switch - so the print will fail

My issue is, that I would print small structures ?

How is Cura deciding what to print and what to leave out?

Could this threshold be set manually ("minimum detail") or automatically (e.g. half of the nozzle size)

Would it even make sense make sense to emphasize these little details to nozzle size?

Without it you won't be able to print the Eiffel Tower in one part because it has structures finer than the print resolution of CURA / netFabb. (it is already loosing a lot of the inner structures)

Is there any way to define it

(or do you have a hint, (in which module) I would be able to hack it ?)

Ultimaker_Original_Plus_iGo3D_1.thumb.jpg.b76266d3f699b7c2ff91609db1f6f706.jpg

Cooling:

It would be great, if the nozzle would be moved away (e.g. mm to the top) from the object while it should cool

If not, the plastic would not cool and the nozzle is moving the still liquid struchture.

Bug - (or feature:)

I am receiving this error messages a lot.

You can reproduce it by pressing "Slice to Gcode" once from the included STL file.

I receive a lot of the following error messages_

IndexError: list index out of range

Traceback (most recent call last):

File "C:\Program Files\Cura_RC3\Cura\gui\preview3d.py", line 427, in OnPaint glTranslate(0,0,-self.parent.gcode.layerList[self.parent.layerSpin.GetValue()][0].list[-1].z)

Are these errors being generated when there empty layers - when there is nothing to print on this layer?

Could this be used to generate a warning - that you are printing something with totally empty layers in between. (at least with one material - without support structures?)

Ultimaker_Original_Plus_iGo3D_2.thumb.jpg.bd764d65f8c39c9c8e6bb08ddd91d3c1.jpg

The original Eiffeltower file is from http://www.thingiverse.com/thing:22051

Thanks,

Janosch

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution

    Because of the limit of three attachments I am using a reply to post another pictures:

    - needed for a better understanding of the upper questions.

    (the print was not optimized for anti-stringing)

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution

    Parts smaller then the line size are lost. It's impossible to make something 0.36mm thick with 0.4mm lines (0.4mm lines are default)

    What you could try, is to set the "wall thickness" to 0.6mm, and the nozzle size to 0.3mm instead of the default 0.4. This tricks Cura in putting down 0.3mm lines. However, this is quite hard for a 0.4mm nozzle and the results might not be pretty.

    As for the cooling problem, in the expert settings there is a setting called "minimal feed rate", set this a bit faster. What is happening is not that the printer stops to wait for cooling, but it slows down. However, it slows down so much that it goes to a crawl. The minimal feedrate is intended to protect against this, however the default of 5mm/s might not be fast enough in your case.

    You can also adjust the minimal layer time so it spends less time printing each layer and waiting for cooldown.

    I've added a fix for the error message in the dev version. It happens if you select a layer which doesn't have any GCode in it.

    I wouldn't recommend trying to hack the GCode generator (Skeinforge), as you will lose your sanity.

    Final note, printing things like this really pushes the printer to it's limits.

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution
    Parts smaller then the line size are lost. It's impossible to make something 0.36mm thick with 0.4mm lines (0.4mm lines are default). What you could try, is to set the "wall thickness" to 0.6mm, and the nozzle size to 0.3mm instead of the default 0.4. This tricks Cura in putting down 0.3mm lines. However, this is quite hard for a 0.4mm nozzle and the results might not be pretty.

    This is the part that I don't understand. We've got this wonderful present of precise volumetric extrusion (marlin and all slicers except netfabb), but cura is putting this severe "handbrake" on this model by limiting how narrow/wide the extrusion can be. saying that nothing can be smaller than the nozzle diameter is wrong IMO, because netfabb is perfectly capable to make a 0.2mm extrusion from a 0.4mm nozzle, it's just a matter of pushing a bit less plastic through the nozzle per sec, not really a physical requirement. the same goes for the other direction, and this includes also the mysterious infill routines of SF (underextruded infill).

    It does compare to the screw drivers in your tool box. in the cura tool box you have only 2 flat screw drivers: medium and medium-big... and doing watch repair with a medium screw driver is impossible.

    yes, one way to trick cura is faking the nozzle diameter (simply enter 0.2 or even 0.15mm nozzle, and it'll produce fine details (within limitations, and lower print speed)

    I think it would be great if cura/SF would extend the great resolution it already is producing in the XYZ dimensions to the E dimension, and offer some more modulation of the extruded width.

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution

    SF does not under-extrude infill. The GCode preview of Cura clearly shows that it wants to put down enough material.

    See this result:

    http://daid.eu/~daid/IMG_20120429_152851.jpg

    The red parts (the white parts are no good, because that extruder was blocking up). It's almost a perfect infill, just a slight under-extrusion, which is expected, as my "100mm" test comes out as 97mm, and material was lost due to oozing.

    As for your "watch repair" compare, SF was designed for the crude early RepRap machines. The fact that it can do what we are doing with it is a wonder on itself. We've adjusted a sledge hammer for car repair, not bad really.

    "Dynamic line width" goes against every design aspect of SF. It would be quicker and better to make a new slicer then. Note, question is a variation of the "thin walls are not filled properly" question. Yes, it's not right, but changing it is not a simple thing.

    I still think printing less then 0.4mm lines with a 0.4mm nozzle is a bad idea, because it reduces your X/Y resolution.

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution
    SF does not under-extrude infill. The GCode preview of Cura clearly shows that it wants to put down enough material.

    We are talking about 2 different things. Solid infill (aka solid layers, or up/down skins) are indeed not under-extruded, but have the proper extrusion rate (assuming you have enough layers and material underneath to actually form a proper up-skin).

    I was referring to regular infill, the fluffy mess that offers no structural support in any direction, when printed a hair to fast, together with the fact that SF and you are insisting that there is no other line width possible than nozzle diameter (compared to the 5 different extrusion diameters netfabb offers, and even compared to the pretty awesome grid and hex infill SF/cura can do) - yes, I do know that SF infill is voodoo, but you did such a great job with cura that I don't see no reason why you couldn't tackle that problem also. (slic3r has the same structurally insufficient infill, but alex doesn't see this as an issue, even though he knows his code and could fix it).

     

    "Dynamic line width" goes against every design aspect of SF. It would be quicker and better to make a new slicer then. Note, question is a variation of the "thin walls are not filled properly" question. Yes, it's not right, but changing it is not a simple thing.

    I think I used the wrong word, "dynamic" might not describe what I wanted to say... customizable, in a netfabb fashion, would be great (which goes back to my initial feedback for cura a while ago, to offer a extrusion width for the regular infill)... but adding a dynamic line width component to the SF code for narrow/small spots would be great, instead of simply discarding a feature by "rounding it off". In (my) theory it doesn't require a new slicer, just a better "rounding" algorithm in the outline.py, to gracefully handle small parts by utilizing thinner extrusions.

     

    As for your "watch repair" compare, SF was designed for the crude early RepRap machines. The fact that it can do what we are doing with it is a wonder on itself. We've adjusted a sledge hammer for car repair, not bad really.

    Yes, that is true, but there is no reason to dwell on the past (you did a great job with cura), but it's time to look into the future, and see how we can make it better.

     

    I still think printing less then 0.4mm lines with a 0.4mm nozzle is a bad idea, because it reduces your X/Y resolution.

    why is that such a bad idea? we know it's possible. I think the slight loss of XY resolution due to some jitter in a i.e. 0.2mm extrusion width (say if it would vary from 0.17-0.23mm), is far more tolerable than loosing a feature because cura/SF is rounding it away (i.e. a small feature that is 0.5mm thick doesn't show up in the tool path anymore because with a 0.5mm nozzle setting it is below the threshold). it would be so easy for cura/SF to just use 2*0.25mm temporarily to make that 0.5mm wall, instead of just ignoring it completely.

    My question is: within SF (outline.py, or however it's called), instead of taking the nozzle/extrusion diameter as a fixed and unchangeable parameter, how about the section that determines how many outlines are printed, would be able to divide the extrusion width in half or 1/4?

    taking the example above (0.5mm nozzle), a part is 5mm wide, and then thins down to 1mm, and then down to 0.5mm (i.e. the panel mount for a headphone jack). SF/cura would start with 2 outlines (to make a 1mm wall on each side) plus some regular infill (3mm wide), then make 2*0.5mm outlines to make the 1mm wide section, and when it encounters a modulus=0 situation (width <= nozzle/extrusion), it simply cuts the extrusion width in half and renders the 0.5mm wide section as 2*0.25mm, which would print just beautifully. in theory it should be possible to go to a quarter, but that is speculative, and would require some real-world testing, but I don't want to dismiss it.

    This code change should get rid of the gaps between walls also, because cura/SF can now fill it. it'll work with a variety of nozzle diameters.

    how all of this is/gets implemented, I do not know, you are the SF magician, I am just a regular enduser. would love to hear your opinion.

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution

    Hello Daid, Hello Joergen,

    Thanks a lot or you answer. I know what I am doing is at the limits.

    But digging into the detail it is not the Ultimakers limit, but unfortunately its the Software (SF / Cura).

    If you look at approx's print of the Eiffel Tower http://forum.ultimaker.com/viewtopic.php?f=24&t=697#p4509

    you could see that print of structure suddenly stopped. This is the result of issue we are discussing here. Its pure software.

    The discussion of "is a printer able to to extrude smaller widths than its nozzle diameter" is academic.

    The result are failed prints. (and fixing it, the print will also be clearer, because currently there are structures "in the air" where the Ultimaker is extruding a bit right in the air, resulting a little blob at the next structure. (because the structure below has been skipped).

     

    About a week ago, I could not have imagined to print these little details.

    What I also tried was emphasizing extrusion on these little details .

    5a330caad9dfa_3DPrinterOS-Ultimaker(7).thumb.JPG.2249aa17f13de54dbd000c168f8b49a1.JPG

    This is a incredibly stable print:

    5a330caa70a5c_3DPrinterOS-Ultimaker(7).thumb.JPG.05ea234452870855c82ee186b63634d8.JPG

    (I think I would have carried 2 to 3 times as much weight…)

    (Also thanks to a good construction >100 years ago)

    Yesterday, I was trying to find the part in the SF source code and modify it. But unfortunately I wasn't able to identify it.

    So - any help is appreciated.

    Thanks a lot,

    Janosch

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution

    Don't try to fix things in SF. You will go crazy.

    Anyhow, I'm posting from a train while I'm drunk, so I hope I make sense. But I think I understand your infill problem now Joergen. It suddenly hit me. What's happening is that all sparse infill lines are really bridges, because they are cross hatched. A simple solution would be to use twice as much material on the sparse infill lines, but after spending 1:30 hours in the train this morning investigating if it was possible to adjust SF to do this, I gave up.

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution
    I'm posting from a train while I'm drunk, so I hope I make sense. But I think I understand your infill problem now Joergen. It suddenly hit me. What's happening is that all sparse infill lines are really bridges, because they are cross hatched. A simple solution would be to use twice as much material on the sparse infill lines, but after spending 1:30 hours in the train this morning investigating if it was possible to adjust SF to do this, I gave up.

    I hope that doesn't mean that you have to be drunk always to read/understand my lengthy FR/complaint/fixit posts :-)

    the thin infill issue (aka the cross-hatched fluffy mess) is one issue, where I suggested weeks ago to add a line width (extrusion thickness) and speed setting, so the user can choose a structural infill that would work with the model to be sliced, since yoda doesn't care if he's all fluffy inside, but my 360 rig certainly needs high-quality, structurally sound 30% infill. again, this is one issue.

    the other big issue hopefully didn't got lost on the train... which is the nozzle diameter and the outline resolution and consequential the wall gap issue, which should be easier to tackle, since you mentioned that you understand the SF outline routine better than the infill voodoo.

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution
    I'm posting from a train while I'm drunk, so I hope I make sense. But I think I understand your infill problem now Joergen. It suddenly hit me. What's happening is that all sparse infill lines are really bridges, because they are cross hatched. A simple solution would be to use twice as much material on the sparse infill lines, but after spending 1:30 hours in the train this morning investigating if it was possible to adjust SF to do this, I gave up.

    I hope that doesn't mean that you have to be drunk always to read/understand my lengthy FR/complaint/fixit posts :-)

    Understood it before that, but didn't have time to post before then.

     

    the thin infill issue (aka the cross-hatched fluffy mess) is one issue, where I suggested weeks ago to add a line width (extrusion thickness) and speed setting, so the user can choose a structural infill that would work with the model to be sliced, since yoda doesn't care if he's all fluffy inside, but my 360 rig certainly needs high-quality, structurally sound 30% infill. again, this is one issue.
    Using the grid-rectangular infill type does put the lines on top if each-other, and will be much stronger. So I recommend you use that then.

     

    the other big issue hopefully didn't got lost on the train... which is the nozzle diameter and the outline resolution and consequential the wall gap issue, which should be easier to tackle, since you mentioned that you understand the SF outline routine better than the infill voodoo.

    Do you have pictures to support his "wall gap issue"? Because I'm not seeing anything like that.

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution
    the thin infill issue (aka the cross-hatched fluffy mess) is one issue, where I suggested weeks ago to add a line width (extrusion thickness) and speed setting, so the user can choose a structural infill that would work with the model to be sliced, since yoda doesn't care if he's all fluffy inside, but my 360 rig certainly needs high-quality, structurally sound 30% infill. again, this is one issue.
    Using the grid-rectangular infill type does put the lines on top if each-other, and will be much stronger. So I recommend you use that then.

    the difference between regular infill, and the grid infill (which I recommended to myself long long time ago :-) and have been using ever since) are the bridging issue, while the grid is printed for every layer, not just for every other layer... but netfabb manages to do awesome infill with cross-hatching, so we know that it is physically possible, and a pure software issue.

     

    the other big issue hopefully didn't got lost on the train... which is the nozzle diameter and the outline resolution and consequential the wall gap issue, which should be easier to tackle, since you mentioned that you understand the SF outline routine better than the infill voodoo.

    Do you have pictures to support his "wall gap issue"? Because I'm not seeing anything like that.

    I had posted this FR quite some time ago: https://github.com/daid/Cura/issues/30, and I think this issue can be fixed with the doubling the XY resolution I had described above. BTW, I see the gaps from slicing in every single part of my rig, especially in parts that are narrower than 4mm (with a 1.5mm wall setting), which are clearly rounding off issues... and this is not an issue of loose belts.

    just to re-iterate the issue and suggested solution, to make sure it doesn't get lost in the shuffle:

     

    we know it's possible. I think the slight loss of XY resolution due to some jitter in a i.e. 0.2mm extrusion width (say if it would vary from 0.17-0.23mm), is far more tolerable than loosing a feature because cura/SF is rounding it away (i.e. a small feature that is 0.5mm thick doesn't show up in the tool path anymore because with a 0.5mm nozzle setting it is below the threshold). it would be so easy for cura/SF to just use 2*0.25mm temporarily to make that 0.5mm wall, instead of just ignoring it completely.

    My question is: within SF (outline.py, or however it's called), instead of taking the nozzle/extrusion diameter as a fixed and unchangeable parameter, how about the section that determines how many outlines are printed, would be able to divide the extrusion width in half or 1/4?

    taking the example above (0.5mm nozzle), a part is 5mm wide, and then thins down to 1mm, and then down to 0.5mm (i.e. the panel mount hole for a headphone jack). SF/cura would start with 2 outlines (to make a 1mm wall on each side) plus some regular infill (3mm wide), then make 2*0.5mm outlines to make the 1mm wide section, and when it encounters a modulus=0 situation (width <= nozzle/extrusion), it simply cuts the extrusion width in half and renders the 0.5mm wide section as 2*0.25mm, which would print just beautifully. in theory it should be possible to go to a quarter, but that is speculative, and would require some real-world testing, but I don't want to dismiss it.

    This code change should get rid of the gaps between walls also, because cura/SF can now fill it. it'll work with a variety of nozzle diameters.

    Here are some real-world examples:

    Gap issue:

    2012-05-19%252009.27.51.jpg

    2 gaps visible: one vertical one left of the metal grid insert, and one horizontal one between the rectangular insets on the left.

    fluffy infill issue:

    IMG_3989.jpg

    IMG_4605.jpg

    Left side is netfabb, right side is cura

  • Link to post
    Share on other sites

    Posted · Cura - Bug and a question about printing resolution

    I've actually used the 'rounding bug' to my advantage to print several parts with thin slots for inserting filter paper.

    don't think of it as a bug, more an opportunity waiting to be utilized ;)

  • 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

      • 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
        • 16 replies
      • S-Line Firmware 8.3.0 was released Nov. 20th on the "Latest" firmware branch.
        (Sorry, was out of office when this released)

        This update is for...
        All UltiMaker S series  
        New features
         
        Temperature status. During print preparation, the temperatures of the print cores and build plate will be shown on the display. This gives a better indication of the progress and remaining wait time. Save log files in paused state. It is now possible to save the printer's log files to USB if the currently active print job is paused. Previously, the Dump logs to USB option was only enabled if the printer was in idle state. Confirm print removal via Digital Factory. If the printer is connected to the Digital Factory, it is now possible to confirm the removal of a previous print job via the Digital Factory interface. This is useful in situations where the build plate is clear, but the operator forgot to select Confirm removal on the printer’s display. Visit this page for more information about this feature.
          • Like
        • 0 replies
    ×
    ×
    • Create New...