[Q] Problems with TFT E3_V3.0 and Marlin 2

[Eddiiie]

Your question or details you need. Please describe.
I have BTT SKR Turbo Mini V3.0, TFT E3_V3.0, Marlin 2, configuration.h and configuration_adv.h changes made according to the readme on this github page. Also use Octoprint.

I have the events setup to change screens on the TFT, they seem to work.

The problem is, or at least this is when I noticed it, none of the controls on the TFT screen will work. They display active values, but if you adjust the hotend temp, the temp never changes. If you change temp on bed, nothing happens. If you go to terminal and send a command nothing returns.

I also notice in the upper left corner there is text that says "M600 Emulation" .... It is always there and it is turned off in the TFT settings.

The controls work on power up, but not after sending a print job or during a print job. I have to reboot to get the controls to actually work again.

Its not touch related. Touch is fine. Everything functions, just that the commands are not received by the controller board. ??

What can I do to troubleshoot this?

Marlin 2 BugFix from a week ago..

#define CONFIGURATION_H_VERSION 02000903
#define CONFIGURATION_ADV_H_VERSION 02000903

TFT firmware uhhh from Feb 24, 2022...

Thanks!

[kisslorand]

Is it working OK as long as you do not start a print job? Do you have many files on your storage media?

[rondlh]

Sounds like a unreliable serial connection, perhaps you can try a slower baud rate. How is everything wired up? Where is Octoprint connected?

[Eddiiie]

@kisslorand Yes, working OK as long as I do not start a print job.
In fact, just re-testing this now, I am able to control everything while a print job is running. I think the problem comes when the print job completes.

Way down on the Readme.md says this:

When the trigger print_start is received, the TFT switches to Printing menu. Once on Printing menu, the pause, resume and stop buttons on the menu will be disabled. That means only Octoprint will control the print. Only on print end or cancel (with triggers print_end or cancel) the TFT Printing menu is finalized (statistics available etc.) and unlocked (the menu can be closed).

So,
When the trigger print_start is received, the TFT switches to Printing menu .... Yes, this happens.
Once on Printing menu, the pause, resume and stop buttons on the menu will be disabled. ... I will test.
That means only Octoprint will control the print. Only on print end or cancel (with triggers print_end or cancel) the TFT Printing menu is finalized (statistics available etc.) and unlocked (the menu can be closed). ... Well, I do get a Print Complete message and the option to view summary at the end of a print. But could it be that the display is still 'locked' some how?

@rondlh Interesting... Bad serial connection? Maybe missing the unlock command or something? Lower baud rate, great idea. is there a note somewhere on how to improve .. Ground? to the display.. Is it RX/TX wires?

[rondlh]

@Eddiiie Based on your initial report I can tell that some of the communication is working and some is not, so it seemed to be a communication issue, but after your update this does not seem to be the case.
Keep the serial cables short and of course they should be grounded on both sides. Keep the serial cables away from stepper and power cables as much as possible, these cables cause a lot of noise when the steppers are running, often enough to trigger end stops and flip some serial bits.

[Eddiiie]

OK, will relocate a power wire I have running parallel with the flat cables.

Is there a way to send the bits received over serial to some unused pins on the display for logging and sniffing purposes?
Even if it is custom firmware

[digant73]

@Eddiiie "M600 Emulation" message is a bug fixed in one of current PRs (the right message should be "Remote Printing..."). As reported in README.md, when a print is controlled by Octoprint, the TFT menus are disabled. Only on abort or print completion (with trigger print_end) you will get again the control of TFT

[rondlh]

@Eddiiie Some displays have a debug serial port for this purpose, but your TFT doesn't. You can monitor the serial data on the Wifi port via wifi or a (custom) serial cable. Make sure to enable that port on the TFT and select the correct baud rate.

[radek8]

OK, will relocate a power wire I have running parallel with the flat cables.

Is there a way to send the bits received over serial to some unused pins on the display for logging and sniffing purposes? Even if it is custom firmware

In the Configuration.h file you can enable the serial port on the TFT for debug communication

/**

• If one of the DEBUG_x below is defined the SERIAL_DEBUG_PORT defined in board specific Pin_xx.h file
• will be used for debugging purposes. DON'T enable one of the DEBUG_x below for normal printing.
• WARNINGS:
• • SERIAL_DEBUG_PORT needs to be activated specifically. Please consider SERIAL_PORT setting in the config.ini.
• • If the TFT is only showing the boot logo and is not responding anymore, check the SERIAL_PORT setting.
• • If you update the config.ini you need to reset the TFT twice (first reset to update the config, second

• reset to enable the SERIAL_DEBUG_PORT due to the changed firmware config).
  

*/

/**

• Generic Debug
• Uncomment/Enable to enable arbitrary debug serial communication to SERIAL_DEBUG_PORT defined in board specific Pin_xx.h file.
  */
  //#define DEBUG_SERIAL_GENERIC // Default: commented (disabled)

/**

• Serial Communication Debug
• Uncomment/Enable to forward/dump all serial communication to SERIAL_DEBUG_PORT defined in board specific Pin_xx.h file.
  */
  //#define DEBUG_SERIAL_COMM // Default: commented (disabled)

/**

• Config File Debug
• Uncomment/Enable to show debug information during config file processing.
  */
  //#define DEBUG_SERIAL_CONFIG // Default: commented (disabled)

[Eddiiie]

Great.

So, uncomment
//#define DEBUG_SERIAL_COMM // Default: commented (disabled)

Recompile, do I need to set anything in config.ini? such as
serial_port:P1:6 P2:6 P3:0 P4:6

These are 3.3v pins? Pin outs for tft35 e3 v3 ?

It looks like the SERIAL_DEBUG_PORT for this display is SERIAL_PORT_3.... which is UART3?
Does this dump both sides of the conversation?

[oldman4U]

What is the status of this ticket?

[Eddiiie]

@oldman4U Are you talking to me? No one answered my questions above..

Are the pins for UART3 3.3v logic?
Does this dump both sides of the conversation? RX and TX?
@rondlh says my display does not have the option to dump the conversation, whereas @radek8 says to enable lines in configuration.h ... Which I have done, but have not compiled yet or tried out yet because I was waiting for response.

Which is it? Does this TFT (tft35 e3 v3) have debug or no?

Also, during this time, I have moved the ribbon cables around a bit to clean up wires hanging around and strange things have started to happen. I can really only print reliably from the SD card now on the controller. Printing the same file via octoprint makes the hotend pause, studder, which sent me down another rabbit hole. It seemed to start after I added the layer stuff to Prusa Slicer... " ;LAYER:[layer_num] " on after layer change. But that can't be it... There's no retries logged on the Octoprint webpage either.

During prints from the SD card on the controller, I get strange messages pop up with Typos. I did not take any pictures but for example a message SD Card OK would be like SD CArd OK Some letters will be caps. But the message is still readable sorta. It sure does seem related to moving the cables around. Hoping there is a short that will be revealed by enabling raw serial debugging. I just want to see a bunch of random characters go by when I move the cables. That would make my day. (line noise)

If I was to add a ground wire between display and ? where would the best places be to do this, both ends.

[radek8]

What's your control board?
I did not find BTT SKR Turbo Mini V3.0 anywhere ....
SKR mini E3 V3.0 or SKR E3 Turbo ?

[Eddiiie]

Sorry, this is related to an Ender3 with an SKR Mini E3 V3 and TFT35-E3 V3 ..

Here are my config files..

Configuration.txt
Configuration_adv.txt

[radek8]

I will not answer your questions about the debug function. I never needed it, so I didn't study it. I know about that function, that's why I showed you the way.
Your questions could be answered by @guruathwal , he has programmed this function.

[radek8]

SKR Mini E3 V3.0 is often discussed. Many users complain of frequent crosstalk in serial communication or electromagnetic interference. There is a lot of discussion where users complain about this. But I have never seen anyone find a final solution.
You also contributed to some of them, so you probably found out.
The shielded serial cable is good, but it probably won't help with your board.

The SKR Mini E3 V2.0 board did not suffer from these problems

[Eddiiie]

There is also a new checkin with Marlin relating to filtering of logic levels with 3.3 when marlin was built on 5v.
MarlinFirmware/Marlin#23925

Should I add this in or keep things as-is ? My goal is to enable a debug port to dump both sides of the conversation, looking for random line noise during print.
short-of slicing the cable and tapping in, it could be a bad cable, would like to examine serial streams, then mess with that cable.

[radek8]

The interception of communication has already been handled by @kisslorand
look here

#2295 (comment)

[Eddiiie]

So with that being said, I am going to close this [Q] topic and watch #2295 .

I also moved wires around trying to make things worse but after 3 long prints there have been no strange messages or pauses.
I basically have 24v wires +/- wrapped around the ribbon cables... Thinking that would for sure cause some noise...

Just now I crashed my display updating to my compiled firmware and config.ini. lol Just sits at the boot screen. I remember reading about this somewhere but dont remember what. Going back to the "COPY THIS TO SD CARD" files and will try 2295 patch.

Thanks all for the attention.

[Eddiiie]

For what its worth, I ran a 19 hour print job through Octoprint and the USB port on the controller and got the following notices at different times during the print on the TFT35 e3 3.0...

9usy: processing
/usy: processing
usy: processing
b@sy: processing
nusy: processing
ousy: processing
bysy: processing
3usy: processing
busy processing (no colon)

Also, rate seems to get set to random numbers at the start of a print job sometimes
and the display is no longer talking to the controller (SKR e3 mini 3.0)..

[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.