Marco_TvM

Can you dump the logs (especially after a reboot) to the USB stick and upload them? From the information you gave, I think the MPEG streamer fails to load due to not being able to find the camera hardware. This might be caused by a simple loose cable, so could you check those?

This almost sounds like you are using the mobile app? Can you check if http://<your printer ip>:8080/?action=stream will show you the life feed?

Nope. Still testing.

Then it will be a bit of a waiting game I'm afraid. We're currently very focused on S5 firmware and have made some improvements on pause/resume when it comes to retract/prime and this being tested. Once this is deemed ok, the PO can decide to put these changes into the UM3 firmware as well. @WesleyE might shed more light on this.

It would be good to know which UM3 firmware was being used for these findings.

This can be fixed by resetting Cura Connect on the UM3. Got to the menu System -> Maintenance -> Cura Connect reset (the one below Firmware reset). This should fix your problem.

I'm going to mention this to the PO (product owner)... Seems like a good (and not to hard) piece of information to add to the display.

PO = Product Owner

An interesting idea. It could be done in a way I'm currently thinking of, but I will pass it on to our PO.

Another short addendum, after talking with @CarloK: If you can switch the brick with another printer's brick, see if the problem moves as well. If it does, then it's unlikely an UPS will help, because then the brick seems to be on the very low end of the specifications.

And this leads to the final: More cooling down is being detected, and then the Opinicus notices it takes too long to heat up the hotend and giving the final error. But all of this is because of a reboot of Marlin due to some power fluctuation. If you say you have used the normal UM PrintCores, I'd advise buying a cheap UPS and make sure to use a grounded socket. Not sure how your situation at home is, but if you have attached the printer's powerbrick onto the same subnet as for example big power users (fridge, oven, microwave, dishwasher) those might kick in at some point causing the powerfluctuation which leads to the brick getting into problems. Changing to a different subnet and/or using an UPS might save the day.

Next more interesting stuff happens, but related to the previous issue: We see that Opinicus thinks that a cold extrusion was prevented (due to lack of heating up) and following with another command to heat up hotend 0. This is however not happening: you can see it cooling down.

Hello @The_Rob, I've been looking into your latest logs, and see a lot of similarities. Some excerpts from the log that caught my attention: Here we can see the hotend started heating up, but then Marlin rebooted which indicates a short power surge/spike, just as @CarloK mentioned earlier as well. This then also causes mismatch in the communication protocol buffer between Opinicus and Marlin.

I think it's trial and error for now. You can keep an eye out on http://<printer ip>/api/v1/debug/marlin/errors for buffer underruns which is an indication of marlin having an empty planner buffer.

If you know you printer's IP address and it's in Developer mode: ssh ultimaker@<printer_ip> You get a special shell in which you can do a sendgcode <your gcode comes here> But as @nallath says: 0 warranty

As for changing the kernel, I'd suggest getting familiar with https://github.com/Ultimaker/um-kernel and https://github.com/Ultimaker/um-u-boot

Follow the instructions given by @gr5 in

Actually, when the NFC filament was detected, we did find a bug related to it, but this was solved months ago. So not sure why this pops up. It would be helpful to get some logs (from app) when this problem occurs.

No worries about that. Still wondering what may have caused it. Mostly it's a mechanical problem causing an electrical failure when the PrintCore suddenly goes missing. So it's bad connection of PrintCore in the head (dirty copper) or PrintCore too loose within the head. And you say neither is the case, so at this moment I'm baffled. Keep us in the loop when this might be happening again.

The problem was actually with PrintCore 1 (left side). Did you clean that one as well?

If you can dump the logs to the USB stick and upload them here, I can take a look. I really would like to see what happens.

Sure. Let me know how things progress.

I've seen something in the log that caused a problem Apr 06 10:26:52 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:26:52,468 INFO printerService Procedure next step: ALIGN_Z_AXIS: HEATUP_HOTEND_WAIT_0 Apr 06 10:26:52 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:26:52,473 WARNING materialManager No maximum temperature for material in hotend 0 Apr 06 10:26:52 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:26:52,475 INFO waitForHeatableObjectsStep Setting target temperature of hotend-0 to 210C Apr 06 10:26:57 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:26:57,490 INFO waitForHeatableObjectsStep Waiting for hotend-0 heatup: 177.1/210.0 (wait_tolerance: 0.0) Apr 06 10:27:02 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:02,504 INFO waitForHeatableObjectsStep Waiting for hotend-0 heatup: 185.4/210.0 (wait_tolerance: 0.0) Apr 06 10:27:07 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:07,520 INFO waitForHeatableObjectsStep Waiting for hotend-0 heatup: 197.4/210.0 (wait_tolerance: 0.0) Apr 06 10:27:12 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:12,043 INFO procedure AlignZAxisProcedure(key='ALIGN_Z_AXIS') transitioning from WaitForHotendTemperatureStep(key='HEATUP_HOTEND_WAIT_0') --> GotoPositionAndSetZ0Step(key='MOVE_TO_POS_AND_SET_0') Apr 06 10:27:12 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:12,049 INFO printerService Procedure next step: ALIGN_Z_AXIS: MOVE_TO_POS_AND_SET_0 Apr 06 10:27:12 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:12,054 INFO gotoPositionAndSetZ0Step move to: 'G1 X200.000000 Y105.000000 Z7.143593 F9000' to apply bed level parameters and set Z0 position Apr 06 10:27:19 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:19,606 INFO hotendCartridgeManager setPresentChanged(0 is not present) Apr 06 10:27:19 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:19,624 INFO hotendCartridgeManager _updateHotendGone deleting reference to hotend(0, b'4\xdb]\x1e\x00\x00') Apr 06 10:27:19 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:19,679 INFO heatableHotend setting default on pid_Kd Apr 06 10:27:19 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:19,708 INFO heatableHotend setting default on pid_Kp Apr 06 10:27:19 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:19,731 INFO heatableHotend setting default on pid_Ki Apr 06 10:27:19 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:19,795 INFO hotendCartridgeManager setPresentChanged(0 is present) Apr 06 10:27:20 ultimakersystem-ccbdd3003e12 python3[459]: 2018-04-06 10:27:20,056 ERROR procedureStep Exception caught from step: MOVE_TO_POS_AND_SET_0 Apr 06 10:27:20 ultimakersystem-ccbdd3003e12 python3[459]: Traceback (most recent call last): Apr 06 10:27:20 ultimakersystem-ccbdd3003e12 python3[459]: File "/usr/share/griffin/griffin/printer/procedures/procedureStep.py", line 82, in _run Apr 06 10:27:20 ultimakersystem-ccbdd3003e12 python3[459]: outcome = self.run() Apr 06 10:27:20 ultimakersystem-ccbdd3003e12 python3[459]: File "/usr/share/griffin/griffin/printer/procedures/pre_and_post_print/auto_bed_level_adjust/gotoPositionAndSetZ0Step.py", line 52, in run Apr 06 10:27:20 ultimakersystem-ccbdd3003e12 python3[459]: controller.sendRawGCode("M218 T%d Z%f" % (hotend_index, z_at_0_0 - z_hotend_0_at_0_0)) Apr 06 10:27:20 ultimakersystem-ccbdd3003e12 python3[459]: TypeError: unsupported operand type(s) for -: 'str' and 'float' What happened here is that while heating up the left printcore, it suddenly seems to be removed. This happens while the printer is also active trying to move to the correct position based on the left printcore. But now, it can't be found, resulting in an error when calculating the bed z movement. Can you check / clean the printcore contact points, both of the printcore(s) as well as within the head?

Thanks. I'd really like to see the logs, but I expect a possible issue with a corrupt file

Random Generation of Blobs? I think that would be possible