Duet2 WiFi frequently disconnects when Paneldue 7i is connected

edsped

as soon as the paneldue is connected the disconnects start up again.

dc42

@edsped it could be that the enclosure that you have mounted the PanelDue in is pressing the touch screen and sending continuous commands. Please check that is not the cause, for example by loosening the mounting screws.

Another possibility is that the PanelDue cable is picking up a lot of interference, for example from an adjacent stepper motor cable. However, that seems unlikely if the problem occurs mostly at startup when the motors have (I presume) not been energised yet.

edsped

@dc42
I took the case off so the Paneldue is now sitting bare on a pile of napkins and am still getting the WiFi drops. I also switched from the 4 wire to a ribbon cable and the WiFi drops persist.

All that being said the drops pretty much only occur during G32. Once the print starts the connection stays solid. Not sure if it makes a difference but the consol on the paneldue doesn't show any issues. And disconnecting the paneldue eliminates the WiFi drops completely.

edsped

@dc42
As can be seen below, no disconnects once bed is leveled. I'm not going to go too crazy on this as I'm not sure how long it's been happening or if it's even worth chasing at this point as it's more of an annoyance and doesn't affect printing.

Phaedrux

What's in your bed.g? What kind of probe is it?

edsped

@Phaedrux
It's an omron switch, (Jubilee Printer)

I tried commenting out M558 as an experiment and it had no effect.

I'm not overly concerned and as far as I know it may have been happening for the past couple of years and I just never noticed but I don't believe that was the case.

M290 R0 S0 ; Reset baby stepping
M561 ; Disable any Mesh Bed Compensation
G91 ; Switch to relative positioning to drop the bed
G1 Z3 F700 ; Drop Bed 3mm
G90 ; Return to absolute positioning
G1 X150 Y150 F18000 ; Move to the center of the bed
M558 H3 A3 F100 T20000 ; Set the probing speed
G30

G30 P0 X290 Y290 Z-99999 ; probe near front left leadscrew
G30 P1 X10 Y290 Z-99999 ; probe near front right leadscrew
G30 P2 X152.5 Y10 Z-99999 S3 ; probe near back leadscrew and calibrate 3 motors

G1 X150 Y150 F18000 ;Move probe to center of bed
M558 H3 A3 F100 ; Set the probing speed
G30 ; Set Z = 0
G1 X0 Y0 Z4 F18000 ;Move probe home

Phaedrux

Just to test a theory, since it seems to only be a problem during the bed.g file, and it contains a bunch of probing moves, can you create a macro that has a similar amount of z axis moves and see if it can trigger the wifi issue?

That would indicate some noise being picked up from the Z steppers. Perhaps shielding or twisting/braiding the cables would help there.

edsped

@Phaedrux
Will do but probably Friday before I give it a go as I feel like I'm in the Griswold house at the moment.

dc42

@edsped As you have a DueX5 connected, one possibility is that a wire connected to an endstop input or a GPIO pin on the DueX5 is picking up noise. Whenever the state of a DueX input changes, an interrupt is generated and a task is activated to read the status change, and if this happens very frequently then it can starve the CPU. Are you using any inputs to the DueX5?

edsped

@dc42 A quick follow up to finish out this thread...

I very incorrectly assumed the issue was with the Duet board. I ended up moving to a Duet3 6HC with an RPi v4 SBC and upon connecting the PanelDue the same "connection interrupted" errors. At this point I'm going to assume there's some sort of issue with the PanelDue and will put it off to the side as I don't want to damage the 6HC board.

edsped

Just a quick addition…. The duet Wi-Fi and duet3 w/SBC are in two separate networks. WiFi was on a 2.4 GHz and SBC is on a 5GHz both managed by two separate ubiquiti UAP’s