Posts made by deadwood83

Might be a bit presumptive to ask since I do not know the heart of DSF very well, but would these rates conceivably be different with an SBC at a future date?

I.e. is computational offload to SBC present/planned or will it remain as an alternative method of getting gcode to the board? Asking on behalf of my ~620step/mm extruder (duet 2).

Also, good information though maybe on the high side? my duet2 cannot run a btech bmg at 417.29 steps/mm at 128 microstepping with 30mm/s retracts without accruing ~600 hiccups over a 2 hour print.

Either way, this is some super good baseline information. Thanks.

@smoki3 it would still require traces back to the 24v input. Also, the coils used on those (and more often the B or C-lot mp1584) are intolerant of feedback on the 12/24v line. Not to mention the RF noise it generates and the extra heat to dissipate. When the fail, they fail open. If that overwhelmed the 3.3v stepdown on the pi it would probably damage the input buffers on the PCB; so then you're either doing micro soldering or putting on a whole new daughterboard just to avoid running one tap from the PSU and a dedicated 5V for the pi.. in addition to having to buy a new pi.

Add that to quadrupling the PCB cost due to needing to stretch all the way back to the inputs and suddenly that mod costs Pi+PCB+Time+Risk to damaging mainboard. Add a voltage regulator after the input and the PCB SMT cost skyrockets due to small quantity. It's just not worth it and defeats the tiny form factor. One of my goals was to give people an option to add SBC support without having to redesign mainboard housings.

In comparison, a 50W Meanwell 5V supply is ~USD $13 and includes a meshed RF-blocking shell (for the high frequencies that could interfere with comms); voltage regulation; transient handling; and is not exposed to feedback spikes from, say, a ceramic-potted heater cartridge.

The design is fully open source. I won't ever put a cheap digital buck, but nothing stopping you from dipping a toe into PCB creation and doing it yourself. That's how I got started, and I highly recommend it. It's pretty fun!

My 5v PSU and USB-C hookup should be here Wednesday. Kudos to the firmware team for the excellent work on the Duet2 SBC support. I have not been able to derive a synthetic test which causes it to fail where standalone does not. I still have 4 PCBs I am willing to send at the cost of postage to homes in the continental USA.

Dry run looks super promising. I goofed though and realized I do not have any 24->5V USB-C power delivery units.

Now I need to build out a male-male harness, throw this on my delta, solder a second board to the delta duet, and try a real run.

Have you ever had a DHL driver scream at you then throw a package at your face while shouting "Social distancing?"

Yeah, me either. They do leave things at my door and run away though. Jumper for scale.

Look at those tiny resistors. Aren't they cute? you could accidentally desolder them with an intense gaze. I'm going to do just that to R1 and at least once to an R2.

It's ALIIIIIVE!

It was the ESP all along. One of the diodes (too small to see?) along the edge with GND and CS had fractured solder.

Guess I could have baked it, but honestly not worth the effort when an ESP-07s is available.

I think I now have the confidence to try replacing the E1 driver on my 1.02 board if I ever take it out of the DLP printer.

@GeorgeM You 100% need an M575 in the config and you need to set the baud on the BTT panel to 57600

source: running a TFT35V2 on one of my Duets

@arhi

There is a PCB in the EasyEDA link which is closed off and with through-holes for the ethernet board for those who want to just stick on some headers and go. The components are low-profile so it will fit top or bottom.

The only things you would need to add are 5v buck and some LEDs. Look in the EasyEDA project for ethernetPCB and you will find it there, ready for you.

@arhi said in Duet 2 Ethernet and SBC:

@deadwood83 said in Duet 2 Ethernet and SBC:

The schematics/PCB

awesome thanks
Did you made this in kicad and exported to easyeda or you made it directly in easyeda. I can redraw it in kicad but if you already have it in kicad it would save me some time

I made it in EasyEDA. I keep trying to go to KiCAD but snap to grid just... drives me completely insane. I wager that will become pretty much mandatory once I graduate beyond 2-layer.

@smoki3 said in Duet 2 Ethernet and SBC:

@deadwood83 Cool design. I use a would use a similar one but with an integrated 5V DCDC converter to power the raspberry. Otherwise you need an external one which is not so pretty and easy to use.

I also integrated the same pin layout as on the raspberry to use a simple ribbon cable.

But actually the firmware is the first thing which need to be fixed

I fear that any buck which would fit on a reasonable sized board would not be up to snuff. I have seen LMs and MP bucks burn Pi's faaaar too many times to feel comfortable putting one in one of my designs. Also, when you put power to the pi through GPIO it is my understanding that it bypasses a significant section of input protection. I will stick to $10 10A converters. Much safer to run 10-30% of a very cheap piece of kit's rating IMO when it has questionable pedigree.

RE: Ribbon cable; My personal preference is to twist MISO/MOSI lines from individual conductors. CS has a buffer resistor near the node end (and doesn't have the sensitivity of the other 3) and 3v3_Pi isn't near the SPI pins anyway. Plus anybody soldering to a 3d printer controller probably has some dupont connectors #DiabloEternal

RE: Firmware fix; from the RF3.2 excel spreadsheet -
Duet+SBC support
Duet 2 SBC support Done

@PCR said in Duet 2 Ethernet and SBC:

@deadwood83 Wrote you a PM

Replied

@bearer said in Duet 2 Ethernet and SBC:

@deadwood83 said in Duet 2 Ethernet and SBC:

2 layer FR4 1.6mm 1-Oz copper PCB

4 layer and 2 Oz for the Duets

Understood, my impedance calcs were based on my cheap PCB though. I am not worried about the Duet circuitry since it comes from more capable designers than I

@T3P3Tony said in Duet 2 Ethernet and SBC:

@deadwood83 R100,R101,R105 on the SPI lines on the Duet 2 side are 47R. There are relatively short lines from those resistors to the relevant pins. External copper is 2Oz and these are 0.25mm traces. internal solder is 1Oz, same trace width.

Where we use those buffers on the Duet 3 we don't have series resistors in the circuit as well as the buffers so the 470R is probably unnecessary

Thanks Tony. I have updated my PCB layout to remove that and will put a simple solder bridge once my PCBs arrive. Being 0403 size, it could probably be bridged with a c-store lighter! (I will use my T12 station)

I think I may have messed up in my design.

@T3P3Tony I have a question about the SBC conn on the duet 3 v1.01. On my little breakout I put a 470-Ohm in series with the input buffers on SCLK and only just realized (after ordering some) that your placement of the 470 was NOT on the clock line but rather on PC23/IO_7_OUT. Looking at TI's guidelines for matching a series damping resistor: https://www.ti.com/lit/an/scba012a/scba012a.pdf

Assuming worst-case scenario, at max output current for the SN74LVG2G34 (12mA) we get Irms of ~8mA

Using PCBWay's trace impedance tool shows a line impedance of roughly 105-Ohm for 2 layer FR4 1.6mm 1-Oz copper PCB using the trace width of .61mm

My worry is that the 470-Ohm resistor will provide too much dampening and round off the waveform peaks too much since SCK on the daughterboard lives at the termination rather than origination (or could this be considered the origination due to the amount of PCB the signal must travel?). Do you think this is a valid worry, or should it be OK with the resistor there at the current speed of 8MHz?

Considering other solutions to this point involved some wires with crimped/socketed resistors, and one instance of a breadboard, am I just overthinking it now?

That right there is an Azteeg X3 Pro. https://www.panucatt.com/Azteeg_X3_Pro_p/ax3pro.htm

Specifically, it is a clone of an Azteeg X3 Pro. The genuine boards have screw terminals where the clones have Molex 4-pin headers.

As others said, the expansion board should work but it is difficult to say what sort of cost/benefit ratio you would be looking at versus getting a replacement Azteeg and trying to figure out the firmware.

It is version agnostic. It is attached to the back of the board, so it works with both ethernet and wifi versions. No desoldering required, only attaching pins to the Pi header. I will publish the public EasyEDA links once I verify all my measurements in KiCad.

EDIT:
-Updated image to be proper scaling.
-Created non-hollow version with plated through-holes for ethernet users who want to stick it on the headers
-License is CERN open hardware, feel free to commercialize it if anybody feels so motivated.
-Strengthened top section, re-scaled text, verified clearance against paneldue header, extended bottom of board to index against duet mainboard.
-NO DESOLDERING NECESSARY
-Updated grounding to star/bus ground pattern

The schematics/PCB

I took the plunge.

I will keep 5 for me. The others can go to homes in the US at the cost of a flat rate envelope.

@bearer I think it would be much less intrusive to figure out a way to pull PE4 and PE5 low in firmware.

I poked around in the Duet3 designs and I see that someone (Tony?) had a great idea for v1.1.

Input buffers. With that in mind, I present version two! All parts available for SMT from JLC, incorporates the design guidelines laid out in the duet3, comes to $19.5USD per 10 (please note I am not selling these, this is the price from JLCPCB) (plus shipping). Sadly I did have to bump it to a dual layer PCB.

For V1.04 Duet Wifi, the CS/NPCS0 pin already has a 2k2 resistor. R2 can be bridged in that case.

Fixed the dims.

OK, here's my thinking on an easy way to connect SBC regardless of ethernet or wifi version.

The header on the side is a 2.54mm, could accept female or male, protrudes past the board edge and sits forward and next to the paneldue header. The adapter is soldered to the bottom in the same manner the ESP is attached to the top. It could also be mounted with pins through it.

Hole for plastic push-fitting to reinforce.

Relief is left for up to a 7mm diameter fastening post around the board mounting screw. Resistors are 470-Ohm.

Anything I am missing?

@bearer said in Diagnosing a failing ESP-12:

sbc worked a month or two ago when i last tried 3.2 and i saw dc42 posting preview beta links to troubleshoot issues in another thread so 3.2 shouldn't be too far off methinks.

edit: btw you don't need a pcb to make the ESP pluggable; won't be super sturdy though

buy some through hole 2.0mm 8-way headers (or 40 way to break apart). get the right angle female version and straight males. solder males into esp. fit female header onto already soldered male headers and trim leads to stay out if trouble when aligned onto the duet. tack down female headers while attached to esp and aligned to duet, remove esp and solder remaining leads. et viola! (a little fiddly, but doable)

Right, I get that. I was just thinking a way that could come pre-assembled (all smd done by JLC) and then with ~6 touches to a soldering iron you're done. Then you have your wifi and headers with inline resistors underneath running parallel to the board for connecting to an SBC if and when so desired. a bit of ribbon cable and presto. Keeps the clutter down. Then run parallel mp1584 bucks with LC filter to power the pi (if it's a 4B, 3b+ is OK with one). I did a similar setup in my duet powered resin 3d printer. That project looked simple in the brainstorming phase but got complex pretty quickly lol. Eventually I;d like to run that all on an MX8m board (putting motion control on the Cortex M4 core) with hat, but I have been writing the SPI control on the firmware and working a custom kernel for aaaaages. I'm awful at it.

@Veti said in Diagnosing a failing ESP-12:

@deadwood83 said in Diagnosing a failing ESP-12:

I was tempted to stick an in-wall HD ubiquiti AP in the printer room, but they're still almost 200USD. Wifi has worked for years.

a tp-link access point flashed to openwrt only costs a few bucks.

or a GL.iNet GL-MT300N-V2 very cheap and openwrt preinstalled

Had that exact setup with a TP-Link N-band router in that room running OpenWRT. Compared to Ubiquiti's system, it is fiddly at best. The signal advantage was ignored by most clients since the main AP had fewer 'hops'.

UBNT HD line with a controller (which I run in a VM on my server serving my wireless VLAN) has not only band steering but AP steering. The real draw is not just the wifi but the low-profile with PoE from my main PoE switch (600W of 802.11at) and a 4 port VLAN-capable integrated switch with PoE pass-through. Oh and all the whole remote monitoring and automated config backups, centralized stats into my analytics VM, etc. Would also make cameras a lot more stable and reduce load on that section of my breaker box.

Heck, after typing that paragraph I bought one. I guess for the price of a new duet I can now convert at least 3 of my machines to ethernet if I so desire.... I think I will get better reception on my toilet as well. Lots of piping, high amperage wiring, and tiling between my throne and current AP.

The experts do not believe self-regulation would be sufficient without oversight. The new regulatory body could be organized by existing licensing organizations such as the UK Copyright Hub, National Copyright Administration of China, the UK Intellectual Property Office, the Copyright Tribunal, or Information Commissioners Office.

Dr. Griffin said: "Digital watermarking and 3-D printed products present a future where objects can be searched for with nothing more than the equivalent of a Google search word. 3-D printing and digital watermarking specifically has not been considered by any government or regulatory body, nor has there been any regulatory research carried out on the matter. Our proposals help to ensure the protection of individual privacy in an increasingly digitized world."

"Oh noes! Someone's gonna print my thing and I'm not gonna get paid for it!"

The only other thing I can imagine from that article, which had quite a few glaring typos such as:

Legally governing 3-D printing is not straightforward as the underlying technologies are so precise. With 4-D printing objects print themselves and the use of augmented and virtual reality allows for enhanced tracking.

What? So someone in biomed 3d prints me some new arteries for some reason and they get installed. They propose all the tracking with copyright orgs so that the design of my arteries is protected?

Lol no. They want to have a formal way to sue the pants off amateur CAD designers for infringing copyright / patents whether intentionally or not.

. . . a new voluntary code of conduct to protect people's privacy, and a regulatory body to provide guidance and oversight.

Oh yeah, a regulatory body to just provide guidance and oversight. Right up until the lobbyists walk into parliament offices / congress. The pandering is not subtle.

Not sure if this paper is "I need to keep my tenure" or "please hire me away from this University"

Some more goodies:

. . . to trace, track and observe objects, which can reveal an incredible amount of information about the users of such content."

Oh yeah, good point. Like being seen using an Adroid phone? Or wearing Airpods? Or the carrier branding on your phone's exterior? How about the information your personal transport provides about you? Brand names on clothes? What about the home you live in?

The experts carried out 30 in-depth interviews with representatives from Chinese 3-D printing companies.

Mmhm. Best to consult the experts when it comes to privacy issues / tracking / intellectual property rights.

The article is kind of gross. The linked article gives it all away:

Academics will analyse what the impact of this system would be on copyright law. Credit: Shutterstock

So this article is a remix of another article which is itself a follow-up to a third article. That's quality content right there.

Well. I figured it would be best to know sooner rather than later if I would need a new board.
KSGER 2.1s station with medium chisel and some genuine dry-aged RadioShack 2mm solder wick from pre-2011.

All the pads are there! I think all the SMD components as well. ESP-07s is on order. I'll clean the flux and prep for the transplant.

I was tempted to stick an in-wall HD ubiquiti AP in the printer room, but they're still almost 200USD. Wifi has worked for years.

I wonder what jlcpcb would charge to make some daughterboards to solder to the bottom/ethernet pins similarly to the ESP. I saw that SBC support for duet wifi was on the 3.2 roadmap....

Swapping a pi is a lot easier than desoldering ESPs.

Is there a good way to do this without a frequency analyzer/o-scope?

I got one of my printers back up and (mechanically) running but something seriously funky is happening with the wifi.

First of all, yes, this is out of warranty. My FIlastruder ship date for this particular board was May 21, 2018.

Hoping to confirm it's just the ESP taking a dump since my fat fingers have the best chance of desoldering that compared to the SAM8 chip.

Board boots, all LEDs light up, and the wifi connects. M122 from Pronterface doesn't show any errors, and the networking section reports an IP, etc.

Running RRF3.1.1 and WIfi server 1.23 the same as my 4 other Duet Wifi boards. I can see the IP assigned in Windows Server DHCP, I can run an nslookup on it, sometimes it returns pings, and I even got into the FTP once. However; DWC never loads, it's dropping packets like mad, I've been through three different SD cards and run an M997 S1 about 20 times today. I'd really prefer not to order another board with the mini 3 seeming so close.

Do the details below suggest that I might just be able to swap the ESP, reflash the wifi server, and get another couple years from the board? The latency on the pings is all over the map. Log from the duet attached. Three other duets live in the same room with a wyze cam, and none of the other three are exhibiting the same issue.

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.[duetLog.txt](/assets/uploads/files/1599877358830-duetlog.txt) 
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Reply from 10.10.30.23: bytes=32 time=61ms TTL=254
Reply from 10.10.30.23: bytes=32 time=213ms TTL=254
Request timed out.
Request timed out.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 61ms, Maximum = 213ms, Average = 137ms

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Reply from 10.10.30.23: bytes=32 time=689ms TTL=254
Request timed out.
Reply from 10.10.30.23: bytes=32 time=978ms TTL=254
Reply from 10.10.30.23: bytes=32 time=46ms TTL=254

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 46ms, Maximum = 978ms, Average = 571ms

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 10.10.20.1: Destination host unreachable.
Reply from 10.10.20.1: Destination host unreachable.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Reply from 10.10.20.1: Destination host unreachable.
Reply from 10.10.30.23: bytes=32 time=824ms TTL=254
Request timed out.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 824ms, Maximum = 824ms, Average = 824ms

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Reply from 10.10.30.23: bytes=32 time=59ms TTL=254
Reply from 10.10.30.23: bytes=32 time=62ms TTL=254
Reply from 10.10.30.23: bytes=32 time=2ms TTL=254
Reply from 10.10.30.23: bytes=32 time=18ms TTL=254

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 62ms, Average = 35ms

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Reply from 10.10.30.23: bytes=32 time=249ms TTL=254
Reply from 10.10.30.23: bytes=32 time=60ms TTL=254
Reply from 10.10.30.23: bytes=32 time=12ms TTL=254
Reply from 10.10.30.23: bytes=32 time=83ms TTL=254

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 249ms, Average = 101ms

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Reply from 10.10.30.23: bytes=32 time=328ms TTL=254
Request timed out.
Request timed out.
Reply from 10.10.20.1: Destination host unreachable.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
    Minimum = 328ms, Maximum = 328ms, Average = 328ms

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Reply from 10.10.30.23: bytes=32 time=25ms TTL=254
Reply from 10.10.30.23: bytes=32 time=227ms TTL=254
Reply from 10.10.30.23: bytes=32 time=23ms TTL=254

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 227ms, Average = 91ms

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 10.10.20.1: Destination host unreachable.
Reply from 10.10.20.1: Destination host unreachable.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),

C:\Users\Phil>ping 10.10.30.23

Pinging 10.10.30.23 with 32 bytes of data:
Reply from 10.10.20.1: Destination host unreachable.
Reply from 10.10.20.1: Destination host unreachable.
Reply from 10.10.20.1: Destination host unreachable.
Reply from 10.10.20.1: Destination host unreachable.

Ping statistics for 10.10.30.23:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Also, if replacing the ESP, is desoldering the only method, or can I use some flush cutters to remove majority of the ESP pcb and desolder the pads separately so I can work one side at a time?duetLog.txt

You're a wizard. That solved everything. It is now flying as I would expect it to!

Thank you so much for the second set of eyes.

I am trying to move away from S3D (no development) and Cura (slow, unstable) into Prusa Slicer.

While tuning my newest printer with Duet Wifi, I have noticed that there is a definite pause when the printer is performing a firmware retract. I have no such pauses with retracts baked into the gcode using slicer parameters. I can't seem to find any information on this on the forum, but perhaps I am using the incorrect search terms.

Please find M122 output, config.g, and gcode below as well as a video showing the issue. The first pause happens at ~41 seconds.

https://youtu.be/SvlKPNYZXGg

M122:

8/18/2020, 6:27:40 PM 	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later
Board ID: 0JD0M-9K662-MG5TD-6J9D6-3SJ6S-1ALLX
Used output buffers: 3 of 24 (16 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 94300 of which 44 recycled
Exception stack ram used: 536
Never used ram: 8212
Tasks: NETWORK(ready,708) HEAT(blocked,1224) MAIN(running,1552) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:33:28 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 8420 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04417000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 8
MCU temperature: min 40.5, current 42.2, max 42.5
Supply voltage: min 23.6, current 23.8, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/225
Driver 2: standstill, SG min/max not available
Driver 3: ok, SG min/max 0/299
Driver 4: standstill, SG min/max not available
Date/time: 2020-08-18 18:27:39
Cache data hit count 3373496550
Slowest loop: 29.67ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 11.1ms, write time 4.5ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 156, MinFreeDm: 128, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 6147, completed moves: 6131, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: 3
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X142.985 Y144.775 E0.01617" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 199.66ms; fastest: 0.09ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.23
WiFi MAC address 48:3f:da:4e:c4:bc
WiFi Vcc 3.37, reset reason Unknown
WiFi flash size 4194304, free heap 21912
WiFi IP address 10.10.30.28
WiFi signal strength -48dBm, reconnections 0, sleep mode modem
Socket states: 4 0 0 0 0 0 0 0

Config.g:

; Drives
M569 P0 S0                                     ; physical drive 0 (X) goes backwards 
M569 P1 S0                                     ; physical drive 1 (Y) goes backwards 
M569 P2 S0                                     ; physical drive 2 (Z) goes backwards 
M569 P3 S0                                     ; physical drive 3 (E0) goes backwards 
M569 P4 S0                                     ; physical drive 4 (E1) goes backwards 
M584 X0 Y1 Z2:4 E3                             ; set drive mapping for dual Z
M350 X16 Y16 Z16:16 E16 I1                     ; configure microstepping with interpolation
M906 X1275 Y1275 Z1150:1150 E1000 I30          ; set motor currents (mA) and motor idle factor in per cent
M92 X80 Y80 Z400:400 E413                      ; set steps per mm
M84 S30                                        ; Set idle timeout

; Speeds
M566 X900 Y900 Z600:600 E120                   ; set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z600:600 E7200              ; set maximum speeds (mm/min)
M201 X3500 Y3500 Z120:120 E10000               ; set accelerations (mm/s^2)
M204 P2500 T3500                               ; Set printing and travel accelerations (mm/s^2)

; Axis Limits
M208 X0 Y0 Z-5 S1                               ; set axis minima
M208 X300 Y300 Z325 S0                         ; set axis maxima

; Endstops
M574 X1 S1 P"!xstop"                           ; configure active-low endstop for low end on X via pin xstop
M574 Y2 S1 P"!ystop"                           ; configure active-low endstop for low end on Y via pin ystop
M574 Z1 S2                                     ; configure Z-probe endstop for low end on Z

; Z-Probe
M950 S0 C"exp.heater3"                              ; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H5 F100 T4000 A10 R0.5 S0.020 ; set Z probe type to bltouch and the dive height + speeds
G31 P500 X0 Y-42.8 Z.6                              ; set Z probe trigger value, offset and trigger height
M671 X-20:320 Y150:150 S5.0                         ; Define Z leadscrews on either side
M557 X0:300 Y0:257.2 S50                            ; define mesh grid

; Sensors
M308 S3 P"mcu-temp" Y"mcu-temp" A"MCU"         ; Create sensor for MCU temp
M308 S4 P"drivers" Y"drivers" A"TMC"           ; Create senhsor for drivers

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4092 ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0                          ; create bed heater output on bedheat and map it to sensor 0
M307 H0 B0 S1.00                               ; disable bang-bang mode for the bed heater and set PWM limit
M140 H0                                        ; map heated bed to heater 0
M143 H0 S120                                   ; set temperature limit for heater 0 to 120C
M308 S1 P"e0temp" Y"thermistor" T100000 B4092  ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1                           ; create nozzle heater output on e0heat and map it to sensor 1
M307 H1 B0 S1.00                               ; disable bang-bang mode for heater  and set PWM limit

; Fans
M950 F0 C"fan0" Q500                           ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1                                 ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"fan1" Q500                           ; create fan 1 on pin fan1 and set its frequency
M106 P1 S1 H1 T45                              ; set fan 1 value. Thermostatic control is turned on

; Virtual Fans used as Variables
M950 F2 C"duex.fan8"                           ; virtual fan on duex fan 8 pin
M106 P2 S0 C"vFan Homeall"                     ; set name for macro use

; Tools
M563 P0 S"Dragon" D0 H1 F0                     ; define tool 0
G10 P0 X0 Y0 Z0                                ; set tool 0 axis offsets
G10 P0 R0 S0                                   ; set initial tool 0 active and standby temperatures to 0C

; Firmware Retraction
M207 T0 S5.55 R0 F2400 T2400 Z0                ; firmware retract G10/G11 5.55mm at 40mm/s no z-hop

; Custom settings are not defined

; Miscellaneous
T0                                             ; select first tool
M575 P1 S1 B57600

M501                                           ; Load Config Overrides

gcode file is available here. I can't seem for the life of me to figure out why this is pausing. The slowness makes the retraction distance meaningless since the hotend has time to dribble filament anyway.

Any assistance is greatly appreciated.

Wizards, one and all. I knew I had to be missing something. I put a little pat of SuperLube on each balljoint and ran the test again.

6:27:06 AM
Stopped at height -0.172 mm
6:27:05 AM
Stopped at height -0.185 mm
6:27:03 AM
Stopped at height -0.166 mm
6:27:02 AM
Stopped at height -0.172 mm
6:27:01 AM
Stopped at height -0.166 mm
6:27:00 AM
Stopped at height -0.166 mm
6:26:58 AM
Stopped at height -0.166 mm
6:26:57 AM
Stopped at height -0.172 mm
Stopped at height -0.178 mm
Stopped at height -0.166 mm
6:26:56 AM
Stopped at height -0.172 mm
Stopped at height -0.178 mm
6:26:55 AM
M98 P"0:/macros/BLT Repeatability Test"
Stopped at height -0.172 mm

I still have a little bit of tweaking but that's very, very close to the mean error of .009mm

Thank you!