[BUG] Random moves and stopping when printing from TFT

[alfondehesa]

Description

Posted this on the Marlin repo but wondering if this is a Tft bug.

When printing from the tft with either SD or USB, the print head moves at random to random locations randomly during any print (usually max X or Y), reports errors of "Unknown Command: G X100 Y100" or things like that, and then eventually stops printing early in the print, with no indication as to why. The screen itself is not frozen, and still looks like it's printing, steppers are still locked on and nozzle and bed are still being heated, just nothing is moving.

Other shenanigans: Sometimes too, in the middle of the print, a stepper will start buzzing like crazy as if it was missing all the steps, but then it keeps going where it is supposed to so no missed steps...

It looks like it might be a serial issue, where 99% of the communication between the screen and the main board is good, but for some lines it misses the some characters (which would explain the error above, which BTW on the file itself it is "G1 X100 Y100", but during the communication it seems to drop a random caracter on random lines and it results on the "Unknown Command: G X100 Y100").

Would be lovely to know if anyone else is experiencing anything similar to see if it is my screen that is defective or if I am not crazy. Wondering if it involves only the GD version of the display or all.

Steps to reproduce

1. Flash TFT to the latest working version (or any version within the last 2 years).
2. Flash SKR mini V3 E3 with Marlin 2.1.2.1.
3. Print from either the SD or USB port in the TFT.

Expected behavior
I can print from the SD or USB of the TFT in the same way as when I print directly from the SKR board.

Actual behavior
When I try the same GCODE file on either the USB or SD port on the TFT 35:

• At random points, hotend moves to random locations, usually to either Max Y or Max X.
• Print stops at a random point (usually close to the start), but display is responsive and says that it is printing. Steppers are still on and locked, and heaters are still on and heating, but no movement and no reaction to pause/resume commands.
• Steppers sometimes buzz loudly like they are stuck but then work perfectly fine with no missed steps.
• Messages on the TFT of "Unknown Command: XYZ" that show a line that is misswritten slightly when compared to the file in the storage medium.

Hardware Variant

Btt SKR mini E3 V3 with the GD version of the TFT 35 V3.0.1 (non E3 or D).

Board is self compiled marlin 2.1.2.1, with settings adapted for a bl touch CR 10 V2, based on the Ender 3 SKR mini E3 V3 example config.

TFT Firmware Version & Main Board Firmware details

Latest TFT pre-compiled version -1 commit (because to my knowledge the latest commit has a bunch of errors between the settings and config and language and icon files, and the pre-compiled bin firwares, but one commit ago it was all good).

I did try a lot of different TFT pre compiled firwares and even tried a self compiled bin, from different points and commits (up to 1.5 years ago) and although they each have a different set of bugs or issues they all share this problem.

I did compile my own version of Marlin 2.1.2.1 for the SKR, for which I based it off of the example Ender 3 and then just changed minor things to adapt it to a Cr10 V2 (I added a bunch of different things like input shaping or a bed leveling probe, but nothing that I feel could have caused these issues, especially nothing concerning buffers or serial settings).

Additional Information

N/A

[kisslorand]

Check please if you have the same behaviour with the FW from here.

[alfondehesa]

Just flashed it. The problem still persists in the same way.

[kisslorand]

You still had the "Unknown Command: XYZ" problem?
What happens if you print from Cura, Octoprint, Pronterface, etc by USB connection?

[alfondehesa]

When I print over USB (I use octoprint) it prints normally. I used the same GCode file too.

[githubber4ever]

I have similar issue using this (modified) TFT firmware on my Sidewinder X1:
When printing over USB (stick or cable) I get randomly stopped prints (just after skirt) or random errors/movements due to unknown commands that are not even in the gcode file.
...printed over USB stick:

...printed over SD card:

...printed over USB cable from Slicer:

Debug (examples):
echo:Unknown command: "MH�@157.107 Y171.340 E0.0977"
...
echo:Unknown command: "�""
...
echo:Unknown command: "C� ��58.660 Y113.713 E0.3887"

Something seems to randomly modify gcode commands when using USB.

[kisslorand]

When printing "over USB cable from slicer" where is the USB cable connected to?

[githubber4ever]

When printing "over USB cable from slicer" where is the USB cable connected to?

the USB cable is directly connected with the MKS Gen L 1.0 mainboard of the X1 where the TFT board is also connected to.

[kisslorand]

When printing "over USB cable from slicer" where is the USB cable connected to?

the USB cable is directly connected with the MKS Gen L 1.0 mainboard of the X1 where the TFT board is also connected to.

At this point I am sure you realize that the TFT has no influence on the printing job, it might be disconnected as well from the mainboard.
You should look for problem solving elsewhere, the firmware of the TFT has nothing to do with your problems.

[burneme]

I had this effect that it stops mostly in the first layers suddenly. This effect took place after the changes "Removed unnecessary cache queue for managing PLR feature". When I used older version I didn't see that. I did not investigate, just stick on older version.

[digant73]

When printing "over USB cable from slicer" where is the USB cable connected to?

the USB cable is directly connected with the MKS Gen L 1.0 mainboard of the X1 where the TFT board is also connected to.

if you have the MKS Gen L 1.0, the bus is shared with the TFT so you will have collisions. If you print from USB port you have to put the TFT on Listening Mode from the Connection menu

[githubber4ever]

When printing "over USB cable from slicer" where is the USB cable connected to?

the USB cable is directly connected with the MKS Gen L 1.0 mainboard of the X1 where the TFT board is also connected to.

if you have the MKS Gen L 1.0, the bus is shared with the TFT so you will collisions. If you print from USB port you have to put the TFT on Listening Mode from the Connection menu

@digant73 thanks for your reply. I actually used your X1 firmware and TFT firmware🙄. I could solve my USB printing issue (from stick and cable) by going back to Marlin 2.1.1 (had to build it myself from your sources).
But printing from USB stick should never caused a collision, right?
I have not yet tried your newest firmware from Jan-24 yet that might work again out-of-the-box.

[digant73]

When printing "over USB cable from slicer" where is the USB cable connected to?

the USB cable is directly connected with the MKS Gen L 1.0 mainboard of the X1 where the TFT board is also connected to.

if you have the MKS Gen L 1.0, the bus is shared with the TFT so you will collisions. If you print from USB port you have to put the TFT on Listening Mode from the Connection menu

@digant73 thanks for your reply. I actually used your X1 firmware and TFT firmware🙄. I could solve my USB printing issue (from stick and cable) by going back to Marlin 2.1.1 (had to build it myself from your sources). But printing from USB stick should never caused a collision, right? I have not yet tried your newest firmware from Jan-24 yet that might work again out-of-the-box.

printing from TFT's USB stick (or even TFT's SD) should not give you any issue (no collision etc...). I usually prefer to stay on stable Marlin fw (e.g. 2.1.2 or even 2.1.1). I never use Marlin bugfix (it is a work in progress usually with huge bugs).
If with Marlin 2.1.1 you have no more issues printing from TFT's USB stick (and TFT's SD) it is clear that the problem was in Marlin (I also have this feeling for the same issue reported by other users).
Which Marlin versions are giving you the issue? 2.1.2, 2.1.2.1?

[githubber4ever]

printing from TFT's USB stick (or even TFT's SD) should not give you any issue (no collision etc...). I usually prefer to stay on stable Marlin fw (e.g. 2.1.2 or even 2.1.1). I never use Marlin bugfix (it is a work in progress usually with huge bugs). If with Marlin 2.1.1 you have no more issues printing from TFT's USB stick (and TFT's SD) it is clear that the problem was in Marlin (I also have this feeling for the same issue reported by other users). Which Marlin versions are giving you the issue? 2.1.2, 2.1.2.1?

Marlin 2.1.2 (May 14 2023) I had the issue with

[digant73]

I had this effect that it stops mostly in the first layers suddenly. This effect took place after the changes "Removed unnecessary cache queue for managing PLR feature". When I used older version I didn't see that. I did not investigate, just stick on older version.

are you using the latest TFT fw with also advanced ok feature enabled on both TFT and mainboard? If so, try to simply disable advance ok on TFT only (from Feature menu) and let me know if it solves your issue

[burneme]

are you using the latest TFT fw with also advanced ok feature enabled on both TFT and mainboard? If so, try to simply disable advance ok on TFT only (from Feature menu) and let me know if it solves your issue

I tried both ways with "../Feature/Advance ok" without success. The TFT program is the actual version for TFT70 (no GD), precompiled. In one case it stopped early before G29, in the next case it hang in the first layer. It seems that the communication with marlin-board stopped, the TFT pgm is not frozen. Board is SKR V1.4 TURBO with Marlin 2.1.2.1.
When I use Octoprint thru BTT TFT70-board there is no problem.
Will downgrade the TFT-SW and retest with the same SD-card to make sure that it is no sd-card effect.
:)

[digant73]

@burneme try also to reduce the baudrate. It seems more a connection issue. Disable also advanced_ok feature on TFT just to avoid burst of messages that could accentuate a connection issue

[burneme]

@digant73 I checked with old FW, print is pretty good using the same (unmodified) SD-card. Obviously not corrupted. Current baudrate is 115k2 towards the main board, I'm sceptical about lowering the speed. This is no physical stress for the serial interface. I will play around with the effect of advanced_ok together with older FW to provoke error. Possibly something wrong with the configuration of marlin?
Does it make sense to log the serial communication to the main board either by an COMport (I know the difference between 3.3V and RS232-level, I must use a converter) or logic analyzer, to see what is going wrong?

[digant73]

@burneme Try to disable LED event feature from the Feature menu before printing.
I suggest you also to make a full power cycle thus removing also the power cable. So disable first the LED event from menu, then full power cycle and then start a print. Also make testing with both advanced ok enabled and disabled in TFT (you can leave advanced ok always enabled in Marlin).
Just yesterday night I had some errors (also at the beginning of a print exacly when the LED was switched on). Do you have a LED strip on your printer or a simple LED close to the nozzle?
I had the issue only on the printer with LED strip and advanced ok enabled. The printer seems also to be noiser during all the print. When disabling LED event on TFT and making a full power cycle the issue was no more present (and the printing was more silent).
I will continue with the analysis this night.
If you want to snoop traffic on serial port a cheap USB to serial device is enough (an FTDI to serial cable or board of about few Euro/Dollars). You need to connect ground and TX line of TFT. But I already did it and the errors where not present at all.
it seems to me a marlin bug maybe caused by some LED commands. Maybe Marlin starts to be very slow/unresponsive causing all the issues.

[githubber4ever]

@digant73 nice finding! With 2.1.1 the led on the X1 is off by default (with 2.1.2 it was on when print started), so thats possibly why it was failing with 2.1.2.

[digant73]

@githubber4ever the LED configuration in Marlin 2.1.1 and 2.1.2 are the same while LED event feature in TFT is configurable and it is responsible for the LED color changes when starting a print (blue when bed is cold to the color set in led_color parameter defined in config.ini (white color in my printers). If using the same TFT (with LED event feature enabled) you have LED color changes on Marlin 2.1.1 and no LED color changes in Marlin 2.1.2. that could be an indication of the issue. I need to understand if maybe something has been changed in Marlin side so the LED commands sent by TFT are the root cause of the issue (unknown command errors, noisy printing etc...)

[burneme]

Just yesterday night I had some errors (also at the beginning of a print exacly when the LED was switched on). Do you have a LED strip on your printer or a simple LED close to the nozzle?<

@digant73 No, this is a quite boring machine without LED, but I cannot exclude that commands for LEDs are sent. Will look for that this evening.

[burneme]

Since it is a communication problem, I will build at first a small unit which is able to log both sides of a serial connection and log it. Need it for regular work as well, than we can look thru the log.

[digant73]

@ALL if possible, please try the attached TFT fw (implementing #2889) with advanced_ok and event_led features disabled on config.ini or from the Feature menu and the new setting command_checksum enabled.
Flash the attached fw (use the one related to your TFT variant) providing also your current config.ini file with the addition of the new setting command_checksum set to 1 (enabled). At least, in case of communication instability (causing a gcode corruption responsible for the freeze on Marlin side, wrong movements of the nozzle etc.), you should get line number/checksum error messages and the affected gcode will be probably retransmitted successfully. Let me know the results (e.g. did you get line number/checksun errors and no more freeze?), thanks

MKSTFT28.zip
BIGTREE_TFT70_V3.0.27.x.zip
BIGTREE_GD_TFT35_V3.0.27.x.zip

[digant73]

Just yesterday night I had some errors (also at the beginning of a print exacly when the LED was switched on). Do you have a LED strip on your printer or a simple LED close to the nozzle?<

@digant73 No, this is a quite boring machine without LED, but I cannot exclude that commands for LEDs are sent. Will look for that this evening.

I found on one on my printers having a LED strip that the error at the beginning of some printings with settings advanced_ok, emulated_m109_m190 and event_led enabled on TFT are related to command M150 (sent by the LED Event feature). In particular, it is due to the presence of I parameter on M150. Removing that parameter from the M150, no error is present at the beginning of the printing. To avoid the issue, it is enough to disable advanced_ok (avoid sequence of M150 commands) or to remove the I parameter from the M150 (but it requires a change in the source code)

[digant73]

a new TFT fw is available. I would try it

[burneme]

Last Evening I tried it with the youngest version (TFT70, precompiled from here), stopped after approx. 10% of 1.8MB gcode-file.
My previously announced Box which can log both sides of a serial connection is ready, will help me to find the problem in the communication. Unfortunately the whole printer (ender5plus) must be disassembled to get the serial connection to the mainboard. For now I must stay on the old version to work until I have enough time. Thanks.