Slashee_the_Cow

If it ain't broke, don't fix it. And if you just fixed it, don't break it again 🙂 If I want to do more testing, I'm sure I can break it on my computer.

Put the M109 and M190 before the G28. Technically it makes a difference if you home when the bed is heated (it expands slightly), practically not a noticeable one... but I usually go for the "technically better" option. Being a dual extruder could have something to do with it, so in the start gcode, as the first line, before everything else, put T0 That tells it to do everything with the first tool (in this case the first extruder) until it receives a command to use a different one (which it shouldn't if it's only set up in Cura as single extruder). Also if you look in machine settings, there's a tab for each extruder and they can have their own start and end gcode - is any of that set?

Hard to tell because the forum crushes image quality after you upload it but it looks like it's underextruding, very significantly in some parts. Have you calibrated the E steps for your printer? (Also helpful to know to try and diagnose: what printer is it, what material is it, what temperature settings do you usually use)

You should look at the start of a gcode file you saved from Cura. If there's no temperature commands in the startup gcode it will insert them automatically so the printer doesn't try printing cold. As for the temperature commands: you're right that they're not in there. At the very least you need a M190 S{material_bed_temperature_layer_0} ; wait for bed to heat up M109 S{material_print_temperature_layer_0} ; wait for hot end to heat up in the startup code, before the G28. The end code also has an M104 to turn off the hot end but it doesn't have a command for the bed, so you should add a M140 S0 after the M104. (I could rant about a lot of things in that start/end gcode, some of the profiles that come with Cura are a bit terrible, but the temperature is the main problem here)

Are you running the printer over USB or putting the gcode file on an SD card? If you're printing over USB then the control panel on the printer probably won't make it resume; the printer is waiting for the computer to tell it to resume. If you're printing from the SD card I've never had a problem with my E3V2Neo or E3V3SE resuming just by pressing the control knob, doesn't even have to be in the right part of the UI. Also, if you're running it over USB: you shouldn't be. USB printing is deprecated and no longer supported. It's a relic from the days when printers didn't even have enough processing power to read from a memory card. It's more susceptible to flaws in the print (if something else is pegging your computer's CPU, it can be slow to send commands which can stall the printer and a nozzle sitting around waiting is a recipe for flaws) or outright failed prints (computers crash). Also worth noting: With your settings, it's immediately disengaging the stepper motors after it parks the print - this means that the print head and bed can be moved freely, if they're moved at all (or sometimes just a slight movement when re-engaging the motors) you'll get layer shift. Creality printers mostly don't respond to the "Keep motors engaged" command, but you can set the disarm timeout to something long like 14400 seconds (an hour) so you're in no rush to resume it before they disengage. I don't know why you're pausing (often it's done to change colour) but with those settings it's set to turn off the hot end when it pauses and then heat it up after it unpauses before it continues the print. This takes time, but also has the problem that the nozzle tends to drool a little bit as it warms up (which is why it does the nose wipe before it starts a print). If you're changing filament, even if you get to it really quickly it can cool down enough that you can't purge the new filament. You should untick the "Use M109 for standby temperature" box and set the standby temperature to your printing temperature.

So, I'm sorry it's not a plugin, just a post-processing script... but on the bright side that means it's just a single Python file so you can mess with it if you want. Although if you need regexes to control your wiping you may want to see a doctor about that. Just put the Python file inside the zip file (can't upload .py files) into Scripts subfolder of your Cura configuration folder, restart Cura and then add it in the post-processing settings. StopWipingAtZ.zip

I know this one is obvious but I'm going to say it: checked to make sure your bed is level and your Z offset is correct?

Well it means we at least know where it's getting its cura.cfg from now. Maybe try moving (and if that just resets it again, copying) it to ~/.local/share/cura It's not.

Whether they're morons isn't really relevant. What matters is whether they're sheeple who just follow what other people are doing. Less intelligent people (not including you, since if you're smart enough to know you're not a genius, you're not stupid enough to think you are) can be capable of independent thought, which I would say is dangerous, but considering people have killed themselves doing "challenges" on TikTok, probably less dangerous than following the herd. Intelligent people can be sheeple just as easily though (i.e. Cult of iPhone) and that's the real shame since their independent thoughts might be worth something.

For reasons I've never understood, Cura creates folders at both ~/.local/share/cura and ~/.config/cura Why it has a folder in .config I've never understood because it always seems to load the configuration from .local Maybe see if there's a cura.cfg in ~/.config/cura/5.6 and if so move it somewhere else on the computer (move instead of delete in case it messes things up completely, you can move it back) and see if it'll generate a new config file in one or both folders.

I appreciate the sentiment, but don't worry about it. I'm well adjusted. They don't want to act like they're family, I don't have to bother acting like they are. Saves money at Christmas. Fewer presents to buy. 😄

It's been at least ten years since my stepmother has talked to me or even sent an email or message. "Good riddance to bad rubbish", as my mum would say.

Ah, so you have Experimental > Wipe Nozzle Between Layers turned on? Looks like something it wouldn't be too hard (always famous last words) to whip up a post-processor to remove above a certain layer. Just.. not at 12:30 at night. Later today though I'll look it.

As a stepchild, I can tell you from experience that this is treated much better than a stepchild. For starters, someone has cared about it within the last ten years.

Okay, so if I can get back on topic for a second: Firstly, remember, everything looks terrible when subjected to a macro lens, plus this is only a small 32mm x 32mm example. Oh, and it's PLA, because while I keep a bunch of colours of PLA and a few of TPU in stock, I only have grey PETG. Layers of green printed: 3 Green surface flush with blue: yes Scripts by Greg used: ¼ (he's touched pretty much all of the included scripts so it's hard not to) gcode files used to print: 1 Messing with gcode files required: a little bit Colour changes required: 1

... I haven't seen any option for that in 5v7 ... It's important to remember that these are fairly niche features you're talking about, and that development manpower is a finite resource. What percentage of Cura users would have a SpaceMouse? I'm guessing under 1%. Cura is almost certainly used by professionals who use UltiMaker's printers and might have one, but there's also a very high number of hobbyists and things like educational facilities using it, most of whom wouldn't even know what one is. There are bugs that need fixing which affect well over 1% of users. There are features in development which will likely be useful to well over 1% of users. It just makes sense to prioritise these things, especially since Cura might be free to download, but is still essentially "sold" as part of the product with UltiMaker printers, both to individuals and enterprise customers. People who spend the money for an UltiMaker printer (I wish I could afford to be one of them) or buy a whole bunch of them for their school or business want solid software with features useful to them, and the significant majority of them do not own a SpaceMouse. So why is it that smaller open source projects like FreeCAD or OpenSCAD support devices like these? They are passion projects. The people who do the development also use the program a lot. And if you're that much into CAD that you develop a FOSS CAD program, then the odds you have a SpaceMouse are significantly higher. And when you're not a company responsible for delivering the best quality software they can to customers, your priority list can basically be whatever you want it to be. Does it suck when peripheral <x> doesn't work with software <y>. Yes. The number of flight games which only recognise my HOTAS as a three axis joystick make me want to through said HOTAS through the screen (fortunately they're often a bit of a tangle of cables so it's not that easy). I have an eleven button mouse. The buttons can act as generic mouse buttons, but most programs won't let you map anything more than a left, right or middle click, so I have to resort to using the configuration program included with the drivers to map them to key combinations. This also means that running in the background I have configuration software for Corsair, Valve (Steam counts when you own a Steam controller), Razer and four different Logitech programs (and not that it runs in the background, but I do have to fire up 8BitDo's software at times). Far from an ideal situation, but I can't reasonably expect game developers to have native support for all these things which most people don't have. What can I do about it? Well for most games, and most software, not much. But if you want something supported in open source software, then you can implement it and submit a pull request to have it included in the main program. I know that it sounds easy when I put it like that but putting it like that ignores the fact that programming doesn't come easily to a lot of people. And the crux when it comes to development: nothing is as easy as it sounds. Nothing is as moderately difficult as you think it will be. Fixing one bug adds two more. So when there's only so many people working on a program, they have to allocate their time as best they can. And adding support for something that will only benefit a small number of people often just doesn't make the cut.

If you can give me an example file (preferably a Cura project so it's set up for your machine) I'm happy to trawl through settings for a bit seeing if I find anything.

How much of a change needs to be made? Do you just need to insert a gcode command at layer 50, or do you need to remove a wiping command from every layer above 50, or... what?

I can see in the log that it found cura.cfg.bu and tried to upgrade that. I didn't think it ever looked for any file other than "cura.cfg". Try closing Cura, then either moving to a completely different location (like your home directory) or deleting the cura.cfg.bu file, then load Cura again and see if it generates a new config file. If it doesn't, close it, open it, close it (just to make sure the log file is full of whatever happens when it tries to find its config file) and post the log file.

Not that I know of (I'm not really a fan of video tutorials in general, I'd rather something written I can go through at my own pace, though it's getting harder to avoid these days). Do this at your own risk if you don't completely know what you're doing. If you put together a gcode file and want to see if it's valid post it and I'll look. The really, really simplified version is: You slice it at multiple layer heights. Open the gcode file for the layer height you want to start with. In the gcode file, find the start of the layer that is after the layer at the height you want to change (don't go by layer number) - Cura leaves comments in gcode files which start with ";LAYER" so it's easy to find the start of layers. Delete that layer and the rest of the file after it. Open the gcode file for the next layer height and find the start of the layer at the correct height (which will be the layer after the change height). Copy that layer and the rest of the file and put it at the end of the first file. Go back to the gcode file for the next height and look for the first line before the layer you copied over which starts with G0 or G1 and has an E number. Copy the number after the E. Back in your main file, on a new line immediately before where you pasted from the next file, insert this command (obviously replace my placeholder with the right number) G92 E<number from other file> Repeat steps 3-7 for each file at a different layer height. (I told you that you need to know what you're doing)

Not even the RepRap Wiki's gcode reference (which covers multiple flavours, including what flavours support what commands) mentions a G5. For all I know, could just be a typo and result in a no-op. They are working on improved tools to test submitted definitions, but even then there's only so much theoretical testing you can do.

Yeah, a lot of people don't do that. Annoys the cud out of me. I don't want people Googling a problem to open the thread, see a wall of text with no marked solution, so just post the same question again. This thread isn't really "solved' so much as a "not our department" as @Dustin explained so there's not really much that can be done in this case.

Try increasing Quality > Support Line Width. The general guideline for line width is 60-150% of your nozzle width, so if you're using a (relatively common) 0.4mm nozzle, set it to 0.6mm. Okay, not the clearest example ever (I just opened a model I use for testing little things). If you want to stop support creeping into extremely tiny areas that can probably be bridged easily, then increase Support > Minimum Support Area (I can't really give you a value, just start with like 1mm² and play around with it). Everything is a competition, at least to me. Have you managed to cut yourself with a craft hobby knife through cut resistant gloves?

I don't mind so much if they're letting me do the thinking for them. */me remembers all the times she's been called on to fix computer "problems" which just involve looking at what's on screen and pressing a button* You know what, never mind. I concur. But when someone wants to remove the top bit from something spiralised, they're not looking for a script which can remove the top <x> layers from anything, especially since their original problem doesn't even involve layers.

Now I'm even more interested to see the cura.log file. It'd be awesome if you could post it.