[BUG] Odd Behaviors when printing off of TFT35 due to new Marlin Update on SKR Mini E3 V3 #26055
Comments
|
Had a new development I mentioned Squealing a couple of times in my the post, and I was able to get in on video, where oddly it didnt shut off as it usually does and just kept printing, as you can see in the video there is something printed but no filament in the extruder, it happened to fast for me to record but it did rapidly retract the filament before it started to squeal. |
|
Damn, that crash into the printing part was crazy. I can't help much expect to say that I basically have a similar setup as your, just an ender 3v2, and same issue with input shaping. I was just getting random halts of my printer and my extruder started unloading the filament at max speed. Currently just have input shaping disabled, though I quite like the quality I got out of it. |
|
Yeah its been rough. I actually still have input shaping and everything else, except Ive had to transition to Octoprint. So far nothing has failed or had those issues sort of gave up until a better man then me tries to get it working on TFT35. @husakki |
|
Yeah Octoprint or even Klipper may be an option for me to consider. Its been quite a hassle with those weird behaviours and in my opinon there is still not clear cut answer to the problem, although I'd suspect BTT Hardware ^^' As long as it works for you now with Octoprint thats good, I'll probably get a raspbi along the way. |
|
This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days. |
|
Same problem here. Btt SKR E3 V3 with the GD version of the TFT 35 V3.0.1 (non E3 or D). When printing from the tft with either SD or USB, the print head moves at random to random locations randomly during any print (usually max X or Y), reports errors of "Unknown Command: G X100 Y100" or things like that, and then eventually stops printing early in the print, with no indication as to why. The screen itself is not frozen, and still looks like it's printing, steppers are still locked On and nozzle and bed are still being heated, just nothing is moving. Other shenanigans: Sometimes too, in the middle of the print, a stepper will start buzzing like crazy as if it was missing all the steps, but then it keeps going where it is supposed to so no missed steps... It looks like it might be a serial issue, where 99% of the communication between the screen and the main board is good, but for some lines it misses the some characters (which would explain the error above, which BTW on the file itself it is "G1 X100 Y100", but during the communication it seems to drop a random caracter on random lines and it results on the "Unknown Command: G X100 Y100"). I have Marlin 2.1.2.1 on the SKR, and I have tried installing a bunch of different firmwares from the TFT BTT firmware repo, even trying out different commits at different points of the branch. All have a different set of bugs or issues but they all have this problem in common, so thinking Marlin might be the culprit. Also tried different baudrates to no avail. I can still print fine from the microSD directly from the board, but it's kind of disappointing to not be able to leverage the tft ports ngl. I did compile my own version of Marlin for the SKR, for which I based it off of the example Ender 3 and then just changed minor things to adapt it to a Cr10 V2 (I added a bunch of different things like input shaping or a bed leveling probe, but nothing that I feel could have caused these issues, especially nothing concerning buffers or serial settings). Would be lovely to know if anyone else is experiencing anything similar to see if it is my screen that is defective or if I am not crazy. Wondering if it involves only the GD version of the display or all. |
|
@alfondehesa I had all of those symptoms. I truly believe after some TFT35 BTT Firmware commits, like adding support to advanced_ok may help the issue lies within marlin itself. or it could be the TFT35 but I tried so many things and in the end it is NOT hard ware, it cant be. The problem is firmware between TFT35 and Marlin bugfix-2.1.x something they havent been able to find yet. I ended up switching to printing fully from Octoprint and havent looked back I dont used SD or USB and honestly havent found a reason too. I can still use the TFT touchscreen to make changes, Bed level, etc, and In the middle of a print sometimes the extruder will act up and Ill just have to restart the print if I touch TFT35 settings like adjusting babystep Live. If I adjust any settings in marlin mode nothing is affected ever so far. Im actually in the process of switching to Klipper right now TBH. |
|
That's a shame, I actually really like Marlin and having a single board handling everything + not neading extra compute like a Raspberry Pi. I might try to downgrade to an older version of Marlin and see if the problems are still there, but I am not willing to give up input shaping. I will report back if I have any luck. |
|
Hey @alfondehesa So to your pointm, I just downloaded Klipperscreen on a BTT 5inch screen and an Orangepi 5 I have an basically its TFT35 without SDcard/USB support. But Marlin did release a new commit with Automatic minimum planner junction speed (#26198) I have a gut feeling that might work, one of my test was researching that as a potential suspect but it didnt do anything at the time. I had been troubleshooting this for a few months before I posted. Id give that a shot and see if it does anything |
|
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. |
Did you test the latest
bugfix-2.1.xcode?Yes, and the problem still exists.
Bug Description
So this is going to be hard to explain, Im including videos as well. I currently have an Ender 3 Pro, with an SKR Mini E3 V3 Motherboard and an TFT35 E3 V3.0.1.
I wanted to take advantage of Input shaping and MPC auto-tuning that I did not have before which was Marlin 2.0.X now I dont remember exactly what I had before I just know it was not the MArlin Firmware with Input shaping, I was having issues with my CR-touch and found a random firmware that someone made that worked flawlessly and I left there, I just couldnt access the Configuration.h and Configuration_adv.h from that Firmware as he only made the .Bin file available, which was unfortunate but at the time I just wanted it to work. As I finished a project in Early April. I decided to learn how to compile my own Marlin firmware, at the time the Latest firmware with IS and MPC was added. I joined the bandwagon in Mid-April. Since then, it has been a slight nightmare trying to get this to work. I have had mild success from time to time but it always seems to give me issues on different Prints so I know that Its not fully fixed.
Im pretty good at trouble shooting I have tried everything from reverting Firmware ( which still works flawlessly ) to Switching out for a new Motherboard, and a new TFT35 to eliminate it being a Hardware issue and it is not, issues still remains. Ive tried different slicers as well, Just Cura and Prusa using the same file. I have tried out older firmwares under MArlin 2.1.x as well as much newer ones. Everything works until the Print actually. Now I believe that it could be more so on the TFT35 firmware rather then the Marlin Firmware as Octoprint and Marlin work just fine on whatever I compile. but as you'll see in the Expected behavior I am asking for assistance here as I believe there is something wrong in compalibility of some setting in Marlin causing an Issue when printing from the TFT35. The issue with happen quicker if I adjust the Speed Percentage in TFT35 when printing but still happens when printing without adjusting the Speed percentage. One final note here I wanted to add, The Gcode was checked each time to make sure nothing abnornmal was being instructed. this behavior happening has nothing to do with the Gcode being sliced.
Bug Timeline
Anything after April 7th commits
Expected behavior
Print starts, and finishes, Printer (Marlin/TFT35) reads G-Code and performs the subsequent instruction regardless of speed percentage chosen. any negative consequences should be visual only in quality.
Actual behavior
When Print starts, as you'll see in the video, the printer will begin and at complete randomness, the Print head will move to random locations. It will pause and I will need to send an Emergency Parser Gcode like M108 to get it to move again only to have it pause or freeze again. The Printhead will Pause, screech and proceed to either rapidly Retract the Filament, or rapidly Extrude the filament. Printhead will Move up the Z-Axis for no reason and then back down but does not stop and jams into print or bed. ( I lost a hotend like this ) One or all of these will happen when the Print starts, and it will happen at different layers and different points in the layer. More common to happen with Larger prints then smaller ones IE the XYZ calibration cube would not happen as frequently. from time to time I would get a message that would say "Unknown command G X87.89Y88089" Basically a command Jumbled up or missing letters.
Steps to Reproduce
I dont know how to explain what steps to reproduce only to explain this happened after I started using a new version of Marlin. I can explain things I have Uncommented or commented to try and fix the issue.
I believe it has to do with some beneficial setting and not a common setting that does not like another setting. In the last 3 months, I have trial and errored so much Ive gone through One hotend, and multiple 1kg spools.
The closest I have gotten to getting it to work wass at one point Uncommenting "S-Curve Accelration" when using Input shaping, that worked for a bit then I recompiled with The Commit added on May 15th "Disable FT Motion by default"
and that brought back the issue but did not immediately fail as fast as before with S-curve back on with Input shaping. I have messed around more with settings in Configuration_adv.h. then in Configuration.h. The settings I have played with the most are Buffer settings. M114/M154 for Reporting Positions. Input shaping turning on and off //#define SHAPING_MIN_FREQ //#define SHAPING_MAX_STEPRATE. this helped for a bit. I thought maybe it was an Issue with Baudrate as well, when I lowered it from 115200, to 57600, I saw much more improvement issue would persist but come later not earlier. That also removed the Unknown command error. I trialed this by changing it back and forth and everytime 115k would fail. I do not believe that Ram is an Issue, Marlin always compiles at around 20.0% to 30.0% depending on how much the Buffer size change is, and how much Max Accel/Feedrate I put. I tried changing UBL to ABl as that was another big change I did from last Firmware. That did not help. I also went from PID to MPC and back to PID and that didnt help. Ive tried removing and adding anything that would affect the way the Ram is used. IE Bezier curve support, ARC support, IS,S-curve. Etc and yet it does work for a little bit then fails again or fails instantly. I have Attempted to Use USB over SD card, no change in behavior, in fact when it was working for a bit and I got some successful prints out of it, I tried USB and it failed instantly but reverting back to SD was fine. Ive Increased Slowdown divisor and DEFAULT_MINSEGMENTTIME thinkning maybe it was just overrunning the TFT35. Ive turned on/off ADAPTIVE_STEP_SMOOTHING and Edge_stepping. Ive recently turned off some options I thought were needed but were not such as CRC SD recheck, and //#define REALTIME_REPORTING_COMMANDS played around a bit with Advanced OK and Host keepalive on/off. still no improvement. Ive also currently have Linear advanced set to 0 but even when being actively used or 0 no difference. At first I thought the TFT35 was getting to hot which was weird, so I just added a fan to help cool the Main chip down. Lots of cooling is provided for the SKR Mini.
Version of Marlin Firmware
bugfix-2.1.x
Printer model
Ender 3 Pro
Electronics
SKR Mini E3 V3.0 Motherboard. TFT35 E3 V3.0.1
Add-ons
Changed Extruder through out this to Creality E-fit extruder, before it was a direct drive Adpater with stock Stepper motor and dual gear. Upgraded Hotend to Creality Speedy Ceramic Spider 4 ( Or whatever they call it officially ) Octoprint Server running connected via USB on SKR on an OrangePi ( Attempted with it turned off/disconnected no change in behavior ) Dual 5015 Fans running off a Buck Converter. Noctua 40mm Hotend cooling fan running off a Buck Converter. PSU is stock.
Bed Leveling
UBL Bilinear mesh
Your Slicer
Cura
Host Software
SD Card (headless)
Don't forget to include
Configuration.handConfiguration_adv.h.Additional information & file uploads
I would like to note that I will be posting this as well in the TFT35 firmware Github just in case, as I dont know which one is the culprit here. I believe it to be Marlins newest Firmware with a big making it imcompatible with something in TFT35 Firmware. as the issue is only there when I print everything else works fine and on Onboard/Octoprint Printing. Or I could be completely wrong and I compiled something terribly.
I currently have the ability to print normally so i I thought I was good then the second video happened. I was not able to get it I just have no frame of reference on when it will happen, but The print head stopped, extruder Screeched the moved slowly, stopped I used M108 and it proceeded as shown in the video, it stopped because it was actually on the second to last layer, but didnt finish its end Gcode nor stopped the print I had to manually cancel it. Prior to the video I had to restart the print due to the Extruder Squealing and then the printer shut off on its own as if it couldnt handle something.
Last note, thank you for reading everything it has been a long 3 months battling this. IF you have any question feel free to ask, im still working on it now. I have done what I feel like is so much so I may have missed something I did so throw out questions and Ideas . Thank you!
Configurations.zip
dc40dcd3-4396-43f0-a52b-4ebde3362b77.mp4
video-output-C369712C-17FC-4D30-BB90-8DB0CE5E0AEF.zip
The text was updated successfully, but these errors were encountered: