[BUG]Print task is not started on Marlin 2.1.2 from MKS TFT35

[WEREWOLF1973]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Print task is not started on Marlin 2.1.2 from MKS TFT35. Board - MKS SGEN L V2.0, screen MKS TFT35. When launch a printing from TFT, bed heating started, but from some time temperature on TFT display stop updating, the heating is continued till target temperature. On LCD no activities, "Printer is ready".
All commands from TFT35 pass to printer correctly.
On previous release 2.0.7.2 same configuration worked perfectly.
Same GCODE file prints correctly from internal board SD card. Input shaping activated.

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

2.1.2 bugfix

Printer model

Sunlu S8

Electronics

MKS SGEN L V2.0

Add-ons

No response

Bed Leveling

MBL Manual Bed Leveling

Your Slicer

Cura

Host Software

Cura

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Marlin.zip

[IndaloGo]

Hello
I have exactly the same problem, when upgrading to Marlim 2.1.2, the printer never starts.
bed Heating
E0 Heating
And then only Printer ready
In my case it's the same displaay but connected to a Re-ARM with a RAMPS

Although in Configuration.h it says:
#define SERIAL_PORT -1
#define BAUDRATE 115200
(what I always have in other versions)
From the display I have to change to BAUDRATE 250000, so that the display commands respond, but the print does not start.

[ellensp]

@IndaloGo
The MKS TFT35 is not connected to the printers USB port
So the #define SERIAL_PORT -1 and #define BAUDRATE 115200 are not related to the display.
It is connected to another serial port, which probably has its own baud rate.

[WEREWOLF1973]

@ellensp
Anyway, problem exist till now - print task from display is not started. It's looks like display stops get from serial bad and nozzle temperature.
May be display serial port become blocked and busy?
It problem is not related to baudrate - manually all commands from display passed correctly and temperature displayed also correctly. Problem begun when printer task started. I also have tryed to connect other MKS TFT32 display - same issue.
It's looks as Marlin 2.1.2 bug.

[IndaloGo]

Yes, indeed SERIAL_PORT is for the USB port, which by the way I have just tried and from the computer via USB, if it works, it starts printing without problems.
For the communication with the TFT I use:
#define SERIAL_PORT_2 0
#define BAUDRATE_2 115200

But putting these data as they were in previous versions, it still doesn't work.

[WEREWOLF1973]

@IndaloGo
>... from the computer via USB, if it works, it starts printing without problems.
The same behaviour in my case. Through USB printing works normally - from PC or octoprint (Raspberry Pi).
On TFT serial printing is not started.
I use baudrate 250000.

Which type of mainboard in your printer?
Do you activate the input shaper?

[IndaloGo]

The electronics of my printer is a Re-ARM (LPC1768) with a RAMPS.
although I have another one (under construction) with a BTT GTR V1.0 and a BTT TFT35 V3.0 screen, and I want to test this afternoon the same version of Marlin 2.1.2, now it has the 2.1.1 and works properly

Sorry I don't know what you mean by "input shaper".

[WEREWOLF1973]

@IndaloGo
My board based on LPC1769.

Please check in Configuration_adv.h:
#define INPUT_SHAPING_X
#define INPUT_SHAPING_Y
These string are active or remarked?
It just for my understanding, because i upgrade Marlin to 2.1.2 only for this function.

[IndaloGo]

no,
they are disabled

[IndaloGo]

I have tested Marlin 2.1.2 on the printer that is under construction, with the BTT GTR 1.0 with the BTT TFT35 V3.0, and it is working correctly.
Tomorrow I will try the Re-AVR + RAMP with another display.

[WEREWOLF1973]

@IndaloGo
Thanks for testing, very interesting results. For now it looks like issue occurs only on LPC176X platforms....

[dsovsyannikov]

Hello
I have exactly the same problem, when upgrading from 2.1.1 to 2.1.2
Kingroon KP5L

[efsa91]

I have the same issue

[WEREWOLF1973]

@dsovsyannikov , @efsa91
What kind of boards you use?
Processors?

[dsovsyannikov]

clone robin nano with GD32F303
The GD32 has two truncated DMA controller and it cannot serve two channels in parallel.
for SDIO and screen need to use own DMA controller.

[dsovsyannikov]

fix for GD32F303
jmz52@1940418#diff-f64f057c8653ee97ebf3be2065e2d0e14ec568be6ab1e03c98b5282fbf1e4ecf

[efsa91]

@dsovsyannikov , @efsa91 What kind of boards you use? Processors?

In my case: Board: BOARD_MKS_GEN_L, Processor (Enviroment): ATMEGA2560, Screen: MKS TFT28.
i use the following configuration: SERIAL_PORT 0, BAUDRATE 115200.

[WEREWOLF1973]

Finally, no any explanation of this behaviour from development community. I have to reflash printer to release 2.1.1. Display works perfectly.
For everybody, who used MKS TFT series display i am not recommend to upgrade to Marlin 2.1.2.

[efsa91]

Finally, no any explanation of this behaviour from development community. I have to reflash printer to release 2.1.1. Display works perfectly. For everybody, who used MKS TFT series display i am not recommend to upgrade to Marlin 2.1.2.

Yes, for me Marlin release 2.1.1 works just fine.
Marlin 2.1.2 doesn't work with the MKS TFT 28 for now.

[k2ironman]

I run into this issue with MKS GEN L v1.0 and MKS TFT35.

[VampireCrab83]

Same issue using MKS Sgen L v1.0 and MKS TFT35.

[kirolousattia]

Same issue using MKS gen v1.4 and MKS TFT35.
Please if anyone reaches any sort of fix or work around tell us.

[LastDragon-ru]

Same issue with SKR v1.3 and MKS TFT28 :(

[LastDragon-ru]

It was introduced in 0537e78/#24972 (@thinkyhead). After removing the line

Marlin/Marlin/src/gcode/queue.cpp

Line 493 in ef93b40

if (WITHIN(gcode_N, serial.last_N - 1, serial.last_N)) continue;

TFT seems to work fine again with v2.1.2.1

[brunotrocolis]

@LastDragon-ru, thanks, it worked here.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.