Prusaslicer 2.3.3 not resolving mDNS name when underlying Windows 10 does.
 
Notifications
Clear all

Prusaslicer 2.3.3 not resolving mDNS name when underlying Windows 10 does.  

  RSS
Astrobirder
(@astrobirder)
Active Member
Prusaslicer 2.3.3 not resolving mDNS name when underlying Windows 10 does.

Hello, 

I'm not sure if this is a bug or not, as I can't separate all the variables.  I recently upgraded desktop machines where I do my design and slicing.  I moved my Prusaslicer install over to the new machine.

Prusaslicer has an API key for each of my two Prusa i3's (MK3S+ and MK2.5S).   The MK3 just recently became a MK3S+, so that is also a confounding variable.

Symptom:  I can run the API Test for both printers with the mDNS hostname and both PASS the test.  I can also ping both hostnames from inside the Windows 10 Command line or Powershell, so I know that Windows is resolving these names.  However, when I try to send the g-code directly from Prusaslicer to the Octoprint Instance, for either printer, I get an error from PrusaSlicer:
PrusaSlicer has encountered an error

Error uploading to print host:
Couldn't resolve host name:
Could not resolve host: octopi.local
[Error 6]

 

It seems odd to me that the underlying Windows host has no problem resolving octopi.local (or my other octopimk3.local) hostnames, (i.e. they ping and they also ping -4), but PrusaSlicer can't.

Any ideas?

 

QUICK EDIT: Forgot to mention that PrusaSlicer also seems to want to crash out completely to desktop in some instances--even when trying to send to the octopi's IP address.

This topic was modified 3 years temu by Astrobirder
Opublikowany : 08/11/2021 5:44 pm
Vojtěch Bubník
(@vojtech-bubnik)
Member Admin
RE: Prusaslicer 2.3.3 not resolving mDNS name when underlying Windows 10 does.

Windows 10 supports mDNS resolve for some time and it works nicely. However there seems to be some issue if one calls mDNS resolve twice in a short succession. PrusaSlicer first checks the host API opening a first REST connection. Then it closes the connection and opens another REST connection to exchange the G-code. It seems as if Windows is sending mDNS requests for each socket opening and the second one fails. In upcoming PrusaSlicer 2.4.0-beta2 we are going to remember the mDNS resolve after the first REST exchange and use it for the 2nd exchange. This hack seems to work on Windows 10.

 

Opublikowany : 11/11/2021 6:06 pm
Astrobirder
(@astrobirder)
Active Member
Topic starter answered:
RE: Prusaslicer 2.3.3 not resolving mDNS name when underlying Windows 10 does.

Thank! I’ll give it a go when 2.4 hits release!

Opublikowany : 11/11/2021 11:03 pm
Share: