sbierly
commented
1 year ago Updating to this thread, I just pulled the thumb drive to browse on my laptop, and discovered two things of interest:
1) there are two files with bogus timestamps, "prusa_printer_settings.ini~" (not the primary version of this file, it's fine), and one of my Gcode uploads, both having timestamps of "12/31/2097 11:00PM". Something is clearly wrong here. 2) Looking at the other Gcode uploads, and comparing to the source on my laptop, they are all stamped a couple minutes later on the Mini.
On #1...who knows, you have an issue. On #2, it is now clear that you are timestamping on the Mini based on the received upload time. Given Mini clock issues, what's the point of taking this risk? Plus it just adds confusion, I'd like to see the timestamps match exactly from source to destination here, to validate correspondence. Conclusion--please consider preserving the source timestamp when creating the uploaded file on the destination machine, this seems better in every regard.
ondratu
Prusa-Support
Hello, I'm really loving the Prusa Link capability, but there are issues. Sometimes, everything just works. Other times, for no clear reason when I attempt to remotely start a print of an object just uploaded, it refuses to start with some message like "Unable to start print at this time", sorry I didn't capture the exact words but this has happened perhaps 4 times now. When I walked over to the printer and hit print, I noticed that the file was there on the list, but not at the top as it should have been as the most recent file. So, I suspect a timestamp error, not sure if related to the inability to remotely print the file.
By the way, the remote file listing behavior is frustratingly not the same as the on-printer experience. That is, remotely, it is not most-recent-first, but something random, which is just terrible, if you have a lot of files you have to go hunting for your just-uploaded file!
Thank you, --Scott