GregValiant

There isn't a lot you can do if they won't talk to each other. USB Printing is a legacy piece of Cura. It isn't really supported anymore and is rarely updated. If it works, it works and if it doesn't, then it doesn't. You may have run into one of the reasons why. There are thousands of different: computer, USB port, driver, and firmware combinations. Trying to get USB printing to work with all of them isn't possible, so no one wants to put the effort into even attempting it. If Elegoo changed suppliers for the USB port on the mainboard, then it might require different drivers on the computer. Check the properties of the computer USB ports and see if a port driver has any configured as a Serial Port. You will probably need the printer connected to check. Sometimes an operating system will make the driver installation for a specific port rather than allowing just any port on the computer to work with the printer. Try plugging the printer in to different USB ports. You might find one that works. Cura can take a while for Cura to locate a port and connect to it. In the Cura Marketplace are two versions of "USB Printing". By default the original version is enabled. Go to the Marketplace and click on the "Gear" icon. Scroll down and disable "USB Printing". Then go to the regular "Plugins" tab and scroll down to "USB Printing NG" and install that one. Quit and restart Cura. Sometimes it takes a several minutes for Cura to poll all the possible ports while it looks for the printer port. Sometimes it just fails.

If you have a multi-extruder printer then there are 6 Extruder options to pick from. "Support Interface Extruder" can be fine tuned to "Support Roof Extruder" and "Support Floor Extruder".

This is a re-do. I added "Unload", "Reload", and "Purge" options. That makes it more "Filament Change" friendly. There are other changes. The obvious one is that I threw out the "By Height" option as it didn't work with Z-hops enabled, or with Adaptive Layers. I added a "Reason for Pause" option (if you are just inserting magnets or nuts then you don't need the purge settings). PauseAtLayer can co-exist with PauseAtHeight and be installed to the same folder. PauseAtLayer.zip There are a couple more settings.

As Slashee surmises, it's most likely an issue with the Z mechanicals, but there is a slim chance you may need to calibrate the Z steps/mm. It is something that only rarely needs to be done though. If you grab the right end of the X beam with two fingers and move it up and down there will be some movement, but it shouldn't be loose.

M109 S[material_print_temperature_layer_0] Cura uses curly brackets for replacement patterns. The "Initial Layer" is indeed layer 0 in the gcode. That line should read: M109 S{material_print_temperature_layer_0} I would suggest a couple of changes so bed leveling happens with the bed hot and the hot end warmed up. Go to "Manage Printers" and then "Machine Settings". Adjust the startup gcode. M82 ;absolute extrusion mode M220 S100 ;Reset Feedrate M221 S100 ;Reset Flowrate M140 S{material_bed_temperature_layer_0} ;start to heat the bed M104 S150 ; warm up the nozzle M190 S{material_bed_temperature_layer_0} ; wait for the bed G28 ;Home M420 S1; Enable mesh leveling G92 E0 ;Reset Extruder G1 Z10.0 F3000 ; 2mm isn't enough...move up more so there is room for oozing under the nozzle M109 S{material_print_temperature_layer_0} ;move this up a line so heating takes place at X0 Y0. G1 X10.1 Y20 Z0.28 F5000.0 ;Move to start position blah...blah...blah Cura adds a retraction of 0.8mm right before the skirt/brim starts. Your startup has a 1.0 retraction in it as well. So when the skirt starts the filament is 1.8mm behind the nozzle, but the prime is only 0.8mm so you are going to print about 30mm with no plastic coming out.

PrusaSlicer uses different "replacement patterns" and square brackets while Cura uses curly brackets to enclose replacement patterns. You need to make a couple of changes because "{first_layer_temperature[0]}" won't get replaced. For Cura it will be: M109 S{material_print_temperature_layer_0} M190 S{material_bed_temperature_layer_0} AHoeben has put together the full list of replacement patterns for Cura HERE. You can do math in the StartUp Gcode starting with Cura 5.6.0. G0 F{speed_travel*60} will convert the Cura "Travel Speed" setting from mm/sec to mm/minute as is used in the gcode file.

Gcode is Gcode. There is no "better" or "worse". It's just a set of commands that tell the 4 axis robot (in this case your 3D printer) where to go and what to do. If your printer (which you neglected to mention or describe) isn't doing something (which you didn't go into) it probably isn't the gcode.

This can be hard to trouble shoot but there are two things that are usually involved. The ability of the filament to stick to the bed, and the bed leveling (the nozzle is too high so the initial layer is too high). (Another thing would be the E-step calibration but you should have done that.) I also level with a piece of paper. I use parchment paper because it's very thin and nothing sticks to it. A store receipt will work as well. You should feel the paper dragging on the bottom of the nozzle when you level. The bed must be clean so wash it with dish detergent, dry it well and put it back on the printer. Wipe it down with 90% Isopropyl Alcohol taking care not to get any fingerprints on the build surface. In the Cura advanced settings under "material" is "Initial Layer Flow" and it has three or four sub-settings. Set them all to 110%. Do a quick test with a cube or something similar. If the material still wants to drag then you might have to go to an "adhesion promoter". I use Aqua-Net Super Hold hairspray for PETG and there are products like Magi-Goo (and others) that can help. One thing I found was that after I had leveled, the print would start and there was the G28 Auto-Home command in the StartUp gcode. It would home all three axis and my Z would end up not quite where it was when I was leveling. The fix was to change the G28 in the StartUp to "G28 X Y". Now I level the bed and start the print but the Z doesn't home again so when the print actually starts everything is where it was during leveling. I still run my Initial Layer Flow a little heavy at 105% though.

I pulled some speed numbers out of a file made with 5.6. File size: 217,167 lines Print speed: 75 Only looking at the speed of extrusions: Instances of speeds over 75: 2,586 Average of the speeds over 75: 97.55 High speed: 155.44 So of that particular file about 1.19% were overspeed, but some were indeed double speed. There were no over-speed lines in the first layer. That likely has something to do with the model geometry. If I get truly, really, absolutely, mind-numbingly, bored then I'll chart the lengths of the extrusions involved. The end of that particular model is a hemisphere so there will be lots of short line segments. Here you can see that the fast lines are the narrow lines. It's certainly compensating, but in my (never humble) opinion, it's a bit much. These are straight shots here so the print head can and will hit 155 in the straightaways. This is "Speed Changes of Extrusions". It only charts the lines were a speed is mentioned, and not the intervening extrusions made at that speed. The chart should really be a lot longer, but the spikes and dips are variations from "75m/sec" which is the flat horizontal line. This is my "Sportfisherman" Benchy

Part of this is a design thing. If you are building the declination angle into each part then you are going to get more odd effects than if you design the entire part flat and then angle it in the assembly. I don't know TinkerCad, but in AutoCad, building the angle in can be done by "lofting". Loft features and helical features are very complex, but usually as smooth as the conversion from CAD to STL can make it. I have to say though - that is a very odd looking slice. These are the same model. One exported from CAD at high resolution and the other at low resolution. They are both made up of facets.

This has been noted in a few bug reports on Github (including my own). I don't think there has been an official response to any of them, but they are there. In 5.6 - dropping the Flow Equalization to 0% fixes the problem. The setting worked differently in 5.4. As I recall it would slow the speed for heavy flow lines (like printing the infill at 2X layer height) but didn't jack the speed up on narrow line widths. That was the change and so it's likely a "design intent" rather than a "something is broken" bug. I don't care for it myself and turning off the equalization completely isn't a good option for me because I do tend to print infill thicker to speed things up.

Another thing would be to bring in a small model (a cube would work) and make it as tall as the first model then set it to E2. That would be another way to get both extruders working. I suppose a post processor could send the nozzle to the middle of the prime tower and just purge some filament. It wouldn't put any plastic down in layers, but the second extruder would get regular exercise.

In regards to cooling I'd say that if you typically print the material with cooling then the temp tower should be with cooling. The fans (and you have serious fans) are going to effect the hot end temperature. It's hard to tell in those images but it appears there may be some under-extrusion going on.

Regarding the under-extrusion, that was probably the loose drive gear on the extruder motor. The "nozzle size" settings in Cura provide some defaults for things like "line width" and "layer height". Those are the settings that are important. You can run them at any value regardless of the nozzle size setting. Everyone needs to start somewhere so yes, they should match but it isn't a show-stopper if the nozzle size in Cura doesn't match the actual installed nozzle. Trying to put down a 1.0 line width out of a 0.2 nozzle can be done if you print at about 1/2mm/sec and really hot.

I've been coming across some oddities in regard to the V400 definition files. There is a bug report on GitHub and the OP posted a project file. The OP's printer is an FLSun V400 and the project file is from Cura 5.6.0. When I tried to open the project file it immediately crashed Cura. Looking at my installation of Cura 5.6.0 I found that there were no nozzle files for the V400. I opened my V400 definition file and compared it to the V400 definition file contained in the project file. My definition file didn't have "variants" listed, but the 3mf definition file did. Looking further, they aren't even by the same author. This is from the definition file contained in the project file: "name": "Flsun V400", "version": 2, "metadata": { "type": "machine", "author": "FLSUN, Joseph Jackson", "manufacturer": "Flsun", "setting_version": 22, "file_formats": "application/x-ufp;text/x-gcode", "visible": true, "has_materials": true, "has_variants": true, "has_machine_quality": true, "preferred_material": "generic_pla", "preferred_quality_type": "normal", "machine_extruder_trains": { "0": "flsun_v400_extruder_0" }, "supports_usb_connection": true, "supports_network_connection": false, "platform": "flsun_v400.stl", Conspicuously absent is the "inherits" line. This is from the definition file in have in my 5.6.0 installation: "version": 2, "name": "Flsun V400", "inherits": "fdmprinter", "metadata": { "visible": true, "author": "FLSUN, Guislain Cyril", "manufacturer": "Flsun", "file_formats": "text/x-gcode", "platform": "flsun_v400.stl", "has_machine_quality": true, "has_materials": true, "machine_extruder_trains": { "0": "flsun_v400_extruder_0" }, "platform_offset": [ No nozzle "variants" in that one. Something seems odd here. There have also been problems with at least one other printer (Longer??) missing files. If a definition doesn't "inherit" fdmprinter.def.json I would imagine there would be big problems. So what Joseph Jackson did was to copy everything he thought he needed from fdmprinter to his V400 definition file. The prject definition is 9517 lines long and the definition file I have is 45 lines long.

I see there is a pull request HERE in for the KE. It appears to have been OK'd so it might make it into 5.7. Someone else will have to comment on Wifi.

With the Snowman model I'm getting these speeds in 5.6.0. (The print speeds are 75 and travel speed is 150 in Cura.) ;Slower Initial Layers: 2 ;Extruder 1 (T0) ; Flow Equalization Ratio: 100.0% ;The speed ranges for this print: ; Maximum Travel Speed: 150 mm/sec ; Minimum Travel Speed: 150 mm/sec ; Maximum Extrusion Speed: 111.9 mm/sec ; Minimum Extrusion Speed: 15.0 mm/sec The only change to this slice was the Flow Equalization Ratio ;Slower Initial Layers: 2 ;Flow Equalization Ratio: 0.0% ; The speed ranges for this print: ;Maximum Travel Speed: 150 mm/sec ;Minimum Travel Speed: 150 mm/sec ;Maximum Extrusion Speed: 75.0 mm/sec ;Minimum Extrusion Speed: 25.0 mm/sec This seems to be affected by the line widths that are required by a specific model. The "snowman" doesn't show anywhere near the "compensation" exhibited by whatever model I used up above.

Natively, Cura does not use a Z-offset. You can add one by enabling the "Z-Offset Plugin" from the Marketplace. Cura always assumes that "0" means "0" because where the build plate actually is in space it is impossible to tell. It's the users job to move the build plate into position so the "Z=0" (the bottom of the nozzle) exactly coincides with the top of the build plate. People use the word "leveling" but that's a misnomer. You are setting the "Initial Z" to zero. I use a piece of parchment paper which means that if I had issues "adjusting the initial Z" then I could use the plugin to make an adjustment. If you use ABL then the adjustment is the Z-offset setting in the printer and there is no need to adjust it in the gcode by using the plugin. They are not "synonymous" but rather "mutually exclusive". If you try to use both you'll end up chasing your tail.

Did you download the zip file that MariMakes posted? Unzip the file. You need to manually copy the files from the unzipped folders ("definitions", "extruders" et al) to the same-named folders in the Cura installation folder. If a folder happens to be missing from the Cura installation folder, then you will need to copy the entire folder over.

Thanks Slashee. That's a much better explanation of "Excepted Behavior". @Kraven33 do you see it? There are going to be "bottom layers" equal to your setting over the cutout. You can adjust the "Skin Expand Distance" to get rid of some of the ins-and-outs so it prints smoother but if you have asked for 4 bottom layers and the cutout is less than 4 layers deep then yes, there are going to be additional "cutout shaped" skin areas to make the bottom count over the cutout = 4. If the cutout is deeper than "bottom layers" then it looks like the normal situation where the "real" bottom layers on the build plate stop, the cutout continues up, and then the cutout gets capped with 4 bottom layers. (Could've been a model error though. I did say "maybe".)

In the Mesh Fixes section turn up the "Maximum Resolution" to 0.60. With the setting at 0.25 a lot of short lines make it into the gcode. I didn't count them but there are lines in the range of .006mm long. With the Maximum Resolution at 0.6 the shortest line in the file was 0.146mm. That's a big improvement. The file length fell by 4000 lines.

Cura can control any number of fans...as long as they are layer cooling fans because they must be tied to an extruder. As Slashee indicated the commands that come from Cura will be M106 Pxx commands. The "P" parameter is only inserted if the printer has multiple hot ends/extruders and they have different fans. All fan commands go in at tool changes. For simple on/off functions you could put the commands into the StartUp and Ending GCode. For real actual control then the commands need to be interspersed throughout the gcode file. You have a third party printer that has been modified by a fourth party using fifth party parts and firmware. That's fine, but I think you need to take the next step to "custom everything". If the firmware is capable of accepting certain commands, and if you have the output capability for the defined fan circuits that will respond to particular commands, then you could post-process a Cura gcode and insert the commands wherever you want. You may not need a Klipper macro, but you may need a custom mainboard (or a daughterboard of some sort) to give you sufficient I/O for what you want to do. There is no point in putting all the time and effort into this if your current mainboard only has 1 cooling fan output.

That shouldn't happen. It may be a misplaced layer. If there is a bad edge or flipped surface within the model (likely within the cutout) you could get something like that. Have you tried running the model through a repair program like MS 3D Builder? If you load the model, set Cura up to slice the way you want, and then use the "File | Save Project" command, you can post the 3mf project file and it will contain the printer, the model, and all your settings.

You might not be doing anything wrong. There are a growing number of reports about Windows 11 not playing nice with Cura. Starting (as I recall) with Cura 5.4, a bug would keep good models from slicing. There were a couple of workarounds that could fool the bug: Rotate the model in Cura. Move the model away from the mid point of the Cura build plate. Change the Initial Layer Height by a little bit (for example: from 0.20 to 0.23). Turn off "Optimize Wall Printing Order". Turn off "Print Thin Walls". The #1 problem is issues with the model itself. If you haven't done so - go to the Cura MarketPlace and install "Mesh Tools". It has some repair ability but whether it can fix a model or not it will give you a notification that the model has issues. If you are using Windows then you can download "MS 3D Builder" from the Microsoft store. It has a pretty good repair function that runs when you load a model and "Insert" it into the workspace. There are also free on-line repair services like formware.co/OnlineStlRepair. Just because you downloaded/bought a model doesn't mean it's structurally sound. If a model has open seams it is called "Not Watertight" as in water would leak out the seams if you tried to fill the model. When you scale the model down those open seams also scale down and might fall below some threshold and don't pose a problem. At full size the cracks are wide enough that a slicer can't tell where the outside ends and the inside begins. The official terminology used in regards to non-watertight models and models with inside-out surfaces is "It be broke".

I'm not sure why this is, but I enjoy starting a day with a philosophical discussion. The only slicer that started Gcode layer numbering at "1" was Simplify3D and they went out of business. PrusaSlicer doesn't use layer numbers at all. It is..."difficult"...to post-process a Prusa sliced gcode file. You can't just go through and look for a layer to start at and "rafts" make a mess of the count. You have to look further into it. Just counting the instances of ";LAYER_CHANGE" doesn't get it done. Cura layers in the gcode don't always start at 0. If you use a raft then they start at "-6". Depending on other options there may not be a "-1" or "-2" but rather might jump from LAYER:-3 to LAYER:0. At least you know that a negative layer number indicates a raft. It's a small gift but I'll take it. The Cura post processors were written by different people who often spoke different languages. Sometimes, what is perfectly clear to them in a ToolTip is as clear as mud to others. I suppose it is the nature of open source software to have issues like that. In the past year or so, I have gone through all the post processors with an eye on making all the layer number references agree with the Cura preview. I've adjusted the "ToolTip" texts to explain to the user how to input the numbers. I've been striving for consistency. The translation to base0 takes place in the background. For a variety of reasons (including the fact that my amateur coding style is painful for real software engineers to go through) those changes have not yet been accepted. This is my proposed change to the "Filament Change" tooltip ("Pause at Height" is similar): "Enter the Number of the LAST layer you want to finish prior to the pause. Use the layer numbers from the Cura preview. If there will be more than one change then delimit with a comma. Spaces are not allowed.". I am positive that it will not be sufficient to keep people from making mistakes. They won't double check their gcode to make sure it's right, and then they will hurriedly print a file that isn't what they wanted. I only know "Americanized English". What makes sense to me in a Tooltip is not necessarily going to be clear to someone else. It's the same problem other authors have had. My last actual real computer programming class was Fortran II in 1969. We actually started with analog computers and moved up to Fortran. Yes, we used punch cards and everyone was amazed when paper tape came in because you couldn't drop it and scramble the order like you could when loading a stack of 2000 punch cards into the room sized IBM 360. Base0 was the rule for all the CNC machines that were coming into service at the time at GM. They used Gcode. Gcode came out of MIT sometime in the 1950's. It was 0 based then as well as now. There is no "Option Base 1" in gcode. It is a fact that if the ancient Romans and Greeks had invented computers everything would be Base 1.