I use my PanelDue a lot but I can't use the extrusion buttons when calibrating eSteps...

I like to calibrate by eSteps at the filament flow rate that I normally print at (1.75mm filament) which is about 1.5mm/s. The first flow setting in the extrude options is 5mm/s which would be pretty fast even for 2.85mm filament.

The jumps in values don't really make sense; they double from 5mm/s which I think is too high to start with and then keep doubling to 40mm/s and then just up to 50mm/s. I think 50mm/s is pretty redundant here when compared to the other values.

Perhaps we could have some different values, assuming we stick to 5 buttons:
1, 3, 9, 27, 81
1, 2, 4, 8, 16
1, 2, 5, 15, 45
2, 4, 8, 16, 32

To be honest I haven't got the experience to best estimate the range that suits most people but surely 5mm/s is too high for the lowest feed rate?

Anyone agree?

Should be going to bed now but thought this might make some folk laugh and hopefully you can relate to it..

So I was just installing a couple of z axis stabilisers into my i3 plus which required me to remove the top gantry from the printer.
Just as I was taking out the last bolt I dropped it; I heard it bounce a couple of times and it sounds like it landed inside something.

Could I find the darn thing - could I heck! I looked absolutely everywhere.

And I mean everywhere; I took the entire printer apart concerned that it had landed in some electronics or mechanical parts. I could not find it anywhere. I double-checked all the dangerous places (power supply, duet-wifi housing) and thought I'd switch it on and check that the printer works and can move freely to kind of reassure me that the bolt couldn't be inside anything too important.

So I put the printer back together and put it back in the enclosure, powered it up and everything homed ok! Phew! but where was the blooming bolt? I knew it was inside something because of the sound it made...

Anyway it had gone midnight and with work tomorrow I decided to leave it for the night. I finished putting the printer away and the drill and bits. I then started putting all the screwdriver heads back into my screwdriver set and one head wouldn't drop into it's slot!!

Bingo, the little blighter had found its way into the smallest nook and cranny possible - how do they always do that??
And as always - it was the last place I looked!

Anyway, I can go to bed a happy chappy now..

Night!

(p.s. there should be a 'random' category for fun conversations)

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

@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.

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

@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!??

Ah good stuff, cheers!

And another thing I noticed is that my first print on the new firmware started printing correctly but on DWC the layer had jumped to 4.

It wasn't until the real layer 4 completed that the layer counter started displaying the correct value.

Indeed, the first three layers were recorded as taking 0 time and layer 4 just under an hour.

hhmmmmm.. the stats have just changed to this..

Hey @dc42 thanks for implementing the wifi re-connecting functionality in 2.02! (I'm running RC3) I've been doing some testing on the web connectivity...

At first I thought it was working perfectly and it was until...
I switched on my Pi running motionEye (which is normally running 24/7). The moment that the feed came up and started displaying in Duet Web Control the drop outs started immediately exactly.
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.

Interestingly I have just put the web feed url back in (same url as I cut it previously to put in clipboard) and I am now not getting drop outs. I will continue to monitor and test this though.... EDIT: after about 5 mins of writing this email we're back in the state where it disconnects and reconnects.

I can open the web feed on a separate browser tab and it continues to feed as expected during the drop outs.

Could there be an issue with taking web feeds and it causing DWC connection drop outs?

My Duet config
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.02RC3(RTOS) (2018-10-17b2)
WiFi Server Version: 1.21
Web Interface Version: 1.22.4-b1

My network config
EE router in house on which my machine connects.
Netgear EX2700 extender in garage on which Duet WiFi and motionEye both connect.

Running Mac OSX Mojave & Google Chrome (Version 70.0.3538.77) but the same thing happens on Safari (Version 12.0.1 (14606.2.104.1.1)) and on my smart phone (Samsung s8+ on Chrome).

note: I work in IT and am pretty confident it is not my network as I work from home and use it constantly without any other issues.

I hope that helps?

With the exception of the 54 seconds (I did see this but can't say its consistently every xx.54 seconds.) I am getting constant connection failures as well on the latest version 2.01.

With a fresh connection on the duet and a fresh connection from mac osx Google Chrome I get a connection for a couple of minutes but after that I get a disconnection and EVERY subsequent connection attempt fails. I can even open the Chrome developer tools and do a hard refresh and clear the cache with the same result.

@dc42 Hi there,

I was just wondering if you've included this in the 2.02 release as I can't see it in the WhatsNew notes.

I know this isn't related to auto reconnecting but I've found that the wifi connectivity when using DWC is much more prone to disconnects since upgrading to v2.0 and above. At best I can connect for about a minute before being disconnected.
To be honest I've not investigated but it looks to me like the web server is taking too long to return API calls and DWC just disconnects.
Is there anything that can be done about this?

@phaedrux I hadn't seen them; I'll start using them straight away. Thanks again!

I've come to the conclusion that the filament I was using was simply terrible filament. I've stopped printing the model I was trying to (1st pic below) and have just taken delivery of some Filamentum Extrafill PLA which has shown absolutely no stringing whatsoever with your settings. The 2nd pic is the temp tower test I did (literally the very first print with this new filament)

Note: I did dial down the retract speed for the first print 7200 -> 2400. I am new to this filament and not being familiar with it led me to lower the retract speed until I learn more about its viscosity. I didn't want it snapping with high speed retracts.

Looking at the 2nd pic suggests to me that I need to introduce some negative R values as the point after a retract seems to over-extrude a bit. The whole print is generally over extruded but that's the next task now I know the print temp..