Jump to content

burtoogle

Expert
  • Posts

    1,529
  • Joined

  • Last visited

  • Days Won

    20

Everything posted by burtoogle

  1. Do you still have the gcode that produces a better result? If so, please attach it to this thread so I can compare it with what is produced now. Thanks.
  2. Hi @smsusi. Until recently, there was a regression in Cura whereby the mach3 option was being ignored (which you have found!) A fix has been submitted to the Cura devs and I should think that it will be in the 4.1 release. In the meantime, if you are using either Linux or Windows (sorry, not OS X), you can try one of my releases that already incorporate the fix. I don't know how well the Mach3 flavour works as I don't think it sees a lot of attention so when you get to try it out, if you find any issues, please report them. You can find my releases at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 They do not conflict with the Ultimaker releases.
  3. Hi, thanks for the file. I would recommend two changes, enable the Optimize Wall Print Order setting to reduce the amount of travel required and also set Max Comb Distance With No Retract to some non-zero value (10 or 20?). Hope this helps.
  4. Great, glad you have found a solution.
  5. Hello @nagygabor679, to help us diagnose the problem, please save a project file (File -> Save) and attach the resulting .3mf file to this thread. Then we can see the settings you are using. Thanks.
  6. Ah, I just noticed that your file doesn't contain any settings so I was using my settings. You should do File -> Save not File -> Export. This confuses Cura users new and old but the Cura devs do not seem very keen on making it obvious that to save a project file you need to save rather than export.
  7. The slicer assumes that the lines are rectangular in cross section (of course, this isn't true in reality but, then again, FFF printing is all one big approximation anyway). So for a line width of 0.4mm and a layer height of 0.3mm, 1mm of line needs 1 x 0.4 x 0.3 mm of filament which is 0.12mm^3. The filament dia is 1.75mm so that gives a cross section area of approx 2.4mm^2 so we need to extrude 0.12/2.4 = 0.05mm of filament for each mm of wall line length. Reality and intention diverge? Sorry, haven't a clue. I recommend that you use slic3r, then.
  8. I sliced your project using 0.4 and 0.5 line widths and the extrusion amounts for the wall line scaled as expected. Here's the 0.4mm line width extruding at 0.050 mm/mm rate (which is correct if you do the calculation) And here's the 0.5mm line width extruding at 0.062 mm/mm (which is also correct) I don't think Cura is causing the problem you observe. Hope this helps.
  9. Sorry, I don't use Marlin so I can't help you there.
  10. Perhaps the extruder acceleration and/or jerk has been set very low? I don't think Cura does that.
  11. Thanks for the file. I sliced it and looked at the gcode and the retractions are happening at 60mm/S and then I changed the retraction/prime speed to 40mm/S and the gcode changed as expected so I really don't know why you are seeing the behaviour that you are. This image shows the retraction speed in the gcode to be 2400mm/min = 40 mm/S which is what it should be.
  12. Welcome @Stratos, it's hard to give you an answer without seeing your settings so please save the project (File -> Save) and attach the resulting .3mf file to this thread. Thanks.
  13. Hello @Froissart. Yes, the z-hop will work irrespective of whether it is the extruder that moves up and down or the build plate that moves up and down.
  14. Hello @Mozella, if you use 2.85mm filament and, somehow, the old Cura thought it should be using 1.7mm filament, that would probably account for it. Just guessing, really.
  15. I'm guessing that you are using Windows and have a firewall operating. Try disabling it?
  16. It looks like the nozzle is too close to the build plate.
  17. Hello @Jimmy8881, this has been fixed for the next release.
  18. Hello @ArturoToons, I have tried slicing your project using a Cura based on the current development version and it doesn't show the problem you report. I also tried with infill densities of 80, 60 and 10 and that's good too. One oddity I noticed is that changing the infill density for a model doesn't change the blue button back to the slice button, you have to change something else in the main settings also.
  19. It sounds like that setting is related to infill but, actually, it is really related to walls. What it does is fill the gaps that can occur when there either isn't enough room to fit in a complete wall or when there would be a gap between an inner wall and a skin region.
  20. That's weird because I don't have any problem with that at all. I suspect that your extruder is underperforming for some reason. Have you actually checked the calibration at the extrusion rate required for the infill you are printing?
  21. So, @CalebPetersenPhD, back to the original problem. I assume you are using 100% infill? I ask because, if my memory serves me right, when you specify 100% infill it actually doesn't use infill anyway, it just uses skins instead and so it will be the skin speed and flow that is limiting the achieved extrusion rate.
  22. The engine needs to be modified and rebuilt too so without doing that, you can't change how it works.
  23. Hi @CalebPetersenPhD. Cura is basically a two-part application. The front end that provides the UI and all of the settings stuff and the back end (CuraEngine) that actually does the heavy lifting to turn the model into g-code. The PR I cited above is what is required to be changed in the front end, there is also a PR that makes changes to the back end. So without both PR's being applied and the application rebuilt, it's not going to be effective. There seems to be a bit of a log jam with the processing of contributions to Cura at the moment so I really can't say when they may get around to evaluating that contribution and considering incorporating it into a future release. Sorry to have got you all excited!
  24. Hello @Babaganoosh, the reason the walls are not being recognized as bridges is because the individual lines that make up the curved walls are smaller than the min bridge wall length setting. Reduce that to zero and the walls are recognized as bridges. Now, you could argue that it should add together the lengths of the segments and if the total is > the min bridge wall length all the segments should be treated as bridges. However, given that you can't print a curved bridge wall anyway, it's really not worth doing.
  25. That's what tends to happen, also, in the example I show above if the skin lines go across the regions (at 90 deg to how they are shown above), then the walls curve inwards in the middle due to the tension. You really need the skin lines to anchor on supported areas rather than bridge walls if possible. With my example above, the skin areas are, essentially, triangular so you can't avoid the skin lines terminating on one of the bridge walls but at least they are at quite a shallow angle which will minimise the inward pull.
×
×
  • Create New...