GregValiant

I actually printed it but I used the SmartAvionics fork as I like it better for Spiralize. So I guess any comparison would be apples and oranges. At .2 layer height and .6 line width it came out well. A couple spots of super glue and in a few minutes it was rigid enough for use.

When the spokes print, each spoke receives just a dot of filament and then the printer moves to the next. You can see it here with my regular settings. The travel lines are dark blue because I'm not getting a retraction after each "dot" is put down. This is with the "Retraction Minimum Travel" at 0.02 and the "Maximum Retraction Count" at 300. All those dark blue lines are now pale blue which indicates that there was a retraction. Now your question "Is this impossible?" comes up. Your UM S5 or maybe a direct drive setup might be able to handle it. My Ender would scream bloody murder and then the hot end would clog, or the filament would get ground down to nothing by the drive gear.

Torgeir's project sliced fine for me as well. Check the settings "Outer Wall Inset" and "Horizontal Expansion" and "Horizontal Hole Expansion". They can have an effect when features get close together.

There are two sides here regarding print speed. The first side is what you enter into Cura for speed. If you were to enter 50mm/sec for print speed then the Gcode would show "F"3000mm/minute as the print speed. The LCD display would show 100%feedrate of the 50mm/sec. There is no box for a "percentage" of the print speed in Cura. The second side is what the printer is told to do with the feedrate. You can manually adjust it on the LCD and all speeds coming into the printer/processor will be adjusted by that percentage. If you were to put M220 S80 in your startup gcode it would do the same thing as a manual adjustment and the LCD would show 80% feedrate. Every "F" parameter that comes into the printer would be adjusted to 80%. Your print speed would be 40mm/sec and your travel speeds would be 80% of whatever ended up in the gcode. Cura calculates the speeds...the printer feedrate% is a global adjustment of those calculated values. The Fan Speed% should build from whatever you start at up to "Regular Fan Speed" at layer "Regular Fan Speed at Layer". If a layer time is below "Regular Maximum Fan Speed Threshold" then the fan speed will go to "Maximum Fan Speed". Your fan icon on the LCD will show the current fan speed (as a % of duty cycle). If it says 100% then yes, the fan is spinning at 100%. As to why it's at 100%, now you have to go looking at the settings and at the gcode.

Can't tell without a project file. Load the model and set Cura up to slice. Use the "File | Save Project" command and post the 3mf file here.

I see that. This is the repaired model in 4.13.1 and the original model that @Torgeir translated looks much like this with nearly the same missing features.

I repaired it using formware.co/onlinestlrepair and double checked with MS 3D Builder. It seems fine now. There are two spots like this. I noticed this as well. It looks like a layer is missing but I think the extrusion took a different path and is sitting inboard. Test_Step_AP203_fixed.stl

The model is close to being able to Spiralize. You can see the white "layer start" indicator. It's there because on this layer an "island" formed that is disconnected from the main toolpath. Since Spiralize is on, Cura extrudes from one island to the other making the characteristic thick line between the islands. In addition, you can see that there are travel lines. If Spiralize had worked as you wanted there would be no need for travels. I know this is hard to see but the diagonal lines running up to the top of the image are also connecting islands. More starts and stops. There really aren't very many but every one results in a thick string (really an extrusion) running across air.

"- klipper flavor" I've been over the information on the Klipper site. I perused it but I didn't notice any real difference between Klipper and RepRap/Marlin. The Klipper site starts by saying that certain commands (G0, G1, G4, M104, M140, etc.) are the same. It then informs the reader to go to the RepRap Wiki for others. There just isn't much of a difference and a member of the community would need to do the research and point out what (if any) changes would need to be made to a Cura gcode to make it 100% acceptable to Klipper. Klipper allows for custom macros. You can add the macro name to a Cura Gcode manually. I have made changes to "Insert at Layer Change" to allow for a single insertion rather than at every layer. That would allow you to add a macro name to the gcode one time. It's part of the package I posted HERE. Cura is open source but it's' UltiMaker that does the heavy lifting. None of their printers use Klipper so it would seem to require a "community member" Klipper guru to add (if required) specific capabilities for Klipper.

"When clicking the Pause button in Cura..." That sounds like you are printing via the USB port. If you are printing from the SD card then the printer "Pause" function may do what you want. On my older Ender the pause routine does park the head but it also allows the hot end to turn off. In addition, the stepper motors disable in 2 minutes and at that point the printer loses track of where the nozzle is. You can't simply auto-home and continue. BUT only the LCD menu will allow you to have any control of what happens during an un-planned pause. It should be good enough for a quick peek before you have to hit the resume function. If you use Pause at Height then you have more control (you can park the nozzle in the back so your view of the model is better) but the Pause code is hard coded into the Gcode at a specific layer/height.

Alright, I found it. There is a typo in your nozzle files. In Windows they are located in "C:\Program Files\UltiMaker Cura 5.4.0-beta.1\share\cura\resources\variants\elegoo\elegoo_neptune_3plus" folder. Using a text editor open each nozzle file in turn and change the line: definition = elegoo_neptune_3max to definition = elegoo_neptune_3plus I'll go ahead and put in a pull request on Github for this.

Go to the MarketPlace and load the "Printer Settings" plugin. After restarting Cura and switching to "Custom" settings - Printer Settings will be the bottom group in the settings list. One of the settings is "Nozzle Diameter" and you can try inputting the nozzle size there. Are you using one of the definition files built into Cura or did you install the printer as a Custom FFF?

For the last 6 months I've been going over Cura's post processors. In response to requests I've seen both here and on Github I've written some new post processors. I have also fixed a couple of bugs and did some tweaking to expand the capability of some of the others. I think they are ready to debut. Rather than putting up an overly long post, I'm including a PDF "readme" file (within the Zip folder). The zip folder contains a complete set of my altered Cura post processors. They could use a few more pairs of eyeballs to spot any bugs that might be hiding in the woodwork. So far as I can tell they all work as advertised. New Post-Processors: "Add Cooling Profile" has been a Cura request since at least 2017. "Add Cura Settings" adds them to the end of the gcode "Alter Zhops" allows for turning them off in specific parts of a print. "Bridge Temperature Adjustment" makes temperature changes for bridging "Multi-Extruder Color Mix" supports both 2-in-1 and 3-in-1 mixing hot ends. "Timed Cool Down" adjusts the cool down rate of the heated bed. "4 Little Utilities" includes: "Remove All Comments" "ReNumber Layers" (for One-at-a-Time prints) "Add Data Header" (A debugging tool) "Add Extruder End Gcode" this is a bug fix that will be removed when the bug is fixed. "Time Lapse", "Insert At Layer Change", and "Search and Replace" get expanded to include "Insert Frequency" and optional "Range of Layers" with multi-line support where applicable. All of the post processors now add their name to the beginning of a gcode file. That, coupled with "Add Cura Settings", provides a complete record of how the gcode was sliced. If the posts are unzipped and put into the configuration folder (Windows: "C:\Users\...username...\AppData\Roaming\cura\5.4\scripts") they will be added to Cura and co-exist along with the stock scripts. The names are prefaced with "gv_" so you can tell them apart. I would like to thank @ahoeben, @Cuq, @ghostkeeper, @Torgeir, @gr5, @nallath and @rburema for their help (and for allowing me to steal code snippets when they weren't looking). That didn't take long. Fixed a bug in Search and Replace when non-regex and replacement is First Instance Only. gv_PostProcessorsBF1.zip

I posted a model called "berserk fury" up above. It will slice in all Cura versions up to and including "5.3.0 alpha+christmas". As much as I have played with it, I cannot get to slice in 5.3.1 or 5.4-beta. It's not something I would print myself, but so far as I can tell it is an error-free model that Cura is no longer capable of slicing. My question is "What's up with that?".

If there is something above that gap then Cura is pulling the skin back to allow infill to continue up into the part. "Skin Removal Width" and "Skin Expand Distance" effect the gap.

I went back to 4.13.1 and found the same behavior (T0 end gcode is always returned). Within the ending gcode there isn't a way to ask Cura to provide the Tool Number so it can pick out (in this case) the proper Extruder End Gcode. Cura just performs a simple replacement as near as I can tell.

It isn't necessary when things are working right. If for some reason the commands aren't in the gcode then they aren't there for the printer to follow. So the first trouble-shooting step is to figure out which side the error is occurring: on the Cura side or on the printer side. That will dictate the second step.

Hi @Garythebloke. The Post Processing alters the gcode that is written to the file. The method it gets to the printer (SD, USB, Octoprint) doesn't matter. From the top: Go to "Extensions/Post Processing/Modify Gcode" and then "Add Script". Select either Filament Change or Pause at Height. Either will work. Choose your settings. Slice and save the gcode. Open the Gcode file in a text editor. Do a search for the command used for your color change. Filament Change uses M600 and Pause at Height is adjustable so you would need to remember the command you used in the Pause settings (often M0) .

The "active tool" can't be asked for in the Ending Gcode (no decisions allowed) and so it defaults to the first tool "[0]" in the extruderList. As a consequence this needs to be done as a post process. Unzip and put "gv_AddActiveExtruderEnd.py" into either the Configuration Folder "scripts" folder or the Installation Folder "postProcessing/scripts" folder. It will be available under "Extensions/PostProcess/Modify Gcode" as "Add Active Extruder Ending Gcode" when you restart Cura. gv_AddActiveExtruderEnd.zip

From Github #15757 Berserk_Fury.stl

Cura bases the estimate on the speed and acceleration that are entered into the Cura settings. If your printer has lower "Max Speed" and "Max Acceleration" then those become the speed limits and the time Cura estimated will be off. (It isn't usually that bad though.) The Vyper printer definition file doesn't list the Accel numbers and so the default Cura FDMPrinter numbers are used of 3000mm/sec°. But within your printer the M201 acceleration maximum might be 500 and it's that number that will override whatever is in the gcode. If you have PrintRun/Pronterface installed you can send M503 to the printer via the usb and see the result. It will tell you what the printer settings are. If you enter numbers at or below those limits into Cura you will find the estimate is much closer to reality. A while back there was a post here regarding the Cura estimated print time versus the PrusaSlicer estimated print time. That turned out to be a settings issue as the poster was using a 7mm retraction distance at a speed of 1mm/sec in Cura but at 20mm/sec in PrusaSlicer. Every retraction/prime cycle was taking 14 seconds in Cura and 0.7 seconds in PrusaSlicer. When there is an equivalency (apples and apples) between the printer settings and the Cura settings you will find that although it's not exact, it's not far off. Certainly not by a factor of 2..

In that image you posted - that appears to be either a pretty cool top pattern or it's the most severe under-extrusion I've seen in many moons. You should not be able to see between the individual extrusions that make up the skin. Does the printer have a mainboard cooling fan and is it working? If the stepper drivers overheat they will get glitchy and they can send the wrong number of steps to the motors. Your Y axis appears not to be the only problem. If you have the original mainboard laying around maybe putting it back in and running a test print will tell you something. In regards to the 3mf file, some of your settings I would call "out of mainstream". Printing PLA at 220 seems pretty hot as does the bed temperature at 70. By comparison I print at 200-205 and 50 bed on my Ender 3 Pro. Thermocouples never read identically so there is going to be at least some variance. I'm not a fan of jumping the speed up and down especially on small models like the cube. It can have bad effects on the nozzle pressure as it is slow to react to the almost instantaneous speed changes. Consequently the pressure never has a chance to really settle down. That makes analyzing a small print tough. I'm assuming here that the top surface probably shouldn't look like a cheese grater.

The nozzle for the printer is listed as a 0.4 and here are the line widths from your setup. In addition, you have the Minimum Line Width at 0.34 which is a contradiction since you are asking for .2 (and a .1) line width. I don't know what you are using for a build plate, but this piece should absolutely not need a raft. It has good surface contact and should stick. At any rate, I made some changes and here it is back at you. GV_Cab front.3mf I'm going to guess it's the front wall of a steam locomotive cab?

It's likely in your settings (there are a lot of settings). Load the model, set Cura up to slice, use the "File | Save Project" command and post that 3mf file here. Look at "Wall Order" in 5.3.1. There was no such thing in 4.8 and many printers struggle when the wall order is "Outside to Inside". Those travel lines look like extrusions rather than strings. Make sure "Spiralize" is turned off.

Or you could unzip this wonderful, new, not yet included in Cura Post Processor and put the "gv_AddCuraSettings.py" file in your configuration folder. In my Windows installation it would go in "...\AppData\Roaming\cura\5.3\scripts" gv_AddCuraSettings.zip It would be available under "Extensions/Post Process/Modify Gcode" and runs with 4.x or 5.x versions. It adds the settings to the end of the gcode file. You can pick which "sections" of the settings, or all of them.