Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dell9 opened this issue Jan 8, 2019 · 28 comments
Open

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

dell9 opened this issue Jan 8, 2019 · 28 comments

Comments

@dell9
Copy link

dell9 commented Jan 8, 2019

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 F4500
checksum
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
Copy link
Author

dell9 commented Jan 8, 2019

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
Copy link

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

@makerbase-mks
Copy link
Owner

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

@dell9
Copy link
Author

dell9 commented Jan 9, 2019

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
Copy link
Author

dell9 commented Jan 9, 2019

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

@cihankosar
Copy link

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

@robustini
Copy link

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

@dell9
Copy link
Author

dell9 commented Jan 9, 2019

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
Copy link

I agree with you :) @dell9

@robustini
Copy link

robustini commented Jan 9, 2019

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
Copy link

Are you there???? @makerbase-mks

@cihankosar
Copy link

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
Copy link
Owner

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
Copy link
Author

dell9 commented Jan 10, 2019

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
Copy link
Owner

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

@dell9
Copy link
Author

dell9 commented Jan 12, 2019

@makerbase-mks
Copy link
Owner

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
Copy link
Author

dell9 commented Jan 16, 2019

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

@makerbase-mks
Copy link
Owner

@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
Copy link
Author

dell9 commented Jan 18, 2019

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
Copy link
Owner

Give me your email.

@dell9
Copy link
Author

dell9 commented Jan 19, 2019

I've sent message using email from your profile.

@Nick33N
Copy link

Nick33N commented Feb 6, 2019

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
Copy link

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
Copy link

yodine commented Feb 29, 2020

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
Copy link

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
Copy link

yodine commented Mar 28, 2020

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants