ctbeke

Hi @deisengard, Thanks for your feedback. I've distilled the following possible improvements from your description: * Add the ability to multi-select print jobs to execute actions via the cloud. * Add the ability to 'select all' print jobs to execute actions. * Add the ability to 'clear entire queue' (basically a 'select all' + 'delete' action). * A bug caused a print job to appear 100s of times (I'm unfamiliar with this bug, could you describe the steps you took to get into this situation?) I'll relay these to the product owner of Digital Factory, and he will make the call whether and when to include this in our roadmap. These are not per se an oversight, but we have to juggle many priorities and this hasn't floated to the top just yet. Thanks! Chris

Thanks for reporting, I'll relay this to the team working on this functionality.

We've started an internal investigation into this. It seems like the printer is a bit too restrictive with which characters it does not allow when parsing file names, and there's also some inconsistency between Cura, Cloud and Printer regarding the validation rules. Since Cura and the Printer firmware are not released continuously, it'll take some time before any fixes end up in releases, but we're working on it for sure 🙂

@Gero very helpful and thorough debugging! I'll take this issue back to the team to see if something can be done about it!

For any networking/cloud related issues, please check the sub forums about Digital Factory as well. There have been several posts there with in-depth analyses and (temporary) fixes. In short, network issues are always difficult to debug because it could be a problem with the hardware, embedded software, the specific network setup (i.e. a customer had issues with DNS because in their network setup Microsoft Active Directory deviated from DNS caching standards that our printer software assumes are in place, as they should be). Usually it comes down to sending us the printer debug logs so we can have a look what's going on in your specific case, and hopefully help you further. All I know is that it's not a general issue as we have many users and printers online every day.

Unfortunate that you can't do some tests, but no problem, I understand how IT departments can be 😛 Could you confirm with them if they happen to run Microsoft Active Directory in the network? And if Active Directory is used for domain control and DNS as well? If so, you're likely experience a known (but yet unresolved) issue where Active Directory does not fully adhere to DNS specifications that the printer expects are in place (see the long thread above about this topic). If not, we'll have to dig deeper and find another root cause of your DNS resolve error logs. Chris

Hi @epakkane, I've scanned through your logs and I see the following line: socket.gaierror: [Errno -3] Temporary failure in name resolution This means the printer was not able to resolve the api.ultimaker.com DNS record. This usually happens in certain network setups where for example the DNS server on the LAN caches records for too long. Things you can try: * Reboot the printer. * Do a factory reset via the touch screen. * Check if you can resolve api.ultimaker.com manually from your own computer (in the same network), e.g. using nslookup. * If you have a company-controlled network, ask your IT department to check the DNS setup (known setups that cause problems are networks with an Active Directory domain controller). Chris

Ah, I think we were confusing print speed (movement in xy direction) with extrusion speed (how fast the extruder motor pushes out the filament). In my posts I meant the latter.

Np, it's fine to disagree on something, as long as it's civil 🙂 Anyways, Cura is open source, so if you have ideas and/or abilities to write something that could solve this (for either modifier meshes or adaptive layers), feel free to do so!

The extruder motor (E values in G-code) only determines the speed component of that equation (again, this is the one with the physical delays caused by the distance between extruder motor and hot-end). The position of the extruder (X, Y, Z values in G-code) determine the (layer) height and are determined by the motors that control the X, Y and Z axes. The width is mostly caused by the nozzle diameter (with some limited control over that by how much material you push through). So although it's a single set of settings, or even a single G-code command even, the results are influenced by many different parts of the printer. Controlling all of these components to such a level that you can have minimal changes in how much material is being deposited is hard, and becomes even harder when you're going to change something like the layer height.

I'm not sure, I'm only reporting on what I experienced during testing. However I can imagine that because height, width and speed are implemented by different parts of the mechanical system, these 3 never align as perfectly as you want them. For example layer height has a very direct result (just move the Z-axis up), but speed has that delay between moving the extruder motor vs the actual extrusion at the hot-end caused by the physical distance between those two components. So all combined it's just a complex system that is hard to capture in a mathematical model that can be used to 'predict' the needed flow. Again, theory vs real-world conditions don't match up here.

The delay is not caused by settings, it is caused by the physical process of pushing on the filament with the extruder motor, then that force actually resulting in more or less material being extruded at the hot-end. So in a perfect world with no friction inside bowden tubes etc (and many other physics laws), the settings above would work. But in practice you always have that delay and you get visual artifacts in your printed part.

Theoretically yes, but in practice this is hard because there's delays between the G-code instructions and the physical act of laying down material and it cooling off (mostly caused by the distance between the extruder stepper motor and the hot-end). So you could write something to 'look ahead' and take that delay into account, but that's very hard to do as well as you'd need to model these delays and other physical properties of the printing process. Also Cura cannot really change the line width currently (although a new version of CuraEngine is being worked on that has that capability, you can try it out in the "Arachne Alpha build" of Cura that was released in December). So I think over time it might be possible to do this, but it requires a lot more research and testing.

Hi! I'm not expert on the slicing engine and the physics of laying down molten plastics, but to me it seems in order to get a clean print when changing the layer height, you still want a consistent line width (otherwise you get 'banding'). To achieve this, when reducing the layer height, you want to extrude less material, so a lower flow rate. But in the current architecture of both the slicer and the printer mechanics, it is nearly impossible to change the flow in a short time frame (from one move to the next ideally), so when building adaptive layers I've tweaked around with the parameters until the flow rate change was small enough to not have a negative impact on the print quality (visual defects, or even worse: part-strength issues). I think in general this topic needs more research to see what the limitations are and if they can be stretched or solved.

Note sure who is using this IRL (as it's still experimental as well), but the biggest advantage of adaptive layers over modifier meshes is that adaptive layers changes the layer height gradually, resulting is less sudden changes in the flow rate (this proved to be the biggest contributor to ugly prints whenever the layer height changes when I did the research and testing for the adaptive layers algorithms).

Unfortunately such a simple statement would often not be true, because it very much depends on the topology of the model you're slicing. But if there would be a single way to capture the concept, I'd say it determines the 'hardness' or 'sensitivity' of the algorithm, similar to how Photoshop brushes can have hard or soft edges.

It would be great if you could upload or DM me some printer logs. The more logging we have from customers, the better we'll be able to find a solution (if it's a printer firmware issue).

For the next reader: materials/plugins are also 'unsynced' from your account if you uninstall them in Cura's Marketplace (installed section) while signed in.

Thanks for confirming. If the nslookup indicates that AD is involved in DNS I think we have found the issue. Ultimaker also runs AD and we experience similar issues under certain circumstances, but this confirmation that it also happens on your AD controlled network helps us to get to the core of the problem. I know the embedded software team and our own IT department are looking into this particular issue, so once they have some information I'll be sure to share it with you. This could for example be a guide that explains what to configure in AD to make it work correctly (as I've said before, it currently looks like AD is not adhering to some network standards that our printer assumes are in place).

Interesting! Could you confirm with your IT admin if they also use AD as DNS server inside the (V)LAN? Also, I got some commands you can run on the printer to verify (if you enable developer mode via the printer setting screen and then SSH into the machine): vi ./system/multi-user.target.wants/connman.service Inside that file, modify the ExecStart line like this: ExecStart=/usr/sbin/connmand -n -o -r -c /var/lib/connman/ultimaker_network.config (move the -r to before the -c, this lets the network stack no longer use the LAN DNS proxy) systemctl daemon-reload systemctl restart connman It's also OK if you're not able to do this, just getting confirmation from IT that AD manages your DNS already helps us a lot to confirm the root cause! Chris

@GLIL I have spoken to some of the engineers in our embedded systems department. They asked me to check with you if your network might be running Active Directory (AD) as domain controller (and DNS) by any chance. We have seen issues with networks that use AD for DNS before (appearently AD has implemented some networking standards incorrectly there, or it caches too much). If you could check that for me that'd be great. Chris

Hi, I have notified the team that works on the printer networking to have a look at this. Hopefully they'll be able to provide more insights. Chris

Thanks. I've scanned through the logs and found the following line of interest: socket.gaierror: [Errno -3] Temporary failure in name resolution This usually indicates that for some reason, the network configuration of the printer or the LAN was not able to find the correct server that fits the api.ultimaker.com domain name. In the past we've seen that a factory reset and reboot via the printer settings menu often resolves this problem. Is there anything in your network that you would consider out of the ordinary (e.g. specific firewall rules, white/black lists of domains, etc)? Chris

Hi, Unfortunately the main system logging file seems to not be in this ZIP file. Can you upload all the files that he printer outputs? Chris

Assuming that you're following the flow via https://digitalfactory.ultimaker.com/app/printers -> add printers -> S5 -> on the printer display go to settings -> network -> Digital Factory, and for some reason it doesn't work, please export the printer logs and post them here or send them to me in a private message.