Posts made by sigxcpu

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.

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

@sigxcpu, I have come to the same conclusion that there are problems triggered by the increased number of concurrent connections that DWC2 uses. The problems are worse when there is a password set, but I get them occasionally even with no password. I've asked chrishamm if he can reduce the number of concurrent connections used. When I next work on DuetWiFiServer, I'll review the way that multiple concurrent connections are handled.

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

@dc42 browsers have a limit of the number of concurrent connections to the same domain (IP address in this case).

All the more reason to simplify.

It is the other way around. Browsers have a too high limit of concurrent connections per domain.
Most of modern browsers have 6, which is too much compared to Duet's 4.

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.

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. I don't know how much memory a backlogged connection eats.

I don't think users care too much about the UI load time, but we do care about it to load reliably.
Another fix is in DWC2 to compact all JS files in a single one and all CSS files in a single one.

Maybe there is a web tool to compact all these in a single "archive" whatever that is. I am a backend developer, therefore I'm not versed in all of these.

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

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

Well, I spoke too soon. The issue came back, randomly. Updated to RC2, no change in behavior.
DWC1 works, 2 fails to load assets. "ab" testing on a failing asset is successful so I think it is something related to sockets/memory/wifi firmware. There are lots of dups and retransmissions when it fails.

Do you have a M551 password set? If so, try removing it. I've found that RC2 still doesn't work on my Kossel unless I remove the password.

Btw you can temporarily revert to DWC 1 by entering <ip_address>/reprap.htm in your browser instead of just the IP address.

I do have M551 Preprap but that is ignored. Before you asking me I've never noticed it is set. Always logged in as "ftp" with no password.
I know about /reprap.htm and that's what I'm using. I still don't understand why downloading assets in DWC2 fails randomly but DWC1 loads.
And, again, downloading them with ab returns successfully each and every request. Tried with 2 threads, let's try with 6 just like the browser does.
...
ab testing works up to 3 connections. Everything higher than that breaks with connection refused. I think that is the problem with the UI download.
Testing it further, I see that it works reliably with 2 connections. 3 is hit and miss, >=4 always fails.

Well, I spoke too soon. The issue came back, randomly. Updated to RC2, no change in behavior.
DWC1 works, 2 fails to load assets. "ab" testing on a failing asset is successful so I think it is something related to sockets/memory/wifi firmware. There are lots of dups and retransmissions when it fails.

Is there any special thing to do except uploading the .ZIP?
I have updated to Duet WiFi Firmware 2.0.2 yesterday and today to DWC2 RC1.

Both my printers behave the same: the page does not load.

The browser console shows two errors:

If I click reload maaaany times, I get a page without style applied sometimes. DWC 1.22.6 loads and works perfectly every time.

Strange thing, Firefox fails to load it the first time (missing files errors) then a refresh fixes it. Another refresh breaks it the same way then a another refresh fixes it and so on.
Other browsers (Safari, Chrome, Webkit based) all fail.

Later edit:
I think this is more for @dc42.
Interestingly, a failed request for /js/app*js shows this:

HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Encoding: gzip
Content-Length: 70034
Connection: close

But the connection is forcibly reset by Duet with RST, ACK after ~26KB. These 26KB are interesting because they match around the value of the uploaded file over FTP, which is another bug I encounter. (not related, because there are 26KB uncompressed vs 26KB compressed sent by FTP). The FTP bug described below is still valid, but it may have nothing to do with the HTTP download bug.
If I try to upload file on /www over FTP they always reach the SD card truncated. This specific file has it's size between always the same 3 values: 26.XX KB, 27.XX KB and 28.XX KB. Never 70.XX KB.

Again, I don't think this is a Wifi network error because everything else works beautifully. Even more, doing an ab benchmark on these specific JS files, it never fails in 100 requests with concurrency 2.

Even later edit. Sorry for the long post.

It looks like downloading the "big" files like chunk-vendorsjs and appjs always fails. One of them is always failing randomly.

Enabled serial debugging and got this:

HTTP connection accepted
HTTP req, command words { GET / HTTP/1.1 }, parameters { }
Read 0 1 12022
Read 0 1 23286
Read 0 1 23287
Sending reply, file = yes
Read 0 1 119158
HTTP connection accepted
HTTP connection accepted
HTTP connection accepted
HTTP req, command words { GET /css/app.41ddf9b3.css HTTP/1.1 }, parameters { }
HTTP req, command words { GET /css/chunk-vendors.30c0b939.css HTTP/1.1 }, parameters { }
HTTP req, command words { GET /js/chunk-vendors.92cfeab5.js HTTP/1.1 }, parameters { }
HTTP connection accepted
HTTP req, command words { GET /js/app.9bf271d0.js HTTP/1.1 }, parameters { }
Read 0 1 12022
Read 0 1 23286
Read 0 1 115190
Read 0 1 115191
Sending reply, file = yes
Read 0 1 12022
Read 0 1 23286
Read 0 1 115190
Read 0 1 115191
Sending reply, file = yes
Read 0 1 12022
Read 0 1 23286
Read 0 1 116982
Sending reply, file = yes
Read 0 1 12022
Read 0 1 23286
Read 0 1 116982
Sending reply, file = yes
Read 0 2 118390
Read 0 1 118392
Read 0 4 119414
Read 0 4 119418
Read 0 4 120822
Read 0 4 120826
Read 0 4 120054
Read 0 4 120058
Read 0 4 119422
Read 0 4 120830
Can't send anymore
WiFi reported error: incomplete write

Looks somewhat solved. Errors appear from time to time, but it works. What I did on both printers is that I've forced a firmware rewrite for the WiFi server using serial console.
Both were 1.21 before, both are 1.21 now. Maybe there are multiple 1.21 versions out there?

If your steps/mm are correct (prints have the expected size), your (0,0) point matches what you configured in slicer and your bed size (X & Y sizes) is correctly configured in slicer it is impossible for your prints to not be in the center of the bed.
Post slicer setup and real pictures with an off-center print.

@lui2004 said in Problems with the E3D-V6 Temperature:

Now i See my mistake.

And for E3d-v6 What i can do to solve my problem any idea?

I assume you fixed this one too?

M143 H1 S28 0 ; Set temperature limit for heater 1 to 280C

Never bothered with that so... good to know

Thank you again.

@lui2004 said in Problems with the E3D-V6 Temperature:

You have multiple mistakes in your config file:

; Axis Limits
M208 X-34 Y-1,5 Z0 S1 ; Set axis minima

M143 H1 S28 0 ; Set temperature limit for heater 1 to 280C

Thanks @dc42, already seen your video, but I'm still confused.

Sadly there are two different pinouts of stepper motors with integrated connectors. If it's any consolation, I've blown a stepper driver in exactly the same way.

What can be the wrong wiring method of a stepper mottor to trigger a driver suicide?

I see only one way in which wiring can be wrong: coils are not AABB but another combination (BABA ABAB ABBA or BAAB). In my experience this generates a motor buzzing with almost no movement.
Another unlikely option is to have 2 or more of the 4 motor pins shorted, but that should be taken care of by the driver protection.

Is there any other bad motor pinout that I fail to see?

Btw, the 1-3-2-4 happened to me twice when using some old copier motors with the same exact 6 pins socket on them like modern ones. The result was buzzing with no movement.

@JKaechler try M201 X500 Y500. If homing works this way, then you need to set that on homing and create a macro to restore accelerations to their initial values (1000 in your case).

Here's my homex.g (Y is analogous).

M400					; make sure everything has stopped before we make changes
M915 P0:1 S3 F0 R0			; configure stall detection
M574 X1 Y1 S3				; set endstops to use motor stall
M913 X50 Y50				; reduce motor current to 50% to prevent belts slipping
M201 X500				; reduce acceleration to avoid false triggering
G91					; use relative positioning
					; X or Y is homed at this point, now home the other axis
G1 S1 X-325 F4000		      	; move towards axis minimum 
G1 X5                      		; move away from home
M400                  			; make sure everything has stopped before we reset the motor currents
M913 X100 Y100 				; motor currents back to 100%
G90                   			; back to absolute positioning
M574 X1 Y1 S1
M98 Pset_accel.g			; restore acceleration values

set_accel.g restores the acceleration values and has the following contents:

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