All Activity

Sorry if it feels like I'm pestering you, I do appreciate your help, and in part I am venting my frustrations. I'm running a long print so it will be a little bit before I can test this, but I was dealing with prints taking about 1.4 times as long as predicted, so that's why I'm so concerned about how slow its going, Id rather my 24 long prints not take 34 hours. I don't have that setup at the moment but I will look into it. However, I am fairly confident that I have met or exceeded the values I am asking it to do on gcode coming out of ideamaker. I will test your Start Gcode when I get the chance. Is it ok for me to not define the M203 Z and E, since those haven't seemingly been problems yet I don't want to mess anything up. If it was purely just a problem of not being able to exceed a certain speed, wouldn't both the inner and outer walls be going at the same maxed out speed? Instead the sequence each layer is - 2 inner walls seemingly at 50 mm/s - 1 outer wall seemingly at 100 mm/s - the first straight line of (gyroid) infill will be at speed, 100 mm/s - then the rest of the infill will be at a slower speed, presumably back around 50mm/s And this is all in spite of the Gcode to the best of my parsing all showing the correct values. Its almost like the machine is trying to read the speed values from somewhere else. Its just observational but it seems to be using a slightly wrong version of the Cura calculated speeds, in that it appears to be doing the two wall speeds as multiples of each other, albeit in a wrong order, and seemingly independent of the value I set as overall print speed, instead sticking to the default 100 mm/s.

ugh. So much memory is in the config. I'm always so frightened to move on --- that I'll never get back to where I am ... or will chase little errors. But the obvious solution is to try this first on my workstation ... and not the workshop laptop. And I agree, it's a good thing and the right direction. I just want you to know that it's _very_ scary!

The printer knows what it's maximums are for the feedrate and acceleration on each axis. If you have Printerface installed and a USB connection to the printer, you can send M503 and the printer should respond with it's settings. This is my printer response: You can put that M203 line anywhere within the StartUp Gcode. I would suggest you do it like this: M201 X1000 Y1000 M203 X250 Y250 Z45 E50 and see how it goes. That M201 line will set the Max X and Y accel to 1000 and the M203 will set the Max feedrates for each motor.

Thanks a bunch this is great!!!

I looked at the formulas and they already consider the nozzle size. If the "reload" amount is too long then the filament will get to the nozzle before the speed slows to "purge speed". As written, the script reloads 90% of the "reload amount" at max E speed, and then slows to Purge Speed (3.33mm/sec for a 0.4 nozzle) for the last 10% of the reload amount and for the Purge Amount. So it sounds like your "reload" amount is too much. Probably the Unload Amount as well. The extruder should quit retracting just when the filament comes free.

I agree with not changing too much while its working. The weird part for me is still that when reading the gcode in other softwares it shows the speeds I want. It just doesn't do so on the printer. I can try adding in your M221 and M220 commands, but another thing I saw I could add is an M203 command, something like this, and if so where in the startup Gcode should I place it. M203 E? X130 Y130 Would this be a reasonable explanation for how the Gcode seems to be correct, but the machine doesn't want to follow the specified speeds? This still wouldn't address the fact that its also doing slower speeds for the inner walls and then faster speeds for the outer walls, but if it was at least listening to my speeds, I could just put the numbers in backwards and let it mirror them so it would be correct. Another thing I realized is the printer profile I built is adapted off the N2 Plus which may have had lower limits that are somehow affecting this.

The Unload and Reload numbers need to be adjusted to your machine. The purge number needs to be adjusted to the filament. For example if you are changing from white to red it will need to purge more than going from dark blue to black. I didn't add the purge speed because I didn't deem it necessary. Purge speed is hard coded to 200mm/min or 3.33mm/sec. I can see where that would be too fast for some machines. I think I'll add a formula based on the nozzle size and a print speed of 75mm/sec. I'll post it when it's done.

GregValiant - It worked perfectly - will try again.. only issue was maybe too much filament comes out on the purge - Maybe a tad slower on the purge and not so much.. Going to give it a go again - apparently you have back out and on the touch screen and then play button resumes. Finally got the play button back with this new script.. this is great thanks. Oh and had to change pause command to M25BQ - this is what brought the play button back. With the default settings it doesn't. Not sure if these are ideal with the purge amount #s, so any other numbers which you think might be ideal could work too. Thanks..

The first layer looks a little underextruded and you really want to squish hard to get things to stick. How hard the first layer squishes is the most important thing by far but not the only thing. some (not all) of the other things are removing surface oils (that come from your fingers probably), glue, brim, bed temp. squish 1) This is a UM3 right (I don't think you answered slashee's question)? 2) Do you use active leveling (I don't on my UM3)? Assuming you do manual leveling, turn the 3 bed screws CCW as seen from the bottom to move your bed up just a tiny bit. Turn them all the same amount, about 1/2 turn. This should increase squish without changing the "level" part of leveling. material Is this PLA? I don't think you mention anywhere. This is crucial information. glue 3) Did you use hairspray recently? I don't like hairspray much because it can get all over the printer and cause havok with all the moving parts. bed temp 4) Do you have one of those contactless IR thermometers ($7 at harbor freight)? I recommend you get one. Check the bed temp with that by pointing straight down (any kind of angle will reflect and you'll get the wrong temp). It should be 60C. Your temp sensor on the bed may report 60C when the bed is actually only 30C. Please respond to all 4 questions!

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.

And this is the sort of thing that happens when I scramble late at night. The new "enable" box had a bug. This one doesn't have that particular bug. PauseAtLayer.zip

My good, old Ultimaker S5, which has been in use for almost 5 years, always on, suddenly died this night. It completed a print last night. This morning the screen was black, no light, totally dead. I checked the power button, the cable etc, but it's not something external to the printer. Since is not reacting at all to the power button, I guess a fuse has blown. Has anyone experienced the same? Any tips on what it could be? Marius

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.

That's brill @GregValiant I'll check out the new version & thanks for your continued plugin work

Thanks! Ill give this a try

OK. What do I do next to diagnose this. I don't want to wall myself off from Cura updates.

No... it's obviously fine. heh.

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):

M25 works on some of the Creality machines. There is a glitch between the mainboard firmware and the LCD firmware that keeps commands that send messages to the LCD from working. Some printers required a string of "do nothing" commands in the "Gcode after Pause" box. The usual fix is to enter a string of M105 commands as M105,M105,M105,M105,M105. That insured that if the processor does a "read ahead" that it just sees temperature requests rather than any movement commands. Your M300 is the same sort of thing, just noisier. Since you are using a couple of my post processors, here is my replacement for "Pause at Height". Among other changes it has a checkbox to "disable" it without having to remove it from the list. There are also new Unload, Reload, and Purge settings. Let me know if there are any bugs. At some point I'll put in a pull request to include this in Cura, but it needs more people to play with it before that happens. EDIT: It's attached below.

Well that's pretty bizarre. When you installed your printer in Cura which definition did you use? When I open that project file it uses a standard Ender 3 with a bigger bed. Here is a project file with your model. The printer name is slightly different. If you get an option to allow Cura to install a new printer - do it. If you have done any customizing to your printer setup in Cura (StartUp Gcode, etc.) you don't want it to get over-written by this project file. GV Exhaust vent bottom modified.3mf

I removed 5.7.0 and all its data files including the ones under AppDate then installed 5.7.1 It still won't accept the file at 100%. If I try to scale down from 100% to 99% it won't work. But if I scale it down to 95% then scale it up one percent at a time I can get it to 99% but not 100%.