burtoogle

Possibly the same issue as discussed in https://github.com/Ultimaker/Cura/issues/3998.

Hi @SandervG , @Keventurist was the person who started the ball rolling by suggesting that the fan should be able to be increased when printing skin above support - this feature has just made it into the master branch and so should be in the next release. Please credit him when the time comes.

Yes, there are various parameters that influence the extrusion rate. If you want to modify the extrusion rate without altering the line width or print speed then I would have thought that the Flow setting in the material section is the one to go for. By default it is 100% but you can make it larger or smaller and that will scale all extrusions.

No, the F600 applies to the X/Y movement only. So the move to those coordinates from the current position will take a certain amount of time, let's call it T. While that X/Y move is happening, the extruder will extrude 73.3386 units of concrete (in M^3, perhaps?!) and so the extruder rate will be 73.3386 / T.

Freecad on Linux does export STL files...

I know next to nothing about licensing but I thought the whole point of the LGPL was that it did not "taint" the code that it was linked to so it can be used within closed source (or otherwise encumbered) programs.

Hello @pieri70, I think the difference is that Cura has the fill gaps between walls option enabled and this produces zillions of little line segments. Try turning that off and see if it makes a difference. Looking at the s3d gcode, it doesn't look as if the gap is being filled there. Hope this helps.

One good thing about the delay before contributions are merged into Cura is that it gives more time for testing and refinement. So by the time something becomes available for users to test, I have probably been using the changes for months and will have found most of the problems by then.

Personally, I would be happy enough with just a mention at the bottom.

Who cares? Kudos all round, I say!

Hi, @SandervG, thanks. I know I did contribute some stuff but it wasn't me that worked on the avoid supports when travelling option. I think that was likely to be @bagel-orb ?

I recently had some of this underextrusion on skins and the only way I could improve it was to print the skin slower. I am using an e3dv6 hotend I have come to the conclusion that it simply doesn't have the heat transfer capacity to continuously print large areas quickly. Setting top surface skin layers to a non-zero value and then using a much reduced speed for the top surface layers helps the speed/time trade off.

Sorry you have lost your settings, I can't help you get them back but perhaps others can. However, what I wanted to say was that you should put all the settings files under version control. Just install git, create a repo in the settings directory and every now and again commit a snapshot of the files in there. You need not lose everything ever again due to Cura trashing things. Even better get a github account (or similar) and push the repo so that you have a backup in the cloud.

I submitted PRs to allow the cooling fan number to be specified on a per-printer basis. https://github.com/Ultimaker/Cura/pull/3950 https://github.com/Ultimaker/CuraEngine/pull/797 Don't get too excited, these are unlikely to be incorporated for months (assuming they get accepted, that is).

Hi, I looked at your model using the FreeCAD analyzer and it said it had a self-intersection which was in the hub area. I asked FreeCAD to fix it but the model still didn't slice right. Anyway, I think the problem is with the model rather than with Cura or the settings.

I don't know what kind of printer you have but I would have thought that this gcode at the start will smack the build plate with the nozzle: G1 X150 Y150 Z25 F12000 ;recenter and begin G1 F9000 G92 E0 G1 F2100 E-0.4 ;LAYER_COUNT:132 ;LAYER:0 M107 G0 F3600 X89.815 Y103.19 Z0.1 It's descending 25mm at 60mm/s and is meant to stop at a height of 0.1mm, I have my doubts that it can do that without any overshoot.

Do you read C++, if so, here's the proof: skirt_brim_config_per_extruder.emplace_back( PrintFeatureType::SkirtBrim , train->getSettingInMicrons("skirt_brim_line_width") * ((storage.getSettingAsPlatformAdhesion("adhesion_type") == EPlatformAdhesion::RAFT) ? 1.0 : line_width_factor_per_extruder[extruder_nr]) // cause it's also used for the draft/ooze shield , layer_thickness , (layer_nr == 0)? train->getSettingInPercentage("material_flow_layer_0") : train->getSettingInPercentage("material_flow") , GCodePathConfig::SpeedDerivatives{train->getSettingInMillimetersPerSecond("skirt_brim_speed"), train->getSettingInMillimetersPerSecond("acceleration_skirt_brim"), train->getSettingInMillimetersPerSecond("jerk_skirt_brim")} ); Just kidding! How about this, let's play spot the difference... So it looks from the code and the layer view that the brim is influenced by the initial layer flow.

Sorry, I don't use any plugins so I can't help you but as they are written in Python they should work OK irrespective of the host machine architecture.

Looking at the code, the flow for the skirt and brim is controlled by Initial Layer Flow setting.

I guess you could use the post processing plugin to modify M106 and M107 lines to specify the fan.

I looked at your gcode and can not see any movement of the nozzle to near the bed. Where does the crash occur? At the start of the print or later? Are you sure your printer has homed correctly?

It's in the 3.4 beta so will be in 3.4 when it arrives.

There is also now a Max Comb Distance With No Retract setting that when set to a non-zero value, all combing moves longer than that distance will use retraction (but not z-hop). So this gives you the ability to comb short distances and retract for long distance travel.

It simply tots up how long it takes to carry out each extrusion and travel move based on the values for speed/acceleration(/jerk?) that Cura believes are right the printer. As is mentioned above, you can specify those values for the various types of move. I think Cura assumes linear acceleration (speed ramps up, constant speed, speed ramps down) for each move and so if your printer implements some fancy acceleration scheme (s-curves, or whatever) then it's not going to be right. Also, I don't think that Cura knows about extruder acceleration and so if you are using low acceleration values for your extruder that's going to make the print take longer than estimated. I find for my Kossel deltas that the estimate is very good, maybe a couple of minutes per hour optimistic but really OK.

Maybe their logic is the following: as some beds take a lot longer to heat than hot ends, the ordering is OK as it minimises the amount of time that the filament is static in a hot nozzle while waiting for the bed to heat.