Marco_TvM

That's not the led I was talking about. The brick that comes with the printer that you put into the power outlet on one side, and on the other side, it will connect to the printer, has a small blue led. I will check the logs... @tinkergnome I understand why a rollback could help getting started with printing again. However, I would rather find the cause. Rolling back, in this case, might not solve the problem.

1. I will have to check later but I think some optimisations have been made for decrease waiting time. 2. I doubt it would have to do with either slicer. Mere coincidence. If you check multiple from Cura, try doing so from a fresh start (ie. a cold printer) 3. The led on the power brick, which emits a blue light when it's on.

After talking with my colleagues, @daid mentioned something I forgot about. The printer reboot would normally not happen when trying to print, except when the power consumption gets too high, for example when heating up build plate/cores. In that case, the power brick will reset itself. causing loss of power to the printer. The second time it will be ok because then less power is required since build plate and PrintCores have been heated up for a bit already. When you notice the printer rebooting, can you verify if the power brick led is also turned off and on? Also are you using the original Ultimaker PrintCores?

If you can try slice3d again with the printer and get us the logs that would be helpful. I've tried the sliced gcode and it just starts printing without rebooting or other issues.

Is it possible to get the sliced gcode you made using slice3d? It still not a good sign that that would cause a printer rebooting. I'm glad that Cura now works for you and that you can print again.

Unless @msuurmond corrects me, I think you are right. Cura should be reporting the remaining estimate time with the printer.

Can you see if the gcode sliced by Cura have the same problem? Going back to an older firmware might not be the answer to your problem.

Basically, you're comparing the estimate from Cura with the estimate from the UM3 printer? Am I correct? The printer will adjust the estimated time based on 'real time' measurements. So the mileage may vary. Sometimes layers will go faster which will reduce the total printing time, then layers will take more time, adding to the total printing time. That may explain the differences you've seen.

If possible, can you insert a USB stick? If an error occurs the chances are good the logs might be dumped onto the stick. If you wouldn't mind sending these to us, using wetransfer, we can hopefully analyze what goes wrong.

Hi, I'm sorry to hear you're having issues with the latest firmware. Do you have a USB stick inserted while the problem occurs? If so, there would be some log dumps on it. Can you send these to us, using wetransfer? (Send a PM with the link to wetransfer, so I can take a look)!

I will just blatantly copy the answer @indy31 gave already: From a technical point of view, this is implemented as a gain: applying a factor and offset. Effectively, this will adjust the measured temperature starting at 50 degrees and gradually change while the PrintCore is being heated. @tomnagel might give you more (mathematical) details...

Glad to hear it's working again! A power loss during a firmware update may indeed cause the machine to become bricked.

@msuurmond Something to consider?

Hello Kai, Sorry to hear you had problems while updating the firmware. The instructions of @gr5 should help you get your UM3 unbricked. But to satisfy our curiosity, do you remember from which version you were trying to upgrade? I'd assume you wanted to upgrade to the stable version? I hope you can answer those questions for me.

@msuurmond might be able to answer the question...

If that's the case, the build plate seems to be a bit skewed. Doing a manual leveling first might help fix this. After the manual leveling, the automated bed leveling would have fewer problems.

This is most likely to because of a corrupted gcode file on the USB drive. Make sure to clean remove the USB drive from Mac/PC before inserting it into the printer.

Hi, I've checked the log files. The conclusion we made is that the printhead cable has some failure. Please contact the reseller to get this fixed.

Use the menu to dump the logs to the USB stick instead: System -> Maintenance -> Diagnostics -> Dump logs to USB Then put them on wetransfer and put the link to those files to a personal message to me.

Posting logfiles would be helpful yes. If you use something like wetransfer it allows us to take a peek. Also, just out of curiosity, what Print Core are you using? Is it always the same Print Core? If you, for example, use AA in both slots, if you change them, what happens: is the error for the same Print Core, or for the same slot?

Mostly wrong use and remarks about it not working (as expected). If there is no bed leveling data, then the manual Z-offset function can not work properly. Hence you always need to be sure a manual bed levelling has been executed before. I do feel your pain with the wheel though. Have experienced it myself to that instead of turning I accidentally clicked. It's very sensitive I just replaced the wheel with a https://www.youmagine.com/designs/ultimaker-2-knob--2

Diagnosis will stay in, even in release until further notice. It helps with analyzing problems more quickly. Maybe it's an idea to have it enabled only when Developer mode is switched on? That would make more sense to me, similar with Android - flip a switch and you can debug and diagnose more.

Yes, it seems like that. However, I'd like to point out the following: Q: When would you be abble to screw up the Z offset calibration? A: As far as I know only during the manual bed leveling. Oh, and when using the option to do a manual Z offset calibration when it was still available. Q: Is there another way to correct the Z offset calibration? A: Yes, run the automated bed leveling (once). If you think it's can be screwed up when using a different Print Core (or combination), then I'd say that only doing the manual Z offset calibration is probably not enough (either do a manual bed leveling or an automated bed leveling).

En ik zou je aan willen raden om deze vragen evt. ook in het Engels te stellen

Actually, you can, using the WEB API: http:///docs/api/PrintJob/put_print_job_state You can send an abort or even a pause command to an active job. To send commands, you need to be authenticated though, and for that, you need physical access