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.

[flipside101]

Here's hoping! I know this is getting close, and it would be good to get this at least to the point of basic functioning before the final 2.1.3 release. Most recent interest on Discord popped up here… https://discord.com/channels/461605380783472640/1345344421851430962/1345486851900964966

how goes teh merge request