-
I'm doing some upgrades on a Robo3D R1+ printer, including replacing the motherboard with a BigTreeTech SKR Pro running RepRapFirmware, along with a BTT TFT35-E3 display panel. I've verified the below using another printer with a genuine Duet 2 WiFi, so I don't think it's specific to the BTT SKR Pro or the STM32 port of RepRapFirmware. Both motherboards are running RRF 3.2-beta3.2.
The problem I'm having is that the TFT35-E3 can't reliably get a list of .stl files from RepRapFirmware. When I go into the "print" menu on the panel, I can print from a USB flash drive or SD card, but when I click the option to display objects on the main control panel, it displays a "Loading..." message and then hangs. I can issue other commands (to move the head, heat the bed, etc.) without problems, so it's not a general communication issue; it seems to be limited to the M20 command specifically. This is with the very latest firmware from BTT's github, as well as with the bcmob and jimmymadDness forks of BTT's firmware recommended on the gloomyandy RepRapFirmware fork's wiki. (These forks make changes designed to make the display more friendly to RepRapFirmware.) I've also tried both with and without an "M555 P2" command in config.g. I've also tried a variety of baud rates, from 19200 to 115200.
Furthermore, the panel includes a g-code entry feature. Most commands (G28, M115, etc.) produce reasonable and expected output and/or printer activity; but if I type M20 in the g-code entry area, I get nothing back; it just hangs at that point. I'm able to print files from the SD card slot on the TFT35-E3, so I don't think the connection is generally flaky.
I have no problems with a PanelDue, even when I set "M575 S3", the same as I use on the TFT35-E3. I've tested all combinations of the TFT35-E3 and PanelDue on both the Duet 2 WiFi and BTT SKR Pro, and the problem follows the TFT35-E3; it's not restricted to the BTT SKR Pro.
I find it odd that the RRF-specific variants of the TFT35-E3 firmware don't work. I've examined the source code, and those variants include lots of code that's obviously designed to better handle RRF file listings. My best guess is that something has changed in RRF, perhaps with the shift from 2.x to 3.x, that's causing them to stop producing output because of some quirk of how the TFT35-E3 is feeding its commands, but I'm pretty much out of ideas at this point.
Does anybody else have any suggestions? Thanks!
-
This is a follow-up, in case anybody has similar problems. In brief:
- I've ended up getting the best results with the Thro42 variant of the TFT35-E3 firmware; however....
- Contrary to the documentation, I need to use "M575 P1 S1", not "M575 P1 S3" (plus "B{baudrate}") in config.g to enable support. Using "S3" results in flaky behavior.
- The Thro42 variant (as well as its immediate predecessors, the bcmob and JimmymadDness variants) disable the ability to print from the TFT's own SD card and USB slots. They also lack some of the more recent feature additions of the main BTT branch. OTOH....
- The point of these forks is to enable RepRapFirmware-specific functionality, including the ability to start prints from files stored on the mainboard's micro-SD card, a print status screen when a print is underway, and (for the Thro42 variant) the ability to run RRF macros. These features more than make up for the ones lost.
It took me many hours of experimentation to get to this point, so I hope these tips will smooth the way for somebody else.
Note also that the BTT github page for their TFT-series displays is quite active. Somebody recently submitted a merge request for some changes to improve RRF compatibility, but those changes don't come close to doing what the Thro42 fork does. It's possible that a future merge will do so, though.
-
Thanks @rodsmith I have flashed my screen with the firmware by ThRo42 & it's waaay better than the one I had, I just wish that there was a more recent version (26.2)
Have you came across any?
