Posts made by Drammy

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

@Phaedrux These are excellent! Well done and thank you for taking the time to share them!

@phaedrux Not particularly, I see there is a setting in Simplify3d to retract whilst wiping so I need to test turning that off and then I should be able to use wiping.
I'm running out of ideas of how to remove the stringing..

I've found that, with this specific material, if I slow the retraction down there is less stringing but still a significant amount. I'll take a pic when this print is done

I get it now - I guess I have to turn the wipe off.. and correct the {REPLACE "G1 E0.0000 F7200\n" "G11\n"} to use relative values

@dino Sorry, just seen your reply. I'm glad you suggested to check the post-processed g-code as it isn't right.

Is it a problem that the G1 E command is on the same line as the X and Y? Also it shows as a different speed..?
Can you share your post-process commands?

This is what I have in my post-process commands:

{REPLACE "G1 E-0.8000 F7200\n" "G10\n"}
{REPLACE "G1 E0.0000 F7200\n" "G11\n"}
{REPLACE "G1 E-0.8000 F2160\n" "G10\n"}
{REPLACE "G1 E0.0000 F2160\n" "G11\n"}

And this is part of the print file g-code

G1 X82.117 Y86.207 E0.1197
G1 X82.205 Y86.170 E0.0034
G1 X82.605 Y86.170 E-0.8000 F3600
; outer perimeter
G1 X84.145 Y90.645 F9000
G1 X84.148 Y90.645 F9000
G1 X84.150 Y90.650 F9000
G1 E0.8000 F7200
G1 X103.260 Y90.650 E0.6712 F2304
G1 X103.260 Y109.760 E0.6712

@phaedrux thanks for the useful info. Interesting..

Do you find wood filaments abrasive on the nozzle?

@dc42 Thanks

Have implemented this and with the better acceleration and jerk extruder settings the retractions are happening in the right order; i.e. before the travel moves.

@Phaedrux Am still getting bad stringing with your settings.

I get that this woody pla is not a good material to tune but my figuring is its best to tune with something that highlights the problem the most.

I will however try some other filaments out and see what kind of results I can get form them..

Good news.. the blockage was just off the hobbed gear. I think I had the tension too high so with all the fast retractions the gear was chewing through the filament and ultimately jammed the top of the inner PTFE lining.

I'll get the rest of the extruder put back together this evening and re-test with your settings @Phaedrux. My extruder jerk / acceleration was quite low compared to your settings so that might explain the slow retracts to the point where the travel was starting before the retraction?

@dc42 - I followed your forum post here and am using S3D to send M101, M102 and M103 codes for retraction - is that still valid? Could that explain why I'm seeing travel completing before retractions?

@phaedrux Oh well, you live and learn! I prefer to not ask questions until I've tried things but in this instance it would have paid to ask first!

Thanks for the suggestions. I have some accupuncture needles and a 1.6mm rod that came with the printer for clearing jams but it ain't budging. I don't want to put to much pressure on the print head whilst it's assembled in case I'm forcing something other than the filament.

Guess I'll be taking the quite fiddly aero apart then..

How much do I need to disassemble?

@phaedrux I've spent quite some time improving the print quality and this is my last thing on the list now.

So I haven't tried other materials yet. I just went with what I had in which is a wood fill pla. Maybe not the best material to tune retraction with tbh.

I read on the e3d forums not to go above 2mm retraction else risk jams. So I now have jam at 1.2!

Just as you said. Wish I'd asked on here before I'd started...

Any techniques for clearing a clog from the titan aero? Can't push filament in and the filament has sheared so no longer connected to the jammed bit..