You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using "Send to Connect" from Prusa Slicer, the file would upload to connect but then fail to send to the printer:
However, I could successfully transfer the file to the printer using the Prusa Connect web interface (and successfully print)
I was stumped for quite some time on this until I started clicking around on the "Folders View" in the Connect web interface and I could see the SD card on the MK3S+ which was empty (tried to upload a file to it and it said the device was write protected, this may be true I didn't investigate this further), however I also noticed it had the folder 'Prusalink gcodes' but it was not clickable and had a big questionmark for a picture.
I had changed the default location of the gcodes folder in my pruaslink.ini file:
I commented that line back out (reverting it to the default) and just like that I was able to "send to connect" from the slicer and have it send to the printer with no issues.
So I actually think this bug may be in Connect not Prusa-Link? But I thought if I put it here anyone else who has this problem might be able to search this here.
Additional info which I don't think is relevant because I do have everything work now, but hey you never know:
I'm running Prusa-Link as a Docker container using: https://github.com/donslice/prusa-link-docker, however I'm actually running it in K3S and was changing the directories to make it easier to mount persistent volumes to them.
The text was updated successfully, but these errors were encountered:
Hi, actually, I'm not sure what was exactly happen to you. But some information:
PrusaLink can't write to SD card in Printer - so it is marked as Read-Only, which does not mean, that it really is in read-only state (physical switch or error)
directory for printer aka PrusaLink gcodes have to be writable and available. PrusaLink watch this directory with inotify system. So if is not available for PrusaLink it is not available for Connect
Theoretically, you can se some operation system lack, when inotify don't see the directory, even if the Prusa Link print from that.
I think what I found is that Prusa Connect may have a hard coded path somewhere to PrusaLink gcodes and when I changed the default path for my setup it broke Connect, it seemed that as soon as I changed back to the default setting for directory under [printer] that everything was fine?
Could have been something else, or transient too? /shrug
Found kind of a peculiar bug.
When using "Send to Connect" from Prusa Slicer, the file would upload to connect but then fail to send to the printer:
However, I could successfully transfer the file to the printer using the Prusa Connect web interface (and successfully print)
I was stumped for quite some time on this until I started clicking around on the "Folders View" in the Connect web interface and I could see the SD card on the MK3S+ which was empty (tried to upload a file to it and it said the device was write protected, this may be true I didn't investigate this further), however I also noticed it had the folder 'Prusalink gcodes' but it was not clickable and had a big questionmark for a picture.
I had changed the default location of the gcodes folder in my
pruaslink.ini
file:I commented that line back out (reverting it to the default) and just like that I was able to "send to connect" from the slicer and have it send to the printer with no issues.
So I actually think this bug may be in Connect not Prusa-Link? But I thought if I put it here anyone else who has this problem might be able to search this here.
Additional info which I don't think is relevant because I do have everything work now, but hey you never know:
I'm running Prusa-Link as a Docker container using: https://github.com/donslice/prusa-link-docker, however I'm actually running it in K3S and was changing the directories to make it easier to mount persistent volumes to them.
The text was updated successfully, but these errors were encountered: