burtoogle

I changed the support overhang angle to 50 and the min support area to 0.5 and got this...

If you need to contact me, please use @burtoogle as @smartavionics is no longer logging in to the forum. Forum admins, if I remove smartavionics from the forum will all the past postings get trashed or will they remain?

That is part of the CuraEngine which is a C++ program that does the actual slicing. It would need to be recompiled.

This is where it decides to reset the extruder. https://github.com/Ultimaker/CuraEngine/blob/cf47e6dd3115d1998b93047ba6617ace1cf8badf/src/gcodeExport.cpp#L861

I put all my Cura config stuff in a git repo so that from time to time I can make a snapshot to go back to when the latest Cura decides to trash something (I work on the bleeding edge). Of course, once the files are in a repo, it's easy to share the repo between computers.

Check in the machine settings dialog that the cooling fan number on the extruder tab is correct. For almost all printers it should be 0.

That is entirely reasonable. That's why they get paid. Yes, I build releases for Linux (x86_64 and armv7l), Windows and MacOS. The MacOS releases are for High Sierra or later.

Hello @macaron, I have contributed to Cura a setting that informs Cura that the extruders share a heater. I don't think this feature has made it yet into a UM Cura release but if you install one of my releases you can try it out. You can find my releases at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0. Please read the README.md file there for more information. The shared heater setting is in the machine settings dialog...

Yes, if you want a stable Cura, use Linux. It's pretty much bomb proof and performance is well acceptable even on an i3.

Hi @DivingDuck, thinking more about what you have said above, I don't believe you are actually using my plugin if you haven't disabled the 3Dconnexion driver. If the cursor moves when using the spacemouse, you are not using the RawMouse.

Ah, I understand. The Cura 2d mouse interface only supports rotation in the yaw and pitch axes. It doesn't support roll. I can possibly add that for the HID devices and add an additional rot axis. Will look into that. It's unlikely that this plugin will ever make use of any 3Dconnexion software or related configuration files. Really, the whole point of it is to support HID devices without the need for any manufacturers drivers.

Thanks for the feedback. I'm not sure what you mean by flipping the bed on the y axis. If you mean change the direction of movement, that can easily be accomplished by editing the config file and changing the sign of the appropriate scale value. You don't even need to restart cura, just goto the RawMouse menu and restart to read the new config file.

I have created a plugin that lets Cura access HID mouse devices such as the 3Dconnexion Spacemouse. It's called RawMouse because the plugin interfaces directly to the raw device without the aid/hinderance of an operating system driver. It's not a sophisticated all-singing, all-dancing interface, it simply converts the HID mouse commands into the equivalent 2D mouse commands. It has been (vaguely) tested on Linux and Windows 10 and it should also function on MacOS (10.13 upwards). For a quick install, unzip the latest RawMouse.zip from https://github.com/smartavionics/RawMouse/releases into your plugins directory, connect your Spacemouse, and start Cura. The usual weasel words apply, it's supplied with no warranty, YMMV, etc. All feedback is welcome. Either comment in this thread or open an issue on the github page.

Hi @Cuq. Yes, the Schwarz P isn't really much good as a general infill but apparently it has potential applications in medicine and other niche areas. Personally, I will keep using gyroid as my day-to-day infill.

Hi @tajino, I just sliced your project with no problems and I don't think what I am using is much different from the last release so I can't explain why it isn't working for you.

Yes, you either have to use supports or do what I often do which is make the smaller hole depth such that it doesn't go all the way through to the large hole. After printing, you then have to drill/clean the hole. This technique of leaving a thin layer of skin over a hole is especially useful for holes for fasteners that are visible, i.e. on a front panel. If you make the hole go all the way through the panel, the top skin has to be printed in segments. But if the hole doesn't reach the top skin layer, the top skin can be printed with fewer (possibly 1) segments so the finish quality is better. As for the bridging settings, this is what I am currently using for PLA on a SV01 printer: Some of those settings aren't in the UM cura but most are.

Hello @tilio09101, there is quite a lot of flexibility when you look at the custom infill settings. There's a few different infill patterns and then you can alter density, line angles, etc. For example, I have a print that I use lines infill with line angles that cycle through 0, -45, 0, +45 degrees as I wish to have more strength in a particular direction.

Hello @ArcticEddie, as mentioned above, you could try one of my builds which are available at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0. Please read the README.md file there for more info.

the setting search box is very handy - you could have just entered brim and it would have shown you want you wanted to see.

Try the Enable Support Brim option... Without... With...

Yes, I think the slowness is down to the fact that Marlin expects some values in mm/s but other firmwares (e.g. RRF as used on the Duets) expect the values to be in mm/min. So as you have already found, you need to use RepRap flavour. As for the being too high, I don't think that is a Cura problem, it's more likely to be a problem with the config for the Duet. The modified start gcode doesn't look like it is causing this issue. After homing, if you manually move the nozzle up using the Duet controls, does the height make sense? i.e the z scaling is correct?

That's true for the direction of that pipe's axis but for the orthogonal direction there's a shallow slope near the top and bottom of the pipe.

Your image is too small to see what's really happening there but when I slice your object it looks as I would expect. Obviously, the slope is very shallow there so the walls are widely spaced. Have you tried the adaptive layer height feature? That can improve the look of shallow slopes.

Hi @geert_2, thanks for the input. Yes, a test print could be useful. Perhaps just a region of skin that narrows. When the skin lines are printed, as the hotend reaches the area where the length of the skin lines is such that, the hotend is switching direction at the resonant frequency, the user should notice the resonance and where it is occurring. They could then adjust the Avoid Frequency to reduce the print speed in that region. The layer view gives a crude indication of print speed so they just need to adjust the Avoid Frequency to move the lower speed (bluer) region to coincide with where the resonance occurred. I would expect the resonance characteristics of a printer to be quite complex (i.e. different resonant frequencies in x and y and maybe multiple frequencies). So if I get any feedback that indicates that my current simple scheme isn't sufficient, I'll think about a more sophisticated solution.

Hello @ramsesiden, I notice that the gcode header in the 4.4.1 file contains this line: M203 X500.00 Y500.00 Z10.00 E50.00 ;Setup machine max feedrate Marlin expects the values to be in mm/s but most of the other printer firmwares (I believe) expect the values to be in mm/min. I don't know how Klipper behaves in this respect but if it's like the majority of firmwares, it will end up using a very low speed limit. As for the print time estimates, I cannot explain the big difference other than perhaps the print time estimate algorithm used in Cura got reworked between the 4.1 and 4.4 releases. That's possible.