Ender 3 S1 Pro (F401) latest firmware ignoring Cura settings

[necrolingus 0]

Hi everyone

 

Printer: Ender 3 S1 Pro with the F401 chipset

Printer Firmware: Ender-3 S1_Pro_JPN KR_HWv24S1_301_SWV2.0.8.28F4_F401_FDM_LASER (Firmware)

Cura Version: 5.6.0

 

Today I upgraded my Ender 3 S1 Pro with the F401 chipset to the latest firmware from Creality's website. I installed the screen and motherboard firmware according to their instructions.

 

I used my usual Cura profile to run a test print, just to make sure everything is fine, and everything turned out great. 

But, I then realized that after the firmware upgrade, my printer is ignoring a lot of Cura settings, especially the settings related to speed and acceleration. I proceeded to slow down my print, by a lot, so that the difference in speed will be obvious, but my printer still just prints full speed. (I tried multiple different 3d models, both bigger and smaller ones, but all with the same results).

I also removed my Ender S1 Pro from Cura and added it again, just in case, but no change.

 

I have no clue if this is firmware related or if the firmware expects "different" Gcodes now that Cura does not provide in the GCode file. I guess I can just downgrade the firmware again then everything will be fine, but I am hoping one of the community members might have some advice.

 

I attached my Cura project file for one of my test print as well as the GCode file for the same test print. I also attached the profile that I used.

 

Any help will be greatly appreciated.

 

 

Project.3mf newCuraSlow.gcode

Leigh Dec 2023 - LatestSuperSlow.curaprofile

Edited February 17 by necrolingus
Added profile

[jaysenodell 13]

Are you printing from SD card or via OctoPrint? 

 

I have the same setup and I generally print from Octo. I print with reduced rate with no issues. If you are printing from SD, I'll move one of my "reduced rate" prints to the SD and see what it does. 

[Slashee_the_Cow 269]

It's a firmware thing, and not just yours, a deliberate choice on Creality's part. My Ender-3 V3 SE (both on stock and latest firmware) ignores speed and acceleration limits on prints from an SD card so I have to limit the speeds in the machine's firmware. Which is annoying as hell when you're using different materials (i.e. TPU likes to print reeeeeeeal slow). That's one of the reasons why I started using option B:

 

Printing over OctoPrint is fine because it's only getting one command at a time and doesn't know what'll be coming up so it can't try and plan ahead like that (like if you know you're going to hit a concave corner, you can't go too fast or your jerk will be way too high).

 

The marketing for the E3V3SE bragged about being able to print at 250mm/s and accelerate at 4000mm/s² (until the E3V3KE came out because it goes even faster). Neither of those are particularly good ideas, unless you're using high speed PLA on a printer held in suspension that will stop the large vibrations that can come with moving and turning so fast.

 

At default acceleration it even started pulling parts of my (PLA) model with it when it started a travel move because it just zoomed off before it had a chance to set (that's why I wrote my own post-processing script to limit acceleration while printing support (yes I know that is an option in Cura) but also on the travel moves before and after the support (which is when it was getting pulled) and Cura just uses the travel acceleration rate for those.

Edited February 17 by Slashee_the_Cow

[jaysenodell 13]

My e3s1p is printing from SD and seems to be respecting cura speed limits. This is the 1.0mm noz project.  Same code I ran through octo. 
 

Do we have some simple code that we can try that will work with any noz size? I’m not in a position to swap right now. 

[Slashee_the_Cow 269]

3 minutes ago, jaysenodell said:

My e3s1p is printing from SD and seems to be respecting cura speed limits. This is the 1.0mm noz project.  Same code I ran through octo. 

In your case it might be limiting itself purely because it's reached its maximum flow rate and therefore can't print any faster (watch for travel moves). It also depends on the model you're printing, some it doesn't try to speed up on because it doesn't think it can do so without compromising quality.

Edited February 17 by Slashee_the_Cow

[jaysenodell 13]

Giant oval tube 😁

 

I know the printer will print it faster. If you recall we agreed that I needed to slow the printing for the 1mm snoz. It’s printing those speed adjusted files off the SD. No idea what I’m doing differently than you folks. 

[Slashee_the_Cow 269]

Printing tubes, especially if you're using @ahoeben's awesome Arc Welder plugin to convert Cura's curves-by-a-lot-of-straight-lines into arc moves on printers that support them.

 

It largely does its own thing on linear moves, the longer the more likely.

[jaysenodell 13]

Well… there you go. 
 

I will say that the cubic infill lines are respecting speed limits. Maybe it’s the newer hardware? Or I’m just getting lucky. 

[necrolingus 0]

Hi @jaysenodell I'm printing from an SD card. I've always used an SD Card, on both the old firmware that respected Cura as well as the new firmware that is not listening to Cura anymore.

 

@Slashee_the_Cow I've considred going Octo, but I like the simplicity of the SD Card (for now). Its just strange that all other settings such as brim, top layers, etc are all still fine (by fine I mean the printer uses whatever I set in Cura), but it is just the speed and accaleration that the new firmware seems to be ignoring.

 

I'm doing a reset (from the display attached to the printer) now, just to see if that won't fix anything. Will post my results here as an edit.

 

Update: The reset did not work.

Edited February 18 by necrolingus
Posting the results of my test

[Slashee_the_Cow 269]

4 hours ago, necrolingus said:

I like the simplicity of the SD Card (for now).

No arguments here. I just do it the complicated way:

a) because I like to do things the complicated way where I can - I don't think there's any OctoPrint feature I can't live without, the most interesting (and useful to me) is watching the webcam, but I can do that from my regular computer with a USB extension cable - and if I do it that way, it's a hell of a lot less compressed, and sending commands over USB when when needed (something which can also be fixed with a USB extension cable to reach my PC)

b) because I had a Raspberry Pi 3 B+ that wasn't doing anything after I replaced it with an RPi 4 for my Piputer (boots quick, does most anything I want to do, much bigger screen to do stuff on while laying in bed than my phone).

 

4 hours ago, necrolingus said:

Its just strange that all other settings such as brim, top layers, etc are all still fine (by fine I mean the printer uses whatever I set in Cura), but it is just the speed and accaleration that the new firmware seems to be ignoring.

Pure speculation here: maybe it doesn't mess with the bottom layer or the top few layers, where doing it too fast is much more more likely to cause noticeable problems? There's probably some info about it on the Creality subreddit if you dare to look. (I don't dare, the quality of Reddit seems to have gone downhill even without interference from Elon Musk.)

 

I just use the printer's control panel to set reasonable limits, it seems to follow the ones in its firmware. But annoying if I need to do something like print TPU, which likes to go slooooooooooow (for best results I do it at 20mm/s).

 

8 hours ago, jaysenodell said:

I will say that the cubic infill lines are respecting speed limits. Maybe it’s the newer hardware? Or I’m just getting lucky. 

Don't update your firmware.

[necrolingus 0]

@Slashee_the_Cow Lol I like your comment about Elon and Reddit. I found 2 posts on Reddit where people have the same issue, but they don't seem too phased about it. To be honest, the printing speed and quality is a lot better with the new firmware, even on full blast, but I like things to work the way they were intended to work.

 

That said, I THINK I might have found a possible solution. According to a thread on Github, you have to flash the screen firmware first, and THEN the motherboard. I did it the other way around. Just finishing off a print then I will flash the motherboard again. Will keep you guys posted.

 

Thanks for all the input! 

[Slashee_the_Cow 269]

47 minutes ago, necrolingus said:

That said, I THINK I might have found a possible solution. According to a thread on Github, you have to flash the screen firmware first, and THEN the motherboard.

Good thing it's so easy to convince these things a firmware file is newer than the installed version. Bad thing is it's so easy to accidentally load an earlier version of the firmware. Or a good thing, when an update breaks something.

[necrolingus 0]

Ok yeah updating the firmware again did not fix it. Sigh. Back to Googling and trying to find a solution. Otherwise this might be the swift kick that I need to switch over to Octa. I also have a Raspberry Pi 3b+ lying around looking for work.

[jaysenodell 13]

Octo  serves a purpose for file management, system visualization, workflow automation, and general nerdiness. It also allows you to bypass much “vendor optimization” in any firmware effectively letting yo make your own “pseudo-firmware” sitting in front of your printer. 
 

Add enclosure hardware and it’s an easy “enclosure controller” as well. 
 

basically… I’m a nerd. 

[jaysenodell 13]

I think I just remembered the latest firmware did something to the input shaping default settings. I can’t remember what I set to put it back. Give me a bit. 

 

edit:

Nope. not on the e3s1p running running marlin. Had by brain cells crossed. 

Edited February 18 by jaysenodell
correcting incorrect thought

[necrolingus 0]

On 2/18/2024 at 3:53 PM, jaysenodell said:

I think I just remembered the latest firmware did something to the input shaping default settings. I can’t remember what I set to put it back. Give me a bit. 

 

edit:

Nope. not on the e3s1p running running marlin. Had by brain cells crossed. 

Lol thanks @jaysenodell I appreicate you sharing this. For now I'm just reducing the speed on my printer using the screen until I get time on the weekend to fire up Octo.

[necrolingus 0]

Figured I will post an update here. I downgraded my printer firmware to Feb 2023 firmware. But, same issue, it just prints full speed! It does not seem to care about the print or accaleration settings from Cura. So this is most likely not a firmware issue some other random obscure thing I have no clue where to check...

[Slashee_the_Cow 269]

9 minutes ago, necrolingus said:

So this is most likely not a firmware issue

Could depend on your definition of "issue". Several Creality printers ignore speed/acceleration settings from gcode files. At least on my E3V3SE, I can use the control panel to manually turn down the max speed and acceleration because nobody needs to be accelerating at 4000mm/s² anyway! (Although that's not to say that that's what's happening in your case.)

 

I think the reason it happens when you print from the printer but not OctoPrint is because the printer can preprocess the whole gcode file if it's printing it itself, so can figure out where it can break the speed limit, whereas OctoPrint spoon feeds it commands line by line so it doesn't know what's coming.

 

You could try adding something like

M201 X1000 Y1000 ; limits acceleration on x and y axes to 1000 mm per second per second
M203 X100 Y100 ; limits max speed to 100mm/s on x and y axes

to your startup gcode (replace values if you choose) and see if it at least follows them even if it ignores the feed rate in the gcode.

[necrolingus 0]

Thank you! I will check if those gcodes are in my gcode file otherwise add them manually and see how it goes.

[necrolingus 0]

OK, all back to normal again. Just did a couple of prints and my printer is listening to Cura again. Not sure what happened with the first print after rolling back firmware, but all is good. Thanks for everyone's support!