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.

[gerthalberg]

Is there a timeframe when this is planned to be merged?

[thinkyhead]

I see that you hve now added [CR-6 SE] to the Screen Section, does that mean that is is now possible to compile newest Marlin 2.1.2.2 and make it work on the CR-6 SE with Touch Screen?

There is still an incomplete PR for CR-6 SE that I haven't had time to work on. The documentation contains some things that are not in a release, as I'm just adding things as they come along. We are very short on help, so things are pretty scattershot.

[ETE-Design]

I see that you hve now added [CR-6 SE] to the Screen Section, does that mean that is is now possible to compile newest Marlin 2.1.2.2 and make it work on the CR-6 SE with Touch Screen?

There is still an incomplete PR for CR-6 SE that I haven't had time to work on. The documentation contains some things that are not in a release, as I'm just adding things as they come along. We are very short on help, so things are pretty scattershot.

@thinkyhead So that means that it is possible to use it, but it is not complete yet? Seems like the Community Edition is far behind, so would really like to try the "New" Version out... I can't help you at the programming side, but am willing to test it on an CR-6 SE.

[thinkyhead]

So that means that it is possible to use it, but it is not complete yet? Seems like the Community Edition is far behind, so would really like to try the "New" Version out... I can't help you at the programming side, but am willing to test it on an CR-6 SE.

I have a CR-6 SE also. My initial PR was adapted from the community fork in some older state. It wouldn't even boot up at that time, then I got distracted by other things. I wanted to incorporate the screen code in a way that was consistent with other similar screens, so that was also a sticking point. If a newer community fork can be merged with bugfix-2.1.x as a new starting point, then patched up to properly fit our paradigm, that would be the way to go. We can't just merge the community fork as it is, as it is simply made to work on the one machine and doesn't care about breaking other things.

[InsanityAutomation]

I have a screen file set that will work with the existing code for the CR10S Pro display, my issues list is down to about four items before I can actually get that locked down I just haven't had time to work on it the past few weeks... Then it will be one common code set to drive quite a few different displays on different machines around these touch screens.

[ETE-Design]

I have a screen file set that will work with the existing code for the CR10S Pro display, my issues list is down to about four items before I can actually get that locked down I just haven't had time to work on it the past few weeks... Then it will be one common code set to drive quite a few different displays on different machines around these touch screens.

@InsanityAutomation So as soon you have the CR10S Pro Display done it will be possible to use your screen file set for the CR-6 SE also is that correct understood? Also do you have an ETA for that? :-D Would be great to get it merged into "Official Marlin" so you can always keep the firmware up to date.
Are you the one who keep the Community Firmware up to date?

[ETE-Design]

So that means that it is possible to use it, but it is not complete yet? Seems like the Community Edition is far behind, so would really like to try the "New" Version out... I can't help you at the programming side, but am willing to test it on an CR-6 SE.

I have a CR-6 SE also. My initial PR was adapted from the community fork in some older state. It wouldn't even boot up at that time, then I got distracted by other things. I wanted to incorporate the screen code in a way that was consistent with other similar screens, so that was also a sticking point. If a newer community fork can be merged with bugfix-2.1.x as a new starting point, then patched up to properly fit our paradigm, that would be the way to go. We can't just merge the community fork as it is, as it is simply made to work on the one machine and doesn't care about breaking other things.

@thinkyhead Hope that you soon find some time to look at it, cause seems like there is a little if none activity over at the community fork :-(

[InsanityAutomation]

10sPro has been done a long time. Currently using the same codebase across 3 resolution displays in both portrait and landscape. Did have some discussion with Scott on how I'd look to get things upstream. My code has strict adherence to the API and can be dropped in as a library with no special handling elsewhere in code, and no external includes.

[ETE-Design]

10sPro has been done a long time. Currently using the same codebase across 3 resolution displays in both portrait and landscape. Did have some discussion with Scott on how I'd look to get things upstream. My code has strict adherence to the API and can be dropped in as a library with no special handling elsewhere in code, and no external includes.

Sounds great, so there is light at the end of the tunnel for us with CR-6 SE 😀

[gerthalberg]

Hi, Will I be able to compile the bf2_creality_CR-6_SE_PR branch and use the https://github.com/coldtobi/Marlin_DGUS_Resources and get a CR 6 SE up and running?

/regards.