Creality CR-6 SE

[thinkyhead]

Rebase of #19955 by @Sebazz

---

With this pull request I'm looking for some early feedback on the Creality CR-6 SE changes. I don't expect this to be merged at all, but I hope that we can get some feedback how to improve this so it might be merged upstream some day.

Requirements

The famous Kickstarter Creality CR-6 has a firmware based on an early version of Marlin 2.0 (I traced it back to commit 25a7ceab where the fork was made). About a month ago the source code was released, and after tracing the origin I've started re-implementing the changes on top of Marlin 2.0.x-bugfix - so essentially making Marlin 2.7.1 available to the users.

The main pain point was the "spaghetti" that is the touch screen interfacing code. We have been re-implementing this on top of ExtUI, which allowed some large switch statements and opaque code, including a home-baked filament runout detection, to be cleaned up.

We've made the following extensions to the base functionality of the CR-6 SE:

• Folder support: The CR-6 SE natively only allowed gcode files in the root directory and maximum of 5 pages of gcode files. Besides this, only 8-character limit on files was allowed.
• Integrate with Marlin filament runout: The Creality filament runout was home brew, did not do any debouncing and quite sensitive to false positives (and didn't even allow disabling via gcode)
• Add M300 speaker support: The main board does not have a speaker, but the touch screen does. We can't set the pitch, but we can set the duration.
• Add ADVANCED_PAUSE_FEATURE support, like M600 filament change
• Add EMERGENCY_PARSER (M0) support
• Use Marlins own print timer instead of the print timer of the touch screen
• Add gcode support for the LED
• Fixed some bugs like preheat settings not being saved/persisted

Description

The Creality CR-6 SE has two distinct features that require new support in Marlin:

• Auto bed leveling using the nozzle - the entire hot-end is attached to a strain gauge you can also find in your average kitchen scale. The hot-end is lowered to the bed, and using a threshold determine by a small potmeter, a signal is send that is interpreted as a Z-endstop trigger. This is done for homing and leveling the entire bed. Although the strain gauge / hot-end daughter board is powered by a 32-bit STM processor, there is no real communication between the mainboard and the daughter board. Because the strain gauge can trigger at any time, an optical sensor is used for determining when to "listen" to the strain gauge. Only when the optical sensor is triggered (which is determined by a metal piece - in hardware), then the strain gauge is activated. It is a bit of a double edged sword though, if the strain gauge is set too sensitive it will trigger too early and cause bad bed leveling or homing to fail, if the strain gauge is set with a too low sensitivity, the entire hotend is driven into the bed with force. But that is not something firmware can fix 😀

• DWIN DGUS touch screen - The Creality CR-6 SE features a touch screen from DWIN, similar to the Ender 3 V2 except a somewhat more advanced model it appears. We've been developing a separate firmware for that.

The following is thanks to the Ender 3 V2 already implemented:

• Support for onboard EEPROM. I did notice that unlike the Creality firmware, in latest Marlin, power loss recovery appears to go through the SD card still.

Configurations

For now I've included them inside the pull request.

Related Issues

None - as far as I'm aware.

Additional notes / questions

• Watchdog - Creality configured a watchdog timer but it appears that the watchdog is not used (enabled) at all?

• Optical switch triggering of strain gauge - I was not sure where to place this code.

• G29 leveling heats the bed - Added a new configuration option AUTOLEVEL_NEEDS_PREHEATING. The Creality implementation of the leveling preheats to at least 120 degrees C, possibly to account for metal expansion of the nozzle or hot-end. So, leveling requires a certain temperature.

• Extensible UI extensions

  • Disable/enable steppers - Allow disabling of steppers to be communicated to the touch screen

  • More callbacks to ExtUI regarding the leveling process - It was quite hard to get leveling reliable without explicit callbacks when leveling starts or when a point was probed. This is shown live on the display.

  • Callback when a print is completed

  • Callbacks when homing is being done

• Implementation of touch screen interfacing code - The existing touch screen interfacing code that was already present for DWIN did many assumptions which don't hold true for the Creality implementation. Among others, in the Creality firmware the VP (virtual pointers) are reused across pages or even within the pages. What is a cooldown button on one page, is a "save preheat settings for PLA" on another page. The callback structure does an assumption that a single VP is a single button, in addition to what the values of those buttons are. It doesn't hold true for the Creality touch screen, nor is it easy to change/refactor that touch screen - not in the least due to the buggy DWIN editor. Also, I've encountered some weird issues with the particular piece of hardware of the CR-6 that required me to add some duct tape to the communication code. I don't like that I had to copy code, but I think that plastering more preprocessor code on top of that would not have benefit the code either.

[Sebazzz]

I want to be clear, because I don't think I had been: we're still doing stability testing on this - but I'd like to get early feedback, so when we act on that feedback we catch any resulting bugs early :)

[Sebazzz]

(Besides, I don't want you to waste your time cleaning up any mess I made 😀 )

[thinkyhead]

we're still doing stability testing on this

This has been updated to the latest codebase for maximum relevance and to accelerate integration. Today I'll continue to refine this PR, first to get it compiling, and then to merge the extui/lib/creality_dgus folder into the extui/lib/dgus folder. Once this branch is whipped into shape, it will be at a proper starting point to go forward with additional refinements.

[Sebazzz]

I've some additional input on the use of the COM_PIN:

When COM_PIN is set to 0 it turns off reporting of the Z-endstop. To test this, move the hot-end so it is triggered (blue led), then set COM_PIN to LOW (via M42 P5 S0). The blue LED will turn off.

M119 also says that z_min = open. When you then turn on COM_PIN to 1, the Z-endstop is still not triggered.

If you then apply even more force to the strain gauge, it is then triggering again. So the combination of COM_PIN 0, a delay, and COM_PIN 1 is essentially the act of pressing the "tare" or "zero" key on your kitchen scale. It is self-calibrating (when the Marlin tells it to) which begs the question what that potmeter is even doing there. Maybe all it defines is the threshold. You tare it via firmware, but the threshold (how many "grams" it takes for it to trigger) is set via the potmeter.

So, based on the above, the strain gauge reset needs to happen:

1. Just before homing in the Z direction
2. When leveling after moving to the correct X/Y position but before lowering to the bed.

[bretterer]

So, I have been trying this PR to give you feedback on functionality, and I don't believe this is anywhere ready because I can not even get this to build.

After cloning this PR and testing it with the config found at https://github.com/MarlinFirmware/Configurations/tree/bugfix-2.0.x/config/examples/Creality/CR-6%20SE, I get the following errors:

Terminal Errors

Marlin/src/lcd/extui/dgus_creality_lcd.cpp: In function 'void ExtUI::onPlayTone(uint16_t, uint16_t)':
Marlin/src/lcd/extui/dgus_creality_lcd.cpp:70:19: error: 'class DGUSScreenHandler' has no member named 'Buzzer'
ScreenHandler.Buzzer(frequency, duration);
^~~~~~
*** [.pio/build/STM32F103RET6_creality/src/src/lcd/extui/dgus_creality_lcd.cpp.o] Error 1
Marlin/src/lcd/extui/lib/dgus/creality/DGUSDisplayDef.cpp:42:10: fatal error: PageHandlers.h: No such file or directory


Looking for PageHandlers.h dependency? Check our library registry!

CLI  > platformio lib search "header:PageHandlers.h"
Web  > https://platformio.org/lib/search?query=header:PageHandlers.h



#include "PageHandlers.h"
^~~~~~~~~~~~~~~~
compilation terminated.
*** [.pio/build/STM32F103RET6_creality/src/src/lcd/extui/lib/dgus/creality/DGUSDisplayDef.cpp.o] Error 1
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:85:82: error: macro "TERN_" passed 3 arguments, but takes just 2
RequestScreen(TERN_(SHOW_BOOTSCREEN, DGUSLCD_SCREEN_BOOT, DGUSLCD_SCREEN_MAIN));
^
In file included from Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../core/boards.h:24:0,
from Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/MarlinConfigPre.h:37,
from Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:28:
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp: In static member function 'static void DGUSDisplay::InitDisplay()':
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:84:34: warning: init-statement in selection statements only available with -std=c++1z or -std=gnu++1z
if (TERN1(POWER_LOSS_RECOVERY, !recovery.valid())
^
Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../core/macros.h:416:26: note: in definition of macro 'THIRD'
#define THIRD(a,b,c,...) c
^
Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../core/macros.h:196:29: note: in expansion of macro '___TERN'
#define __TERN(T,V...)      ___TERN(_CAT(_NO,T),V)  // Prepend '_NO' to get '_NOT_0' or '_NOT_1'
^~~~~~~
Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../core/macros.h:195:29: note: in expansion of macro '__TERN'
#define _TERN(E,V...)       _TERN(CAT(T,E),V)    // Prepend 'T' to get 'T_0' or 'T_1'
^~~~~~
Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../core/macros.h:193:29: note: in expansion of macro '_TERN'
#define TERN1(O,A)          _TERN(ENA_1(O),1,A)    // OPTION converted to A or '1'
^~~~~
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:84:7: note: in expansion of macro 'TERN1'
if (TERN1(POWER_LOSS_RECOVERY, !recovery.valid())
^~~~~
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:85:5: error: expected ';' before 'RequestScreen'
RequestScreen(TERN(SHOW_BOOTSCREEN, DGUSLCD_SCREEN_BOOT, DGUSLCD_SCREEN_MAIN));
^~~~~~~~~~~~~
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:86:1: error: expected primary-expression before '}' token
}
^
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:86:1: error: expected ')' before '}' token
Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp:86:1: error: expected primary-expression before '}' token
*** [.pio/build/STM32F103RET6_creality/src/src/lcd/extui/lib/dgus_creality/DGUSDisplay.cpp.o] Error 1
In file included from /Users/bretterer/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/WString.h:29:0,
from /Users/bretterer/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/wirish.h:47,
from /Users/bretterer/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/Arduino.h:30,
from Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../HAL/./STM32F1/../shared/Marduino.h:36,
from Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../HAL/./STM32F1/HAL.h:32,
from Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/../HAL/HAL.h:26,
from Marlin/src/lcd/extui/lib/dgus_creality/../../../../inc/MarlinConfig.h:31,
from Marlin/src/lcd/extui/lib/dgus_creality/../../../../MarlinCore.h:24,
from Marlin/src/lcd/extui/lib/dgus_creality/DGUSDisplay.h:28,
from Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.h:26,
from Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp:26:
Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp: In static member function 'static void DGUSScreenHandler::DGUSLCD_SendAboutPrintSize(DGUS_VP_Variable&)':
Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp:167:54: error: 'Z_BED_SIZE' was not declared in this scope
sprintf_P(PRINTSIZE, PSTR("%dx%dx%d"), X_BED_SIZE, Z_BED_SIZE, Z_MAX_POS);
^
/Users/bretterer/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/avr/pgmspace.h:28:48: note: in definition of macro 'sprintf_P'
#define sprintf_P(s, f, ...) sprintf((s), (f), VA_ARGS)
^~~~~~~~~~~
Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp:167:54: note: suggested alternative: 'X_BED_SIZE'
sprintf_P(PRINTSIZE, PSTR("%dx%dx%d"), X_BED_SIZE, Z_BED_SIZE, Z_MAX_POS);
^
/Users/bretterer/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/avr/pgmspace.h:28:48: note: in definition of macro 'sprintf_P'
#define sprintf_P(s, f, ...) sprintf((s), (f), VA_ARGS)
^~~~~~~~~~~
Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp: In static member function 'static void DGUSScreenHandler::HandlePIDAutotune(DGUS_VP_Variable&, void*)':
/Users/bretterer/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/avr/pgmspace.h:28:59: error: expected primary-expression before ')' token
#define sprintf_P(s, f, ...) sprintf((s), (f), VA_ARGS)
^
Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp:890:11: note: in expansion of macro 'sprintf_P'
sprintf_P(buf, PSTR("M303 E-1 C5 S70 U1"));
^~~~~~~~~
Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp: In static member function 'static void DGUSScreenHandler::UpdateScreenVPData()':
Marlin/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp:1174:14: warning: unused variable 'x' [-Wunused-variable]
auto x = dgusdisplay.GetFreeTxBuffer();
^
*** [.pio/build/STM32F103RET6_creality/src/src/lcd/extui/lib/dgus_creality/DGUSScreenHandler.cpp.o] Error 1
========================================================= [FAILED] Took 52.51 seconds =========================================================
Environment             Status    Duration

STM32F103RET6_creality  FAILED    00:00:52.510
==================================================== 1 failed, 0 succeeded in 00:00:52.510 ====================================================

After resolving errors as they come up with file paths and things, this is what I get: The gist https://gist.github.com/bretterer/b16050e30d75f6d37305fdd236d78e9d has my diffs I had to do to even get close to building due to missing or bad file paths. Even then I still get an error that i can not determine what is going on.

I would love to assist more, but am lost as to how to get this to build.

[Sebazzz]

@bretterer I'm not sure if you're mentioning me or @thinkyhead but this is a work in progress by Thinkyhead so if you're looking to build it I suggest you start with the repository and branch the original PR was created on. 👍

[bretterer]

@Sebazzz, I guess I'm talking to @thinkyhead ... I did also try your original PR, but still no luck.

For this PR, I did the following

1. git checkout bugfix-2.0.x
2. git pull https://github.com/thinkyhead/Marlin/bf2_creality_CR-6_SE_PR 3: copied configuration from https://github.com/MarlinFirmware/Configurations/tree/bugfix-2.0.x/config/examples/Creality/CR-6%20SE into /Marlin 4: ran build from the auto build marlin plugin in VS Code

[Sebazzz]

This PR is still a work in progress in terms of getting it to compile. I'm not sure what your end goal is, but if you just want Marlin for the CR-6 SE then I suggest you check out the extui branch in the original repository 😊

Met vriendelijke groet, Sebastiaan Dammann

---

Van: Brian Retterer [email protected] Verzonden: Friday, November 6, 2020 11:46:37 PM Aan: MarlinFirmware/Marlin [email protected] CC: Sebastiaan Dammann [email protected]; Mention [email protected] Onderwerp: Re: [MarlinFirmware/Marlin] [WIP] Creality CR-6 SE code, examples (#19958)

@Sebazzzhttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSebazzz&data=04%7C01%7C%7C4749edbf092b42ef773d08d882a5d25e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637402995986632775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9O4p5mWn0873MMlAfEVosXxmVuLfLEwBnczlb%2FXN0h0%3D&reserved=0, I guess I'm talking to @thinkyheadhttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fthinkyhead&data=04%7C01%7C%7C4749edbf092b42ef773d08d882a5d25e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637402995986632775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vMxrP3Qkd7D17R6CXAqKbhja1rEK2Anh0YzewJ6gPIg%3D&reserved=0 ... I did also try your original PR, but still no luck.

For this PR, I did the following

1. git checkout bugfix-2.0.x
2. git pull https://github.com/thinkyhead/Marlinhttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fthinkyhead%2FMarlin&data=04%7C01%7C%7C4749edbf092b42ef773d08d882a5d25e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637402995986642771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=guPBwtHgGLVZ00r1iEpeDa3xPP3u0Qr00q38zwMkkIE%3D&reserved=0 bf2_creality_CR-6_SE_PR 3: copied configuration from https://github.com/MarlinFirmware/Configurations/tree/bugfix-2.0.x/config/examples/Creality/CR-6%20SEhttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FConfigurations%2Ftree%2Fbugfix-2.0.x%2Fconfig%2Fexamples%2FCreality%2FCR-6%2520SE&data=04%7C01%7C%7C4749edbf092b42ef773d08d882a5d25e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637402995986642771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hW6zfr20vy7Rke%2BjN5ARyQWEgn6Ygh3ZkkTemHh9CVY%3D&reserved=0 into /Marlin 4: ran build from the auto build marlin plugin in VS Code

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMarlinFirmware%2FMarlin%2Fpull%2F19958%23issuecomment-723333614&data=04%7C01%7C%7C4749edbf092b42ef773d08d882a5d25e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637402995986652765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z2DTDr7%2FefXjcgUsLSphJaaopAFsPeAITgETkFoQEZM%3D&reserved=0, or unsubscribehttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAK4FMLJGRWIJUWQJ76AKHDSOR4E3ANCNFSM4TET3BYA&data=04%7C01%7C%7C4749edbf092b42ef773d08d882a5d25e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637402995986652765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3hwehx6sg4xSsXqeMQxnQTOcKmN06e8HznhdD68Cvwo%3D&reserved=0.

[bretterer]

@Sebazzz My goal here was to help get this out by checking the status here. It seemed like it was a little further along since the configuration was already in the repo as Pre-tested Configurations for Marlin Firmware.

I would love to help get this out in any way I can. Please let me know what you both need and I am happy to lend a hand.

[thinkyhead]

@bretterer — Do you find this to be working at this point?

[bretterer]

I'll check in a little bit to see if it builds.

[bretterer]

It seems this is still not building through the VSCode auto build system.

This is the output of my build command platformio run -e STM32F103RET6_creality ; echo "done" >/var/folders/1v/7n6c3hvn2l58qmp4lzvq0f0w0000gn/T/ipc

build.log

[bretterer]

@thinkyhead looks like this latest update allows the code to build.

I am not able to upload the build to the cr6se tonight to give it a full test on the machine, but may be able to tomorrow after work.

Thank you so much for all you do!

[bretterer]

So the upload to the machine fails and makes the machine not boot. Not sure why or how to help you in debugging this.

Possibly waiting on screen assets?

[thinkyhead]

The screen code is the most unknown aspect of this. I've tried to merge the new screen code with existing screen code in the same family, but I haven't dived into testing on a real CR-6 SE yet.

I spent much of today bringing this up to date with the newest probe activation pin code, and exploring how the recent probe tare code compares with the original referenced PR. One main difference is that the probe is always kept in "tare mode" when not actually probing, so I've made that change here for the STRAIN_GAUGE_PROBE. This at least now compiles, but I expect there is still a bit more debugging and whittling-down left to do before it operates fully.

[thinkyhead]

@InsanityAutomation — The strain gauge probe on the CR-6 SE is kept in "tare" state all the time except when actually probing. Would that be a problem for the type of probe that you used in developing the tare code currently in Marlin, or any tare-able probe that you can think of?

[Sebazzz]

That really depends on the firmware on the probe itself. I think we reversed the CR-6 strain gauge firmware and came to the conclusion that a pin-change interrupt is used on the STM32 on the daughter board.

[thinkyhead]

I have heard rumors that there's a working CR-6 SE branch somewhere out in the wild. I should compare this with that and cobble together a final working version for merge….

[Sebazzz]

Which rumors?

[thinkyhead]

Rumors like… there's even a secret society… 😉 https://github.com/CR6Community

[Sebazzz]

I wouldn't know anything about that 😇

Let me know if you have any questions. Also happy to discuss it on Discord if that's easier 👍

[thinkyhead]

This is now up to date with the latest code. Please confirm that it is still functional. By now there may be some improvements to be found in other Marlin forks. I know the Ender-3 V2 display has been getting some enhancements, and the one in the CR-6 SE is not very different.

[Sebazzz]

@thinkyhead Do you think this is in a testable state yet? Then I'Il give it a go.

[thinkyhead]

Do you think this is in a testable state yet? Then I'Il give it a go.

Now it compiles, so that's a start! This is still based on not-so-recent code from the community fork, so I'll either need to rebuild this from the current state (based on 2.0.8.1, I believe) or just incorporate your latest commits since the time when this was last re-based on your fork. I'll grab your branch in its current state shortly, merge the latest bugfix into it, clean up conflicts, and then compare with this. You'll note that I recently consolidated a bunch of the DGUS code to remove redundancies, and made this display into a sub-class. Probably most of those changes will be about the same once I have the new base.

Anyway, feel free to give this a try in its current state and compare to yours. The main thing will be to make sure the code customizations sprinkled here and there are correct, and to make sure they only apply to CR-6 SE. I expect the display code itself will be the easiest part.

[Thinkersbluff]

Am I too "early" to be trying to test this on my CR6? I am able to compile Bugfix-2.1.x with configuration files I have tailored from the 4.5.2 motherboard example configs for my BTT SKR CR6 v1.0 board, but of course it is not "playing" with the CF6.1 Touchscreen firmware. Is "the display part" still pending, or is there another DWIN_SET I could try it with?

[thinkyhead]

@Thinkersbluff — This definitely still needs testing, and another round of comparison with the community firmware to make sure we have all the important boxes ticked.

[Thinkersbluff]

No Joy, again CF6.1 Touchscreen Firmware complains that the "Motherboard BootLoader must be confused..."

Two compile errors, with Source code from Bugfix2.1.1 branch on 5July2022, maybe irrelevant to my troubles... (see attached docx file) CompileErrors.txt

Tailored the CR6-SE Example Config files, to:

1. Work with my BTT_SKR_CR6_v1.0 motherboard, instead of the Creality 4.5.2 for which the example is written
2. Implement my machine-unique settings (esteps, Type1047 E0, etc..)
3. Implement my personal preference settings
4. Implement the CF6.1 settings that are different in the Bugfix example configs

I have annotated the two attached configs with a listing of the edits I made to each of Configuration.h and Configuration_adv.h, to try to run Bugfix2.1.1 on my CR6-SE (BTT_SKR_CR6_v1.0 motherboard, PT1000 nozzle thermistor, Direct-Drive (Orbiter1.5, Moons motor), DragonHF hotend, 0.9deg Y-axis motor, 25mm DD extruder motor)

NOTE: Some of the deltas from the CF6.1 Configs seem to be important! e.g.:

• PROBE TARE is LOW in the CF6.1 Configuration.h, but HIGH in the Bugfix 2.1.1 example

A complete listing of the deltas I observed are provided in the two attached files.

BTT_SKR_CR6_Configs_from_Bugfix2.1.1_MarlinFirmware_Configurations.zip

[rhapsodyv]

I just got a CR200B to play with, and I suspect it is very closer to CR6. The components positions in the board are very similar.

[Sebazzz]

I believe these pages are missing that were developed since I first opened the PR:

 { DGUSLCD_SCREEN_ESTEPS_CALIBRATION, VPList_EstepsCalibration },
  { DGUSLCD_SCREEN_PIDTUNE_CALIBRATION, VPList_PidTune },

  { DGUSLCD_SCREEN_TUNEFWRETRACT, VPList_FWRetractTune },

  { DGUSLCD_SCREEN_ESTEPS_CALIBRATION_RESULTS, VPList_EstepsCalibration },
  { DGUSLCD_SCREEN_LEVELING_SETTINGS, VPList_LevelingSettings },

  { DGUSLCD_SCREEN_AXIS_SETTINGS_NAV, VPList_AxisSettingsNav },
  { DGUSLCD_SCREEN_AXIS_SETTINGS_AXIS , VPList_AxisSettingsAxis },
  { DGUSLCD_SCREEN_AXIS_SETTINGS_TMC, VPList_AxisSettingsTMC },
  { DGUSLCD_SCREEN_ADV_MOV_SETTINGS, VPList_AdvMovementSettings },

  { DGUSLCD_SCREEN_MISC_SETTINGS, VPList_MiscSettings },
  { DGUSLCD_SCREEN_MESH_VALIDATION, VPList_MeshValidation },

  { DGUSLCD_SCREEN_CALIBRATE, VPList_Calibrate },
  { DGUSLCD_SCREEN_RGB, VPList_RGB},

Calibration, axis settings, TMC settings, mesh validation page, e-step calibration, leveling settings, firmware retract turning, PID calibration.

[rhapsodyv]

@Sebazzz what is the state of this work? Is there todo list or something like that? If can I get my board to work with marlin (board 4.2.5), I will probably help here