Ultimaker / Cura

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

Cura 4.0 not saving networked printers after quitting, Mac & PC #5477

Open abalboni opened 5 years ago

abalboni commented 5 years ago

We are running Cura 4.0 on a dozen machines (6 Macs, 6 PCs) and after quitting then relaunching, Cura does not retain the network address of any of our S5s. Each time we re-open Cura, the addresses needs to be manually re-typed and the printers are discovered immediately. All S5s have the latest firmware (5.1.93).

Thank you for using Cura! -->

Application Version 4.0

Platform Win 10, macOS 10.14.3

Printer Ultimaker S5

Steps to Reproduce Quit Cura, relaunch.

Actual Results Printers are still listed in the "Connected Printers" list but their address are committed from Cura completely upon relaunching.

Expected results Addresses should be retained in perpetuity (like they were initially???).

bebop-rocksteady commented 5 years ago

Try pressing the refresh button first instead of typing the IP. Maybe this will work?

I saw something like this in office, I don't know if same as your situation. We had unexpected behavior too at the start. We had 5 PCs connected to same network. The printers are in a different network but they have route to each other. We cannot find the printer by name, but we can find by IP. It was annoying so we just decided to put everything in same network. Maybe you try this to work?

rburema commented 5 years ago

@abalboni Just to get this clear: you're adding the printer 'by IP' rather than 'from the list'?

In any case, maybe there's something in the logs: would you mind attaching those? (They're in %appdata%/cura on windows at least.)

SalvadorPeregrina commented 5 years ago

Hi! I have the same problem. Is there a workaround for this issue?

rburema commented 5 years ago

@SalvadorPeregrina Unfortunately, since we don't know what the issue is you're running up against, we can't recommend anything right now. So, the same questions to you then:

SalvadorPeregrina commented 5 years ago

Hi @rburema,

I feel more comfortable sharing the logs via email instead of here. Could provide an email account to do so?

rburema commented 5 years ago

@SalvadorPeregrina you can send them to software-cura/ultimaker/com where the first slash is an at and the second is a dot. Or to me alone it's the same, except replace software-cura with rburema

Ghostkeeper commented 5 years ago

@rburema They can't send any e-mails there since that mailing list only accepts incoming mails from an Ultimaker address.

You could send it to my personal address at rubend@tutanota.com (the e-mail that is also on my commits anyway so I won't try to obfuscate that).

SalvadorPeregrina commented 5 years ago

@rburema, @Ghostkeeper is right. Email delivery fails when trying to send you the log files to those email accounts.

You can find them attached here.

cura.zip

rburema commented 5 years ago

Oops, sorry :-( Did the rburema one fail too? That shouldn't happen...

SalvadorPeregrina commented 5 years ago

No worries. Yes, both rburema and software-cura failed.

Ghostkeeper commented 5 years ago

That's because it should've been r.burema :wink:

Ghostkeeper commented 5 years ago

Looking at that .zip file, I found that there's a printer called AME that is connected to a printer on the LAN by manually entering an IP address. So it did save the network connection.

I think this is the error that we're looking for, as taken from your logs:

2019-03-29 16:12:18,428 - ERROR - [MainThread] UM.OutputDevice.OutputDeviceManager.addOutputDevicePlugin [188]: Exception starting plugin UM3NetworkPrinting: KeyError('UM3NetworkPrinting',)

This indicates that there was a KeyError somewhere in this function:

https://github.com/Ultimaker/Cura/blob/59b3046c0f04a357593f18434a286832fd072a89/plugins/UM3NetworkPrinting/src/UM3OutputDevicePlugin.py#L122-L124

But it's not a full traceback! But since the KeyError mentions the key UM3NetworkPrinting, I'm guessing that this is caused by a call to PluginRegistry.getInstance().getPluginPath("UM3NetworkPrinting") that is being made during the registering of the plug-in (which is also where the error occurs in the log). Which of the 7 it is though is unclear; we'd need a trace for that or manually step through the code as to when it could reach this during registration. There's also one call to CuraApplication.getInstance().getOutputDeviceManager().getOutputDevicePlugin("UM3NetworkPrinting") which has the same effect: It would crash if called during the plug-in registration because the plug-in is not yet in the dict that is searched for that function.

I'll let the Connect developers know that this could be a problem.

SalvadorPeregrina commented 5 years ago

Hi @Ghostkeeper,

From a users point of view. Is there something I can do solve this issue? Do you need more info regarding the S5?

Programming is not my field but if someone explains to me what to do, I can follow instructions.

Ghostkeeper commented 5 years ago

Not for now. It needs some time from a programmer who is familiar with this code to trace which path the code took to hit a look-up for the UM3NetworkPrinting plug-in or output device before it was properly registered.

Sassw commented 5 years ago

Many people have this issue:

https://community.ultimaker.com/topic/27300-cura-4-forgets-networked-printer-cloud-connect-features-dont-work/

Ghostkeeper commented 5 years ago

We did a bit of rework in 4.1 with this part of the code. I hope we can try again in 4.1. I haven't seen this issue myself yet though, so it's hard to tell if the issue was fixed.

Sassw commented 5 years ago

@Ghostkeeper can I provide any extra info? This is a real workflow killer...

Ghostkeeper commented 5 years ago

No, I don't think so, Sassw. However I did manage to reproduce this issue at home as well now. Maybe it's got something to do with how the network is configured.

Sassw commented 5 years ago

Most educational networks will not have things like IP discovery or bonjour available. Its also likely that the clients are isolated and that the printer is on a separate VLAN to the machine with Cura.

However the behavior for me is literally Cura dropping the static IP it has been told to use (and can access!) when it is typed again.

I am surprised there is not more structure with the communications the S5 makes... To me it would make much more sense for Ultimaker "cloud" feature to do things like:

Printer announces itself locally on network, could be via mDNS and LLDP. Then talks to a API something like https://api.ultimaker.com/, authentication could be done with bearer token posting u/n, password, client secret to https://api.ultimaker.com/o/token/ both at the Ultimaker online portal and inside Cura.

Then you would have a nice place to find all desired data relatively simply.

https://api.ultimaker.com/printernet/v1/my/printers/S5NameHere https://api.ultimaker.com/printernet/v1/my/stats/

Inside nice JSON messages for things to use...

At the moment i'm not sure any data actually reaches the cloud as far as I can tell here, the ultimaker account pages are almost totally blank and I cant even find a sign in page from the homepage.

Swwils commented 5 years ago

@ghostkeeper there are now many more reports of this on the Ultimaker forums. Can we please get this classed as a bug?

Ghostkeeper commented 5 years ago

Yeah, I'll change the tags. Sorry.

I think we have this fixed in 4.1, as I'm not seeing it at work, but I want to test this at home as well before we close this because it is dependent on the network and platform. Pretty soon we'll be releasing the beta for 4.1 so you could test at home as well.