Duet Ethernet connectivity problems

[rootboy]

Several (probably related) problems with my Duet Ethernet board.

1) Loss of connectivity, or frequent resets followed by not connecting again.
2) USB driver dropping out and failing to connect again.
3) Duet Web Control dropping out and not reconnecting until USB cable is removed.
4) Immediate DWC disconnect when a file is uploaded to the printer.

When it rarely connects, and stays connected, the printer never starts the print.

Firmware 1.20 and 1.21 both exhibit this problem.

Thoughts? Suggestions?


Thanks!

[dc42]

As you are using USB, see https://duet3d.dozuki.com/Wiki/USB_ground_loops. Also do not use Repetier host unless you know how to stop it enabling debug.

#4 could be this: https://duet3d.dozuki.com/Wiki/Network_ ... arge_files.

[rootboy]

I disconnected the Ethernet cable and I'm running it directly from MatterControl. So far, so good. The plan is to dedicate this PC to just printing and remove everything else from it. I'll give it another shot once I do that.

As for #4, the file size was tiny, so that wasn't it. There were several times where I couldn't connect, but pinging it worked fine.

[rootboy]

Thanks for the links to the isolator! I ordered a couple from Amazon, they should be here Monday:

https://www.amazon.com/gp/product/B06XB ... UTF8&psc=1

I've been bit by USB (and all manners of other kinds) ground loops before, but this didn't seem to be the problem in this case. But it's cheap insurance...

[rootboy]

Well, with the USB cable disconnected DWC still drops out when I send it a .STL file from the "Upload & Print" button. And is there a reason why it doesn't display .STL files? Am I using the correct button?

[dc42]

You can't print an STL file directly, you need to slice it first.

Did you try a different Ethernet cable?

[rootboy]

Yup. Same thing.

[rootboy]

I tried it in Linux, and with nothing but the Duet and my PC connected to the router. Same results.

[rootboy]

You can't print an STL file directly, you need to slice it first.

Duh! Thanks! I'm too used to printing from MC...

But it's still dying during a print. I'm trying again with the USB cable removed (I have in the past, but forgot to remove it this last time).

[rootboy]

Well, on the plus side, it's printing very nicely - finally! Doing the bed calibration prior to printing really smooths things out!! Beautiful!!

On the minus side, I'm flying blind again with the Ethernet down again. Since it's doing so well at the moment, I'll just let it continue. I can still make some tweaks from the PanelDue.

[dc42]

Have you tried assigning the Duet a static IP address in the M552 command? There were some potential issues with the DHCP client when the lease expired, and although I believe these are fixed in firmware 1.21 it's hard to be sure.

[rootboy]

I set that up in the web-based config tool. From config.g:

M552 P192.168.1.20 S1 ; Enable network and set IP address

In other news, I've got some ferrite chokes coming:

https://www.amazon.com/gp/product/B016X ... UTF8&psc=1

One of them ought to fit...

I also got my USB isolator in today. With it installed, the PanelDue won't boot up properly without turning the power on to the printer. But it's not like I'm going to get very far without the power being on anyways.

I could try a separate Ethernet card I suppose.

[rootboy]

Oh, and I am running my printer off of 13.8 volts. And other than playing havoc with the Duet's PID loop for the hotend, it works fine. I can drop that down if you think that's the problem (it shouldn't be).

[rootboy]

I went ahead and bought a PCI Ethernet card and a crossover adapter. Once it gets in, I'll give that a go.

I also disabled the Bluetooth adapter in my PC.

[dc42]

13.8V is no problem, the Duet can handle up to 25V.

[rootboy]

Sorry about not getting back sooner, but my FSR plate finally came in, as well as my new NIC.

Hopefully now that I have the Duet on its own network it won't disconnect on me. We'll see...

[rootboy]

Well, mostly good. The only dropouts that I got were after firmware uploads, those can be ignored. And I didn't have to power cycle the damn thing after a firmware upgrade. Finally.

But at the end of my first serious print since early March, the nozzle stopped at the end of the print and proceeded to melt into the print. The printer wouldn't home, so I hit the E-Stop to release it. I moved the arms away (too slowly, I had a clog to fix today) and noticed that I had lost communication. Nothing that I did last night and this morning would allow me to reconnect.

This evening I reformatted my card as FAT16 (it had been FAT32) and reloaded the very same files that I had copied off of the card prior to formatting it. That got it going again, but I'm having a hard time believing that really was the problem.

[dc42]

What commands do you have in your slicer end script?

[rootboy]

These are what MatterSlicer adds to the end of the slice, I don't have a separate script at the end of a print.

Code: Select all

; MatterSlice Completed Successfully
M104 S0 ; turn off temperature
M140 S0
G91
G1 Z5.0 E-3.5 F12000
G90
G28
M84     ; disable motors
; filament used = 23810.6
; filament used extruder 1 (mm) = 23810.6
; filament used extruder 2 (mm) = 0.0
; total print time (s) = 14881
; MatterControl - Experimental Version None.None.None Build 2.0.0.9637 : GCode settings used
; Date 04/04/2018 00:00:00 Time 0:35
; numberOfBottomLayers = 5
; numberOfPerimeters = 3
; raftExtraDistanceAroundPart = 5
; numberOfSkirtLoops = 2
; supportInterfaceLayers = 2
; numberOfTopLayers = 5
; numberOfBrimLoops = 5
; outsidePerimeterExtrusionWidth = 0.5
; outsidePerimeterSpeed = 30
; firstLayerSpeed = 15
; numberOfFirstLayers = 1
; raftPrintSpeed = 30
; topInfillSpeed = 35
; firstLayerExtrusionWidth = 0.65
; firstLayerThickness = 0.3
; extruderOffsets = [[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0],[0,0]]
; beforeToolchangeCode =
; endCode = M104 S0 ; turn off temperature\nM140 S0\nG91\nG1 Z5.0 E-3.5 F12000\nG90\nG28 \nM84     ; disable motors
; toolChangeCode =
; minimumTravelToCauseRetraction = 5
; retractionOnTravel = 3.8
; retractionZHop = 0.5
; unretractExtraExtrusion = 0
; retractRestartExtraTimeToApply = 0
; retractionSpeed = 100
; bridgeFanSpeedPercent = 100
; bridgeSpeed = 30
; firstLayerToAllowFan = 0
; extrusionMultiplier = 1
; infillStartingAngle = 45
; infillExtendIntoPerimeter = 0.15
; infillSpeed = 65
; infillType = GRID
; fanSpeedMaxPercent = 100
; minimumExtrusionBeforeRetraction = 0.5
; fanSpeedMinPercent = 0
; minimumPrintingSpeed = 7
; insidePerimetersSpeed = 50
; raftAirGap = .2
; raftFanSpeedPercent = 100
; retractionOnExtruderSwitch = 10
; unretractExtraOnExtruderSwitch = 0
; resetLongExtrusion = True
; skirtDistanceFromObject = 3
; minimumLayerTimeSeconds = 15
; supportAirGap = 0.6
; supportInfillStartingAngle = 45
; supportPercent = 50
; supportLineSpacing = 2.5
; supportMaterialSpeed = 40
; supportXYDistanceFromObject = 1
; supportType = LINES
; travelSpeed = 200
; wipeShieldDistanceFromObject = 0
; wipeTowerSize = 0
; zOffset = 0
; filamentDiameter = 1.75
; layerThickness = 0.2
; extrusionWidth = 0.5
; avoidCrossingPerimeters = True
; enableRaft = True
; outsidePerimetersFirst = False
; outputOnlyFirstLayer = False
; retractWhenChangingIslands = True
; generateSupport = False
; generateInternalSupport = True
; generateSupportPerimeter = True
; wipeAfterRetraction = False
; expandThinWalls = True
; MergeOverlappingLines = True
; fillThinGaps = True
; continuousSpiralOuterPerimeter = False
; startCode = ; automatic settings before start_gcode\nG21 ; set units to millimeters\nM107 ; fan off\nM190 S115 ; wait for bed temperature to be reached\nM104 T0 S235 ; start heating extruder 1\nT0 ; set the active extruder to 0\n; settings from start_gcode\nG28\n; automatic settings after start_gcode\nM109 T0 S235 ; wait for extruder 1 to reach temperature\nT0 ; set the active extruder to 0\nG90 ; use absolute coordinates\nG92 E0 ; reset the expected extruder position\nM82 ; use absolute distance for extrusion
; layerChangeCode = ; LAYER:[layer_num]
; infillPercent = 30
; perimeterStartEndOverlapRatio = 0.9
; skirtMinLength = 366.519153118134
; supportExtrusionPercent = 120
; raftExtruder = -1
; supportExtruder = 0
; supportInterfaceExtruder = 0

[dc42]

That ending code looks ok except that on some deltas, turning off the motors with M84 may allow the effector to drop so that the still-hot nozzle melts into the print. I suggest you leave out the M84. The motor current will be reduced to the idle value after 30 seconds of no movement anyway.

[rootboy]

It was the board resetting that caused that problem, the next print came out okay. I printed out a part this evening, and other than my Z axis stopping at a weird angle, it was fine.

However, I'm back to my board not connecting to Ethernet. I've reformatted the card, and then repartitioned it to a smaller partition size, and formatted it using 32k sector size. I also booted into linux and tried to run it from there. It would ping at first, but shortly after that it stopped pinging. I reformatted it to 64k sector size, changed antivirus programs, and tried Chrome, Firefox, and Explorer. No luck.

It's printing out using the touchscreen at the moment. Not what I was hoping for...

[dc42]

We get very few issues with connectivity on the Duet Ethernet. Have you tried a different Ethernet cable, and a different port on your router or switch? Are you certain that the IP address you assigned to the Duet isn't also being used by another device? If you've already checked those things then perhaps the Ethernet adapter on your board is faulty.

[rootboy]

I leave it on with just USB power while I'm away to see if it fails, and it died again while I was at work.

It's had two different Ethernet cables, and either your adapter or my NIC has automatic crossover because I don't have to use a crossover cable (which is nice).

It has its own dedicated NIC card, and it's set to a different network than the rest of the house. And I've used ipscan to look at the network after a failure (no duplicates).

It's pretty simple to detect a bad or disconnected SD card, go to the console screen and look to see if the system sees your network. If it's unplugged, you will just see a running time stamp and the word "Connected". Nothing else. (BTW, I can't tell you how many times I've popped the SD card out while trying to disconnect the Ethernet cable. This is why I know this). When it's plugged in and working, you will see your network. Non-Gcode (or I suppose a corrupted file) will knock out the network as well.

Curiously, the board says "Duet WiFi" on the bottom, but I'm assuming the only difference between the two boards is the network adapter.

I've tried it with and without the USB cable plugged in and unplugged. It doesn't seem to make a difference.

I'm installing Wireshark, we'll see what it comes up with...

[rootboy]

So I ran it last night with no problem, however the connection had dropped out by the time that I got home today. This is what WireShark shows more and more of near the end of the capture.:

The printer connected again without a reboot of the Duet, but wouldn't respond to commands for a few minutes. Operation seemed sluggish so I rebooted the Duet.

[rootboy]

It just did the lockup thing again (preceded by the click as it stopped), heaters stayed on, and the platform would not move, nor could I shut down the heaters. I turned off the power to allow me to move the hotend off of the part, but I left the USB plugged in.

I googled the problem and DC42 suggested sending a M122 command to the Duet, this is what it came back with:

Code: Select all

M122
=== Diagnostics ===
Used output buffers: 3 of 32 (9 max)
=== Platform ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21 running on Duet Ethernet 1.02 or later
Board ID: 08DGM-95BNL-MGPSJ-6JTD8-3SD6L-1KZMX
Static ram used: 16152
Dynamic ram used: 100336
Recycled dynamic ram: 2296
Stack ram used: 1224 current, 7792 maximum
Never used ram: 4496
Last reset 01:52:52 ago, cause: power up
Last software reset at 2018-04-11 21:26, reason: User, spinning module GCodes, available RAM 4456 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 17.7ms
MCU temperature: min 33.3, current 39.4, max 40.6
Supply voltage: min 1.4, current 13.6, max 13.8, under voltage events: 1, over voltage events: 0
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/1023
Driver 3: ok, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-04-12 22:17:28
Slowest main loop (seconds): 0.056392; fastest: 0.000046
=== Move ===
MaxReps: 2407, StepErrors: 0, LaErrors: 0, FreeDm: 236, MinFreeDm 120, MaxWait: 3923906852ms, Underruns: 0, 0
Scheduled moves: 82628, completed moves: 82627
Bed compensation in use: mesh
Bed probe heights: -0.402 -0.000 -0.406 -0.000 -0.194
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
Movement lock held by file
http is doing "G28" in state(s) 0
telnet is idle in state(s) 0
file is doing "G28" in state(s) 0
serial is idle in state(s) 0
aux is doing "G28" in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
=== Network ===
State: 5
HTTP sessions: 1 of 8
=== Expansion ===

About a minute later the printer did a few homing sequences and I was back in control.