Wrong date/time causing HTTP connection issues?

usinjin

I hope this is the right place to ask this. Would the wrong time/date on a PC networked with a Duet cause HTTP requests to either take a very long time or fail altogether? I recently set up a new system with a Duet Mini 5+ running in standalone mode. However, loading the DWC was very spotty. Sometimes it would fail to load altogether, other times it would load slowly but the connection would reset repeatedly. I tried a new ethernet cable, new SD card properly formatted with SD card Formatter, the DWC and all board firmwares matched. I finally realized that the PC's software and hardware date/time were wrong by about a day. After correcting, performance seems good, but I don't know for sure that it would actually have any affect. Any insight on this would be appreciated.

Phaedrux

Has it been running stable now for long enough that you're sure it's related?
If you get the time out of whack on purpose, can you recreate the issue?

What firmware and DWC versions?

chrishamm

@usinjin I don't see how this could have an effect. In standalone mode DWC updates the firmware's datetime when it is loaded for the first time.

If it is a WiFi board, consider trying out the latest WiFi firmware instead. See https://github.com/Duet3D/WiFiSocketServerRTOS/releases/tag/2.1beta7

usinjin

It didn't really make sense to me either. Indeed, setting the wrong day and time again doesn't make the connection any worse.

It's the ethernet version, running 3.5.0 candidate 3. Right now the connection seems stable, but I'll swap out the Duet with another to see if I can isolate the issue. I think it could be a hardware issue with the computer or the Duet itself.

droftarts

@usinjin Double check how the SD card is formatted, and how it is performing. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues
Particularly check it with M39, and run the M122 P104 S10 speed test.

You could also try updating to the latest '3.5.0-rc3+4' builds, here: https://www.dropbox.com/scl/fo/yzchzlyxmxlzywjawqflu/h?rlkey=tl7dfs75yozhfgpze0jnkn32n&dl=0

Ian

usinjin

@droftarts I checked and this matches the formatting of the card. All SD card tests passed too.

What is the 3.5.0-rc3+4 build? Are there release notes for it?

chrishamm

@usinjin https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC

usinjin

It appears that at times ethernet doesn't seem to re-enable after M112 (both lights on ethernet port stay off). The M569.1 commands are also holding up the reup process, when they are enabled it seems to take the Duet about 20 seconds to come back up instead of about 2. My config.g is below.

Also: 5V_EXT is equal to my VIN (~24V). Why might this be? None of the jumpers have been changed from the factory settings. This may be throwing off my analog sensor reading on IO3, which never reports 0V even with no input. When I take the exact same config and test it with the exact same sensor in IO3 of a different Duet (running the same firmware, same DWC), the input does reach 0V (and 5V_EXT on that board is 5V).

; Configuration file for RepRapFirmware on Duet 3 Mini 5+ Ethernet
; executed by the firmware on start-up

; General
M550 P" " ; set hostname

; Network
M551 P""                                ; set password
M552 P192.168.1.15 S1                   ; enable network and set IP address
M553 P255.255.255.0                     ; set netmask
M554 P192.168.1.1                       ; set gateway
M586 P3 S1                              ; enable HTTP
M586 P1 S1                              ; enable FTP
M586 P2 S1                              ; enable Telnet

; Wait a moment for the CAN expansion boards to start
G4 S3

; 1XD Step Driver
M569 P40.0 S0 R0
M569 P40.0 T2.7:2.7:2.7:2.7
M584 Y40.0 P2
 
; 1HCL Drivers
; Closed loop config
M569.1 P30.0 T2 C4000 E5:10 R100
M569.1 P31.0 T2 C4000 E5:10 R100
M569.1 P32.0 T2 C4000 E5:10 R100

; Start in open loop just for initial home (set known position before calling M569.6 routines)
M569 P30.0 D3 S0  ; driver 30.0 goes backwards (Y0 axis)
M569 P31.0 D3 S1  ; driver 31.0 goes forwards (Y1 axis)
M569 P32.0 D3 S0  ; driver 32.0 goes backwards (X axis)

M584 Y30.0:31.0 X32.0 P2
;  M584 Y30.0 Z31.0 X32.0 P3
M350 X16 Y16 I1
M92 X80 Y59.26
M566 X0.00 Y0.00
M203 X16000.00 Y16000.00
M201 X1200.00 Y1200.00
M906 X2300 Y2300 I0
;  M917 X0 Y0
M17
;  M84 S1 ; Idle timeout

; Kinematics
M669 K0 ; configure Cartesian kinematics

 ; Axis Limits
M208 X0 Y0 S1
M208 X292 Y310 S0

 ; Axis Limits
M208 X0 Y0 S1
M208 X292 Y310 S0

; Endstops
M574 X1 S1 P"^32.io0.in" ; X limit
M574 Y1 S1 P"^30.io0.in" ; Y0 limit
M574 Z1 S1 P"^30.io1.in" ; Y1 limit

; I/O
;   M950 P1 C"io4.out"      ; allocate GPIO port 4 for the triggering of CVM program OR VCA enable (cable must be switched on Copley Controller)
;   M42 P1 S0               ; disable  

; Current-PWM-ctrl for voice coil
M950 P0 C"40.io0.out" Q30000	; allocate GPIO port 0 to out9 on expansion connector, 30kHz
M950 P1 C"40.io2.out"

M42 P1 S0               ; disable motion of pen 
M42 P0 S0.53			; pen up command
M42 P1 S1               ; enable motion of pen
G4 P100

M42 P0 S0.5				; set to 50% (which is 0% output)
M42 P1 S0               ; disable motion of pen

M308 S0 P"io3.in" Y"linear-analog" A"Pen pressure" F0 B0 C174

global pressure_on_pause=0.5
global pen_up_on_pause=0
global pen_is_up=1
global pen_is_on=0
global pressure1=0.44
global pressure32=0.40
global pressure64=0.38
global pressure85=0.36
global pressure105=0.34
global pressure112=0.32
global plot_is_paused=0
global instant=0
global accel=800
global metadata_finished=false
global selected_filename=""
global cancelled=false
global aligned=false

dc42

@usinjin said in Wrong date/time causing HTTP connection issues?:

Also: 5V_EXT is equal to my VIN (~24V).

That's definitely wrong. Have you tried disconnecting everything from the ports that provide 5V_ext power, to see if something connected is putting 24V on 5V_ext? If it was the internal 5V regulator that was passing 24V to 5V_ext then it would also put 24V on 5V_int and the whole board would be toast.

usinjin

This post is deleted!

usinjin

@dc42 Well, now of course I can't recreate that--I don't think I had anything connected to any inputs though, and I'm not using any of the 5V_EXT connections anyways. Maybe something is intermittently shorting?

Before, when I was getting 24V on 5V_EXT, 5V_INT was 5V. Now 5V_EXT is back down to 5.29V. (seems a little high as well)

usinjin

It doesn't seem to matter the firmware. I've installed 3.5.0 rc1, r3, and rc3+4, and they all work until I need to do a board reset. At that point, I just get the error "http failed to connect" over and over again. I always have to power the board off, let it sit, then power it back on.

This is a board we've been using without issue for months. 3.5.0 rc1 has given us no problems either. The only change is the addition of CAN devices. I'm so stumped.

Phaedrux

@usinjin said in Wrong date/time causing HTTP connection issues?:

The only change is the addition of CAN devices.

Have you tested with the can devices disconnected to see if that is related?

usinjin

@usinjin said in Wrong date/time causing HTTP connection issues?:

Sometimes it would fail to load altogether, other times it would load slowly but the connection would reset repeatedly.

@usinjin said in Wrong date/time causing HTTP connection issues?:

I think it could be a hardware issue with the computer or the Duet itself.

@usinjin said in Wrong date/time causing HTTP connection issues?:

It appears that at times ethernet doesn't seem to re-enable after M112 (both lights on ethernet port stay off).

@usinjin said in Wrong date/time causing HTTP connection issues?:

It doesn't seem to matter the firmware. I've installed 3.5.0 rc1, r3, and rc3+4, and they all work until I need to do a board reset. At that point, I just get the error "http failed to connect" over and over again. I always have to power the board off, let it sit, then power it back on.

If I actually took a moment to examine all the information I've presented in this process, I could have addressed the real issue much earlier. I already had all the information and I chose to ignore it. I really should know much better than to fall into thinking traps like this. I guess it could be a learning experience for anyone working closely with hardware and software simultaneously. Or any project for that matter.

It clearly never was a software issue. Wireshark revealed malformed packets and long periods of retransmissions. Definitely not normal on a static network with a single endpoint.

@usinjin said in Wrong date/time causing HTTP connection issues?:

Maybe something is intermittently shorting?

Indeed. Turns out the polyimide tape I bought as a protection for the back of the Duet was not actually polyimide. It most likely is for EMI shielding of some sort, as I found it has a conductive layer. The solder joints on the ethernet port were intermittently coming into contact with it and grounding it out.

After removing the tape, the issues have not re-appeared.

Thank you to everyone who provided insight!

droftarts

@usinjin Good catch! Glad you managed to resolve it. All to easy to fall into thinking traps!

Ian