Marco_TvM

Actually, the time during printing can fluctuate. The printer tries to be smart by measuring the time between layers and estimate based on some formula what the remaining printing time means. So at first, this can look like 2 days and 0 hours, but then some layers take more time than expected, so the time is re-adjusted to 2 days and 17 hours.

To be able to do this right now, you need to turn on the developer mode. Then you can log in with ultimaker@ to get into a command shell. From there you can use the command sendgcode to send gcode directly. It will also have the ability to get the information you need.

Please provide some more details. Does Cura think the printer is in an active print job and you cannot pause or abort from within Cura? Or do you try to use this from the printer Tune menu? It's not clear what your current problem is.

The LCD was completely dark? No logo?

Hi, Some feedback: what we saw in the log (and in your post) is that the Z-nozzle offset procedure was run before active or manual bed leveling was executed. In the next testing release this menu item will be removed, so only an active or manual bed leveling will set the Z offset.

I'm fairly certain you meant Firmware

Would it possible to send the printer logs of a recently failed print? Use something like WeTransfer to get us a link to investigate.

Also, make sure to do a manual or active bed leveling before starting the manual calibration of the Z offset. The manual bed leveling would include the manual calibration of the Z offset. See https://ultimaker.com/en/resources/23127-build-plate-leveling for more information. Either way, some bed leveling data is needed before the calibrate Z offset can be run manually. Hope this helps!

Hello @Ultimak3r, I did find something in the logs that looks wrong. But I'm not yet sure about the cause of it. Can you do a http:///api/v1/printer/heads/0/extruders for me, with the Print Cores inserted that give the issue please? Thanks in advance.

Please check http://ultimaker.com/ER22 It would help to send the log files. Use System -> Maintenance -> Diagnostics -> Dump logs to USB and send those files to us using something like WeTransfer.

Hello, I'm Marco and am 45 years. I started at Ultimaker in December 2015, so almost 2 years already, as a senior software engineer. At this moment I'm one of the DevOps working on the Firmware of the UM3 and to improve all aspects (software, procedures, little bit hardware ) that come with it. And I'm learning more every day! Having an interest in electronics (automating trains H0, Domotica), gaming (MMOs mostly), listening to music (trying to make some with an electrical guitar), watching movies / reading books (mostly sf) and naturally programming keeps me a busy bee.

Glad you found it. I'd advise you to give this feedback to Solex as well!

That's weird then. The only one thing I can think of right now is cleaning the pads with a little bit of alcohol because of grease or other stuff preventing the pads from making a good contact.

If the originals PrintCores are working, and the ones from 3D Solex aren't, it seems to be a problem with the 3D Solex cores. If you use a meter to measure the resistance of the PT100 should be slightly above 100Ohm (100Ohm @ 0 degrees C). The pins to measure are the 2 right pins on the print core. A value of infinite will cause the problem with the MAX_TEMP_ERROR, and might be just because of a broken cable.

Thank @kmanstudios. Sorry for the late reaction, but had to do some other stuff first. I will look into the logs asap and see if I can find anything.

Yes please. If we can get information about this, it would help.

Most of the time, the IT guys use the MAC address of the machines and have the routers give out fixed IP addresses based on those MAC addresses. That's actually the easiest way. Because, uhm... I just for the fun of it, tried to set a fixed IP for my 2 networkprinters, a mobile phone and a ziggo box. I quickly resorted to map a MAC to an IP address in my router...

@kmanstudios It would help us to get the log files after it goes wrong with automatic bed leveling.

First, update to newer firmware. From the logs I gather you were printing using 3.6.3.20170406. Latest stable is 3.7.7.20170627 I notice a small issue with the internal database which likely caused the abort of the print.

It would help very much to get those files, both logfiles and, if possible, the gcode file. If you could use wetransfer and send me sending me a personal message with the link, I can look into it!

Alternatively, to do an update, use the procedure described at https://ultimaker.com/en/resources/20500-upgrade-firmware to download the necessary files and put them on the USB drive. Disconnect the network cable (which should prevent the looping for asking to upgrade the firmware), turn off the WiFi and make sure the USB stick is inserted. Then you should be able to do a manual update of the firmware using the menu items System -> Maintenance -> Update firmware.

Maybe @daid can shed some light on this.

Een foto van het scherm zou helpen. Als dit om een UM3 gaat: even de PrintCores controleren of deze er goed in zitten. Een los contact kan zorgen voor deze melding.

It would be very easy to get the software from the printer: scp -r root@:/usr/share/griffin . would copy the complete source tree to the local directory.

@ngassend: As @sandervg already mentioned, the firmware source used in the printer will be opened somewhere in October. Until then, you can get it from the printer. The library used is normal libnfc. I'm still wondering what you want to do which is not possible right now using the Web based API.