Slashee_the_Cow

Wow. That sucks. Too bad that I'm decent at post-processing scripts but have no idea how to make plugins or else I'd consider maintaining them myself (at least enough to make sure they work with the latest version of Cura). Maybe it's a good time to learn 😄

Sounds like that's the setting you're looking for. Jerk is how much it's allowed to instantly change speed at a corner (because if it came to a complete stop then started moving the next direction, it'd leave a blob. Technically regardless of the jerk setting the head should go to the corner and then move in the next direction, but since the filament you're leaving behind isn't right under the nozzle (it's a small bead that follows it), changing speed too quickly at corners will make that bead take the straightest route to keeping up with the print head, effectively cutting the corner. It's something that requires a bit of testing to set up if you're looking for accuracy: too high and you'll be effectively cutting the corners. Too low and it'll have to slow down so much that it leaves a blob. And not that it's a problem for you, but it also matters if you're printing something tall: if your jerk is too high the bed could vibrate and make your print wobble a bit. Especially fun when you're trying with TPU (although when I did that it actually came out reasonably well).

It would help to know what printer you have, and if you can provide an example Cura project (.3mf, in Cura go to File > Save Project) then we can look at your settings to see if anything looks of. Make sure you've properly levelled the bed and set the Z offset correctly. If it's trying to print a little too low, it'll squish. If you have automatic bed levelling make sure to run that (I put it in my startup gcode... better to take a minute levelling the bed for a good print than getting a bad print... after the line that says G28 add one that says G29). ABL adjustments slowly go back to normal after the first 10 or so layers (depending on your printer).

Afraid I can't solve all your problems... or maybe many of them. I'll go over my best guesstimations then I'll go over some things I see in your gcode: Preheating: This one I'm not sure I can explain. There's an M109 and M190 so it should have waited for both extruder and bed temperature. Extruder crashing: That error message makes it seem like you're trying to print/move the head the head too fast on at least one axis (possibly Z, given the crash). You can't change the maximum Z speed by default, meaning you'd have to either change your definition file or download the Printer Settings plugin (mandatory shoutout to @ahoeben for his fine work): That will give you options for maximum speed for each axis: Make sure your Z is low enough. In theory a printer shouldn't try and follow a command to move faster than it's supposed to be able to, in practice... 🤔 Purge line: I cover this in my gcode section below. About your startup gcode: I seem to be a bit of a startup gcode snob😏 so please don't take it personally: G130 X20 Y20 Z20 A20 ; Lower stepper Vrefs while heating M105 ;Report temperatures G130 X127 Y127 Z40 A127 B127 ; According to the RepRap wiki, neither Marlin nor Klipper support a G130 command. Could be that an unrecognised command is making it not follow the ones afterwards (including the nose wipe)? Also the comment says to lower them while heating, but that code occurs after all of the heating commands. In fact, those commands should run pretty much one straight after the other so the second (if it does anything) would cancel out the first one anyway. Although if those commands are affecting it, it could affect the printhead crashing because it would be changing the voltages on which the stepper motors run. M104 S{material_print_temperature_layer_0} ; Set Extruder temperature M109 S{material_print_temperature_layer_0} ; Wait for Extruder temperature Shouldn't cause any problems, but the M104 is pointless, in theory. M104 tells it to heat to a certain temperature; M109 tells it to heat to a certain temperature and then wait until it reaches it, so it doesn't need an M104 to tell it how hot to get. G0 F3000 X-20 Y-10 Z20 ; Move to wait position considering printhead settings The "apply extruder offsets to gcode" setting only applies to multi-extruder printers where each extruder has a nozzle in a different position (i.e. doesn't share a nozzle). Regardless of what your print head dimensions are set to, X0, Y0 is always going to be the corner for a single extruder printer. Some printers can move their heads past the extremes at one or both ends, but it's often a bad idea (i.e. my Ender-3 V3 SE can go to negative X coordinates but that results in the print head pushing against the homing switch for that axis). This might have something to do with your nose wipe problems if it's trying to wipe from invalid coordinates (since it's trying to start at Y -10). Also, one thing which shouldn't affect prints but annoys me about so, so many startup gcode sequences (i.e. probably feel free to ignore this particular rant 🙂) RED = You haven't extruded yet, why do you think it's necessary to reset the extruder position? Like, maybe one I could understand in case it doesn't reset from a previous print. YELLOW = You have extruded, you should probably reset that before you print.

Hiya! Your friendly assistant mod Slashee here. This isn't really about improving prints so I'm moving it to "third party products" forum. I guess my first questions would be: Are you printing off an SD card (or whatever the Ender-5 Plus takes) or over USB (and in the latter case, from just your main computer or a dedicated system like OctoPrint?) Are you using the same gcode file for both printers? How is the filament being held (like is it just on a holder that comes with the printer or are you crazy like me and have a few holders sitting on a table next to the printer being fed into its tent through Bowden tubing and held on top by a thing I printed just for that)? Other than the stopping after 3-4 hours, are they performing equally well? Printing at the same speed, with the same accuracy, etc.? You could try swapping the motherboards between the two to see if the motherboard is the problem but sometimes Creality have used different boards for the same model printer just so they can get enough, so if they're different I don't know whether swapping them would work. If it just suddenly stopped working I doubt it's the firmware but anything's possible. You could try reflashing it but with Creality printers that's really somewhat of a flip of a three sided coin whether it'll make it better, not change anything, or worse. About the stepper motors: are you noticing any performance degradation or loss of accuracy as the print goes longer? I mean, even if that's happening it could be a long shot, but any difference in behaviour between the two is worth bearing in mind.

You don't download OpenGL. Drivers for it are included in your graphics card drivers. What OS are you using, and what are your system specs? Are you getting a specific error? If so, when, and what's the error?

I don't know if anyone's daring enough to try hot-swapping filament while printing, but I'm not.

I'd just like to pop in here and say that unless you're using specialty high speed PLA, you shouldn't be printing this fast. A lot of spools of filament will list on the side the recommended speed. For regular PLA, it's usually around 50-70mm/s (I go at 60, unless I'm doing something with fine details). By default the "print speed" setting in Cura will do the infill at that speed (not so bad if it doesn't quite print right since it should be invisible to the outside, assuming you have enough walls and shell layers) and everything else at half that (if you ask me, it should do everything at the print speed entered, except make the infill twice that or whatever).

This is why you rename the config directory instead of delete it. All your settings are still going to be around and if nothing in there is a problem, sure you have bigger problems, but you can just rename it back and everything will be just like it was. And doing it this way if something in there is a problem, you'll have everything except that.

If we're playing show and tell I feel obligated to include at least one piece (8 changes):

Tip, from experience: edit your earlier post to remove the attached file. And consider giving them version numbers so if someone has a problem that's already been fixed... you get the idea.

Well you can approach this from one of two directions (as literally as possible), I prefer the "scorched earth" approach myself. Go to %APPDATA% and rename the entire cura folder so it's forced to generate a completely new config from a blank slate. If you're using a custom printer definition, open Cura, then just quit it and put your definition in the %APPDATA%\cura\5.7 (definitions and variants if necessary, if you have a custom definition then you've already done this) folder it should have created so you can open it again and your printer will be in the list to add. Anyways, set up your printer. Get a model which won't slice (if you want one from the calibration shapes plugin, then go to the configuration folder you just moved out of the way and they're in plugins\CalibrationShapes\CalibrationShapes\models\) and see if it'll slice. If it doesn't, then either your custom printer definition is causing it or you have bigger problems. Then it's basically a matter of "close Cura, copy something from previous configuration folder into new one, open Cura, test". If it stops slicing after you copy something, you've found your culprit. Personally I'd test in this order: cura.cfg (overwrite the new one it made) If your printer setup differs from its definition (you've changed some of its settings in Cura) then the changes will be in a file in the definitions_changes folder, so that All the post-processing scripts (which should have nothing to do with it, but computer programs break in mysterious ways) Any custom/changed materials (just the whole materials folder), although if it's happening with a generic material it's probably not this All your quality settings profiles (they're in the quality_changes folder) and then test with those profiles Plugins. Ideally, one at a time. Yes, I know it can take a bit of time if you have a few (I have plenty). To cheat, you can do it about three at a time, just remember which three in case it breaks it you can uninstall those three and test individually. For ones you can find in the Marketplace, download them from there, if something is no longer listed there, copy it from the plugins folder in your old config folder. Then... that's about everything covered. If it works after that, you probably had a bum configuration file somewhere. And when I say you can approach it from the other direction: that's starting with what you have now and removing things individually until it works. But I prefer to do it from the ground up in case of things like aforementioned bum configuration file somewhere which you wouldn't get around to removing.

Alas, you are correct. You could try it with a file with regular supports but open the gcode file in Cura so you can see what the preview looks like before you try and print it.

In theory, it's going by layer number in the Cura preview, which starts at 1, but in the gcode the layers start at 0, so I subtract one from the value you put in the settings (because what the Cura preview says is layer 250 is labelled layer 249 in the gcode, but it is in actuality the 250th layer). I can change it if you want. Whenever I do a script for someone I always want to have a happy customer.

When I've done my art prints from the SD card on my E3V3SE, M0 worked fine. The screen didn't update to say it was paused (blame Creality's crappy firmware - it won't even display messages sent with an M117) but just pushing the control knob resumed it. When I've done it using OctoPrint (from storage on the OctoPrint server), it automatically blocks the M0 command and just doesn't send any further instructions to the printer until you click the resume button in the web interface. Actually pretty inconvenient compared to just pushing the button on the printer. I've never tried running it through OctoPrint with the gcode on the SD card. Stop trying to complicate things. I was referring exclusively to printing through Cura, since the concept of USB printing as a whole cannot be deprecated and the printer does still support it then logically I must not have been referring to the system as a whole.

Okay, scratch that "can't remember why": it's "machine_nozzle_tip_outer_diameter" in the machine definition. Most files don't overwrite it so they just use the value from fdmprinter (the base definition almost all machines are based on) which is 1. If I override it in my machine definition to 0.0, then I can get my cube up to 219.9x219.9mm on my 220x220mm build plate:

I think there is a small disallowed area around the edge (look at the dark grey) by default but I can't remember why off the top of my head (I'm using a custom definition for my E3V3SE so I know there's no disallowed areas):

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.