Fix regression in AnkerMake profiles

[Patnnn]

Reverting the changes that got introduced with the merge request #7117.

This should fix #7633

In addition, this PR swaps the jerk setting from the machine limits tab and the print profile. These were accidentally swapped when @Xelinor initially created these profiles. This should remove the warning that the jerk settings exceed the printer limits.

[robertbaker]

The M5 doesn't have this problem.
Compare the values yourself in anker's studio by adding a M5 and looking at the values compared to the M5C. I provided screenshots showing the values in Anker's Studio 1.5.24 (latest as of writing)

M5:

M5C:

M5:

M5C:

M5:

M5C:

M5:

M5C:

[robertbaker]

also just an FYI. Instead of making a new commit for a revert, it's proper and much better just to do a git revert instead of changing the values in a new commit.

[robertbaker]

[Noisyfox]

How on earth does a 3mm retraction is ever needed for a DDE printer?

[Xelinor]

How on earth does a 3mm retraction is ever needed for a DDE printer?

It isn't. Anker's values in their slicer are not a trustworthy source of truth.

[robertbaker]

Thank you @Xelinor for the info. I submitted a PR to revert the change. It worked fine for the M5 and since the M5C has identical values, I had no idea it would cause such an issue for the M5C.

#7659 fixes the issue and does a git revert, so this PR can be closed.

[Xelinor]

Thank you @Xelinor for the info. I submitted a PR to revert the change. It worked fine for the M5 and since the M5C has identical values, I had no idea it would cause such an issue for the M5C.

Saw that, it's all good man, that said, there is ALSO a change in this PR that is worthwhile. The Jerk settings in the actual print profile are set higher than what is technically the machine limit, and they SHOULD be swapped. It's an old error I made and haven't had the time/headspace to fix.

[robertbaker]

@Xelinor in that case it's better for git purposes to revert the commit first and modify or make a new PR with that change. It's just better for git history and other reasons to do it that way.

[Xelinor]

@Xelinor in that case it's better for git purposes to revert the commit first and modify or make a new PR with that change. It's just better for git history and other reasons to do it that way.

Yep, no, I totally agree with you there, just an fyi

[robertbaker]

@Xelinor if you could tell me what to change I can do that PR now unless @Patnnn wants to do it. I don't mind either way.

[Xelinor]

@Xelinor if you could tell me what to change I can do that PR now unless @Patnnn wants to do it. I don't mind either way.

It's fine, looking at the way @Patnnn submitted it, it's not quite correct either, I'll take some time tonight and get a submission done to finally get this off my to-do list. Jerk can probably be set a bit higher for fast mode then for the non-fast mode profiles, so that needs to be adjusted and validated too, and I have the files already set up to do the test prints so I'll just do that and make the changes.

[Patnnn]

also just an FYI. Instead of making a new commit for a revert, it's proper and much better just to do a git revert instead of changing the values in a new commit.

Thanks for the info. It was my first GitHub commit ever. So I'm not really have any experience on how to do this correctly. I will close this PR for now