MKS TFT32 + Repetier problem. Pauses during printing from SD card

[dell9]

Hello.

Having issue with long pauses (>10s) during printing from SD card using MKS TFT32 (firmware TFT28_32_v3.0.3) and Repetier firmware (tried both 1.0.2 and 1.0.3) on Arduino DUE board (printer boad is RuRAMPS4DUE).

Repetier configuration has enabled

define ACK_WITH_LINENUMBER 1

define WAITING_IDENTIFIER "wait"

TFT32 configured for Repetier firmware support.

Printing starts good, but every 3-10mins I've got pause in printing (more than 10 secs delay). In this time TFT screen shows progress, react for menu, but no action is done by printer.

I was able to mirror communication between TFT and Repetier to Due programming USB port.

So, when problem occurs, situation is the following:

TFT> N135 G1 X4.356 Y2.491 E0.0034 F4500checksum DUE> ok 135 DUE> wait DUE> wait DUE> wait DUE> wait .... a lot of wait for 10-15 secs DUE> wait TFT> N135 G1 X4.356 Y2.491 E0.0034 F4500checksum DUE> skip 135 DUE> ok TFT> N136 G1 X2.944 Y6.016 E31.7239*checksum DUE> ok 136

As you can see, TFT not able to receive OK with line number, waits and waits for it.

I am using shielded wires to connect TFT and Due, Wires are not long (near 20cm). Tried all possible communication speeds and found that lower speed gives more often problem with pause,

I have no problem during printing from SD card using Reprap discount fullgraphics LCD using the same length shielded cable. I've tried to disable LCD in the Repetier firmware and use TFT only - not helped.

Such long delay is not good for printing. Could you please advise if here any workaround of the problem? May be any possibility to set lower time in TFT for command resending if TFT not received OK for the previous command?

[dell9]

May be it will be good option to add TFT screen logic to resend the last and the next command after receiving "WAIT" instead of expected "OK" from Repetier?

Alternative - if I will change WAITING_IDENTIFIER to "ok" - will it give the same logic as I described above? Will I get command resending if printer firmware will send ok instead of wait?

Really I just need to make pause time as small as possible in case of communication issue between TFT and printer controller.

[robustini]

This is a know problem, already reported, it's a TFT firmware problem.

[makerbase-mks]

@dell9 If you don't connect the USB serial port, will the printer still pause?

[dell9]

Yes, but more rarely. Initially I was trying to use TFT with no PC at all and have got pauses. Then connected to PC, added logic to Repetier firmware to mirror communication to USB serial and got more often pauses.

[dell9]

Can confirm, that changing WAITING_IDENTIFIER to "ok" is not good solution. This change breaks printing at all =)

[cihankosar]

If you print with SD&USB , every a few minutes delaying printing.No solution !!! help !!!!!@makerbase-mks

[robustini]

The solution is only one: a new right debugged firmware...

[dell9]

Right now I am using another solution - attach back standard LCD 12864 and print from SD card using it. TFT32 is just instrument for manual action like homing or movements. Expensive toy for such small functionality, right? =)

[cihankosar]

I agree with you :) @dell9

[robustini]

Right now I am using another solution - attach back standard LCD 12864 and print from SD card using it. TFT32 is just instrument for manual action like homing or movements. Expensive toy for such small functionality, right? =)

IF MKS developers don't fix the firmware absolutely yes!

[cihankosar]

Are you there???? @makerbase-mks

[cihankosar]

I am using 115200 baud rate.Printing 5 hour no pause.It is not exact solution but you can use.I hate tft32.I never buy next time....

[makerbase-mks]

Maybe we need more tests to determine the problem, you can provide us with some test information, such as motherboard firmware, GCODE file, and whether you have tried to print with a lower version, like TFT32_V3.0.2 or V_3 .0.1 We can modify the time of the resend instruction in the firmware, but what is the problem that causes the pause? Is it related to the length or quality of the connection line ? it does not receive the OK and causes the pause? These are all issues that need to be detected.

[dell9]

Motherboard firmware - Repetier (tried both 1.0.2 and 1.0.3), TFT32 was V_3.0.1, updated to V_3.0.3 - the same. Sample gcode - later, but tried several codes generated by Simplify3D for normal STLs.

Problem is in data receiving by TFT. As you can see from sample part of communication log - all TFT commands are received correctly by Repetier, but in problem place, OK with number number sent by Repetier and not received by TFT.

May be good option will be special build of TFT firmware were all communication between TFT and controller will be recorded to log file on SD card? And we will see if here any not supported chars are coming from controller to TFT. According to logs produced by controller - all good chars are received from TFT and send back in OK response.

[makerbase-mks]

@dell9 Can you send me your Gcode file ? I will test it.

[dell9]

Sure. http://pics.mydns.su/3d/Optical_Endtop_holder.zip

[makerbase-mks]

Disconnect the USB connection between the motherboard and the computer when using touch screen printing, otherwise there will be a possibility of serial port conflict.

[dell9]

As I've told you before, issue still occurs with no USB cable connection between the motherboard and the computer

[makerbase-mks]

@dell9 I test it many times but no occur pause of printer. I used the Repetier-firmware_0.92.8 and MKS GEN_L board.

[dell9]

This is good for you and not good for me =) Anyhow my proposal -add debug mode to TFT with log writing to SD card and add parameter for response waiting time before command resending. How do you think, is it possible?

[makerbase-mks]

Give me your email.

[dell9]

I've sent message using email from your profile.

[Nick33N]

I have the same problem on the MKS TFT24 on RuRAMPS4D + Arduino DUE and Repetier firmware 1.0.3. Has something changed in this issue?

[Dynamitry]

I have the same problem. My setup is MKS TFT35 RuRamps4D + arduino due. Marlin 2.0. I think we must explain to all buyers, the MKS display is very buggy display, and nowbody know how to solve freeze problem!

[yodine]

Same problem with MKS TFT24 and MKS GEN_L and Marlin 1.1.9. The same code can print perfect but most often is ruined by long freezes. It stops from 0.5s to more than 30s, making a huge bubble on plastic where it stops. On very long freeze, pressing "pause" will take a very loooooong time to pause and park the head. Then pressing "resume" will crash the TFT24. After reboot, shows 0% complete but you can resume and it resumes nearly at the right position (misses a small part). But then it will print fine without any issue.

[Dynamitry]

I solved this problem. I attached 5 ferrite rings on all cables connected to Ruramps board. 1 ring on cable between RURAMPS and MKS TFT, 1 on wires of stepper motors, 1 on wires of endstops, 1 on wires of sensors, 1 on 24 V line and heater+bed cables. It was work stable for 5 month but now I detached MKS TFT and using Octoprint.

[yodine]

Never worked great with the touchscreen but solved by not using it anymore. As stated above, with Octoprint (didn't use any ferrite), never had a single head freeze for one month printing now. Sad that this product just doesn't work, having a touchscreen was a nice idea... if it worked. So the solution in the end is not buying this product.

[amirsolo2]

This product is just a shitti and they can't fix this problem , when they recommend to use old firmware means its not supported and they cant solve this issue better choice is to throw this garbage out and use old smart controller. Do u listen maker base ? This topic is here from april and you cant fix this yet , sorry for you guyes , u better go an sold potato