Daid

There are some ways around the reset, on linux, with stty (you will have to google a bit, you will have to disable all modem control lines). There is no real issue in requesting temperature data very often, if you in a loop "request&wait for reply" you won't run into any issues. The firmware itself cannot buffer more then 4 commands. This all can be made to work, but it's not the easiest thing in the world.

All of them? Nope. There are also a few here: https://github.com/daid/LegacyCura/downloads You most likely don't want those, but I figured for historical reasons that link can be known.

Any specific part/dimension you are interested in?

@kmanstudios the printer in our office seems to stop printing due to communication problems with the print head, but not catching that error correctly. We have replaced the cable to the print head and haven't had an error yet. But our testing time so far with the new cable does not guarantee that this is the true cause. But you can see if you can contact your local sales contact to see if you can get a replacement print head cable. You could have a slightly bad wire in your current one. @Melka, usb printing for the UMO/UM2 is just always a mess. It's part down to USB-Serial being a bit flaky, but also USB port not being all up to spec. The USB-Serial driver from Windows adds up to this pile of problems. (My old Vista laptop can print up to 10 minutes, max. Usually less, before it bugs out. Imagine my frustration as this was before SD printing was even an option) But, I've also seen reports on printers rebooting with SD printing and certain light switches. Not all electrical equipment is equal. Especially workspace equipment has less regulations. TL lights also don't always play nice according to information I got. Using different outlets sometimes helps. (But nothing messes up your printer as well as a tesla coil...)

As lead engineer on the firmware, and the "decision maker". I will just say: * Debian is proven stable. * Debian is easy to minimize, our compressed filesystem is 40mb, Python3 is actually a large chunk of that. * Debian is easy to play with. With our apt-get setup, you can install extra packages in minutes. Great for tinkering. Want to reset? Update the firmware and it will clean everything up. I have a printer that has a full gcc installation. * After working for years with sysv init and even smaller init systems. I say "systemd is the best thing that EVER happened to me". It's consistent, fast, configurable and extremely important, easy to diagnose problems. * The logging system is the only constant writer right now. And that was a choice (it actually defaulted to memory only logging, we had to change configuration to make this work proper) will last at least 5 years according to calculations. And we will most likely turn of "on disk" logging at some point when the firmware goes into full maintenance mode, to reduce wear and the bugs are no longer present. * We have 4GB of flash on the system. We don't need to stick it in 14MB (that's the space I had at my previous job) welcome to 2015. We haven't opened up all repos. But if you want a certain piece of code, you can ask (which is annoyingly valid with GPL) the python code is all readable on the printer itself. Marlin I will open up soon. The kernel we currently run isn't in an online repo, but I can also provide a copy. We try to mainline our patched on the kernel as much as possible, and we are in the process of switching to a better version, which actually is on github.

It means 79.1% of the total file size. So you can calculate back the line number in the file from that. The api/v1/printer also has a head position somewhere (don't know the exact detail out of my head) which reports a Z position as well.

We have no reason to think the 3.6.3 isn't stable. It will most likely be pushed to stable on Monday or Tuesday when I have confirmation that the problem is really fixed.

The move is corrupted when communicated between our linux system and the realtime stepper controller. Note that this could also happen with Octoprint which uses the same principle here. We are currently upgrading the error checking and handling of this protocol.

le_avion: The "detected move outside of normal printer volume" is an error that means the printer was ordered to move 50mm outside of the normal print area. And thus the printer stops to prevent any damage. We (very rarely) had that a printer would slam the printhead repeatedly to the side of the printer, and added this protection to prevent this. We have actually found the root cause, but the cause was found late in the 3.6 firmware development process. So we only added the error detection, and not yet the proper fix to prevent this. As this touches a core component of the firmware. Chances are good that you will not see this error again for a very long time. Currently we estimate this happening less then once every 1000 printing hours. Which is still too often, so it is one of the high priority fixes for 3.7 As for recovering the print, I think, if you delete the proper gcode up to this point, set bed leveling frequency to "never", you might be able to continue. But you will always get a seam where it stopped. The printer log does not show where the head was when it stopped, so the only way to find that would have been to ask the printer API when the machine was still on. (Personally, I wouldn't even bother)

I've created bug with the tracking number EM-1567 for the umlaut issue. It is twofold where the display code isn't accepting it and seemingly crashing, and it's not accepted in the gcode file when S3D generates a file. Not sure what the file list issue is, the other part is an easy fix.

We think we have it! While we are still testing to be a 100% sure internally. We've put this change up for installation already as the "Testing version" 3.6.3. The only change in this update is the fix for the USB always showing empty file list issue. There is still a 2nd issue, where it shows a empty file list on the first try, and a full list if you press return and open it again. We didn't fix that issue yet (We do know the cause, but due to the easy workaround of closing and opening the menu we didn't spend time on that a fix yet) The bug itself. Now. If you want to get technical. The cause here is... the glowing of the LED ring at the front of the printer when your print is finished. What? Yes. This ring is glowing by some code on our side, but the LED output is controlled by a linux driver. So we are talking to this driver. Due to changes in how we manage the LEDs, we are updating this LED more times per second then before. A bug in the LED subsystem of linux caused every write we did to this LED ring to cause 3 or 6 "udev" events. This is a general event system from linux for hardware changes. Hardware changes that include USB removal or insertion. Now, this LED glow was generating these events faster then they where handled. Creating a backlog. This backlog in turn caused the handler of these events to use a lot of system resources, at which point another system decides at some point that this handler is most likely misbehaving and needs to be restarted. Only increasing the amount work to be done instead of decreasing it. Why is this important? Well, because these events where never proper handled anymore, the USB drive removal was never properly handled, and the insertion was also not properly handled anymore. Causing the system to look for the "old" insertion of the USB stick instead of the new one. And thus not being able to read it, it shows no files at all (and the read error never bubbles up to our code) Currently we placed a tiny fix in the code to prevent these events, and nothing else. We already had plans to update our linux kernel towards a more stable version. But we didn't want to push out this kernel in a hurry just to fix this bug, at the risk of introducing a different (possibly larger) problem. This was one of those, you have to be kidding me right? bugs. Now, why didn't we catch this one during testing? We didn't catch it at the development team because we clean our printers pretty much as soon as they are done. Our printers get updates multiple times a day, and you need a lengthy session for this bug to happen. Our testing team switched to mainly network printing to better validate the Cura network printing at the time this bug was introduced. So they did notice it once or twice, but didn't get to notice the severity of the problem. And they also had a bad batch of USB drives before, which made them a bit less alert on USB problems and quicker to think "oh, bad USB drive". Why in the 3.6? Wait you might say! The LED ring was glowing before as well. Yes. It was. But the update was at a lower frequency, reducing the amount of events, giving the system more time to handle them. This change was introduced when cleaning up the LED control code during 3.6 development. Before this release the LED control code was pretty much the first prototype we made for this code. It functioned, but when we wanted to add the user configurable lighting, we also cleaned up this code. Introducing this unintentional bug in the process. The big thank you I want to thank you all for reporting this, and the people that helped in the diagnose both online and offline. It was a tough nut to crack, and really every tiny bit of information helped here.

Cura 15.04 only hast post processing plugins, and there is no documentation available on that. Cura 2.x has a full blown plugin system.

Firmware 3.6 correctly reports the amount of material left on a NFC spool to the app. And the Android app fails to properly interpret this and causes an internal error. (iOS app is fine) The app development team is working on a fix, until the fix is available, not using tagged spools is a workaround.

We have 1 printer at the office which shows the same problem with the 3.6 firmware. So I am aware, but do not have a direct cause yet. We are investigating. If you want, it is possible to downgrade to 3.5 by downloading these files: http://software.ultimaker.com/jedi/releases/UM3-rootfs-3.5.3.20161221.tar.xz http://software.ultimaker.com/jedi/releases/UM3-rootfs-3.5.3.20161221.tar.xz.sig And follow the USB update procedure at: https://ultimaker.com/en/resources/23129-updating-firmware If that removes this problem, please let me know. That gives some indication where the problem could lay.

https://github.com/Ultimaker/Ultimaker2Marlin Firmware is found here. You need to set EXTRUDERS to 2 in the Configuration.h to get the result of the dual UM2 firmware.

If you leave slot 2 empty right now some code gives an exception and aborts the print without giving a message. Potentially this could be worked around by turning off active leveling. However, our hardware team cannot guarantee that the cooling of the printcore is proper with only 1 inserted. So I would advice against this.

(My German is rusty, so I can only reply in English) The 3.6 firmware introduced some extra error checking, which is incorrectly triggering on umlauts that are common in the German language. S3D is adding this at the beginning of the file in the form of a date&time. See: https://ultimaker.com/en/community/39569-new-firmware-for-ultimaker-3-version-36?page=2

Thanks for reporting this. We are currently aware of this problem. But we can use more information as we are currently in the dark for the root cause of this problem. Do you know which version where you running before the 3.6 upgrade? (For your information, I lead the firmware development team. So you have reached the proper channels)

We've done this change because GCode is basicly ASCII, and we've seen gcode files being corrupted on USB drives, causing the file being incomplete and the last bit being corrupted. Before, the corrupted part was silently ignored, and then the file finished without a message, while the print wasn't finished. We've always read it as ascii, but before silently ignored encoding errors. So that causes this sudden shift. Where does S3D use the UTF-8? This should be a simple fix on our side. Would be nice to know exactly what it exported for our internal documentation.

Note, you can still dump the logs after restarting the printer, as this still contains information about the previous "run". So even if dump to logs doesn't work directly, dumping the logs after a restart has value for us.

+1 ! After every print (S3D on USB stick), I have to restart the UM3 ! What is happening exactly? "USB difficulties" is a bit vague, the exact symptoms would be nice to know.

I cannot confirm nor deny the development of new electronics with better stepper drivers.

The UM3 does not have power measurement electronics. So everything the printer can tell you is indirect. The temperature graph (http://[ip]/temperature.html ) does show the amount of PWM output it directs to the bed. The heated bed is the main power usage. So power usage of the printer is pretty much directly related to the heated bed temperature. At 60deg (PLA temperature) the bed is at 40% power on average. With the bed being around 150W, this is ~60W for the bed. The rest of the machine is using about 60W as well, for rest of the electronics and hotends. So the usage for PLA/PVA printing will be around 120W average. (Note that this is a simplification of the reality, as the resistance of the bed varies with temperature, and thus the power usage varies per temperature. But it should be good enough to give a rough estimate)

This wasn't done to prevent hacking. There is a simpler reason, the A4988 chip is becoming short in supply. With a lot of 3D printers using that same chip, stock is running dry. And sourcing is becoming problematic from time to time. This change means we could produce 20% more printers. We did consider keeping it on for the hackers, but we couldn't justify it towards producing 20% less machines. Cost savings on just this single chip are not extremely significant. New UM2+ do not come with the UM3 board (yet). There are plans to move towards that, however, then we will use 2 different component setups. So the UM2+ will have the USB part but most likely not the 5th stepper, nor the RGBW led driver. While the UM3 no longer will get the (unused!) USB components, and PT100 circuits for the hotend (as these circuits are located in the head with the UM3). This will be a significant cost saving for us, so that change will be cost driven. Just giving you a heads up now. This does need a small firmware update, as the UM3 board uses 16 microsteps for the Z axis, instead of 8 that was standard in the UM2 board.

That is rather odd. WiFi was generally unstable in 3.4, as well for NFC. Which exact minor version of 3.4 did you save? Is Cura losing the printer WiFi connection or is the printer dropping of the network? (If you go to the printer to the network status menu, if it switches between connected and not connected, then it's the printer) 3.6 has NFC testing menus in the diagnostics. Do you want a copy of the 3.5 firmware as well to see how that behaves? That could help in diagnosing this problem. (We did test this firmware for 2 weeks on our testing fleet of 30 printers, with WiFi and NFC. I'm not saying your problem isn't real. Just want to figure out what is different in your setup then our testing setup, and why we didn't catch the problem you are having)