Elegoo Neptune 4 / Pro / Plus / Max Definition Updates

[mastercaution]

Description

• Add definitions for Neptune 4 Plus and Max 🥳
• Updated acceleration configuration
• Change default infill to prefer "Grid" when infill density is low
• Updated end G-code: Preset the print with Y{machine_depth - 5} instead of Y{machine_depth} to avoid unnecessary stress on the motors and belt when approaching machine_depth. (Formulas in G-code supported since Cura 5.6)
• Updated N4 / 4 Pro start G-code. Basically, the nozzle touches the print bed during heating, so nothing comes out. Then it prints only one line but twice the length compared to the old code. This should minimize the possibility that the nozzle produces and picks up filament chunks during the start procedure (which happened a lot with the old procedure).

N4 Plus / Max definitions and the new start G-Code are based on Elegoo Cura profiles (v4.8.0_20231208)

🧪 How to quickly test these profiles?

Instead of building Cura yourself, you can use your current Cura install for testing. Simply download the new profiles from my release page, extract the .zip and follow the Readme.txt. It's basically copying the new profiles into Curas configuration folder.

Type of change

• Printer definition file(s)

How Has This Been Tested?

❗ If you have a N4 Pro, Plus or Max, I would love to hear feedback on how the profiles work for you :)

Tested with Cura 5.6.0:

• Printed models on Neptune 4
• Printed models on Neptune 4 Pro (Thanks to @BremerButjer, @gsthnz, @ArthurREGNARD, @NovaScotianNorse, @ToasterUwU)
• Printed models on Neptune 4 Plus (Thanks to @CharlKlein)
• Printed models on Neptune 4 Max (Thanks to @si0ls, @AlbeDarned)

Test Configuration:

• Operating System: Arch Linux (Linux 6.6.4)
• Operating System: Windows 10

Checklist:

• My code follows the style guidelines of this project as described in UltiMaker Meta and Cura QML best practices
• I have read the Contribution guide
• I have commented my code, particularly in hard-to-understand areas
• I have uploaded any files required to test this change

[mastercaution]

Thanks for testing! Your printer behaves very different compared to mine. I just tested it with manual preheating to 205 and 60 (bed). When I start the print, it immediately starts to home all axes and then it starts to print the line at the edge of the print bed. Everything as expected. There is no waiting for the nozzle to cool down to 140.

Between homing and printing the line, the nozzle target temperature is indeed set to 140 but the printer does/should not wait for it (G-code M104). So in case that the nozzle is already at printing temperature, the heating is just paused for a few seconds during homing.

And this: "Basically, the nozzle touches the print bed during heating, so nothing comes out." confuses me, as it does not do this behaviour when a print is started. It does it's initial two probe tab, then raises up above the bed and waits until the nozzle is heated before proceeding.

Maybe there went something wrong during updating the presets. Can you please post your start G-code from: Settings -> Printers -> (Your Preset) -> Machine Settings -> Start G-code?

[gsthnz]

Currently testing this, N4 Pro, on the Visual - Fine profile

Previously, I had a small blob of filament in the center of the build plate, which I had to remove by hand on a print start, now that does not happen anymore :)

EDIT:

There is no waiting for the nozzle to cool down to 140.

I can confirm this, it does not wait to reach 140 :)

[schneid-l]

Tested profiles on my Neptune 4 Max, I'm very satisfied with the result, far better than the Elegoo custom Cura version!
Tested with multiple parameters combinations, works really great!

[CharlKlein]

Need a Hand Testing on a Neptune 4 Plus ?

[mastercaution]

@CharlKlein Yes, it would be great if you could print some models using the new profiles and share your experience. If you are satisfied with the results, I would mark the PR ready for review.

[CharlKlein]

@CharlKlein Yes, it would be great if you could print some models using the new profiles and share your experience. If you are satisfied with the results, I would mark the PR ready for review.

Print in Progress

[CharlKlein]

Results on the Plus look great. Purge line is clean. Temperatures are good.

Just curious about the preheat to 140 then printing temps. It that common on the elegoo's. Relatively new to the brand.

[mastercaution]

Just curious about the preheat to 140 then printing temps. It that common on the elegoo's. Relatively new to the brand.

It's also a recent change Elegoo made to their profiles (for the Elegoo branded Cura version). Preheating to 140 should prevent filament dripping from the nozzle, which usually starts at higher temperatures. But it is important, that the build plate is heated before homing because the Z-sensor reads quite different values depending on the bed temperature.

[AlbeDarned]

Hello,

Thank you for taking the time to do this. It's nice to be able to use the most recent Cura.

I have a N4-Max and most things seem to be excellent, only having just loaded the files. I did note a couple things:

1. The "nozzle_disallow_areas" in the max json need to be adjusted for the build plate size (I just added +/-100 to the values and it seems to be good enough).
2. A small cosmetic thing - The " ELEGOO" of the logo isn't on the build surface.

Again, thank you!

[mastercaution]

@AlbeDarned Thank you so much for testing and reaching out!

1. The nozzle_disallow_areas of the in the max definition is a copy-paste-error! I'm glad you noticed that 😅. The values are actually +- 215 and 211. This should disallow the outer 4mm of the build plate (like on the N4 Plus profile).
2. Ah yes, I'll fix that.

[mastercaution]

Fixed. New version can be found here (link in original comment also updated)

[schneid-l]

I've ordered 0.2, 0.6, 0.8 and 1.0 mm nozzles from Aliexpress (hoping they'll be compatible with the Neptune 4 Plus as indicated by the seller).

I'll try to create the nozzle profiles once I've had a chance to test them.

@mastercaution Do you think I should contribute to this PR or another dedicated one?

[mastercaution]

@si0ls Nice! My experience is that these PRs take quite some time to get merged. And even if they are on main, it is not guaranteed that they will be part of the next release (see #16819). So feel free to contribute to this PR, if you want the changes to be added together ^^

[ToasterUwU]

@mastercaution I tested the new config while at my parents place. Seems to be working fine c: In fact its way better than any other one I ever used. No problems so far and I'm already past any point of failure.

Great work, thanks for your time and effort!

[ToasterUwU]

@mastercaution i just updated my N4 Pro to the newest firmware, and with that, there will be a critical failure with your profile. After finishing the print it will run the end gcode, which contains G1 X0 Y{machine_depth - 5} ;Present print. Klipper cant parse that, saying "Unable to parse move" followed by that line. Im not sure whats wrong about it, all I know is that klipper will show an error and the printer will scream of the top of its lungs with the built in beeper for about 5 seconds.

[ToasterUwU]

If i replace the {} part with the value it should result in (225) it works without flaw. So I think cura is unable to replace that part for some reason and leaves it in, which klipper doesn't unterstand

[ToasterUwU]

So I did a tiny 3 minute amount of digging and I think the issue is the neptune 4 printer Definition. The pro one inherents its machine_depth value from there.
I noticed that there is a "default_value" set, but not a "value", which seems odd to me since the depth of the printer isn't something people (can) change, so why have a default value and not a fixed value.
So maybe the key of the value 230 is wrong and has to be "value" instead.
But I didn't have enough time to go digging for the documentation and check, just a uninformed suspicion.

[DjFingers]

@mastercaution i just updated my N4 Pro to the newest firmware, and with that, there will be a critical failure with your profile. After finishing the print it will run the end gcode, which contains G1 X0 Y{machine_depth - 5} ;Present print. Klipper cant parse that, saying "Unable to parse move" followed by that line. Im not sure whats wrong about it, all I know is that klipper will show an error and the printer will scream of the top of its lungs with the built in beeper for about 5 seconds.

It gave me the same error , im running N4 Plus

[mastercaution]

@ToasterUwU @DjFingers I'm currently investigating this issue but so far I was not able to reproduce it. In my tests, running the stable version of Cura 5.6.0, the {machine_depth - 5} token gets replaced by the corresponding number. What exact Cura version are you using?

If i replace the {} part with the value it should result in (225) it works without flaw. So I think cura is unable to replace that part for some reason and leaves it in, which klipper doesn't unterstand

Exactly. And if something goes wrong while parsing the expression, Cura should print a corresponding error message in the logs ("Unable to do token replacement on start/end g-code" or "Parse error in function ..." or similar). Can you find such errors in the logs?

I don't think that the issue has something to do with default_value. I suppose that the - 5 may be the cause because I didn't see any other definition actually calculating things in such a gcode expression and there have been recent changes to the parser. Does the issue still persists if you remove the "- 5" from {machine_depth - 5} in the end gcode?

Thanks for helping ^^

[ToasterUwU]

@mastercaution i use 5.5 cura since that's the latest version I can get from the Flatpak currently.
I will replace it with the original line ant test everything when I'm back home today.

[mastercaution]

@ToasterUwU Ahh indeed, on Cura 5.5 and 5.4 I can reproduce this. Removing the "- 5" solves it. Looks like formulas in expressions are supported since 5.6 but not earlier (see c3f3a86)

The "- 5" was a change I made to avoid unnecessary stress on the motors and belt.
So instead of removing the formula, I would say that these profiles work for 5.6+ only, because when they get merged, they will be supported. Ok?

[RyanWhipple]

@mastercaution I see your suggestion above that additional changes should go in this PR vs opening a new one. So even though this is a different topic than adding support for new machines, I'll ask my question/make my suggestion here. Also I've only been 3d printing a year and getting deep into Cura profiles for 6 months, so I'm asking more from learning than from advocating a particular change...

It makes sense to me that the Balanced intent has 4 quality levels/layer heights to give people most options in the general-purpose intent, and it makes sense that Visual and Draft have two quality levels that match their ends of the spectrum, but I'm not clear why Engineering is limited to just Fine - 0.1mm and Normal - 0.15mm.

For my use cases, I like Engineering intent's slower print speeds, thicker walls and tops/bottoms and all of the benefits that brings. But it seems like with a 0.4mm nozzle, it wouldn't be unreasonable to have a 0.2mm or even 0.25mm option layer-height option baked-in. Are there conventions around appropriate layer-height-to-nozzle-size ratios for different intents, or perhaps 0.15mm is a conventional cutoff for functional parts, or is this just a case of "no one wanted it enough to do it?"

If it's just the latter, I'd be happy to make, test, and contribute some additional layer height settings for Engineering for consideration in this PR. Just let me know!

[jellespijker]

Nice to read through this PR and all the busy chatter; I do see some open discussions/questions, if you guys are still working on it, fine-tuning and improving can you put the PR in draft. If it is finished feel free to request a review from me.

[mastercaution]

@RyanWhipple There is no layer-height-to-nozzle-size convention I know of 😅. I think a 0.2mm profile for engineering would be a great addition, but I would'n go any higher.

According to this article, the engineering profile is for dimensional accuracy and I think layer heights above 0.2mm are not really accurate anymore ... but maybe I'm wrong ^^. If anyone wishes to print with the engineering intent profile but an arbitrary layer height, they can always change it in the advanced settings.

Adding the 0.2mm profile is basically just copy-paste because the intent profiles are largely parametrized. I'll do it real quick if you don't mind.

[RyanWhipple]

Adding the 0.2mm profile is basically just copy-paste because the intent profiles are largely parametrized. I'll do it real quick if you don't mind.

Sure, that sounds great, and I'll be happy to run some test prints using it over the next couple of days.

[ArthurREGNARD]

@RyanWhipple ,
In same way, I do not understand why materials can’t override speed settings.
Between PLA standard and PLA+ the speed is not the same.
Between TPU and PLA the speed is not the same to.
Every time I change material I have to set the speed and this is boring …
Is it possible to add speed settings in materials that override profile settings ?

[mastercaution]

@ArthurREGNARD The quality settings overwrite the material settings. In the first place I thought this is unfortunate but it's actually more complicated. Your print speed depends on a lot of factors (the material, the quality profile, the printer, nozzle size, layer height, ...). Not every material profile provides speed values. I already parametrized as much as I could but I'm missing some guidelines on how to coordinate all definitions together. What stage should provide absolute values? I think this needs the thought of much more experienced Cura developers than me and is out of scope for this PR.

Currently, we can add new quality profiles and quality intend profiles for other materials. I cannot do it, because I only have experience with PLA. You are welcome to contribute profiles :)

[RyanWhipple]

@mastercaution I printed some Multiboard 8x8 tiles with the .2mm setting. They turned out well. Of course, no reason to expect they wouldn't, but always nice to confirm.

[ToasterUwU]

@mastercaution Hey, just wanted to ask why this is still marked as draft, is something missing? If so, can I help somehow?

[mastercaution]

@ArthurREGNARD @si0ls If you are currently working on additions to this PR please open a PR (draft) to this branch on my fork, then I'll wait for them to be completed. Otherwise, I'll mark this PR as ready.

[ArthurREGNARD]

No need to waiting me. I will work on it later :)

[schneid-l]

I still haven't received the new nozzles, so I think that will be a dedicated PR later ;)

[ToasterUwU]

Cool, in that case we undraft this, and give a ping to the member who offered to review this c: Im excited to see this be part of the next release

[ToasterUwU]

@mastercaution Sorry for the ping again, but now that both people have said we can continue, shouldn't we mark this as ready and ping the Member who offered to review this?

[mastercaution]

@ToasterUwU There's a PR on my branch that I want to handle first. Don't worry, I'll request a review soon, just be a little patient ;)

[mastercaution]

@jellespijker This PR can now be reviewed :)

[jellespijker]

great I will take a look after the weekend. but judging from the chatter I think it will be a quality PR

[jellespijker]

Sorry guys, I was called away this week, I might look at this in the weekend if I find some time or maybe next Monday. But I think we can get it in before the next release for sure, do no need to worry about that

[jellespijker]

LGTM; Great work people!
It should be shipped with the 5.7 release