DuetRRF Cura Plugin, add Duet Discovery
-
I'm interested in adding functionality for automated discovery of the Duet to the DuetRRF Cura plugin. I'm aware that zeroconf can do the discovery, but I have basically no experience working with networking. If anyone is interested in working on this project, let me know because I'd love some assistance!
At this point I'm just trying to extract an IP address from a Duet on my local network using Zeroconf. Can anyone give me advice or tell me how to extract an IP address? I run the example script at the bottom of the linked page and this is returned:
Service hydraresearchna._http._tcp.local. added, service info: ServiceInfo(type='_http._tcp.local.', name='hydraresearchna._http._tcp.local.', addresses=[b'\n\x01\nu'], port= 80, weight=0, priority=0, server='hydraresearchna.local.', properties={b'version': b'1.22', b'product': b'DuetWiFi'})EDIT: I realized that the address is in a readable format in the address object, not addresses. However we have 6 active Duets on our network and it is only returning one. Any idea how to return all of the addresses? Perhaps @chrishamm would know?
-
are all duets running 2.04. Because mDNS support for the ethernet and maestro was only added in that release.
Also if you have 6 duets, the plugin need to be enhanced in the same way that the octoprint pluging does it. At the moment in the cura plugin, there is no associations between cura machine and duet.
so you will always see all duets as a print to target. -
Be aware that DNS-SD is required to discover boards on the network, which has not been implemented in the Duet Ethernet/Maestro firmware yet. The best way to discover Duet WiFis and 3s on the network is to look for HTTP service records via DNS-SD and to check if one of the "product" TXT values starts with "Duet".
-
@chrishamm said in DuetRRF Cura Plugin, add Duet Discovery:
Be aware that DNS-SD is required to discover boards on the network, which has not been implemented in the Duet Ethernet/Maestro firmware yet.
mdns has been implemented in 2.04
-
@Veti Yes and I wrote that functionality but mDNS is not DNS-SD - it only shares a lot of the protocol. With mDNS and without DNS-SD you always need to know the hostname but with DNS-SD all the boards can be listed automatically.
-
@chrishamm said in DuetRRF Cura Plugin, add Duet Discovery:
i only used avahi which implements dns-sd as well.
so i have considered mdns and dns-sd as equivalent so far. -
So as it stands do the Duets need to be on 2.04 to be discovered? Also, is the Zeroconf library searching with DNS-SD by default? Sorry, I'm totally new to working with networking on this level. All the Duets we have are Duet Wifis.
-
No, mDNS support for Duet WiFi has been in the firmware for a long time, I think since it was released.
Ian
-
Okay so I realized it is not firmware specific. All of the printers on our network have the same name, which is why only one seems to appear. When I change the name of a Duet then that one appears as well. Is there a way to access all of the Duets on the network even if they have the same name?
-
@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?
they'll have unique ip addresses and similar, but unique mac addressees. look to your dhcp server or use nmap to find them.
-
@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
