-
Notifications
You must be signed in to change notification settings - Fork 66
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
continuous pauses on SKR Mini E3 v1.2 with TFT35 E3 v3.0 #10
Comments
Does it still happen if you are on Marlin mode? |
Yes. I was testing in Marlin mode. |
Try disconnecting just the serial TFT cable. I'd be very interested to know if that helps. |
I’ll try that once my print is done. That will be tomorrow. I anticipate this also working as the original display is now making the printer work flawlessly! Will get back to you. Sent with GitHawk |
Was able to test now with the serial cable detached on the tft35 - and it works! So it’s def an issue with the serial communication! Sent with GitHawk |
I asked @guruathwal about this previously and he said there are no communications happening over that serial line in Marlin Mode, but from the behavior it certainly seems like there is. It has to be "leaking" in somehow... |
I've been spending a lot of time in the firmware recently trying to get Octoprint to work when connected to one of the TFT UART ports (bigtreetech/BIGTREETECH-TouchScreenFirmware#281). I have not found anywhere in the official firmware where it's communicating over the serial port when in Marlin mode but the fact that @nachosan100 found it makes a difference indicates that it probably is doing something there. Frankly, that's why I made the suggestion. I suspected that it was happening and I was just unable to find it. This will encourage me to keep looking for it. |
@hfog It HAS to be. Myself and another guy on Facebook were just discussing how when the TFT is connected, prints fail all the time and / or stutter, even in Marlin Mode. As soon as we both connected our stock displays ALL the problems went away. If it's not communicating in Marlin Mode, than the only other possibility is some bizarre electrical interference caused by the TFT. EDIT: Link to FB thread - https://www.facebook.com/groups/505736576548648/permalink/885727428549559/ |
I have the TFT35-E3-V3.0.26 connected to an SKR V1.3 running Marlin 2.0 and it seems that there is some interference on the serial port when running it in touch mode. I made a test print that just makes a lot of fast continuous circles and it causes a short pause approximately every 2 seconds. |
I made some tests by printing from the onboard SD via USB cable to PC running Pronterface to start the print, and TFT35 in touch mode. While it was running I went into the Settings/Feature and changed the Filament sensor from SMART to OFF and then suddenly it was running normal without the pauses. When I tried to reproduce the issue though it wasn't consistent. It seemed like it was somehow related to going into that menu and changing something but not specifically the Filament runout. However, once it was running smoothly it would consistently run OK from power up if I didn't change anything in the Features menu. |
Sort of unrelated but maybe can provide additional insight, I recently got a e3 mini v2 and a tft35 e3 v3, and they both work together. However the first two or 3 days I was setting up my board, I found that with bltouch, the TFT35, and the new board, it just wasn't wanting to work completely properly. So what I had was, without bltouch, everything seemed to work fine with basic firmware. Adding bltouch, I had various issues like not homing, x thinking it was triggered, and x slamming into the right with the belt skipping a bunch and I of course switched power ASAP. The reason I'm mentioning this, is because once I unplugged my TFT35 e3 v3, everything seemed to work. While I haven't tested a bunch, it showed no initial signs of failure. Just a theory, the controls being sent from the screen to the board, it's getting hung up somewhere. No matter what the command may be. Because when it did work on non bltouch firmware, I would go to hit stop print, and it would take maybe a layer or two worth of printing most of the time to stop. So i was thinking it's communicating like octopi just in that it reads and sends commands. I'm not sure the nitty gritty of all of this as I'm zero experience in firmware editing or compiling, except for the brief tinkering I did over the weekend. Hopefully this could be useful to anybody and hopefully I can get some answers because I really like the screen. |
This problem was solved in Marlin firmware MarlinFirmware/Marlin#17032 |
The problems I'm describing have not been fixed. I've tried many different firmwares. I'm also in contact with BTT diretly. |
What is your setup? RPi revision and pins that connected to TFT? May be this can help: bigtreetech/BIGTREETECH-TouchScreenFirmware#281 (comment) Also, you could try to compile TFT firmware with SERIAL_ALWAYS_ON and RAPID_SERIAL_COMM enabled. I've sucessfully tinkered my RPi 3 B+ , TFT3.5 v3.0 with SKR 1.4. |
I am seeing a similar thing in my setup (Ender 3 Pro with SKR Mini E3 V2 and TFT35 E3 and octoprint connecting to the USB port on the printer) If I print something via octoprint I will see random 2-3 second pauses as long as the TFT35 is connected from RS232 to the tft port on the main board. If I disconnect this cable, the problem goes away. I am running a custom build of Marlin based off the 2.0.6 tag |
What is the status of the reported issue. @mysticprysm What is the outcome of the contact with BTT? |
The current master TFT firmware comes with some changes how buffers are used. I would give it a try to see if it solves the reported problem. |
As a plus-one to this issue, I came across this issue in github after having the same problem and searching for a cause. I have just installed the bundle of an SKR mini E3 v2.0 plus a TFT35 E3. I use Octoprint to send gcode to my printer. Before I printed anything I updated everything to the latest BTT released firmware (mainboard and TFT), so everything is up to date as of today. The pauses happen quite regularly. |
I have been experiencing the same issue with stuttering prints I am using a SKR E3 mini V2 and a BTT TFT35 E3 V3.0. I have tried the PSU, Main Boards, Firmwares, Slicers, removing Octoprint, Printing from different SD cards, moving the printer to different rooms, buildings, removing surge protectors the lot. The issue was eventually found to be cause by interference to the BTT TFT35 E3 V3.0. I had a SunLu fialdryer next the to the TFT screen as soon as I turned the filadryer off or moved it away from the TFT screen the print stuttering stopped instantly. I have made a video of this happening. https://youtu.be/ohipSSizLVY |
Hello, i'm having this issue too when i load or unload filament in GUI mode. I'm using "malin mode", cause it's working. I'm having a second issue, in GUI mode. When i start print from SD, the head do the lvling, then she goes on 0,0 and she extrude, then move Z a little, then extrude, then Z .... no issue in "marlin mode" |
I've got the same issue with TFT-Firmware E3.27.x and Marlin bugfix-2.0.x Today I updated to Marlin bugfix-2.1.x |
Are you interested in testing a possible solution to this problem? |
Hello guys,
i get continuous small pauses in the print when the mini e3 and the tft are connected. It seems like the tft is causing the board to wait for processing and thus making the print pause for 2-3 seconds. Posted this on FB and got a repsonse to try if the error persists on the original display. And Voilá, the error is gone and its printing smoothely as always.
I am running customized marlin 2.0.0 with ABL and the SKR Mini E3 v1.2 plus the tft35 E3 v3.0 display. On an Ender-3 (or whats left of it..)
Any suggestions as to why the rs232 is causing the pauses?
thanx,
Alex
The text was updated successfully, but these errors were encountered: