DuetRRF Cura Plugin, add Duet Discovery
-
@roseg0ld said in DuetRRF Cura Plugin, add Duet Discovery:
Is there a way to access all of the Duets on the network even if they have the same name?
you could do a portscan of the entire subnet. but i would not recommend that.
just for clarity sake it makes sense that each printer has its own name. -
when you know what you're looking for scanning /24 for devices on port 80 once isn't too bad. my nmap foo is weak, but I'm sure you can throttle the connections/second if concerned about abuse.
if locating them on the network isn't a good solution, then just pull the SD cards, and edit the
/sys/config.gfile and change the name there( its the M550 line, or connect via USB and change the name withM550 P"MyDuet1") -
Thanks for those ideas and suggestions @bearer and @Veti! Just to be clear, we are producing the Nautilus so all of our printers are going to have the same name coming out of the factory. I'll look at some of your ideas and see if I can get any of them working.
-
@roseg0ld said in DuetRRF Cura Plugin, add Duet Discovery:
e are producing the Nautilus so all of our printers are going to have the same name coming out of the factory.
Thats a different usecase.
a possible solution for that is.
use a cheap router (tp link with openwrt) and create a testing subnet (different from your normal network)
lets say you want to test 10 per batch.
configure the dhcp server with a leasetime of 60 seconds. and specify the range to only include 10 addresses.
this way you know that those 10 machines will have useing those specific 10 ip addresses.
if you are finished with one, disconnect it, plug in the new machine and it will take over the ip address that was freed.even more advanced, you could create a subnet for each port of the router which each port having its own dhcp instance running assigning just 1 ip address.
this way you would know that whatever is plugging into that cable has that specific ip address. -
@roseg0ld said in DuetRRF Cura Plugin, add Duet Discovery:
Thanks for those ideas and suggestions @bearer and @Veti! Just to be clear, we are producing the Nautilus so all of our printers are going to have the same name coming out of the factory. I'll look at some of your ideas and see if I can get any of them working.
Unless you only expect the customer to buy one device or explain how to set up multiple devices I'd recommend a different approach. One of the more common approaches is to include part of the serial number or MAC address as part of the hostname. NautilusA0B1EF and variations of such.
If its a "large" scale test setup I'd recommend the last approach Veti suggests, much simpler to deal with a known IP or hostname for a given network port.
-
Sorry, I think I was still a little unclear with my description of the intended use case. Our printer currently has a plugin for Cura that installs all of the printer profiles and also includes a slightly modified version of the Duet RRF Plugin for adding connections and uploading prints. What I would like to do is add a discovery functionality to the plugin (ideally I'll integrate it into the DuetRRF Plugin for everyone else as well) so that a user can open a plugin window in Cura and have it automatically list the Duets on their network for streamlining the connection adding experience.
If a customer of ours (or other Duet user) has 2 or more printers on their local network with the same name, my current script will only return one of them, breaking the discovery functionality. For our purposes, we could follow @bearer's suggestion and give them unique names, though this would add a little more work to our production workflow. This wouldn't be a general solution for adding to the DuetRRF Plugin so it would be nice to find a way to find all of them.
I appreciate everyone's continued input! Based on my now fleshed out description, would it make sense to look to the dhcp server or use nmap? As previously mentioned I'm quite a noob when it comes to networking protocols so most of this is totally new to me.
-
@roseg0ld Bonjour! - That’s how Apple calls it. Aka "Zeroconf“, "Avahi“. What you want is exactly what Bonjour does: to tell a client which printers (or whatever services you can imagine) are available on a (local) network. Most 2D Printers have this built-in.
The basic idea is that a device offers his specific services over TCP/IP, before a client has to establish a connection. Every client (PC) can look up the services it wants to use (scanners, 2D- or 3D-printers…) and, if there are multiple offers of the same type, resolve them to a list of unique device names which can then be presented to the user.
In your initial post, you already mentioned Zeroconf, so I assume you have a basic idea how it works. As a developer of mac software, I use Bonjour on a daily basis - it does exactly what you want, but, as @chrishamm told you, the DNS-SD (Service Discovery) part of the protocol is missing from the Duet.
So, you are on the right track, but you should ask @chrishamm what it takes him to implement "the missing part“, or if this might even be impossible on the ESP. Just to give you an impression of the complexity of such a task, have a short look at the specs (from the lion's mouth, specific to printers).
-
I really appreciate all this assistance, I'm fairly certain I found the missing part @infiniteloop mentioned but I don't know how/why
. I found this stack overflow thread, and Santi Peñate-Vera's script works perfectly for listing IP addresses of the devices on our network on my Mac, but it returns no addresses when run on a Windows machine. Do you know why this script might break down on Windows?I also need to build functionality for confirming the device is a Duet. Perhaps @chrishamm has a suggestion for the easiest way to confirm a Duet Wifi given an IP address? I could certainly submit any of the DWC http requests and if I get an expected response then it's confirmed, but I think there's a smarter way since my initial zeroconf script returned that properties object with the product as Duet Wifi.
-
@roseg0ld said in DuetRRF Cura Plugin, add Duet Discovery:
Do you know why this script might break down on Windows?
are you running with admin privileges?
-
@Veti Not explicitly, might there be a way to run that script or something similar without admin privileges? If they're required that would seem to be a significant roadblock to integrating it into a Cura plugin for distribution
EDIT: running as administrator didn't help, script still returns an empty list
-
Perhaps @chrishamm has a suggestion for the easiest way to confirm a Duet Wifi given an IP address?
Well, that is the missing part, and it must be done on the Duet side. The script you found simply scans for available IPs - and as its buffer is hard-coded to 255 entries, it will fail at larger local address ranges. In addition, it needs a working internet connection because it looks up the local IP base address with a call to Google - this is either ingenious or rather weird. I firmly tend to decide for the latter attribute.
Up to now, the best advice to follow comes from @chrishamm (third post in this thread):
…look for HTTP service records via DNS-SD and () check if one of the "product" TXT values starts with "Duet“.
This means to write some cross-platform code for your Cura plug-in; as a prerequisite, you will want to make sure that the Bonjour framework is installed on Windows machines (and Bonjour or Avahi under Linux, respectively). By the way: doing this for Windows can be a PITA.
This said, you will need to engage a professional with networking- and cross-platform skills to get that job done. Collecting scripts from the internet might be good enough to manage a specific printer farm, but as a general solution, to be distributed by the business you intend to run, this approach jumps too short. Reliable code is never written "on the fly", by no means you can simply copy that from the internet.
