Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.09k stars 2.06k forks source link

Allow for 3rd party printers to show up in "Add a neworked printer" dialog #5778

Closed probonopd closed 5 years ago

probonopd commented 5 years ago

It would be nice if e.g., printers using https://github.com/fieldOfView/Cura-OctoPrintPlugin would show up in the new Cura 4.1 "Add a neworked printer" dialog that appears when you open the app for the first time:

Is there some API to hook into this dialog, and have it detect non-Ultimaker printers as well?

probonopd commented 5 years ago

In the case of printers supported by Cura-OctoPrintPlugin, those are announced on Zeroconf as _octoprint._tcp:

= enp0s25 IPv4 3D Printer (xxxxxxxxxxxxxxxx)                     _octoprint._tcp      local
   hostname = [foobar.local]
   address = [192.168.XXX.XXX]
   port = [80]
   txt = ["path=/" "api=0.1" "version=xxxxxxxx"]
fieldOfView commented 5 years ago

I believe that most work to get this added would be in the OctoPrint plugin.

An as yet unsolved issue is that OctoPrint does not have a set way to identify the make/type of printer so you would still need to pick that from a list to get the appropriate settings and profiles in Cura.

Lets continue the discussion in the issue you opened at the OctoPrint Connection plugin queue (https://github.com/fieldOfView/Cura-OctoPrintPlugin/issues/114)

nallath commented 5 years ago

There is indeed already an API for this, but it's up to the other plugins to use it.

probonopd commented 5 years ago

Cool, thanks @nallath. Is it possible to trigger installation of a plug-in from the marketplace based on a networked printer detected with Zeroconf?

fieldOfView commented 5 years ago

No, that is not possible. Chicken and egg situation; something would need to register what plugin would handle what network service. That something would be a plugin.

probonopd commented 5 years ago

It's a bit sad that seemingly no one outside of Apple uses Zeroconf in the way Apple imagined it to be used - "zero configuration". On the Mac, you see all the (paper) printers on your network in the printer dialog box, and selecting one of them will download and install the appropriate printer driver if needed.

For it to work similarly in Cura, plugins should be able to register Zeroconf service types on which they listen, e.g., the OctoPrint plugin would register _octoprint._tcp, resulting Cura to also search and show printers advertised wth the _octoprint._tcp service in the dialog box shown in the screenshot above. When the user selects such a printer, the plugin would be downloaded and the selected printer would be "handed" over to the plugin.

This would be a workflow very similar to what Apple is doing with (paper) printer drivers, which results in ultimate plug-and-play for the user.

fieldOfView commented 5 years ago

Seeing that OctoPrint is a competing technology to Cura Connect in Ultimaker printers, I don't see Ultimaker putting much development effort into this functionality at this point.

ChrisTerBeke commented 5 years ago

Auto-installation of a driver (plugin in this case) based on available network devices is not part of zeroconf, as it only covers the network discovery of devices given that the 'driver' is already available on the host system. It only removes the need for other network services like DHCP and DNS. Similarly Windows does not ship with Bonjour, the user has to install it to make Bonjour based services work 'automatically'.

The reason your Mac knows the appropriate printer driver is because based on some data from the networked device, your Mac does a lookup to see which printer driver should be installed and used. For Apple this is not a problem, because they don't produce their own printers (anymore).

Not sure how Apple intended this to work, but as far as I can find Cura's implementation of zeroconf is up to spec, although it only covers devices that Cura wants to find (Ultimaker printers). The discovered devices flow you're referring to was only just added in Cura 4.1 Beta, so we just need to give the plugin authors some time to adopt it.

probonopd commented 5 years ago

Desired user experience:

As the user, I see my Fooprinter in the list, I click on it, the Octoprint plugin gets downloaded and installed, the Octoprint plugin recognizes that I have a Fooprinter and selects the Fooprinter profile for me.

A way to achieve it:

nallath commented 5 years ago

But there is another problem; We don't support "hot installing" a plugin at all. Right now forcing a restart is the only way to guarantee that everything works.

I agree that it's a slightly nicer workflow, but it would make the code an insane lot more complicated (and it would require us to do a ton of work to get it to work). That pretty much means that we're back to square one; I can't sell putting that much time (weeks / months if not more) into a feature that doesn't have any benefit for Ultimaker printers.

Ghostkeeper commented 5 years ago

The original issue still stands though.

An as yet unsolved issue is that OctoPrint does not have a set way to identify the make/type of printer so you would still need to pick that from a list to get the appropriate settings and profiles in Cura.

I suppose the callback function could spawn a dialogue and wait for it to be closed, but it'd require re-implementing the QML of the printer list. You could use the model that is used for the offline printers in the add printer wizard.

Ghostkeeper commented 5 years ago

Coming back here again I realise that this is something that is currently not in Cura's court but in the plug-ins' court. Let us know if we can improve something in the API in this regard though.

probonopd commented 5 years ago

Let us know if we can improve something in the API in this regard

Would this be doable without too much effort?

fieldOfView commented 5 years ago

Would this be doable

Sure!

without too much effort?

aww....

Ghostkeeper commented 5 years ago

Plugins in the Marketplace can register for certain Zeroconf service types

Currently the base Cura installation has no notion of "zeroconf". That logic is only in the plug-ins. I think we want to keep it that way, especially if we ever want to include USB-connected printers in this list. So I'd say that this is not a good idea.

When the user selects such a printer, then the printer's address is handed over to the appropriate plugin, or the user is prompted to install that plugin (if it is not installed yet)

But that would mean that once a certain service type is registered, that plug-in has exclusive rights over that service type. No other plug-in can register any more (or at least the other plug-in won't get auto-installed). This is a bit dangerous. For instance, if I know that Stratasys is developing zeroconf discoverability and is about to release a Cura plug-in for it, then I could register a Cura plug-in that breaks the connection and Stratasys can't do anything about it.