Print pauses from time to time

[surdu]

I have the LCD connected to MKS SBASE board.

When I print from the LCD using the SD Card or the USB dongle the print pauses from time to time for about 5 - 10 seconds.

Printing any other way works perfectly.

[pmbroth]

I know on one of the forum boards I'm on, a lot of people have this issue.

[surdu]

Can you put a link here please ? Apparently no one from MKS actually reads these bugs, so it will be ok to move the discussion somewhere else.

[pmbroth]

the other forum is specific to the Formbot TREX series printers, on facebook I added a second display to my printer a 12864 because i wanted the status and to be able to print without pause, https://www.facebook.com/groups/FormbotTRex/

[salcofago]

i am having the same issue with pausing i am using a gen 1.4 and wifi module when is the v2 releasing to the public thanks you in advance

[surdu]

I gave up and now I'm using OctoPrint with a Raspberry Pi that I had laying around, but I suspected my problem is long cable in combination with the cable running very close to the power supply / motor inducing currents (and therefor errors) in the long cable.

My plan was to try moving the cable around and/or trying to find a flat ferrite bead to place on the cable.

[enricodare]

i am having the same issue with pausing i am using a ramps 1.4 and marlinkimbra firmware. Use the original cable.

[salcofago]

Make sure you don't have any usb cable connected to the board

[enricodare]

I'm sure I don't have it connected

[makerbase-mks]

if use s3d to create gcode, please make sure do not select " setting-->temperature-->heated bed--relay temperature between each >" ,because it will create M105 each layer and make tft pause.

[makerbase-mks]

please check the gcode file , if there many m105, it will cause problem,please delete them and check again.

[Sicon76]

Thank you makerbase-mks to answer (it is important to keep in touch with your customers), I have the same problem and I will try your solution. If it is the problem, do you plan to release a new firmware to fix this?

[makerbase-mks]

Thank you. If it is the problem, it is difficult to fix because TFT send M105 get printer's status, it will conflict with M105 in gcode. we have no good idea to fix it.

[Sicon76]

If the TFT already send the M105 by itself, you could filter the M105 commands from the gcode (if you read a M105 in the gcode don't send it and go on the next line), don't know if it possible to do

[Sicon76]

Just checked my gcode generated by S3d, but the option is already deselected and in fact into the gcode I can't see any M105, so the problem is still there, any other suggestions? :(

[cruwaller]

I have exactly same issue and it is not related to S3D or M105 command. It happens also with other slicers....

I guess this is related to flow control issue while feeding a gcode to SBASE.

I requested error message info to get more info but not gonna happen :/

[Sicon76]

What is strange is that this problem isn't frequent otherwise no one will ever buy the mks TFT so there is a combination of firmware and maybe some gcode that give this problem. As underlined, any other commands is taken without problem, just during the print with the SD or USB there are these pauses

[surdu]

@makerbase-mks Only 7 months late to the discussion. I guess better late than never ... ? 😞

[makerbase-mks]

i would like to know more problem details and try to solve it, would you please take some photos and send to me? here is my mail shelly@makerbase.com.cn

[Sicon76]

Thank you for your help. Don't know if photos could help so much for my problem because it is really simple: after I choose a file to print from the SD, it sends the gcode commands one line every 5-10 seconds and the printer moves with such delay. I have a tft28 V2.0 with firmware 2.0.0 attached to a mks gen v1.4 and marlinkimbra MKDUO firmware (based on marlin). All other functions work fine and without delay: homing, moving the axis, set temperature and so on, only the printing from SD have such delay (and no M105 line in the gcode)

[handsomedude]

I have same issue. Printer extruder temp drops 2 degrees and pauses until temp gets back to normal then starts. End up with blobs all over the print. Work fine from PC and cheap reprap discount smart controller. Both have long data cables. It seems to be a temp issue.

[Sicon76]

I tried the following easy gcode G90 G1 Z25.0 G1 Z5.0 G1 Z25.0 G1 Z5.0 G1 Z25.0 G1 Z5.0 G1 Z25.0 G1 Z5.0 G1 Z25.0 G1 Z5.0 G1 Z25.0 G1 Z5.0

It freezes the TFT, I need to shutdown the power. I tried with 1.2.0 firmware, the same thing happen. I still don't know why the firmware of this TFT isn't public, at least someone with more time can help and find a solution :(

[cruwaller]

I have the same issue with MKS Sbase v1.3 & smoothieware + MKS TFT32.... Printing over USB / Sbase SD works great, TFT fails....

[enricodare]

I tried the new firmware TFT 28 32English2.0.1.zip, but no succes! Ramps 1.4, core xy TFT:32 V2.0. I can move, heat, home, etc, but I can not print. Tell me if i have to do some test for you

[surdu]

I would suggest keeping an eye on https://github.com/robotsrulz/MKS-TFT . It's starts looking as a very good open source alternative to this closed source firmware.

Installation instructions can be found here

[Sicon76]

I did a test: I read the serial output of the TFT, it works sending the correct gcode per every commands, but as soon as start the print from SD it sends only this line continuosly

N-1 M110*15

no other lines of the gcode was sent. I contacted makerbase-mks with the email provided, hope for any help ;(

[Sicon76]

Just to update you: I am in contact with Shelly about this problem and thank to the creator of MalinKimbra FW he pointed me about the issue with the M110 command: it seems it is an old gcode command that almost all the new version of Marlin just ignore, this is why some people don't have this problem (old marlin version, other FW etc.) and some have it. The TFT FW just send this command, but the FW doesn't respond and so it stays there forever. The MKS TFT isn't really a simple serial LCD like the reprap one, it doesn't just send lines of the gcode, it is a kind of host so if it isn't updated with the latest firmare it could fail (like now). I really hope Shelly will find a solution soon: it isn't a bad product afterall, it is cheap and has some features, but it has to work :)

[GregoryBakh]

I've got similar problem with printing from SD slot on TFT32. Printing stops on 2nd or 3rd level (depends on model) each time on the same place (if the same model is printing). Sometimes changing level thickness can help with the problem. I've tried to change sd or sliser software with no result. I've checked the gcode files and I have not found any M110 command in it.

[Sicon76]

The M110 isn't in the file, it is a control message that the tft sends by itself to the control board

[GregoryBakh]

Oh, I understand. But how can I filter it?

I'll try to print via USB or Lan to know that the problem is in tft.

[Sicon76]

This is something in the firmware of the TFT so we can't filter it (the TFT seems to wait an answer from the controller board so the only way is to disable such command, but it needs to rewrite the TFT firmware, something only MKS can do).

[cruwaller]

Does the TFT FW expect specific output? If yes could you point me one? I will modify Smoothieware fw accordingly...

[Sicon76]

@makerbase-mks Any news about this issue? To help I asked in a couple of the best facebook groups about 3d printing if someone with a mks TFT could print from its SD to collect data about the firmware used, which version of Marlin and so on... no one answered :( . So, maybe, the problem isn't so small. I wrote to you with the link of latest marlinkimbra firmware to test, any news? I'd like to underline how this isssue should be #1 for you and for your product, printing from SD is mandatory for a lot of customers and you have to allow it for all the major firmwares (for example, marlinkimbra is the second Marlin-derived most used firmware). I strongly suggest to you to release the source code of your firmware, this could help you to fix things and to let your TFT be bought a lot more due to be open source, in the end you are selling the hardware so why not? Please help us...

[murdock62]

@makerbase-mks Any news about this issue please ?

[pmbroth]

Since I have not connected my filament out sensores to this anymore, I do not have the issue . I added a 2nd display to my printer which I connected the filament out sensor to 12864 LCD Graphic Smart Display Controller module . NO issues., with both panels connected and no pausing.

[wbarber69]

same issue here. no m105 no m110 in my gcode. mks gen-l tft3.2

[stetzanton]

I have same issue to. MKS TFT32, SBase 1.3 Print from tft USB or SD generate random pause from 10 to 20 seconds Cable length from sbase to mks tft = 1.2m (network cable 4*2pairs). Print from SD card in sbase work perfect! Wait workaround for this issue!

[Thirkell]

Same issue here. MKS SBase board with TFT. Makes SD printing impossible

[mojtabahdpr]

I have same problem wih mks tft 3.2 this problem cause for me after a week @makerbase-mks not have answer ?

[pmbroth]

I have mkstft 3.2 with ramps no problem. What version of firmware on your MKS TFT? There were issues with older firmware. Latest is 3.2

https://github.com/makerbase-mks/MKS-TFT

[neildmd]

This could be a known issue between Simplify3D and Smoothieware firmware under certain conditions. For me it happens when I have "Only wipe extruder for outer-most perimeters " disabled under Edit Process Settings > Advanced

With that setting disabled I get random pauses on certain prints with small features and lots of curves. Once enabled the same models print perfectly without pausing. I am printing from the micro SD card plugged into the MKS Sbase controller board though.

I also have "Wipe Nozzle" 0.45mm enabled under the Extruder tab and "Perform retraction during wipe movement" enabled on the Advanced tab. Those settings could play a role in the pausing, I haven't tested with them disabled yet.

[Thirkell]

@neildmd It sounds like you are having a slightly different issue to the rest of us. We are trying to print from the an SD or USB plugged into the TFT display which causes the problems. It is not slicer specific either.

[KuroiSabato]

It seems that at Makerbase's, they just don't give a shit...

It's ok to have a problem ... not to give, at least, an answer is unforgivable.

[handsomedude]

Do what I did. Set the LCD baud rate to Hf of what you print controllers baud rate

I set my arduino to 250000 and LCD to 115200 and it works great.

PS if you set you print board to 250000 , you may not be able to refresh using USB. I have to connect a uart serial port in and flash using that to set arduino back to 115200 for USB to work again.

[KuroiSabato]

I'll give a try! Thank you handsomedude!

[handsomedude]

Hope it works pal. Drove me crazy. And last night when I was refreshing stuff, it happened to me again. Put it back to adruino 250000 and LCD to 115200.

Been printing sdcard all day now. Good luck

[KuroiSabato]

the strange is: was working perfectly until I made the dual struders upgrade, added the PWC and UPS ... since then... not a single print if not from cable.

Helvio Conti Rossini

2018-06-11 18:18 GMT+02:00 handsomedude notifications@github.com:

Hope it works pal. Drove me crazy. And last night when I was refreshing stuff, it happened to me again. Put it back to adruino 250000 and LCD to 115200.

Been printing sdcard all day now. Good luck

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/makerbase-mks/MKS-TFT/issues/8#issuecomment-396300571, or mute the thread https://github.com/notifications/unsubscribe-auth/Ahz4BuVjzv7TZOthNY40c8ckfP6PfUNoks5t7phLgaJpZM4Ls8v7 .

[KuroiSabato]

Ok, tried your solution, but does not works on the Mks sbase v1.3. So, I've changed BOTH Baud to 115200. First print: NO STOPS!

Maybe the problem is "solved", but gonna make more tests...

Thank you @handsomedude

[Thirkell]

@KuroiSabato Please do let us know your results on this 115200 Baud fix, especially on longer prints.

It does kind of make some sense. This is not a problem on Makerbases Robin board (which is the same in a different shape) as far as I know, which give a hint. The very long ribbon cable between the screen and the board makes a wonderful antenna at such high frequencies and the pause may just be the screen re-sending the command until it gets the 'ok' reply from the control board. Dropping the baud rate greatly reduced the antenna effect, reducing the noise and improving the comms reliability. That is my theory. I just dont have the wires or connectors to test with a shorter cable. The Robin board does not use the same cable and the one it does use is vary short.

[Thirkell]

I have now also tried this lowering the baud rate fix and can confirm that it works but only to an extent. The print pauses still occasionally but only very. The test print I did it paused maybe 4 times an hour instead of every few seconds. It happens more often when printing complex shapes or printing fast. This might indicate comms errors and it has to wait for the command to get received and acknowledged. I also had to drop my baud rate to 57600 before the problem went away to an acceptable degree. Dropping it further down to 9600 is not really an option, this made the print very slow as it had to wait for instructions very often. I still cannot figure out why more people dont have this problem

[factor31]

Hi, I had the same problem and I managed to fix it. I explain. I have the tornado printer with mks base V1.6 + TFT28 V1.3 + mks PWC v2.0 + mks 220DET v1.0 and powered by a UPS. When the printing failed me, I had this configuration in the config.txt file of the tft, the UPS and the 220DET were activated. I still do not have much knowledge of the marlin, but at the hardware level I could verify that the signals were all good, and making configuration tests, I only entered the pause mode always when printing. After researching a lot of time and reading a lot in the forums without finding a solution, I disabled the 220det in the config.txt but without disconnecting it from the PCB, and I checked that the filament and 220DET detector signals came into conflict if I disconnected the current . My solution: In the configuration menu do not activate the UPS and activate the mks PWC. Then in the section

set error range of Z-axis on breakpoints recovery> cfg_breakpoint_z_error: XX

where XX must be the value of cfg_ZADD: XX and from here, everything is perfect. be sure that when the machine is turned off this head raised the relevant distance, because if it has not done so, when resuming the print try to lower and collide with the piece.

I hope I have helped something. A greeting.