cr6community / marlin

This Marlin fork has the goal of cleaning-up the source code changes for the CR-6 so it can be merged upstream. We also want to extend the functionality to make it fully functional

Community firmware for the Creality CR-6 3D printer

This branch is for the Creality CR-6 SE with stock v4.5.2 motherboard and the stock display.

For other configurations for the Creality CR-6 printer (like BigTreeTech SKR board and optional BTT TFT v3.0 display - please check the branches and development section section below.

Downloads

Please find official releases in the Releases section. Take the release which belongs to the particular touch screen firmware you are going to flash. Please read the release notes carefully - it contains all the instructions you need.

Ensure you take the right assets: the firmware[suffix].bin. You should not download the Source code archive if you are downloading with the purpose of directly flashing your printer.

Support for the BTT SKR board is available.

At least one CF Release 6 user has confirmed that the v4.5.3 firmware configuration also supports the Creality v1.1.03 (ERA) board.

Development and compile-it-yourself

There are several example configurations available for your convenience which can be found in the config directory. Copy the files from the config subdirectory which reflects the needed hardware configuration to the root of the Marlin directory. To build the firmware Visual Studio Code with the Platform.io plugin installed is needed. Please set the Platform.io environment variable default_envs in the file platformio.ini to the string found in the previous copied file platformio-environment.txt.

Examples for the following hardware configurations are currently available:

• Creality stock TFT with:
  • Creality v4.5.2 motherboard (CR-6 SE)
  • Creality v4.5.3 motherboard (CR-6 SE and CR-6 MAX)
  • BigTreeTech SKR CR-6 (CR-6 SE)
• BigTreeTech SKR CR-6 with BigTreeTech TFT v3.0

Legacy branches:

• creality-cr6-merge-attempt - initial branch based on Creality v1.0.3.7 firmware source code release and upgraded until the community firmware 3 release. All new releases are released from the extui branch.

Original source code tracking:

• cr6-creality-changes - tracks the changes from the Creality source code dump against Marlin upstream. As of now we have the Creality v1.0.3.7 firmware on this branch, based on Marlin pre-2.0.

  • v1.0.3.7
  • v1.0.4.1

• cr6-btt-dump - tracks the changes from the Big Tree Tech SKR board firmware source code (which does not have any git history). It appears the for the moment BTT source code is based on the Creality v1.0.3.7 source code release.

Purpose of this community firmware

This fork of Marlin is meant for:

• Providing up to date and stable Marlin for the CR-6 SE native and BTT SKR CR6 motherboard
• Expanding the features of the limited Creality CR-6 stock touch screen

Once upstream Marlin supports the strain gauge, currently being whipped into shape in this PR @Sebazzz has submitted, the future of this project will probably be:

• Still expanding the features of the touch screen and merge upstream
• Continuously update this fork to the latest Marlin stable versions
• Provide builds for the CR-6 and SKR boards for the less technically inclined

Community firmware support & communities

Get in touch with the developers! We have our own Discord server.

The following CR-6 communities exist:

• Facebook independend CR-6 community
• Reddit /r/CR6

Communities hosted by Creality:

• Official CR-6 user group
• Official Creality user group

Other communities:

• Reddit /r/3dprinting

General Marlin support

For general Marlin support, please check:

• Marlin Documentation - Official Marlin documentation
• Marlin Discord - Discuss issues with Marlin users and developers
• Facebook Group "Marlin Firmware"
• RepRap.org Marlin Forum
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube

Reporting issues

• Submit bug fixes as pull requests to the current active default branch (extui)
• Follow the coding standards
• Please submit your questions and concerns in the issue tracker

Credits

The current core CR-6 Community firmware dev team consists of:

• Sebastiaan Dammann [@Sebazzz] - Netherlands   (Donate (Profile) | Website)
• Juan Rodriguez [@Nushio] - Mexico
• Romain [@grobux] - France (Donate)
• Nick Acker [@nickacker] - USA
• And more...

We stand on the shoulders of giants. Don't forget to send your love upstream too!

License

Marlin and the Creality CR-6 Community Firmware is published under the GPL license because we believe in open development. The GPL comes with both rights and obligations. Whether you use Marlin firmware as the driver for your open or closed-source product, you must keep Marlin open, and you must provide your compatible Marlin source code to end users upon request. The most straightforward way to comply with the Marlin license is to make a fork of Marlin on Github, perform your modifications, and direct users to your modified fork.

While we can't prevent the use of this code in products (3D printers, CNC, etc.) that are closed source or crippled by a patent, we would prefer that you choose another firmware or, better yet, make your own.

marlin's Issues

Firmware not installing

Bug Description

Firmware does not install, nothing happens.

My Configurations

Creality CR6 SE
Currently installed firmware 1.0.3.6

Steps to Reproduce

I follow the instructions for installing the firmware:

1. Format card
2. Copy firmware-20201025-162335.bin file onto root folder
3. Eject
4. Insert in CR6
5. Cycle power

Expected behavior:

Firmware to install

Actual behavior:

Printer boots without installing firmware.

[BUG] libmaple/usart.h: No such file or directory

If I tried build in Arduino IDE, I'm getting this error:

sketch\src\lcd\dwin\cr6\touch_lcd.cpp:33:10: fatal error: libmaple/usart.h: No such file or directory
 #include <libmaple/usart.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
exit status 1

How to fix it?
Thanks

[BUG] Homing Failed! if try to set new Z Offset immediately after Bed Leveling

With the Community Version 4 alpha firmware loaded (either baseline or hotfix 3) -
If I select Auto-Level Bed and wait for it to complete, it returns to the Level menu upon completion, without waiting for me to push the "Back" button first.
If I select the Z Offset button after the Auto-Level function has completed, the printer will Auto Home, slowly lower the Z axis until the optical switch is triggered, raise the Z axis briefly, then start to descend again, but it stops before the nozzle reaches the bed and displays a bright yellow screen that says, "Homing Failed !". I then have to cycle power to regain control of the printer.

If, instead, I select Z Offset on the Leveling menu first, after powering up, the Z Offset function works correctly.
I can also select Auto-Level Bed after doing the Z Offset and it works as described above.

This is repeatable.

My Configurations

My Configs.zip

I have flashed firmware-20201109-211912-hotfix3.bin to the motherboard.
I have flashed the v4 DWIN_SET to the display

Steps to Reproduce

1. Power up printer
2. Select "Level" menu
3. Select "Auto Level Bed"
4. Wait for Auto Level to finish (returns to Level menu by itself)
5. Select "Set Z Offset"
6. Wait for printer to place nozzle at current Offset value above bed, and to present the adjustment buttons
7. Printer instead stops before touching bed and displays, "Homing Failed!"
8. Cycle power to reset printer.

Expected behavior: [What you expect to happen]

Expected printer to stay on display of 16 points grid at end of Auto-Level Bed routing, until I press "Back"
Expected printer to complete the Z Offset function normally.

Actual behavior: [What actually happens]

Printer automatically exits Auto-Level Bed routine after measuring 16th point. Does not wait for "Back" button to return to the "Level" menu.
When I select the Z Offset button on "Level" menu after first leveling the bed, the printer stops and displays, "Homing Failed" instead of returning to the "Level" menu.

Additional Information

[FR] Support progress bar and file name when printing from host

Description

Support progress bar and filename when printing from host

Feature Workflow

1. Connect host
2. Change the filename and progress % with a gcode command from host

Additional Information

If no such command exist maybe parse M117 command from DisplaylayerProgress OctoprintPlugin with the following format
[progress]% L=[current_layer]/[total_layers]

Extruder feed rate is unusable slow through LCD touch screen

Description

Extruder feeding through LCD touch screen is extremely slow

Steps to Reproduce

Attempt to feed 60mm using menu, it takes a whole minute

1. Navigate to feed menu on touch screen
2. Enter 60mm
3. Press feed

Personally I would expect it to feed at a reasonable rate, preferable the same speed as Octoprint, which operates at 300 mm/m

It operates at 60 mm/m making the feature unusable for loading / unloading filament

Additional Information

I also noticed that in the source code there are some poorly named enums,

PROC_COM

HeaterMoveEnterKey = 17,
HeaterMoveStartKey = 18,

These have nothing to do with the heater, but rather the Axis, so should ideally be

AxisMoveEnterKey = 17,
AxisMoveStartKey = 18,

Line 63 in touch_lcd.cpp appears to hold the feed rates for the axis movement feature. And the last value for the extruder is set to 60, my recommendation would be (5*60) to match Octoprint.

Obviously I understand that this could be entirely subjective so my apologies if you don't care about this. I just thought I'd mention it whilst I'm poking about in the source.

[FR] When printing from Octoprint 'DWIN technology' is shown

Printing with Octoprint does not show the file name like printing from SD card. It is not necessary but a wishful feature.

[FR] Arc Support

Description

I would like to use https://github.com/FormerLurker/ArcWelderPlugin, but it requires ARC support. Is that something that can be implemented?

Feature Workflow

Ability to process G2 and G3 commands.

Send: G2
Recv: echo:Unknown command: "G2"

Filament run-out sensor immediately triggered

Probably caused in commit ac8835f, the filament run-out sensor triggers immediately when starting a print.

Now directly after start printing (octoprint) and even before homing, I got this screen.

Pause at height

Hi,

Did you manage to get pause at height (M0) running? Can anyone confirm it's working on your newest version?

Thanks for great work 👍

[BUG] Filament change M600 can't recover from 'heater timeout'

The heater change at layer will not reheat the extruder after it has timed out, and the button is blank.
I've attempted this twice with the same issue.

(Unfortunately both times I was not around to do the filament change in time for it to not timeout.)

[BUG] Z offset not consistent

Bug Description

If I press the up and down buttons on leveling screen it sometimes increments for 0.02 instead of 0.01. For example I can't hit 0.15 offset because it goes from 0.16 directly to 0.14.

My Configurations

alpha 4 release & the newest monitor update

Steps to Reproduce

1. Start at 0.20
2. Go down to 0.15

Expected behavior:
Always increment by 0.01

Actual behavior:
Skips some numbers.

Implement GCODE for Hotend LED

If changed the Configuration_adv.h in firmware to this:
Than is the case light (M355) supported and working

/**

• M355 Case Light on-off / brightness
  */
  #define CASE_LIGHT_ENABLE
  #if ENABLED(CASE_LIGHT_ENABLE)
  #define CASE_LIGHT_PIN 6 // Override the default pin if needed
  #define INVERT_CASE_LIGHT false // Set true if Case Light is ON when pin is LOW
  #define CASE_LIGHT_DEFAULT_ON false // Set default power-up state on
  #define CASE_LIGHT_DEFAULT_BRIGHTNESS 255 // Set default power-up brightness (0-255, requires PWM pin)
  //#define CASE_LIGHT_MAX_PWM 128 // Limit pwm
  //#define CASE_LIGHT_MENU // Add Case Light options to the LCD menu
  #define CASE_LIGHT_NO_BRIGHTNESS // Disable brightness control. Enable for non-PWM lighting.
  //#define CASE_LIGHT_USE_NEOPIXEL // Use NeoPixel LED as case light, requires NEOPIXEL_LED.
  //#if ENABLED(CASE_LIGHT_USE_NEOPIXEL)
  //#define CASE_LIGHT_NEOPIXEL_COLOR { 255, 255, 255, 255 } // { Red, Green, Blue, White }
  #endif

[BUG] Auto leveling error

Bug Description

When I try to level the second time (within the same power cycle) it crashes with M112 Shutdown on the screen.

Recv: Opto switch says: 1 Recv: FIX_MOUNTED_PROBE: Preparing for next probe tare Recv: echo:busy: processing Recv: Error:Probing Failed Changing monitoring state from "Operational" to "Error: Probing Failed" Send: M112 Send: N3 M112*34 Send: N4 M104 T0 S0*37 Send: N5 M140 S0*96 Changing monitoring state from "Error: Probing Failed" to "Offline (Error: Probing Failed)" Connection closed, closing down monitor

My Configurations

Alpha 5 and newest screen firmware

Steps to Reproduce

My leveling code:
M155 S30 ; set temperature reporting delay, use a value longer than the time it takes for your leveling command to complete. @BEDLEVELVISUALIZER ; instruct plugin to start recording responses from printer. G28 ; home G29 T ; report the bed leveling mesh points. M155 S3 ; set the temperature reporting delay back to a shorter time span.

Expected behavior:
Ability to ABL during same power cycle.

Actual behavior:
Crashes on 2nd run.

[BUG] (Auto Level hangs)

Under specific conditions, the Auto level function will hang the printer (make it non-functional). Needing a reboot to function again.

Condition:
Strain gauge very sensitive. [Worked fine with Creality 1.3 version]
Blue touch LED will blink very briefly during moving when tube is extended. [But not continuously on]

ABL centers, and touches. [ok]
Then moves to position 1 [ok]
As it moves down, the blue touch LED flickers briefly [but not on perm - due to high sensitivity]
ABL aborts, and moves to the center.
Printer hangs, needing a reboot to function again.

Temp Fix:
I re-adjusted the sensitivity to cause it not to flicker briefly while in pos 1 [tube is stretched and put pressure on gauge]
This makes the gauge less sensitive.

Proposed software fix:
Build in some de-bouncing function for the gauge. Maybe add a sensitivity counter / threshold where it has to be on for ? micro seconds before detecting a touch.
This will make it very sensitive, and also make it work with the strain of the tube loaded on the gauge.

[BUG] Power cycle resets Z offset to .20

Bug Description

Since (finally correctly) flashing this version of the firmware, I've found that I've had to adjust my Z offset down, as anticipated. After each power cycle, it resets to .20. I've been adjusting it in the levelling screen. I'm not sure if it does the same if adjusted by tuning from the print screen. It may or may not be relevant that I power cycle with a surge suppressor, rather than using the printer power switch. I'm also honestly not certain whether my levelling mesh is saved, as I think my bed is pretty level overall and I've been doing mostly small prints in the center of the bed recently.

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Steps to Reproduce

1. Adjust Z offset to a value lower than .20 using Levelling screen
2. Power cycle
3. Z offset is reset to .20

Expected behavior: Z offset should be retained

Actual behavior: [What actually happens]

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

Drop support for Chinese

Related: CR6Community/CR-6-touchscreen#1

Don't migrate code for Chinese support.

[BUG] Canceled Prints freeze touchpad

[BUG] Canceled Prints freeze touchpad
When I cancel a print, the Confirm/Cancel screen comes up, but the screen freezes without being able to activate either one.

[BUG] Bed levelling starts immediately but screen says waiting for 200C

Bug Description

Press preheat PLA and then start the bed levelling. It starts levelling directly instead of waiting for 200C, as the screen says.

My Configurations

Using the "Community firmware release 4 alpha".

Steps to Reproduce

1. Preheat PLA
2. Start auto bed levelling

Mesh data not saved after autolevel

Description

The mesh data is not saved to "eeprom" after an autolevel initiated from the screen.

Steps to Reproduce

1. Reset factory settings
2. Execute "M420 V" -> invalid mesh
3. Execute autolevel from screen
4. Execute "M420 V" -> valid mesh data
5. Cycle power
6. Execute "M420 V" -> Invalid mesh

Expected behavior: Mesh data should be saved thru power cycles

Actual behavior: Mesh data is lost after power cycle

Additional Information

As a work around, changing the z offset after an autolevel will cause the equivalent of an M500 resulting in parameters being saved, including any changes to esteps (M92 Exxx) and Fade Height (M420 Zxx).

Filament run-out sensor immediately triggered with fw v2.0.0-bugfix-a1

Description

Same as issue #7 , but with latest release available. After aborting and then starting the print again, it goes on flawlessly.

Additional Information

Using start/end gcode found on r/CR6's wiki , using Cura 4.7.1 with printer profiles downloaded from Cura's github.

[BUG] With current (10/26/2020) community firmware and screen firmware, sometimes stuck trying to bed level due to 0C temp goal?

On occasion, it appears the automatic bed leveling does not work because it pauses waiting for the hot end to reach the desired temp of 0. After a reboot it usually comes back with an expected temp of 120, but not always.
Menu is not disabled, can back out of the wait, but only a reboot seems to clear the issue. I will attempt to replicate and see if it's in response to any button presses in particular.

Cancel Print - If the print doesnt stick you press cancel which works. But then locks the screen and requires restart.

Bug Description

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Steps to Reproduce

1. [Try to print - not sticking to bed - Hit Cancel print and confirm]
2. [Printer responds but then cancel page stays on and printer must be restarted to continue]
3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[BUG] ETA override and Tune button

Bug Description

No Tune button and his function during printing.

My Configurations

Community firmware release 4 alpha

Steps to Reproduce

1. Send a print from Octoprint
2. Start printing model

Expected behavior: [What you expect to happen]

Showing printing progress with ETA and Tune button on the screen.

Actual behavior: [What actually happens]

Time stuck to starting model time and no Tune function.
Shown on pic.

• Provide pictures or links to videos that clearly demonstrate the issue.
  

• See How Can I Contribute for additional guidelines.

Change in default for runout sensor is a breaking change, makes old slices missing runout detection

Description

In Community Release 3 the default for the runout sensor was changed from enabled to disabled. For those of us with functioning runout sensors, this is a breaking change if we were to upgrade to the new firmware, or we have to re-slice any old models we already have.

This is a proposal to revert 6d5bdd5, and update documentation fo those with filament runout sensors to add the correct gcode to their slicer configuration. Additionally, while the flag was flipped, the in-line comments were not, so there is now a disconnect.

[BUG] Lock up after stopped print

When stopping a print from touchscreen, the print successfully stops, but screen locks up at the confirmation page. Must reboot in order to start over.

LCD Nozzle tempature command issues?

Description

Nozzle Tempature set via touchscreen triggers thermal runaway screen.

Steps to Reproduce

1. Set nozzle temp to 220. Correct temp goal is set.
2. Heating to successfully to about 210, then stalls.
3. Thermal run away screen.

Expected behavior: [What you expect to happen]
Heat to 220.
Actual behavior: [What actually happens]
Heat to 210. Thermal runaway screen.

Additional Information

When printing from gcode or using the pla preheat LCD command heating seems to function as intended.

Raise Z-Height During On-Screen End-Print Process

CR-6 SE Specific Issue

Description

Z does not raise when using the on-screen end-print functionality.

Steps to Reproduce

1. Begin a print.
2. After printer is laying down plastic, hit end print.

Expected behavior: [What you expect to happen]
Expect Z to raise to avoid crashing before homing.
Actual behavior: [What actually happens]
Z stays at existing height when print ends and then homes.

Additional Information

If on layer one, it appears that the machine stop respecting the bed mesh while homing and drags the nozzle on the glass bed. This is the primary concern that if your un-adjustable bed is higher on the homing side your nozzle may either dig into the glass or into the print and cause damage.
Note that this is the same behavior as the factory firmware and is an issue in that firmware as well.

Question: How are buttons added to the LCD touch screen?

Hi there, my apologies if this is not the correct place to ask this, in which case please disregard.

I was just poking about with your CR6-SE patches for Marlin, great work by the way, my printer is running pretty good now that you appear to have fixed a lot of the issues I had.

I wanted to add something to the feed menu, a filament load / unload option which I would previously have used via the M700 / M701 options through the old LCD screen, but I understand that this isn't possible with the new touch screen, even with ADVANCED_PAUSE_FEATURE and FILAMENT_LOAD_UNLOAD_GCODES for one reason or another.

Anyway, is it possible to add buttons or does that require compilation of something that Creality hasn't provided? I mean I have a zip with a bunch of bitmaps in and various bin files, but no idea how the bin files were generated. Any ideas?

Thanks for your time.

[FR] Undependency from the mainboard

Hi, i have a Longer LK4 Pro which has the same LCD of CR6, hence i tried to use your GUI on my printer. I had some trouble to compile your code for the original atmega2560 based board, and finally it compiled well but the screen stayed on initial boot picture.

I know that yout work is about CR6, but since your code is very promising you could think to write your code undependently to the mainboard. In this way your work could be used also on another printers. It would be a shame to close this code limiting it to a single printer

[BUG] G29 failing when printing from touch screen

Bug Description

When printing g-code from the touch screen, if there is a G29 command right after the G28 command, it causes ABL to fail and for the hot end to fly off to one side and grind the motors. Running exactly the same gcode from Octoprint works fine. I believe it may be down to the touch screen page that reports which section it is levelling.

I now have an Ender3 V2 with a BL Touch as well as a CR6 SE, and the way that handles ABL is slightly different, it also doesn't have this fault. When levelling from the touch screen you merely get a prompt that tells you to wait until it is complete, rather than the rather superfluous progress page you get on the CR6 SE (does this serve any purpose?).

When the G29 command is streamed from Octoprint, the ABL progress page is shown, but it does not cause any issues, this may be due to the fact that the print progress screen is never shown when printing from Octoprint.

My Configurations

Current latest CR6Community version.

Steps to Reproduce

1. Generate GCode for any small print using Cura that has a G28 followed by a G29 in startup.
2. Stream generated gcode from Octoprint, observe correct behavior)
3. Print generated gcoode using SD card and touch screen, notice how G29 fails. and the nozzle flies off < 0,0 and causes the motors to grind until power off.

Expected behavior: [What you expect to happen]

ABL command to work as expected with either Octoprint or the touch screen.

Scenarios:

1. ABL option from touch screen
2. ABL (G29) command whilst printing from touch screen (print progress page shown on touch screen)
3. ABL (G29) command streamed from Octoprint

Actual behavior: [What actually happens]

ABL command (G29) fails whilst in "print progress page" (scenario 2 above) causing the nozzle to fly off axis and grind the motors.

Additional Information

Personally I would say that the ABL progress page is entirely pointless, and highly restrictive. Not only does it have a hard coded 4x4 matrix but provides no relevant information to the user. If I were to change my ABL to a 5x5 matrix, the page would not function correctly. Ideal behaviour would be similar to that of the Ender 3 V2 (Smith3D 2.0.x.14 firmware) where it merely shows a dialog that says "Bed Levelling, Please wait until done." when selecting Levelling command directly from touch screen, and when G29 is processed during printing; nothing is shown.

[BUG] Screen issues

Bug Description

Flashed firmware and screen. When I went to print from SD, there was a list of "files" that was all garbage. I was not able to select any of them. There was only one file on the card. I flashed the firmware back to the previous community release (left the screen) and was able to print, but other functions are no longer working correctly, like Z offset is always 0 and must be set every time I print and, if I select to heat the nozzle, it does not heat, I must select Preheat PLA.

My Configurations

I'm sorry, I don't know how to do this.

Steps to Reproduce

1. Flash firmware
2. Flash screen
3. Try to print
4. Flash to previous version of firmware

5. Try to heat nozzle, etc.

Expected behavior: Files show to print. Z offset is maintained. Nozzle heats when set.

Actual behavior: Garbage shows on screen. Z defaults to 0. Nozzle does not heat.

Additional Information

I'm really sorry if this is the incorrect way to do this, or if this is even the wrong place to report.

[BUG] Auto bed leveling freezing

Bug Description

When I start the auto bed leveling after the home position, the nozzle moves to first probing and immediately turns back in origin

My Configurations

Community firmware v1.0.3.6

Steps to Reproduce

1. Start auto bed leveling from the screen

Expected behavior:

Probing from 1st to 16th point

Actual behavior: [What actually happens]

Nozzle stops on first probing

(https://youtu.be/klTeJAVzQS0)

[BUG] While pre-heating, ABL has no effect on adjusting the temp down to 60

I was wanting to pre-heat the printer, and do a ABL (To quickly get the bed up to 60deg)

To replicate
On boot, navigate to pre-heat PLA
Temperatures were set to ?/200 and ?/60
When bed reached 60, I selected Auto Bed Level
Nozel temperature was set to ?/120 [at the time, the nozel temp was 132] (bed temp was set to 0)
During ABL, the nozel temperature kept climbing until it reached 200 (although the nozel temp was set to 120) (bed temp dropped fine)

Potential software issue:
During ABL, the temp is displayed on the screen as 120, but somehow the set nozel temp is still stuck on 200 from pre-heat.
Only when it reached 200, then it drops.

• Nice to have: don't let ABL adjust the bed temp. (I would like to ABL when the bed is at it's working temp of 60)

Removing SD card while printing from host reverts to main menu

Removing the SD card while printing with Octoprint will reset the display and all tuning options are not available any more. Fortunately the print won't stop and runs till the end.

Marlin CR-6SE Alpha-4 leaves printer prompts in chinese

Bug Description

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[FR] configure e-steps directly from printer

Description

Add an option to configure automaticaly e-steps in the printer without Octoprint or a USB cable plugged to the PC.

Feature Workflow

1. Select in the menu somewhere "configure e-steps"
2. Follow the instruction (like here) : mark your finament @120mm, run the procedure, measure agains the mark, enter the value
3. Printer compute & save e-steps

Additional Information

• CR6-SE USB port is crap, if we can avoid using it, it will save a lot of USB ports & motherboards

Filament runout detection

I've got the filament runout configured like this:

#define FILAMENT_RUNOUT_SENSOR
#if ENABLED(FILAMENT_RUNOUT_SENSOR)
#define FIL_RUNOUT_ENABLED_DEFAULT true // Enable the sensor on startup. Override with M412 followed by M500.
#define NUM_RUNOUT_SENSORS 1 // Number of sensors, up to one per extruder. Define a FIL_RUNOUT#_PIN for each.
#define FIL_RUNOUT_STATE LOW // Pin state indicating that filament is NOT present.
#define FIL_RUNOUT_PULLUP // Use internal pullup for filament runout pins.
//#define FIL_RUNOUT_PULLDOWN // Use internal pulldown for filament runout pins.

// Set one or more commands to execute on filament runout.
// (After 'M412 H' Marlin will ask the host to handle the process.)
#define FILAMENT_RUNOUT_SCRIPT "M25"

// After a runout is detected, continue printing this length of filament
// before executing the runout script. Useful for a sensor at the end of
// a feed tube. Requires 4 bytes SRAM per sensor, plus 4 bytes overhead.
#define FILAMENT_RUNOUT_DISTANCE_MM 50

#ifdef FILAMENT_RUNOUT_DISTANCE_MM
// Enable this option to use an encoder disc that toggles the runout pin
// as the filament moves. (Be sure to set FILAMENT_RUNOUT_DISTANCE_MM
// large enough to avoid false positives.)
//#define FILAMENT_MOTION_SENSOR
#endif
#endif

I know that the filament sensor is not implemented in this firmware. But what i see is that de detection is correct with these settings (GCODE M119) but that the filament runout distance mm (GCODE M412) is always set to 0mm. Whatever you change this value, it is always set to 0mm. Can this trigger the false positives?

Draft release notes for community release 4 alpha

Community firmware release 4 alpha based on Marlin v2.0.7.1 - rewritten from scratch

In this release the interface between Marlin and the touch screen has been rewritten - this release has all Creality code rewritten. Because of this, we will mark this as an alpha and though I have been printing successfully with it, you might not - for you it might not be as stable as the previous release or have small annoyances. There will be also some rough edges, but the added features might make it worth your while. There is also some user interface improvement still to be done - but release can be considered feature complete.

As always, flashing firmware is entirely on your own risk.

Changes compared to Community Release 3 and Creality stock firmware

• Touch screen interfacing layer between Marlin and Creality touch display has been completely rewritten (issue #1) - The code of Creality was not maintainable(1000+ line switch statements, more "if" statements than you can count, void of comments, incorrect constants).

• Full support for folder navigation when starting a print from the SD card - your gcode files no longer need to be in the root directory

• Loading and unloading of filament changed to Marlin native procedures and speed configurable in FILAMENT_CHANGE_FAST_LOAD_FEEDRATE (by default 6mm/s)

• Movement tweaking Use a good default for JUNCTION_DEVIATION

• Implement proper retrieval and save of preheat PLA / ABS settings

• Improve auto bed leveling (issue #32)

  • More often taring/zeroing the strain gauge probe, reducing possible issues with the bowden tube or cable pulling the strain gauge up and causing false or inaccurate readings (issue #32) - for this reason you may need a lower Z-offset than in previous release. You may also be able to increase your strain gauge sensitivity to allow less flexing of the hot-end while probing.
  • Always pre-heat both bed and nozzle before G29
  • Support M48 probe accuracy test
  • Automatically save mesh after leveling from the touch screen (issue #14)

• Filament runout detection has now been enabled by default again. (issue #19)

  • We use the Marlin native filament runout detection. This is more reliable than the home-brew implementation of Creality because it debounces any possible false readings. Give your filament sensor a chance again.
  • If you have previously used the resistor trick to bypass the filament runout sensor, you can undo it. If your filament runout sensor is really defective, you can disable it using M412 S0 - otherwise you can enable it using M412 S1.

• Use the native Marlin print timer formatting (so format as 1d 5h 7m instead of 29:7)

• Support HOST_ACTION_COMMANDS

• Support G2/G3 arc support - Useful if using Octoprint with the Arc welder plugin (issue #23)

• Support M355 for controlling the hot-end LED (issue #9)

• Support M300 (play tone / buzzer) (issue #20) - You can now let your printer make some noise! Note that we only support the duration parameter of M300, and only with 8 millisecond precision due to the touch screen limitation.

• Support M73 (print progress) (issue #7 and issue #27)

• Support M75/M77 (start/stop print timer) on the touch screen level. This can be useful if printing from a host, because if you issue this gcode, the touch screen changes to the print progress screen. When printing from Octoprint, you will probably want to include this particular gcode.

• Support M117 LCD message (issue #7) on the print progress screen

• Support ADVANCED_PAUSE_FEATURE

  • Support M600 filament change
  • Support M701/M702 filament load/unload

Bugs fixed compared to previous release

• Z-offset shows as 0 after start though it works correctly (issue #5)
• Lock-up / freeze when cancelling a print (issue #25)
• For some users, bed leveling from the touch screen indefinitely waited for the hot-end to heat up (issue #21)

Changes compared to Community Release 1 and 2, and Creality stock firmware

• Disable CLASSIC_JERK - you can now do acceleration tuning
• Merged Marlin 2.0.7.1, Marlin 2.0.7, and Marlin 2.0.6.1 sources (previous community firmware release was based on Marlin 2.0.6
• Prevent first layer abort from scratching the bed (issue #12)
• Allow the probe offset to be set in 0.01mm offsets (issue #15)
• Save to EEPROM after bed leveling (issue #14)
• Restore bed leveling mesh automatically after homing (RESTORE_LEVELING_AFTER_G28)
• Enable G26 mesh validation pattern tool
• Pre-heat PLA and ABS temperatures are properly shown in the touch screen interface
• Save power loss recovery settings to the SD card instead of EEPROM, preventing blobs

Changes compared to Creality firmware (in addition to the changes above)

• Save settings to EEPROM
• Improve SD card sorting
• Integrate filament runout feature with Marlin base code allowing it to be disabled using M412 gcode. If you have previously used the resistor trick to bypass the filament runout sensor, you can undo it. If your filament runout sensor is really defective, you can disable it using M412 S0 - otherwise you can enable it using M412 S1)
• Based on recent version of Marlin (as mentioned above) instead of a pre-release version of Marlin 2.0.0
• Increase reliability of filament runout sensor - allow for false positives to happen
• Enable linear advance / pressure advance allowing you to do linear advance calibration
• Fix temperature reporting issues in Octoprint (issue #3)
• Drop support for Chinese (consider flashing at least the CR-6 community touch firmware v1.0.0-a1 to remove the Chinese options from the menu also)
• Implement saving pre-heat PLA and ABS settings (issue #6)
• Enable EMERGENCY_PARSER commands
  • Enable support for gcode command M0 with resume via M118 via the touch screen (the "power loss recovery" screen is (ab)used for this)
• Enable S_CURVE_ACCELERATION
• Don't execute the SD abort gcode sequence when a print is succesfully finished - you can add G1 X0 Y{machine_depth} ;Present print to your end gcode in Cura to put the bed forward after the print completes.

Known issues

• Auto-homing shows "auto-leveling please wait" instead of "auto-homing please wait" (issue #8)
• Fonts and font-sizes could be tidied up, especially for M117
• Print progress for Octoprint / host printing also allows messing with the print from the touch screen. We should probably disable that - for now, don't mess with a running print when running a print from a host.
• This release cannot be compiled from sources using Arduino IDE - use Visual Studio Code with PlatformIO instead - this is probably an upstream bug (issue #30)
• When printing from a host like Octoprint, dwin technology might be shown as a print filename

Flashing instructions

Note: This release is accompanied by a new firmware for the touch screen. This release and the new touch screen firmware goes hand-in-hand - one cannot be used without the other

Touch screen flashing instructions

This release of the touch screen firmware comes with a new version of DGUS OS (the underlying operating system of the touch screen) to fix text rendering issues.

Flashing instructions are also available as a video - this video is for the Ender 3 V2 but the same procedure applies to the CR-6. For instructions, check the README.txt in the touch screen firmware download.

For this release download touch screen firmware community release 4 alpha.

Mainboard / Marlin flashing instructions

0. If you like to remember what settings you had, run M503 in a serial monitor.
1. Use an empty SD card formatted FAT32 4096KB sector size.
2. Put the firmware .bin file downloadable from this release page (check the 'assets section' below) onto the SD card.
3. When using Windows - do a "safe removal" to remove your SD card.
4. Put the SD card in the printer.
5. Either turn the printer off, then on again or issue command M997 from Octoprint/Pronterface.
6. Verify the firmware is flashed by issuing M115 or going to "Control -> Info" on the touch screen.
7. You can now remove the file from the SD card.
8. After flashing go to the menu and reset to factory settings or issue M502 in Octoprint - do this also if you have been running Community Release 3. You need to relevel the bed, reset the z-offset, and reprogram esteps (if you've changed them from defaults).

Release SHA256 hash: 06236286A7917240D14B6399A0A75069D606B33EB338E4766D0CF9CC0468AF00

Rollback instructions

To completely roll back to an earlier release:

1. Flash the v1.0.0-a1 touch screen firmware
2. Flash Creality stock firmware or Community release 3

Troubleshooting

• Verify that the issues are not in your hardware. We've seen issues that were reported as firmware issues, but were actually hardware issues that "just" happened.

  • Check you have a good SD card. Do not use the Creality SD card that came with your printer. It will fail sooner or later and result in failures. Try a different SD card
  • Leveling: try it again a second time and try using the stock cable ties

• Verify that the issues are not in your slicer

  • Cura 4.7.x is having issues
  • Cura 4.8 is still in beta and not entirely out of the woods yet either

Reporting issues

Follow the guidelines below for reporting issues - report them on Github because it allows us to watch a single place for issues and workarounds might already be available:

• Open an issue on the Github repository page if you have found no issue matching your problem.
• Mention which release you are on, and if you compiled a release yourself (and in that case: what changes you have done).
• Be specific in reproduction steps. Include pictures or a video if useful. Ensure you have been able to reproduce it.
• Check if the issue has not been reported in Marlin, nor that you are using a slicer known to have problems (Cura 4.7 or higher).
• You can collect logging using M111 S247 and M928 log.txt - please collect logging, without it is practically impossible for us to help you. Use Pronterface or Octoprint to capture serial terminal output.

Thank you note

• Thank you to a few early testers who compiled and flashed firmware before this release
• Thanks to @Doridian for contributing a few bugfixes and improvements
• Thanks for the support, love and even cups of coffee

Up for grabs

Feel free to connect with us and take on one of these issues:

• Fix 0C temp goal issue #21 for the current stable release
• Improve the style of the toggle buttons #10
• Change bitmap for auto homing to the correct text #8

Additional notes

• If you're compiling this release yourself, either take the zip archive or download the extui branch for the latest sources
• We're active in the CR-6 community discord - come say hello!
• Remember that this is a community project, we're not paid (definitely not by Creality!), we have a full time job, doing this in our spare time, and we're just 3d printing enthusiasts who like to have a better Creality CR-6 experience for everyone.

[BUG] Octoprint receives error "kill()" from printer

Hi, sometimes when i click Auto Home on the printer and will start than a print or Bed Visualizer with Octoprint, it kicks me out and gives error "kill()".

On the "original" firmware it was working

Also the Auto Home is very weird i think...

The Auto Home touches the bed, than goes up, than goes slow down to touch again, than goes much up and than goes down to the Z-Offset Level...

Why it goes up so much to than goes down to 0.22mm in my case.
On the original it goes just up to the z-offset but not like 5.00mm or something to go down than

Error 'Probing failed' when doing an second G29

Printer is reporting an error when doing an second G29. (for example, for Better Visualiser)

1. Connect to printer
2. Home (G28)
3. Level (G29)

Everything Ok for now

4. Level (G29)

ERROR

If doing an G28 between the G29 then it is OK.

Error from printer:
Send: G29
Recv: T:23.12 /0.00 B:31.02 /0.00 @:0 B@:0
Recv: echo:busy: processing
Recv: T:23.12 /0.00 B:30.94 /0.00 @:0 B@:0
Recv: Error:Probing Failed
Changing monitoring state from "Operational" to "Error: Probing Failed"
Send: M112
Send: N2 M11235
Send: N3 M104 T0 S034
Send: N4 M140 S0*97
Changing monitoring state from "Error: Probing Failed" to "Offline (Error: Probing Failed)"
Connection closed, closing down monitor
OCTO: Power off printer outlet

Marlin pre-heat settings not saved/retrieved

This appears to be because it is not implemented.

Auto Bed Leveling via Touchscreen or G29 fails.

Whenever I try to ABL the printer in any way it aborts and gives me the Error Message on the touch screen or/and octoprint fails with the alert "Probing Failed".
From what it looks like its homing the Z wrong but that is just what I have observed.

Clean-up touch screen code

The touch screen code is a mess currently:

• Switching between languages is sprinkled throughout the source
• There is one big switch to handle events from the touch UI

[FR] When using either the display controls or Octoprint controls to move a stepper motor, all steppers are locked, instead of just the stepper that has been moved

I was planning to file a bug report, saying that Stepper Control seems to be implemented as "all or none", rather than each motor enable/disable being controlled individually as it is on my Ender-3, but I suspect the CR-6 behaviour is actually coded this way by Creality for some reason. I have therefore classed this as a Feature Request instead, for consideration.

On my Ender-3 running either Marlin 2.0.5.3 or 2.0.7.2

• when I power-up, all 3 stepper motors are disabled by default.
• if I move just one axis (any of X, Y or Z), only that stepper is locked at the end of the movement. The other steppers remain disabled unless and until I also command those to move.
• when I select "Disable Steppers" (which has no ON/OFF status indicator in the menu), ALL steppers are released.

On my CR-6, running the latest extui version (downloaded 10pm on 25 Nov 2020):

• when I power-up, all 3 stepper motors are disabled by default.
• when I select "Prepare" - depending upon whether Octoprint is connected or not, before I do that (see https://github.com/CR6Community/CR-6-touchscreen/issues/18 - the "Disable Stepper (ON/OFF)" button is EITHER ON or OFF
• IF it was OFF, then selecting Disable Stepper causes the button to change to ON. After that, I can find no way to make it go back to OFF, even if I move the motors, etc., but that might be because I leave Octoprint connected to enable logging.
• when I move ANY one axis, ALL 3 motors lock.
• when I select Disable Stepper ON/OFF ALL 3 motors are released.

I only own the two printers, so I have no idea whether the Ender-3 behaves the way all other 3D printers behave, or whether they are both unique, I only know they are not the same.

**In my mind, it would be wonderful if users could have all printers running Marlin behave in one standard way.

If possible, please at least rename the Disable Stepper ON/OFF control to read "Disable Steppers", since it actually does release them all, by design, and the ON/OFF suggests a toggling function but pressing the button repeatedly does NOT toggle the state of the motors.**

NOTE: If in fact that button SHOULD toggle the state of the steppers, please note that it presently does NOT.

Disable Stepper Bug Log.txt

[BUG] Support print progress display

Bug Description

I am using https://plugins.octoprint.org/plugins/DisplayLayerProgress/ and it doesn't show print progress on the LCD during print.

My Configurations

Community release 3 + ARC support

Steps to Reproduce

1. Open terminal
2. M117 xxx% L=xxx/xxx H=xxx.xx/xxx.xx
3. See if anything happens on LCD

Expected behavior: Some kind of print progress display.

Actual behavior: Printer ignores command.

Fix duplicate temperature reporting in Octoprint

The duplicate temperature reporting issue is still present on this firmware. We need to fix it.

I got contacted by an individual (to protect his privacy - but still give him credit, I'Il call him RC):

You notice that in Octoprint, sometimes the temperature comes out correct but mostly during a print it comes out wrong. If you issue a M150 command it comes out right. It is only when M155 (auto report) is set that it comes out wrong. Octoprint automatically turns on auto report (see settings->serial connection-intervals & timeouts). You’ll notice that autoreport temperature interval is set to 2s. This is the value used in a M155 command. If set to zero it turns off autoreport and polling automatically begins which uses the M150 command. The temperature comes out correctly when polling. Armed with this information I went digging around in the M150, M155 command code and temperature.cpp code where the temperature is reported. I was looking for a place where it sent the characters twice. The SERIAL_OUT macro defined in serial.h below seemed to be the obvious culprit.

   #define SERIAL_OUT(WHAT, V...) do{ \
      if (!serial_port_index || serial_port_index == SERIAL_BOTH) (void)MYSERIAL0.WHAT(V); \
     if ( serial_port_index) (void)MYSERIAL0.WHAT(V); \
   }while(0)

As you observed, Creality changed MYSERIAL1 to MYSERIAL0. If serial_port_index is set to SERIAL_BOTH the characters (and number strings) will be doubled since both if’s will be true. It just so happens that the only place SERIAL_BOTH is used is in a PORT_REDIRECT in the autoreport code in temperature.cpp (Marlin/src/module) around line 2924 in the file from Creality. What I don’t understand is “where does serial_port_index get changed back after using PORT_REDIRECT”. I’ll have to look at that some more.

   void Temperature::auto_report_temperatures() {
     if (auto_report_temp_interval && ELAPSED(millis(), next_temp_report_ms)) {
       next_temp_report_ms = millis() + 1000UL * auto_report_temp_interval;
       PORT_REDIRECT(SERIAL_BOTH);
       print_heater_states(active_extruder);
       SERIAL_EOL();
     }
   }

“serial_port_index” is typically “1” therefore the second line outputting to MYSERIAL0 is used. It is only when set to SERIAL_BOTH that the characters get output twice. My initial thought was to put MYSERIAL1 back in serial.h and swap the port numbers for SERIAL_PORT and SERIAL_PORT_2. But after looking some more I’m not sure what other side affects this may have. I know this is what is causing the problem, I just don’t know what other things Creality may have done that could be impacted. I hope this gives you something to look at and I’ll look at it again tomorrow to see what has to be done to unravel Creality’s change. I would like to get back as close to Marlin code as possible.

[FR] Add M300 (Play Tone) support

Description

Since this printer is very quiet, adding a little sound at the end of the gcode it's a nice touch.
I tried building the firmware with #define SPEAKER enabled in configuration.h file, but when sending an M300 to the printer, the console outputs an "unknown command", with no sound played at all.

While trying to search for some fixes among the files, the only thing I was able to understand is that there is no beeper reference in pins_CREALITY_V452.h file, if that can help.

Z offset on screen - Change partially worked but not during print.

Bug Description

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Steps to Reproduce

1. [Change Z offset works well in the levelling page although the steps are not clear - Sometimes its 0.005 and others 0.01 but display is only to 0.00]
2. [Change Z offset during printing is still in 0.05 steps (so 4 steps to bed contact)]
3. [and so on...]

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[BUG] Bed leveling fails

I just flashed the Community Release 4 version on my printer. I also updated the touch screen. When I go to bed level, the homing sequence runs, the temperature targets get set, and once the temperature is reached it heads for position 1, pauses a bit, and then returns to the center of the bed.

I have tried reflashing the firmware using different SD cards. I have tried running the leveling with and without an SD card. I have tried running the leveling from a "print" file. Nothing seems to make it want to properly level. I do not believe I have a hardware issue because prior to reprogramming the stock firmware worked and during the homing sequence the nozzle taps the bed as expected.

I have not tried any debugging with PC connected because I don't have any USB power isolators and I don't want to risk my laptop's USB port.

Will revert to community release 3 and see if that works for me.

Increase Z-Offset Resolution in the Level Screen to 0.01

Description

Finer control over the Z-Offset is needed. Increasing the resolution from 0.05 to 0.01 would be helpful. I noticed that this has already been done in the screen firmware for the Print->Tuning screen.

Steps to Reproduce

Additional Information

File touch_lcd.cpp needs to be changed in 6 places between lines 978 and 995, reducing 0.05 to 0.01. See attached file
touch_lcd.zip

Edit: There is a problem with float precision and a single press up or down does not always result in a displayed 0.01mm difference. This can be compensated for by:

probe.offset.z = roundf(probe.offset.z*100.0 + 1.0)/100.0; // increment

and

probe.offset.z = roundf(probe.offset.z*100.0 - 1.0)/100.0; // decrement