No telemetry data available when printing from SD card
This might be related to the issue: No telemetry data available, but it could also be some other cause.
When printing from an SD card, the first time it was like a hard shutdown of the RPi port or lost connection to the RPi as shown on the attached screenshot. The Prusa Link reported N/A everywhere and Prusa Connect saw the printer as offline.
The second time I printed from an SD card, it was different. The Prusa Connect saw the printer as "printing", and I have a nice graph from that period (very useful). In the Prusa Link, data were available only sporadically with a lot of errors reported on the screen as shown in the other picture. Mainly there were errors like "Something bad happened on the printer's side", but the printer was happily printing and finished successfully.
PrusaLink type: Raspberry Pi Zero
PrusaLink version: 0.5.2
Printer type: MK3s with MMU2 (I use single-mode)
Printer firmware version: 3.10.1-RC1
More log
Could you send us daemon.log (you can found it on Settings tab), when this was happen. There can be some errors here, which can tell us what printer do.
RE: Daemon.log
Could you send us daemon.log (you can found it on Settings tab), when this was happen. There can be some errors here, which can tell us what printer do.
Sure thing! Look around yesterday evening (19.8.2021).
RE: What I could see from the logs
Hi,
You really did not give it the best chance to work properly, but good job breaking it 🙂
Thanks to some firmware limitations, I cannot scan the SD files when printing.
Moreover I cannot get the proper path to the file being printed when it's... you know... being printed, I'd need the file list for that. What broke was a thing that reads metadata from the long filenames, things like material and printer type, it tried to get the corresponding file object, but as there were no SD files loaded, it utterly failed and threw an unexpected error, I will fix that. Try letting it boot and list files, then start a print and see if that works better.
Did you have the pi port enabled the first time around? It's wierd it failed so bad, but I guess it wouldn't be the first time either.
No idea what happened today, except it has been started during an operation again, which should work, but there has been a lot of changes to that lately, so I don't even know what code might be broken there, it's most likely fine, or broken in a totally different way in the newest commit.
...
Thank you for your analysis. We also have to thank the Original MMU2 firmware, which helps a lot to break things.
For the log. Ignore the first lines at the beginning of the file. I had the wrong firmware for the first time 🙂 (I just had to try to know where is my baseline).
I had to revert from a custom 3rd party one which was perfect for more than two years to be able to use the newest MK3s FW required for this beta test. All the problems are suddenly back 😶. But don't worry I use it only to load a filament. I know its features are not supported yet.
But even now PrusaLink was able to tell when the printer had a problem that needs to be resolved manually. 👍
When I do everything properly like I let it boot, start printing, everything looks much better. There are stats in PrusaLink, and so on. I think problems start together with the X button which resets the printer, when I use it, it usually breaks the PrusaLinks flow.
How fast can you read the SD card while printing and while not printing? It must be pretty slow, but I assume you have mitigated this by reading only metadata instead of the whole gcode, or by using some compression.
PS: If you have some good news about the MMU, just between us here in this private section, I am one ear 😉
Confirmation
I have just finished a few prints and confirm that the main problem is resetting the printer or other errors while starting the print. If everything goes smoothly from powering the printer to the start of the print, data are there without issues.
Hi, we read only file names, size and modify time from SD card, no other data. So we parsed metadata from filename for files on SD card, this SD scan stopped the printer for a few time, which is according to files count on SD 🙁 You can try it by ejecting and inserting SD card to your printer - and check progress bar on LCD.
And of course, printer has filename length limit, so too long names on SD card is no read completely.
Thank you for all the info. I think what we have done here is that we have a bug reproducible. And we can move on from here.
At least, it is quite consistent in my case. Anytime the start of the print fails, data flow with PrusaLink breaks. So I don't even need to restart a printer, which I originally thought would be the biggest thing.
How have I not noticed
The custom FW says "TZB3.2.0-2495" as an answer to PRUSA Fir, I do not expect that format. I need to check the FW version to throw errors at casual users. We'd have to detect it's a custom fw and just ignore this check altogether, leaving the users "on their own".
RE: No custom FW for sure 🙂
Is this related to my case? Where did you read this FW info? I am on official FW on MMU and MK3s, no TZB definitely.
I got interested in why did the custom fw fail, and it was the fw version reported having an unsupportex format, that's all.
I had to revert from a custom 3rd party one which was perfect for more than two years
...
Yeah, I started the printer with this FW, but I didn't even get to the wizard. So I reflashed all MMU and MK3 with the official FW, and all prints were done only on the official one. So everything I am reporting here, all fails of the PrusaLink, has been done on the official FW only without any changes, as stated in the first post. So I really don't think that leaving users on their own applies to me here.