Marco_TvM

Telnet ok, but streaming from api or Cura isn't working. That's really a strange one.

Not @daid here, but sitting next to him A few questions: How often does it happen? Every print? Every day? Allways? What brand/size stick(s) are you using? If possible, check wat a dump logs to usb stick does. This 'forces' a remount of the stick and might even put the log files on the stick which we could use to find information. As @daid said in different topic, even after a reboot, you can do a dump usb logs which might help us pinpointing the problem

The line tells me that the streamer is listening to port 8080 Can it be a router/switch/firewall that prevents you from connecting to port 8080? IF you can try to telnet to the machine on port 8080: telnet 8080 it should return with Trying ...Connected to .Escape character is '^]' If it fails to connect: Trying ...telnet: Unable to connect to remote host: Connection refused In the latter case, something on you network is blocking access to port 8080 on the printer.

Can you dump the logs to USB stick to analyze? Use System -> Maintenance -> Diagnostics -> Dump logs to USB to make this happen. Check for messages about the mjpg-streamer starting (or failing to start). If this service cannot be started, we'd like to know.

Some help with this (reasons why / possible solutions) can be found on the UM website: http://ultimaker.com/ER22

Actualy, that tells me, there is some invalid text (invalid unicode, as far as I know) which cannot be handled. If you remove that particular file from the drive, can you verify it still happens? We will check on this end as well, but for us it's somewhat hard to reproduce (preparing special gcode files that contain some weird undecodable characters. Also, what strikes me as odd, is that the faultHandler should display a warning on the screen (a warning can be ignored), but for some reason, it seems that this surpressed on the file selection screen. I will have a look at it as soon as I can.

Correct, if it cannot read / mount the usb drive, it would not be possible to dump logs. However, if you can dump logs, something really weird is happening, in which case the logs could help. Also, I'm curious to see, if after even an attempt of dumping the logs, the problem would be solved. Dumping the logs remounts the USB drive, and might make it visible again.

Instead of restarting, would taking the USB drive out, wait a few seconds, put it back in also fix the problem? Can you try with another USB drive and experience the same behavior?

I'm sorry to hear you're having problems with the 3.6 release. It would help, if you would perform the update once more, and if / when things go sour again with the WiFi or NFC perform a couple of steps to maybe pinpoint the issues: If the NFC stops working, can you send screenshots of the NFC diagnostic screens. These can be found under System -> Maintenance -> Diagnostics -> NFC spool holder test and NFC reader test When the WiFi stops working, a screen shot of the network connection screen. This can be found under System -> Network -> Connection Status And the logs, which can be dumped to USB using System -> Maintenance -> Diagnostics -> Dump logs to USB Thanks in advance! This applies to all of you who are experiencing these kinds of issue.

Have you installed the latest drivers for the video card? The Multiply tool is still present: if you select a model, you can right-click to get a context menu and choose the option "Multiply model..." For the initial layer width being gone, maybe @nallath can help you with that.

It would help if you could send us the logs when this happens. This can be done using the menu steps: System -> Maintenance -> Diagnostics -> Dump logs to USB. Thanks!

This will be fixed with the 3.6 version of the Firmware on the printer. This release can be found as the testing release if you want to try it out. Also, it's expected for the release of the 3.6 version of the Firmware to happen this week.

Yes, that's the one.

When this happens, would you be able to send the log files? These can be copied to USB using the menu System -> Maintenance -> Diagnostics -> Dump logs to USB.

Hello Will, Let me shed some light on this. The message "Difference between detected height of both nozzles exceeds realistic values" is a check that verifies if the offset measured for both nozzles at each of the probe locations is within certain limits. That is: there is a minimum / maximum difference for height measured by the left (first) and right (second) nozzle. The logs should specify the probe location that would give the failure. For us at Ultimaker it would be interesting to get that data. It might provide information as to why it would be failing. Dumping the logs can be done using the Menu: System -> Maintenance -> Diagnostics -> Dump logs to USB

As for problems with connecting to the UM3 using Cura, can you please specify if you are using Wifi or Cable?