Daid

USB printing on the UM2 is not officially supported. If you do want to do this, you have to use the UMO machine settings instead of the UM2. But no guarantees.

The fix is already included for the next update. We've improved on it even more :-)

I know we can be a bit slow in communications sometimes. But, this feature has been developed. And is going into the next testing firmware. Which (by my estimate, could be wrong here) will be in the stable firmware in less then 2 months. It allows for the same level of lighting control as in the UM2. So you can configure brightness and always on/off, as well as only on during printing features.

The interfaces file won't work. The rc.local option will most likely fail as well. We are using "connman" to configure the network. So here are some tips: https://communities.intel.com/thread/60242 In the future we want to provide some better support for static configuration, as this request is more common then expected. (Shame on the IT infastructure providers of the world)

The reprap smart controller works without firmware changes on the UMO. As it follows the same design. The display you are looking for is a HDD44780 4 lines 20 characters. They are extremely common. If you just want to change the display.

The WiFi setup is designed to be only used during the WiFi setup. If used at any other time, it bugs out and shows this incorrect error message. We are planning towards a proper website dashboard for the printer.

The actual camera feed is provided by mjpg-streamer, which crashes occasionally. We've updated the service script to restart this service better. Not a perfect solution, but it would put an end to the camera stopping to work. root@ultimakersystem-ccbdd3000d97:~# cat /etc/systemd/system/mjpg-streamer.service[unit]Description=mjpg-streamer, Webcam streaming for all[install]WantedBy=multi-user.target[service]Type=simpleUser=ultimakerEnvironment=LD_LIBRARY_PATH=/usr/lib/mjpg-streamerExecStart=/usr/bin/mjpg-streamer -i "input_uvc.so -r SVGA -d /dev/video0" -o "output_http.so"Restart=alwaysRestartSec=3TimeoutSec=1

Hi David, David here, "master of disaster" so to say, as I'm in the lead of firmware development. 1) You need to confirm the printer is empty after a print, so we know it is possible to start the next print remotely. You should be doing this when you are taking the print out of the printer, so you are at the printer and visually you can see that is empty. (Note that everyone else with network printing does no checks at all, or needs a on-printer confirmation before starting a print) We did identify that the current flow isn't optimal in two cases: a) If you abort a print before anything is printed the bed is still empty, so no need to ask the user. b) If you remove the print before everything is cooled down, you do not get the option to mark the printer as emptied yet, as the printer is still "finishing up" 2) This feature didn't make the initial release due to time constrains. It is in testing right now, so it will be available shortly. 3) Not sure what you mean? "reconice" isn't available in my dictionary. 4) Single extrusion prints? Because of a bug. We heat up the printcores to their starting temperature. However, with a single extrusion print, the 2nd core's starting temperature is "0". And we heated up to "melting" temperature for active leveling. So it is waiting for it t cool down after active leveling, as it is going to the starting temperature. (Currently in development, almost fixed) And respectfully. You do not know it better because you have an UM2. The UM2 is a much much simpler machine. Networking, nozzle lifting and PrintCores change everything.

First word of warning, updating to the testing branch is always a risk. For example, I just disabled the update to 3.5.92, as it breaks the update mechanism (which is pretty bad, as you cannot switch back to stable) I'll have a quick check if I can share are full internal release notes. But the current focus is APIs (so better integration with Cura and possible future products) and diagnostics. As well as a bunch of small fixes. Most noticeable new feature that 3.5.92 would have added is the ability to change material during a print. But, as I just retracted this release, you do not get this feature just yet. (If anyone updated to 3.5.92, let me know. I'm writing down instructions on how to recover as soon as we have 3.5.93)

"Cooling" is a bit of a misnomer. In some cases it is actually heating up, retracting a bit, and cooling down. As it is actually disconnecting the filament from the PrintCore. In newer firmware versions this process can be skipped, and if it is not skipped, changing material is a lot faster as we know the material is disconnected from the printcore.

I understand the need for the "cancel" button in the first step of change material (and a few other actions) as well as a "no delay" early abort of the print. Both are features in our issue list already. But currently not scheduled for the next update. The abort on change material shouldn't be hard, and I might move to the next update, just need to double check a few things. The one on the print is more complex at the moment, as we try to keep the printer in a consistent state. And then we would get into a bit of complexity where we can decide to skip the "end of a print" part if we are before a certain point in starting a print. The "The UM2 is faster, and UM3 slower". I need more specifics, exactly which part is slow? With the 3.5 firmware release we did our best to streamline most things without sacrificing certain certainties that the UM3 provides. But we can always improve this more.

Note, we are currently fixing a bug where the printer waits for a printcore to cool down when starting a single extrusion print. (The core isn't used, but heated to 175C for active leveling, and then cooled down again, problem is, it is waiting for it to be cooled down)

I just fixed a firmware bug where the printer wouldn't heatup properly. But I'm not entirely convinced that you are having this exact bug. You can check if this bug is the case by tuning 1C offset to the temperature when this stop happens. If it continues then, then you are experiencing this bug (and the bug is them more critical then I expected) Another thing that could be happening is that you are hitting power limits. There is a special webpage on the printer, reachable with http://[ip address]/temperature.html this gives a readout of all the current temperatures and heater outputs. It might give more insight into this issue as well.

M0 or M1 pauses the printer, this acts the same as pressing the "pause" button on the machine.

I just looked at the log files you send it. (This really helps) Your left PrintCore is trying to heatup to 200C, but it does not reach a temperature above 196C. Can you try heating up the PrintCore to 240C, and checking which temperature it reaches? You should have a 2nd AA PrintCore, try swapping this other AA core for the left one. If this fixes the problem, then your primary AA core is faulty.

Could be that the SD card is corrupt or damaged. If it is corrupt, a "format" should be able to clean it up. However, it is best to do this with the "quick format" option disabled (at least, in Windows) This is not caused by the STL. Problems like this can be caused by not safely ejecting/removing the card from your computer.

We are using mjpg-streamer, which does as an rtsp output option. However, we haven't tested or enabled this. If you are feeling experimental, you can enter developer mode, and edit the "/etc/systemd/system/mjpg-streamer.service" file, and add: -o "output_rtsp.so" To the startup, that might cause rtsp to work. However, a quick google shows that this work on implementing rtsp might not be completed and thus it might not work.

It's a pretty standard MJPG stream, I'm pretty sure just about anything can view it. (A browser is just simple)

PETG and CPE differ very little, so the settings will be very close. Cura is in full control of all the temperatures and stuff when printing with the Ultimaker 3. So you can overrule everything there. Custom material in the Ultimaker 3 is supported, however, during development a few work flow issues remained unsolved on how to set this up. Which means adding custom materials is currently a pain in the machine and Cura, and requires all kinds of implicit knowledge. Good thing is, I am planning to sort this out. I have a few ideas that would make the whole flow more convenient.

Hardware wise TPU works fine in the Ultimaker 3. We are working on our Cura profiles for this material. So you could already use it in an Ultimaker 3, but you are a bit on your own on finding the proper settings.

Thanks for reporting this! I had the odd suspicion something was wrong with the dhcp, but we could never "nail" it. I'll put up another mark on the network setup problems list. Note, the current network configuration is provided by connman: https://01.org/connman So this bug is a direct result of a bug in there. And I can tell you, we are far from happy about connman. This DHCP bug is one of the many problems with it, and we are planning to replace it with a more standard linux solution. (DNS problems, Wifi connecting problems, not detecting wifi hardware are just a few others to name) All difficult to debug due to connman being one single big entity. Initially it looked like a good fit, as it did everything we needed. But the amount of problems we are having with it are now overshadowing the positive. As a workaround, switching the configuration to wifi and back to wired might cause the dhcp client to forget about its lease. But I'm not sure.

Normally the bed leveling data would survive an update, however, we changed this to be stored in a more logical way. The old storage method could mean you would use old data if you changed printcores. We intend not to change this again for future updates. We also changed the XY calibration offset, however, at this data takes a lot more time to acquire, we did implement migrations for this data. @Dim3nsioneer, do you have the printer connected with WiFi or cable?

You can, you have to re-calibrate the switching bay location. The reason why this is not per default is to get the maximum build volume.

I completely understand. But that is currently not the view of Ultimaker, as Ultimaker does not want to offer something until it is a finished solution. I cannot say anything about which cores will come when, as I've seen 3 different timelines already and I'm most likely not allowed to talk about any of them ;-)

Just a random proof of principle experiment. Remember, we use star-wars names for just about anything. http://starwars.wikia.com/wiki/Watto As you might also noticed, the hex file isn't there, as the experiment didn't continue beyond a single machine. As for secret projects, yes, we have them. As for the 3.5 firmware. The 3.5.1 is a quick fix for a problem where the heated bed was causing some problems with the active leveling measurements on the 3.5.0, we are currently working on a better fix. As the 3.5.1 now takes longer before a print starts. (As it heats the bed after leveling instead of during)