Marco_TvM

Hi Dim3nsioneer, I'm afraid I can't answer that. The only one who can is the Product Owner of Cura.

The browser on your mobile device can still cache pages - in which case it might not work as expected. It is a good idea to clear the browser cache before trying, or as you did, use an url you have not tried before... Making one up should work as well: "iwant.wifi.now"

From the Menu -> System -> Diagnostics -> Dump logs to USB. Then you will get a bunch of files on the USB which you can upload.

Once you created the hotspot, make also sure that your device (laptop, tabled, mobile smartphone) is also connected to that hotspot. If it keeps failing, can you send the logs?

@WesleyE might have the full answer for this, but I think a solution is in the works...

I noticed the following problem: Basically this tells me the hotend is found to be removed... Since this is not the actual case, it comes down to bad connection (cable) as said by @fbrc8-erin and/or the core itself wobly in the head (clean the core/connectors within the head)?

I think the feature is being discussed...

@Brett and @chuckmcgee: we do know what seems to be causing the problem and I think there is some work being done to fix it. For now, if you can try a Cura Connect reset that might solve the problem.

Thanks @rogersj3 . This makes the situation a bit weirder even.

Wow really love the results! Make sure to share the pictures of the Diorama ?

As said before - I'm not the one making the decisions...

Not as easy as it sounds unfortunate.

@korneel Not going to quote all the points, but... I don't make the decisions on what is going to be done - I only gave my opinion based on my experiences with big and small networks, for big and small companies at the time I was involved in this - that included commercial and non-commercial sectors including University networks etc. So don't make assumptions on sizes I have worked with, please, even tho it is already 15-20 years ago At the time of implementation of the UM3, the use for static IP was moot (at least for those making the decisions). The stack, connman, should be very well able to handle it (being used on Android devices too afaik) but interface wise (hmi) nothing is defined. Also, the impression of how it currently works is wrong. The MAC address is always there (for both the cable as wifi connection) but we lack in the display to show this information (when the network is not active). I think that is an oversight from our part, as we just should show both MAC addresses. Unless I misunderstood your statement I quoted...

I disagreed with the statement that having a static IP is crucial. It is not. As @nallath mentioned: people WANT it - but with current technology there is no need for it. Speaking from experience having being part of network engineering and having to fix all kinds of weird static ip issues, mostly due to bad bookkeeping leading to double or even triple use of the same ip address - which are a hassle to find and fix.

This statement already contradicts itself. Simply said: you want to install a DHCP service for every device out there, except it should not give out IP addresses being used by servers and printers... Hence multiple places to manage IP addresses. You have to record every static IP address; to make sure a) it cannot be given out by the DHCP server (using pools of addresses) and b) it will not be manually assigned again and c) if a server is replaced, it will get the same ip number again... But sure, I guess IT companies love making money doing things much harder than they really need to.

Hi @rogersj3 I have checked the logs and didnt find issues with the mjpg-streamer. I have a request: if / when the camera stream is no longer visible on Cura/Cura Connect, can you try to access the stream directly from the printer using a browser: http://<printer_ip>:8080/?action=stream If that works, it helps to focus on what parts need more analyzing to find the cause of the problem.

Correct. If there is no DHCP server on the network the printer is connected to, or the DHCP server is MAC restricted, it will use the 169.x range. I disagree with the statement that a static IP address is crucial. Or are you enjoying to have to manually install an IP address on every device like a pc, laptop, mac, tablet, mobile phone, any wired/wireless device able to connect to a network? I'm not - having many devices, I rather have a well-configured router/switch that provides a DHCP service which can be configured to give out 'fixed' IP addresses to specified MAC addresses. The error you received seems like a fault that could not be recovered from. Did you by chance look at the leds of the cores and remember the color? I think this error was caused by some stalling communication between opinicus and marlin, leading marlin to believe the printer stopped working and halting operations (turning off heaters and stuff). All those files on the USB stick are helpful in analyzing and backtracking the problem that has popped up - they are copied from the system to USB (if possible) so it is a sort of snapshot to give insights in what was going on with the printer during the time the problem occurred. If it is possible, can you send them to us using wetransfer.com so we can have a look?

@WesleyE beat me to it, but the hostname part does indeed contain the MAC address. In your case it is CC:BD:D3:00:5F:24

Ok thanks! We will wait for them.

Did it fix the camera issue? Good!

Please send the logs if you can.

@jimmieshear from the logs I gaterh that mjpg streamer is running fine: Jul 11 03:43:19 ultimakersystem-ccbdd3004dc8 mjpg-streamer[246]: MJPG-streamer [246]: serving client: fe80::c1c:d4c4:d08c:3146%wlan0 Jul 12 02:39:33 ultimakersystem-ccbdd3004dc8 mjpg-streamer[246]: MJPG-streamer [246]: serving client: 10.0.1.50 If you really can see the image directly using the printer API, then I think the problem is with the camera part: is the lens clean and visible, check the housing of the camera. The chance is small, but it still can happen, that the camera even tho it is detected by MJPG streamer, is broken.

Unfortunately not much information in them; also seem to be missing some files. Is it possible to do a reboot after a print finishes, then immediately after reboot dump the logs? That should show more information on the booting up process being executed.

From the menu, System -> Maintenance -> Diagnostics -> Dump logs to USB will dump the log files to the USB drive. You can upload them using something like WeTransfer and paste the link to WeTransfer here.

@brewweasel Can you dump the logs (especially after a reboot) to the USB stick and upload them?