OK, so after 4+ years ( ), I donated the printer to a friend and came back to this issue. I will leave the fix here, if others hit it .
Disconnecting the thermistors had no effect. The indicated temp was still around 66 degrees now (yes, it degraded over time).
Compared bed, E0 and E1. Measured resistors, voltages. Short circuiting indicated 2000C, as expected. E1 was different from bed and E0 in measured values (3.3 V compared to 3.1V on the others the measuring pin).
Long story short, replaced C19 (the bad guy, or C18 looking at the picture. The one that filters the E0 sensor signal) with C65 (donor) and everything works as in the first day.

Or you can wait to get old. My printer is almost quiet, I just need few more years

Based on @dc42 idea here: https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing#Section_Using_extruder_stall_detection_during_filament_loading

I did the following filament loading macro that works for me:

M302 P1				; enable cold extrusion
M201 E1000			; reduce extruder acceleration
M915 P3 S10 F0 R0		; set stall detection threshold
M913 E100			; set extruder motor to reduced % current
M83				; relative extrusion
G1 S1 E800 F3600		; move fast 500mm of filament
M913 E100			; set extruder motor to full current
M302 P0				; disable cold extrusion
G1 E50 F300			; extrude slowly 50mm of filament
M98 Pset_accel.g		; restore acceleration values

set_accel.g is used to set working accelerations for all axes after sensorless homing of X and Y. It has the following content:

M201 X2000 Y2000 Z100 E9000		; Accelerations (mm/s^2)

… play Doom on PanelDue while printing?

Post some pics, but I bet there is also some over-extrusion going, which adds to the pressure build-up (btw, did you try pressure advance?).

Some time ago, I've attended a machining exhibition and noticed something at Stratasys stand: in all their demo prints you can clearly see the infill lines in top/bottom. They are not squashed trying to generate a smooth top layer. Then is when I've realised that I was overextruding all the time, trying to get rid of that small spacing between the tops of the oval beads of the infill.

Since then, I've adjusted my extrusion factor to always see the top spacing, but they still touch in the middle and the quality of my prints improved a lot.

+/- buttons would be very helpful for mobile devices. I don't know about others, but that slider on Safari on IOS is painful. Sometimes it simply jumps at one end and 150% extrusion is not nice for sure.

Your thermistor, the wires or the way it is mounted are bad. Never had any temperature issues even with the cheap thermistors.

Can you post a picture of your hotend?

At 600F (315C) many things will go bad, so try to avoid that.

@snowcrash said in Help with Steps per mm Calculation:

Thanks for everyone who replied!

That's a really interesting discussion and I think it illustrates perfectly why it tends to get my brain twisted up with all the terms, partly because...

@aidar said in Help with Steps per mm Calculation:

@dougal1957 Got it. But i am sure by 25mm and 12 mm OP means lead then, not pitch.

Actually, I did mean 'pitch' rather than 'lead' - and I'm not going by what I know here (as I know close to nothing on this), but by the documentation.

Check out the link I provided to the products' page on Igus and see what it says there, or if you prefer, here's a snapshot of the 2 relevant rows in the listing:

Actually that is "lead". I find it amazing that Igus confuses "lead" and "pitch".
Check their drawing before the table:

https://www.igus.com/contentData/wpck/images/global/1_1/dst_spindeln_zg.jpg

That P is clearly "lead", not "pitch". The pitch is the axial distance between adjacent threads. They measure the "pitch" as distance between the ridges of the same thread, which actually is the "lead" - axial advance after you turn the screw 360 degrees (1 turn).

https://www.youtube.com/watch?v=0Pg-L1pQ6qU

Are you talking about that capacitor connection?

OK, so after 4+ years ( ), I donated the printer to a friend and came back to this issue. I will leave the fix here, if others hit it .
Disconnecting the thermistors had no effect. The indicated temp was still around 66 degrees now (yes, it degraded over time).
Compared bed, E0 and E1. Measured resistors, voltages. Short circuiting indicated 2000C, as expected. E1 was different from bed and E0 in measured values (3.3 V compared to 3.1V on the others the measuring pin).
Long story short, replaced C19 (the bad guy, or C18 looking at the picture. The one that filters the E0 sensor signal) with C65 (donor) and everything works as in the first day.

Hello,

I have two Duet boards, one is 1.0.1 and one is 1.0.3.
The older one is doing some funny stuff for around a year now. It is reading around 40C on the hotend thermistor and 44C on the bed thermistor. Both are at room temperature (confimed by the other printer with 1.0.3 that is sitting next to it).

This worked perfectly for more than a year and then I've noticed that it measures higher and higher on both thermistors. Even thermistors are not the same. One is the general Chinese one (bed) and the other one is the one that comes with E3D V6.

Printing is fine, that is why I was lazy to report this issue.

I should mention that I didn't change the config, even then it doesn't explain why it started to drift more and more.

Did anyone hit this issue?

I don't want to mess with the config to make them match the real room temperature because I may break the working temps.

Set your multimeter to 10A scale and connect it in series with the Duet. If there is a short, it should jump (above 10A most likely). If the PSU is at fault you will see much less current than 10A.

@peirof M119 ?

@dc42 Interface loads reliably now. Many refreshes and no problem on sockets. Now I get the CORS error after a while, randomly. Cannot reproduce to see what triggers it.

UF4007 is a good choice.

@dc42 said in Duet Web Control 2.0.0-RC2 is ready:

@sigxcpu said in Duet Web Control 2.0.0-RC2 is ready:

Then something is broken in backlog implementation because the Nth+1 connection gets TCP RST instead of waiting. Here is how to find out N:

I've found a couple of reasons for these issues:

1. DuetWiFiServer is coded to reject TCP connections if there are no listeners available for them. There are 4 HTTP responders, so an attempt to open a 5th concurrent HTTP connection is refused. I think this is the right thing to do. With luck, the browser will respect it.

2. The main problem I have identified is that DuetWiFiServer is running out of buffer space when returning multiple files concurrently. This results in the connection being aborted. I plan to change the code to buffer outgoing messages in our own code instead of in lwip, so that I can be sure that sufficient memory is available before accepting a message from the Duet.

Maybe I don't get this right, but 4 HTTP responders and backlog = 8 means that we can have up to 12 simultaneous connections, 4 accepted, 8 pending. The reset/connection refused should happen on the 13th concurrent attempt.
Based on your description (thanks, btw) and my network knowledge, I am pretty sure that the actual backlog is 0 if the 5th connection is refused.

@dc42 said in Duet Web Control 2.0.0-RC2 is ready:

For example, I've recompiled the firmware with 6 HTTP acceptors instead of 4. It reloads DWC2 most of the times, with very few exceptions (i've had DWC1 open in another brower so that ate a connection).
Unfortunately, I am pretty sure that will kill the firmware during printing because increasing to 8 kills it in a boot loop.

My guess is that with 8 you are running short of memory. Each HTTP responder needs around 2K of memory.

The proper fix here should be to implement TCP connection backlogging, instead of refusing them. OK, we serve 4 simultaneout, but we can keep more intents in the backlog before accepting them.

It already does. From https://github.com/dc42/DuetWiFiSocketServer/blob/dev/src/Listener.cpp, around line 150:

	}
	p->listeningPcb = tcp_listen_with_backlog(tempPcb, Backlog);
	if (p->listeningPcb == nullptr)
	{

The constant Backlog is set to 8.

Then something is broken in backlog implementation because the Nth+1 connection gets TCP RST instead of waiting. Here is how to find out N:

bash-3.2$ ab -r -v 0 -dSq -n 10 -c 3 http://192.168.27.8:80/index.html
...
Concurrency Level:      3
Time taken for tests:   0.185 seconds
Complete requests:      10
Failed requests:        0
...

bash-3.2$ ab -r -v 0 -dSq -n 10 -c 4 http://192.168.27.8:80/index.html
...
Concurrency Level:      4
Time taken for tests:   0.123 seconds
Complete requests:      10
Failed requests:        0

bash-3.2$ ab -r -v 0 -dSq -n 10 -c 5 http://192.168.27.8:80/index.html
...
Concurrency Level:      5
Time taken for tests:   0.162 seconds
Complete requests:      10
Failed requests:        9
   (Connect: 0, Receive: 1, Length: 8, Exceptions: 0)

True, but the problem here is the initial/cold/first load. Speeding that up will be helpful if it actually loads reliably.

@gnydick said in Duet Web Control 2.0.0-RC2 is ready:

@sigxcpu That's exactly my point. The web page code should be simplified. It shouldn't be all ajax-y for an embedded web host (with limited resources -- 4 concurrent connections) .

There definitely are minifying tools fro JS and CSS.

Ultimately, the interface is way too complex for the task. Read my rant up the thread.

I think "ajax-y" is the right way to do it here because after loading the assets, it just polls for status, which is thin.
Initial loading is the issue here because it tries to load the assets like from a "normal" web server, with parallel connections up to 6.
I see that there are 2 JS, 2 CSS and one "font" besides the index page.
The 2+2 are loaded right after the index page but sometimes one of them fails so I would assume that the browser optimizes loading and initiates an asset download before the index loading is finished and connection reused.
I am pretty sure that's the difference between:

• it loads => index page connection is finished and reused, therefore there are 4 conns available
• it fails to load => index page is lingering a bit more, so one of the 4 assets is failing to load

Maybe another thing that will help is to enable caching because I always see all the things loading, never a 304.
I don't know how complicated would be but HTTP/1.1 does have connection keep alive. Browser asks for it but the server reponds with Connection: close explicitly. Though this means up to 6 connections anyway.

Overall, my grip is not with the complexity of the JS app, but it is obvious that the way it loads is completely incompatible with the embedded webserver.