[WIP] Creality CR-6 SE - DWIN DGUSOS - ExtUI #19955
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I will remove this later from the changeset, but it allows for testing the compilation and porting. Notes: - CR-6 has ARC_SUPPORT disabled - SDIO_SUPPORT was added by Creality - Platformio.ini changes not necessary: those were already here from the Ender 3 V2 implementation - To build, use: platformio run -e STM32F103RET6_creality New board for CR-6: BOARD_CREALITY_V452
It does appear that the CR-6 v2.5.4 board is an entirely different board. I had to split up the old board file from the Creality changes because they used one board file.
Originally changed in source by Creality in timers.h
Note CR-6 requires 1250 but the watchdog is disabled anyway?
I don't think this is actually used.
Creality included bedlevel.h - it seems to be no-op to me, but let's confirm.
Creality updated the second constant, I do it proper.
- Translated comments to English (it was Chinese to me) - Renamed LCD_RTS to touch_lcd instead
I don't dare currently to touch the power loss recovery code.
Creality called explicit settings.save() at the end of ABL. Not ported that - not sure what to make of that.
…eed to think how to refactor this.
Not sure what to make of it. All the preheat temperatures used to be communicated to the LCD, but now they are not?
Creality source had HAL_watchdog_refresh. Not ported. Does it need to be ported?
RTS_AVAILABLE is the original Creality constant. I think we can say that one goodbye.
Replaced with present feature from Marlin/MarlinFirmware/18758
…zz/Marlin into creality-cr6-merge-attempt
|
Thanks for the submission! To prepare a PR for the updated Marlin you'll need to merge in all the latest changes from |
|
Ok…. So, it wasn't too hard to rebase onto bugfix and bring everything up to date. The cleaned up PR based on |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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:
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.