So... here's a little request: Can we have a free space display on the various file listings? The SD card I have in there isn't large, but it's fairly large by gcode file standards --- but still not unlimited. Would be nice to have a little indication of usage.

@nightowl actually... I was considering that my take on e3d's tool changer might have one of the tools being a dremel like device --- for cutting and buffing... but right now it's just a thought.

Thank-you for your patience. I believe I have resolved the issue... with a combination of your thoughts and my experimentation (as it should be). For posterity, here's wazzup.

BACKGROUND

The printer in question was built (originally) mid-2014 ... and with Chinese electronics. It was noisy and it ran hot. It's largely a Mendel from reprap.org ... combining some of the Prussia Mendel with some ideas from the Reprap-Pro Mendel and some custom changes suggested by the helpful fellow who printed the initial printed pieces for me (among them, a fine herringbone main gear set).

This I upgraded ~2016 or so --- the duet2wifi was a "new thing" when I did this, if that helps nail down the timeframe. I swapped the Chinese electronics for the duet2wifi, I added a heated and magnetic bed and I made minor improvements in the geometry.

This printer eventually choked on some filament and I didn't get around to fixing it until just recently. I have been collecting supplies to make something with the e3d tool changer (but different), but I haven't started assembly yet.

THIS ITERATION

So I started this iteration to improve a few things... one of the most major: add a BLTouch to the system. I ended up learning first that I had some really sub-optimal motors in play --- that only took 0.4A of max current (for X, Y and E0). I replaced these with 1.5A motors. Seriously, the documentation about selecting motors is good (although I found utube about parallel and serial that seemed to explain that better) ... but I'm relatively sure it wasn't available when I first did this.

After the upgrades, I found the print occasionally getting out of square. The pair of Z-axis motors were 2.4A beasts --- and so I hadn't replaced them in the first go round, but motors are pretty cheap ... so I ordered some more of the 1.5A ones. Then my Z-Axis problems got worse.

THE SCALE PROBLEM

So... here-we-are. The problem. Have you guessed yet? I think Phaedrux was dancing around it above. The original pair of Z-Axis motors were 0.9 degree motors. It would seem it is much harder to drive these fast. This is why the motor multiplier was 5104. I discovered this because after configuring my new motors to move more slowly, my "test cube" was 20x20x40 (and having trouble with layer adhesion).

Of course lightbulbs immediately lit (I didn't actually finish printing the cube --- I got to around 50% --- where it was 20cm-ish high ... and noted that it was only 50% finished and stopped the print). I cleared the bed and reached for the caliper --- 10 cm of commanded movement ... 20 cm of actual movement. Hrmmm.

This is the point I realized the situation. So I changed the multiplier to 2552 and adjusted the speed of that axis to 300mm/min (150 was working for the old config, so it made sense. 180 wasn't). I re-printed my test-cube. (If anyone's curious, with a nod to Star Trek's "Transport Test Cube", I have a 20mm cube that I use for testing the printer).

@jay_s_uk I have to say, my mind is kinda blown on what this can do. I suppose I'm off on this rabbit hole today.

@droftarts thank-you, but ... it's a pretty obvious thing to include in the web control thing --- which is where I posted this.

@zBeeble So... after some time, I finally did run out of filament, and that, then, verified both branches ... "This works" ...

Re: Clarifying BigTree Filament Sensor Connection.

I stared at the problem again. The difference between the markings on the wires is subtle and my glasses were dirty. In the end, I didn't fry it with the multiple wrong connections (crongrats both duet and bigtree for tolerating my stupid).

My config file is now M591 D0 P7 C"e1stop" L6.5 R75:125 E22 S1

I've had both 75% and 125% trigger --- 6.5mm is a lot in this sense. But when it has triggered, one restart has run to completion. Maybe changing the check value (E22)? Dunno.

Anyways ... works like a charm.

@OwenD Just got verification that this works (at least to sense the filament not running out).

... I increased it to 100ms to be pessimistic, but that would be correct... the printer is still (for a little while) in filament. It should run out for real (testing the other branch) before this print is through.

I've just updated to 3.5.2, but this was also happening at 3.5.0. I updated so I wouldn't be told to update ... and it's very obviously still happening.

While the following screenshot was taken, the printer was working on the first layer of my model. AFAICT, the position of the tool is correct. The amount of the model showing is not.

I think the step it's highlighting is also wrong, but I have trouble parsing that.

Here's the versions:

I delivered m111 p1 s1, and this is the changed repeating output:

WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
1ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Con^?/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578
): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
WiFi: /hom^?s/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1

Debugging enabled for modules: Network(1 - 0xffffffff) WiFi(14 - 0xffffffff)
Debugging disabled for modules: Platform(0) Webserver(2) Gcodes(3) Move(4) Heat(5) Kinematics(6) InputShaping(7) unused(8) Print
Monitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) CAN(17) Expansion(18)
ResponseTimeout, pending=1
Bad recv status size
ResponseTimeout, pending=1
Bad recv status size
ResponseTimeout, pending=1
Bad recv status size
ResponseTimeout, pending=1
Bad recv status size
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projec^?/home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Con^?uet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projects/^?t 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on po^?/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
Bad recv status size
ResponseTimeout, pending=1
Bad recv status size

This is the log from the first few glitches above (posted here) through starting a new print and then it glitching hard:

Debugging enabled for modules: WiFi(14 - 0xffffffff)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Gcodes(3) Move(4) Heat(5) Kinematics(6) InputShaping(7) unus
ed(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) CAN(17) Exp
ansion(18)
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
Done printing file
Finished printing file 0:/gcodes/CFFFP_DeckStand_Anker.gcode, print time was 13h 4m
ResponseTimeout, pending=1
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1

And just to be clear, two local computers are pointing at it and no network traffic (as expected) is coming from the router for it.

OK. Now it's full-on inaccessible.

Lots of these lines scrolling on the console.

ResponseTimeout, pending=1
ResponseTimeout, pending=1
ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
ResponseTimeout, pending=1
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns

OOB ... looking at your debug message ... you could probably significantly cut binary size by cutting /home/renz/Projects from the path of all debug messages --- ie: cut to the root of the project.

@Phaedrux said in Duet2 wifi stuck repeating Wifi Error.:

Have you tried updating to 3.5.2 yet? Or the 3.6 alpha release? I think the beta is upcoming as well.

I'm a little bit upgrade adverse ... you can convince me, but equally, I don't believe this is upgrade related.

The printer was idle, so I shut off the constant network chatter. wifi debug was still on (as it's fairly quiet). During the idle day, it said this:

Debugging enabled for modules: WiFi(14 - 0xffffffff)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Gcodes(3) Move(4) Heat(5) Kinematics(6) InputShaping(7) unus
ed(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) CAN(17) Exp
ansion(18)
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns

Now.... 2 computers look at the web server and the web server is on an RFC 1918 address behind NAT ... so not general internet exposed.

I've turned on the debugging for 14 and 1 (wifi and network). Lots of chatter, but the printer is definitely acting up. The serial is no longer chunky, but at one point, I disconnected the serial ... which would reset the driver on the server.... and probably the duet, too.

m111 and chatter look like:

Debugging enabled for modules: Network(1 - 0xffffffff) WiFi(14 - 0xffffffff)
Debugging disabled for modules: Platform(0) Webserver(2) Gcodes(3) Move(4) Heat(5) Kinematics(6) InputShaping(7) unused(8) Print
Monitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) CAN(17) Expansion(18)
New conn on socket 0 for local port 80
Found responder
Received 367 bytes
New conn on socket 1 for local port 80
Found responder
Received 329 bytes
New conn on socket 0 for local port 80
Found responder
New conn on socket 1 for local port 80
Found responder
Received 329 bytes
Received 367 bytes
New conn on socket 0 for local port 80

Notably, on one output not shown, "slowest loop" was around 146ms.