CarloK

You found the correct patch for the UM2 hotend fan. When you say it fails when adding to Marlin 1.1.x I don't understand how it fails so can't help you. Also, I'm on vacation now and don't want to spend to much time in this topic. Sorry.

The UM2 hotend cooling fan is connected to pin J6 of the CPU, for this pin there is no corresponding pin number defined in Arduino. This means that you can't use the standard Arduino functions for controlling this fan and configuration of this pin in the file pins.h won't work. In the UM2 firmware you will see the pin is controlled by a direct register write. Some similar solution will have to be added to the Marlin firmware (this is your special UM2 hack on your own forked Marlin variant). Note that forking a project in Github is easy. It is just pressing the 'fork' logo on the right top of the Marlin Github page. There are already over 7500 forks of this project. 🙂

Can you start a print with Active Leveling enabled and when you see the problem dump the log files to usb? Send all the log files to me in a private message.

The UM3 firmware is not going to help you since a lot of the bed leveling code is not handled by Marlin but by the extra Linux board. Porting the leveling code from Marlin to UM2 will be a lot of work. Both source codes were equal 6 years ago but then deviated in so many details that it will be a lot of work. Do-able, but very easy to miss out a few details and then it will take you long time to find the bugs. Make it a proper github fork and other people might be willing to help you and you help others by sharing the code. Best way to go seems to be to use the Marlin code as it is and add the few UM2 features that you find important. You will miss the Ultigcode flavour but the other gcode variants work just as well.

Have you tried? The M142 command is still the same You still didn't mention why you want to use gcodes. The web API is the preferred interface method as that is officially documented and will have less potential problems interfering with the rest of the printer.

The two cases that I looked into, from Wesley and Cabriobob, showed a broken WiFi module. There is a testing firmware release which adds extra logging and in some cases this logging reports the WiFi as broken, but not always. On request I can make this software available. We had more reports of WiFi modules breaking down but no cause was found. It is a hardware problem, not software related. When your printer is still under warranty I suggest to contact your reseller and ask for a WiFi module replacement. Without warranty it becomes more problematic. The WiFi module in the printer is a small seperate module, usb based. Your options: - Be nice to your reseller, perhaps they are willing to do the repair anyway (or they can send you just the module). - Perhaps the reseller / distributor can send you a WiFi module for a small fee. - Add another wireless mechanism. For example an ethernet-over-power-lines modem can be bought from €30 and then connects to the ethernet port of your printer. Works fine at my house. - Never tried, but the printer runs standard Linux and supports many different wireless modules. We never removed the support for all those other modules since it wasn't worth the memory savings. Most likely you can buy any Linux supported USB WiFi module and plug it into the printer's USB socket in the printer's front. Perhaps add a USB hub so you can still insert flash disks as well. For the S5 you could use the internal USB socket where the WiFi is connected now, but then the antenna will get poor reception.

Sorry to hear the date check in 4.3.96 bugged you. Reading your comments in another topic I assume your printer is working again?

First of all, the command_util script is a debug tool that Ultimaker uses internally and has no official support. This means that we don't test it every release and behaviour might change without notice. I haven't tried the root login for this in a long time so it is very well possible that's broken (from the dump it seems like a dbus access right is missing). The recommended way for starting the util_command is by logging in as ultimaker / ultimaker. This will immediately give you the command prompt. Or, when you are logged in as root you can do an: su ultimaker As mentioned above, before you can execute any G0 or G1 command the head is to be homed once: G28 X Y Z or short: G28 Having said all this, I don't know why you want to move the head, but the recommended procedure is to use the web API.

Great to hear you were able to solve the time synchronization. The other solution I mentioned is that you use Cura to connect to your printer, then Cura should automatically set the time in the printer. After this you can start a download.

4.3.96 had a bug where it fails to update when there is no network connection to a time server. When the printer can't set the current time it will fail with the verify error. Do you have a network connection? Can you reach the printer from Cura? This is another method for setting the time in the printer.

We decided against the homing before resuming because the switches do have a small tolerance. The accuracy is good enough for homing but was never intended to be used as an absolute accurate position calibration. A shift problem after a material change during a print is rare. The motors remain engaged to keep the position locked and it requires considerable force to move the head but it is possible. As suggested, another cause for the shift could be a glass plate shift, this can't be detected or fixed. I'll keep an open eye for more problem reports of this type.

Thanks for reporting this. You are right that reports like this are exactly why we want to do a beta. I'm on holiday now and don't have access to a UM2 printer, but I'm sure the TPLA is there. What we will have to improve is the documentation by mentioning that a factory reset is required to see the new material. Technical details: Some users added custom materials to the printer so we can't overwrite the material list on an update. After the factory reset, the internal material list is updated in the first step of heating up before material loading.

I suspect there is a problem in reading the data from the print core. Try switching your two print cores. Is the error then in the same slot, or does the error move to the other slot? If the error remains in the same slot then the problem is with the connection points in the slot being dirty. Clean those If the error moves to the other slot, then try cleaning the print core's contact points. When the above doesn't fix it, then please try to get more data for us to investigate this. When you start a print and it complains about the nozzle size mismatch, then I would like to see the debugging data that's normally hidden: 1) Is your printer in developer mode? The just scroll down the error message on the screen a bit more and post a photo of the data there. 2) When your printer isn't in developer mode, open a web browser and surf to the printer's home page. Select there 'Event Log' and copy / paste the error message related to the print cores not matching. The web page address will be something like: http://10.183.3.120/info/log.html

What type of print core are you using? Is it an original Ultimaker print core? When the print core is not an official Ultimaker core, then I suspect the print core was programmed with wrong data. I don't see the second print core printing material. Why? I'd like to see that for reference as well.

@cboath You posted a screen dump of the temperature graph. The most interesting aspect of this graph are the feeder-info lines which are missing from your picture... 😞 Can you post again? As you can see in the legend a few graphs are not drawn (strikedthrough). Enable these graphs by clicking the text in the legend. For clarity disable the lines that are not interesting, like the bed temperature.

The flow sensor and feeder are sensitive tools. As Ultimaker we work hard to make them reliable and we are monitoring this thread to see where we can improve upon. Just a few reminders: - Check the pressure setting of the filament feeder. On the side of the feeder is a gauge which should sit in the middle of the scale. It might be a production error when this feeder was not tigthened. When the feeder wheel is slipping you can increase pressure here. - Ultimaker tested with a lot of materials but some materials are problematic since their coating is too slippery or too hard. Flexible materials like TPU are also problematic; TPU 95 is supported, but TPU 85 is not. - The flow sensor is sensitive for the curvature in the filament since it uses a spring activated sensor wheel to push against the filament. So, moving the filament onto your own spool holders will go wrong when the filament enters the feeder from a different direction. - A 5kg spool is outside the specifications. If the flow sensor triggered, then this was correct since the feeder is slipping. Fix by using a spool holder with less friction (ball bearings, etc.). - Never use abrasive materials in your UM3 feeder! From tests we know that printing only 1 spool of abrasive filament destroys grip of the filament wheel forever. The feeder uses a knurled wheel where the teeth wear of fast when using abrasive materials. The S5 feeder uses wheels that received an extra (expensive) treatment to harden them.

The API for retrieving the camera's URL is confirmed as a bug in v5.2.11, it was broken since v5.1 and will be fixed in the next release. The index number you specify in the API call is to specify the camera number you want to access. Not officially supported yet, but you can connect up to 10 camera's over usb and then this index number will select each camera. Not officially supported because never tested, and there is no guarantee that the number connecting to the camera's will remain the same.

The UM2(+) firmware hasn't been updated in a long time, so 3.3 is the most recent official release. I'm sad to say that the UM2 development is in an 'end of life' state which means only huge bugs will be fixed. I prepared a beta-release with some of the last remaining bugs fixed but this gets no priority from Ultimaker. I'm looking for people to give this beta-release a try. So far there has been little response, but the reponse I did get was positive. With more positive results from beta-testers this release can be made into an official release. The UM2+ firmware can be found here: https://github.com/Ultimaker/UM2.1-Firmware/tree/UM2.1_JarJar/releases/beta And the release notes: https://github.com/Ultimaker/UM2.1-Firmware/commit/f6e69344c00d7f300dace730990652ba614a2105 Please give this a try on one of your printers if your model is a UM2+. You can upload the firmware through Cura. Reverting to the original firmware is always possible, the original firmware is provided with Cura. Report your test results back here. Without positive reports I can't get the momentum for releasing this update.

Wow, that's strong language. Recently the Ultimaker website was moved to another hosing provider. I guess in the process some directories were set to a more strict access rule for safety reasons. I just checked and all firmware files are still there but I don't have the rights to make the whole directory visible again. When you know the firmware number and release date, you can download them all by making up the link yourself: Recovery images for a clean install from SD-card: UM3_recovery-3.7.7.20170627.img Very old, not recommeded. Same as the requested v3.7.6, but this is the official release which added the missing PP material. UM3_recovery-4.3.3.20180529.img A very stable version with few known problems. And for the new 5.2.x versions, and newer, which have a whole new file format to support both the UM3 and S5: recovery-5.2.11.20190503.img For both UM3 and S5. Greatly enhanced Cura Connect and Active Levelling. Has WiFi related problems on few UM3 printers (garbled screen and stalled prints).

I asked one of our engineers working for the Cura Connect project, and according to him the UUID only changes when the printer is removed and re-added again.

This forum is here for users to help other users. Occasionally Ultimaker employees monitor these forums but they do this in their own time so don't be disappointed when response time is slow. The official Ultimaker support is provided by your reseller and regional distributor. The traceback error you reported here is something I've never seen before. It indicates that the processor can't read the eeprom chip where the product-id and MAC address are stored. The only reason for this failing that I can think of is that the eeprom chip is broken. Perhaps this happened when you opened the printer to insert the SD card for the software downgrade. Contact your local reseller / distributor. They will have to replace the Olimex CPU board.

Even bigger than that: on the UM3 there is build plate area where the left print head can't reach the most right locations and equally the right print head can't reach the locations on the far left, both for about 18mm (the distance between the two print cores). On the S5 extra space was added to both the left and right sides of the build plate and now the full build plate area can be reached by both print cores. The only remaining limitations are the retention clips which are considered in the advertised volume (advertised as 330 x 240mm where the actual build plate is larger).

Moderator action: Moved topic from the Firmware to the Cura section where it better fits and hopefully gets more response.

Great !!! I think your system has two different problems: 1) The corrupted display 2) Getting stuck during a print For the corrupted display I found a difference between the v4.3.3 and 4.3.97 that might explain the weird behavior. I'll build a new image file for you to test and will mail you the link for downloading later this evening. For the printer getting stuck problem it would be nice for you to try to reproduce this. Then after getting stuck, wait a moment and reboot the printer. Then use the above described menu item for dumping the files to USB and email them to me.

@neo-ninja You are hijacking this thread. Your problem might be related but is best handled in a new topic. The material list being empty can be for two reasons: 1) You installed a firmware where this list is missing. I think we accidentally shipped one such version which means you are using an older firmware. Follow the above linked thread from GR5 which uses the recommended v4.3.3 recovery image file. 2) The printer lost its identification code. Check this by going to the maintenance menu and then the 'About this printer' screen. On the 3-rd line it says "hardware type-id". For an UM3 that's 9066 or for an UM3-Extended it is 9511.