This morning I updated all 3 of my screens (MP3DP V4, Primo & LR3) to the latest TFT release from Ryan. New TFT release
Now on my MP3DP and Primo (Haven’t checked the LR3 yet) i get “No Printer Attached” I didn’t change anything in the firmware, just downloaded and copied to the card. there were no errors when they updated that I saw. No wiring was changed and they were working fine before hand. @jeffeb3 mentioned in the linked TFT post that it could be a baud rate issue but I’m not sure why that would be since I didn’t edit the firmware or how to fix it if that is the cause.
Hmmm, good question. I‘ve flashed my tft a couple of times in the last days. In some cases I saw the ‚no printer attached’ message and I had to manually change the baud rate in the tft settings menu which I normally never need to do. ATM it is set to 250000.
This is what i had to do. I still need to go check the Primo and LR3 to see if those need to be changed at all. I know the Primo said no printer attached but I didn’t pay attention to the LR3
I confirm the config.ini sets the baud rate correctly in the Repeat TFT package. I’m confused that a reset.txt is present in the same directory. It resets the tft to default values.
Ok so Primo and LR3 were already set to 250000. My DA had the black TFT wire backwords on the Primo. I always run in marlin mode so i never noticed it before…but that is corrected now and works great.
I ran the CNC file on the LR3 and Primo and the Repeat file on the MP3DP. The repeat file is the only one that had the baud rate incorrect. I assume I was correct in using the different file for the printer but if not i can go back and flash with the CNC file.
I’ve looked at the startup procedure of the tft (boot.c, line 370).
It firstly reads all bmp’s, fonts, the config.ini and processes them. All processed files are being renamed to ‘*.cur’.
Finally the software checks whether a reset.txt exists. If so, the tft is being reset to standard parameters (haven’t found the standard baudrate setting yet). The reset.txt is renamed to reset.done.
If the user cycles power the screen will startup again, but will not find a config.ini (as this was renamed before). This means the tft operates with standard settings until the config.ini file is copied to the SD card again.
If the above is correct, the reset.txt should be removed from the package. It hasn’t been part of the previous release which explains why there haven’t been issues before.
I don’t like the BTT implementation. If a reset.txt is available, why is the config.ini read? I would change the sequence.