Firmware 2.02 Release candidate 3 now available

[dc42]

I have improved the layer detection code in the forthcoming 2.02RC4 release. I'll ask chrishamm to look at whether dropouts in the IP camera feed could cause disconnections.

[Drammy]

Ah good stuff, cheers!

[garyd9]

@dc42 said in Firmware 2.02 Release candidate 3 now available:

I have improved the layer detection code in the forthcoming 2.02RC4 release.

I don't know if it's related, but I had a print (sliced by Cura engine 3.5.1) this weekend with a total height of 400mm, layer height of 0.2mm. The duet board (1.04 with 2.02RC3) failed to properly parse the proper total height of the print.

Instead, it showed an object height of 1mm. (It usually detects the object height properly with files sliced by this version of Cura.) Layer height and filament usage was properly detected.

GCode file (zipped) shared from my google drive here: https://drive.google.com/open?id=1LsdgTVO-XuDT8jmWM_NMnu4kEoQ3Fxpi

[chrishamm]

@drammy said in Firmware 2.02 Release candidate 3 now available:

I never thought the cause of all the problems I'd been having could be the web feed and the Pi just happened to be switched off. Sure enough, deleting the link to the feed in the user interface settings and, boom, the disconnects stopped.

It sounds very odd that a bad connection to your IP cam causes DWC to disconnect. In fact DWC does not track if the loading of a webcam image is successful, so I see no reason why it would misbehave. However if you get connectivity issues while using the webcam image, I suggest you press F12 to open the developer console and switch to the Network tab. There you can track which network requests suceeed and which ones fail. DWC should only disconnect if rr_ requests in there fail.

Is there any chance you can send over a screenshot of that section when the problem shows up again?

[Drammy]

@chrishamm thanks for your help.

I'm a developer so have had the Chrome dev tools open since the print began. I cleared the console down after the last time I removed the webcam url from settings and there has been 0 xhr exceptions raised for the last 2.2 hours; everything is working as expected. Like I said, 2.2 hours without a single failure

I then add the webcam url and within a couple of minutes it permanently loses connection. Some times it may reconnect for a couple of seconds which may be long enough to remove the web url and hit save and for the rr_upload to complete. If this happens then everything returns to normal but its rare to get long enough. I've found the best way to recover the connection is to reboot the motionEye server.

I've done a video of the problem if you need it? Here's the screen grab. Let me know if you need any more info.

EDIT: thought I may as well add the console exceptions..

arrrgghh, akismet.com is flagging the console log screenshot as spam!??

[chrishamm]

Hmm, thanks for that - I just saw the exceptions that you showed. But as you can see the web interface fails to receive four rr_ requests in a row, which causes a disconnect in DWC's logic (provided you have set the number of AJAX timeouts to 3).

May I ask what OS you are using and if the same problem occurs on a different device, too?

[Drammy]

I'm running the latest MacOS Mojave and latest Chrome, happens in Safari as well and on my phone (Samsung s8+ with Chrome)

[chrishamm]

@drammy I honestly have no good explanation for this - it almost seems like your webcam server DOSes the Duet.

I actually tried to reproduce your problem on three different devices on my network and each of them stays connected (Safari on OS X, Firefox on Windows and Chrome/WebKit on Android). Does the problem persist when you set the webcam URL to a different image source? If so, what does M122 output when the problem is present - could you attach a notebook to your board over USB and check via the serial console?

[Drammy]

@chrishamm well thanks for looking. Yeah this all suggests that the problem is with the motionEye system. It does have a DOS feel about it as the two tabs, dwc and motionEye both degrade at the same time.

I'll do some more tests and check the M122 output when this print has finished so will be another couple of days..

Out of interest what webcam stream do you point dwc at? Maybe I can recreate your test environments a bit to try rule out the network..?

Just re-read your last post and remembered I have a octopi on another machine that is streaming a web image.
Will test that in the morning.

[chrishamm]

@drammy I have had some success running motion from a RaspPi using an always-capture config but it's been a few months since I used it. Nevertheless I think it even provides an MJPG stream which eliminates the need for regular refreshes (you can set the update interval to 0 in this case).

[Phaedrux]

@drammy I'm using a raspberry Pi w running motion OS as a camera feed and have had no issues with the DWC. Just as a point of reference.

[Drammy]

@phaedrux thanks for the info. What camera is running on it?

[Phaedrux]

@drammy I'm using the Pi camera module. V2 I believe.