That certainly took care of the Z axis scaling issue.
The other axis don't want to home, but I'll work on that tomorrow. I suspect that it now is in the code and easily resolved.
Thank you very much for your time and patience. Sorry for such an amateur mistake.

@Danal , @dc42 Please read on as I suspect that this situation might recur.

So I received a replacement board from MatterHackers and here's what happened:
Plugged the new board into the desktop via usb and it immediately recognized it as a Duet device and installed drivers. Huge relief.
As soon as the drivers were installed, the error message popped up about the "unrecognized USB device".
No problem, just short the jumper, push the reset, and it will be recognized, right??? NOPE!!!
All of a sudden I was reliving the exact same experience with the new board as the last one. Not recognized regardless of USB port, USB cable, or VIN power.
Tried it on the laptop and it recognized the port as Bossa, consistently. This was new. But every time I connected Bossa and tried to flash it, either Bossa locked up, threw an error message, or just refused the connection. But I was encouraged by the consistent recognition of the Bossa port by the Device Manager. Then I noticed that the laptop had had a pretty substantial windows update in the last couple of days, so it seemed appropriate to dig a little deeper.
Back to the desktop. Windows still didn't recognize anything, so I tried Opensuse. Tried putty, ssh, hardware recognition, and about 50 different commands that should have enumerated the Duet board as a tty device. Of course, nothing at all, no recognition, no active ports or devices, just... nothing.
I flashed an updated UEFI/bios, which seemed to have a bit of an effect. Meaning that it would occasionally, maybe 10% of the time, recognize the Bossa port.
So I started googling and reading blogs. Although they mostly consisted of more commands and diagnostics, one of the arduino blogs suggested moving the usb connection down by a level and running it off of a separate usb hub. This was kind of intriguing, first, because of both machines' different behavior after updating, and second, because I have always suspected that my desktop is just off a bit. It has a first generation Ryzen 7 CPU, and also what was a bleeding edge, first gen, X370 motherboard when I built it. But it always seemed to have weird USB issues, especially with the USB 3 integration, which was originally accomplisher by software, not hardware.
So I went to WalMart and bought the cheapest USB hub I could find, unpowered. Plugged it in, and I was able to flash both boards, the new one and the old “defective” one without a hitch. Also tried with the laptop, and after erasing the updated firmware, it also worked exactly as advertised.
All I can think of that there is a disconnect somewhere with the USB 3.0 protocol since this resolution worked across two very different machines, and the USB 3.0 seems to be the common denominator. Hopefully this will help someone else out, as it has taken a few weeks and probably over 300 attempts to get this ironed out.
Now that the board is functional, I’m sure that I’ll be hitting you guys up for help with something else. Thank you in advance…

@droftarts , rebooting without the card did restore some functionality in DWC but has led to a whole host of new errors.
@Danal , I have already configured my Pi with duetpi, but I suspect, after reading all of your information, that something has become corrupted by updating with the SD card in the Duet slot.
Tomorrow, I'll wipe everything and reload and see if that solves the problem.
Thank you both for the assist, I certainly appreciate it.

@droftarts Hi Ian, thank you for the pointers
I do not have any test macros, at least that I am aware of
I was totally unaware of the SD card thing, in fact, I thought that I had seen some contradictory information on other posts. Regardless, I'll remove it and retry.
As far as the connection, it seems like everything is communicating internally. I can putty into the Pi with no issues. The Pi also seems to be talking to the Duet, so I don't think that's the problem.
I'll report back in a few hours, the day has gone totally sideways on me
Thank you
Derek

I am getting odd error codes and have very limited communication via DWC on my 6HC
This is a corexy, custom built
6HC board, 3.01 beta 3 firmware, DWC 2.0.7
Raspberry Pi 4 running duetpi 4.19.97-v71+

The DWC is almost unusable. I can update system files, and the emergency stop functions. Nothing else does anything. The homing buttons, command line, tool, and heater buttons either do not function or start the “waiting” animation and just play it until I reset. It does seem like the temperature sensors are providing real time feedback, and correctly. The tool position is way off, by a factor of 10. Finally, it says that there are no fans, even though one is configured.
Upon rebooting, I am getting some really odd error messages, like the board is reading a config file from a different printer:
Error: M558 Pin ‘io4.in’ is not free
Error: G31 Invalid Z Probe index
Warning: M307: heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 365C.

My io4 is empty and not configured for any devices
I don’t see anything in the Z probe configuration that would be invalid
I have not yet successfully run any heaters

I am able to communicate with the board via a Paneldue 7. Sort of. If I use the self test functions, I get:

For the Test IR and PD Homing
Warning: Obsolete use of S parameter on G1 command. Use H parameter instead.

For the Test Fans
Error: M106: Fan number 1 not found Error: M106: Fan number 2 not found

If I try the Test Heaters, it gives me the same error as the Test Fans
These tests require that I trigger the X axis end stop. This too is a problem, if I push on it several times it sometimes recognizes that it has been triggered. Often, it does not, and the test just freezes right there.

The Test Motors leads to the motors running much faster than they should, and with no regard to the end stops. The printhead also moves diagonally for the x and y test, not linear
Entering commands directly into the Paneldue console sort of works, as it does accept most commands. Unfortunately, it gives very little output, especially on any diagnostic tests.
All of these diagnostic results also seem like they are from a different config file than mine.

I can, and have, successfully updated firmware and config files through the DWC. It will not update beyond my current firmware, but that appeared in a different post so it is hopefully an unrelated issue. I did have the board updated to the current firmware, 3.01 RC 2, with no change in this behavior.

The Pi is updated and upgraded almost daily

My config file:

; Configuration file for Duet 3 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2.1.8 on Thu Feb 13 2020 22:38:28 GMT-0700 (Mountain Standard Time)

; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"Duet 3" ; set printer name

M669 K1 ; select CoreXY mode

; Drives
M569 P0.0 S1 ; physical drive 0.0 goes forwards
M569 P0.1 S1 ; physical drive 0.1 goes forwards
M569 P0.2 S0 ; physical drive 0.2 goes backwards
M569 P0.3 S0 ; physical drive 0.3 goes backwards
M569 P0.4 S1 ; physical drive 0.4 goes forwards
M569 P0.5 S1 ; physical drive 0.5 goes forwards
M584 X0.0 Y0.1 Z0.2:0.3 E0.4:0.5 ; set drive mapping
M350 X16 Y16 Z16:16 E16:16 I1 ; configure microstepping with interpolation
M92 X200.00 Y200.00 Z400.00:400.00 E800.00:800.00 ; set steps per mm
M566 X2400.00 Y2400.00 Z120.00:120.00 E120.00:120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00:180.00 E1200.00:1200.00 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00:20.00 E250.00:250.00 ; set accelerations (mm/s^2)
M906 X1400 Y1400 Z700:700 E1200:1200 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X300 Y300 Z290 S0 ; set axis maxima

; Endstops
M574 X1 S1 P"io1.in" ; configure active-high endstop for low end on X via pin io1.in
M574 Y2 S1 P"io2.in" ; configure active-high endstop for high end on Y via pin io2.in
M574 Z1 S2 ; configure Z-probe endstop for low end on Z

; Z-Probe
M950 S0 C"io7.out" ; create servo pin 0 for BLTouch
M558 P9 C"^io7.in" H5 F100 T2000 ; set Z probe type to bltouch and the dive height + speeds
G31 P25 X35 Y0 Z0.53 ; set Z probe trigger value, offset and trigger height
M557 X15:215 Y15:195 S20 ; define mesh grid

; Heaters
M308 S0 P"temp0" Y"thermistor" T100000 B4000 ; configure sensor 0 as thermistor on pin temp0
M950 H0 C"out0" T0 ; create bed heater output on out0 and map it to sensor 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0 ; map heated bed to heater 0
M308 S1 P"temp1" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 1 as thermistor on pin temp1
M950 H1 C"out1" T1 ; create nozzle heater output on out1 and map it to sensor 1
M143 H1 S290 ; set temperature limit for heater 1 to 290C
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit
M308 S2 P"temp2" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 2 as thermistor on pin temp2
M950 H2 C"out2" T2 ; create nozzle heater output on out2 and map it to sensor 2
M143 H2 S290 ; set temperature limit for heater 2 to 290C
M307 H2 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit

; Fans
M950 F0 C"out7" Q500 ; create fan 0 on pin out7 and set its frequency
M106 P0 S1 H1:2 T45 ; set fan 0 value. Thermostatic control is turned on

; Tools
M563 P0 S"Tool 1" 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
M563 P1 S"Tool 2" D1 H2 F0 ; define tool 1
G10 P1 X0 Y0 Z0 ; set tool 1 axis offsets
G10 P1 R0 S0 ; set initial tool 1 active and standby temperatures to 0C

; Custom settings are not defined

@dc42, no other devices. I did try to flash it utilizing the Pi, but that didn't work either.

@Danal , @dc42 Please read on as I suspect that this situation might recur.

So I received a replacement board from MatterHackers and here's what happened:
Plugged the new board into the desktop via usb and it immediately recognized it as a Duet device and installed drivers. Huge relief.
As soon as the drivers were installed, the error message popped up about the "unrecognized USB device".
No problem, just short the jumper, push the reset, and it will be recognized, right??? NOPE!!!
All of a sudden I was reliving the exact same experience with the new board as the last one. Not recognized regardless of USB port, USB cable, or VIN power.
Tried it on the laptop and it recognized the port as Bossa, consistently. This was new. But every time I connected Bossa and tried to flash it, either Bossa locked up, threw an error message, or just refused the connection. But I was encouraged by the consistent recognition of the Bossa port by the Device Manager. Then I noticed that the laptop had had a pretty substantial windows update in the last couple of days, so it seemed appropriate to dig a little deeper.
Back to the desktop. Windows still didn't recognize anything, so I tried Opensuse. Tried putty, ssh, hardware recognition, and about 50 different commands that should have enumerated the Duet board as a tty device. Of course, nothing at all, no recognition, no active ports or devices, just... nothing.
I flashed an updated UEFI/bios, which seemed to have a bit of an effect. Meaning that it would occasionally, maybe 10% of the time, recognize the Bossa port.
So I started googling and reading blogs. Although they mostly consisted of more commands and diagnostics, one of the arduino blogs suggested moving the usb connection down by a level and running it off of a separate usb hub. This was kind of intriguing, first, because of both machines' different behavior after updating, and second, because I have always suspected that my desktop is just off a bit. It has a first generation Ryzen 7 CPU, and also what was a bleeding edge, first gen, X370 motherboard when I built it. But it always seemed to have weird USB issues, especially with the USB 3 integration, which was originally accomplisher by software, not hardware.
So I went to WalMart and bought the cheapest USB hub I could find, unpowered. Plugged it in, and I was able to flash both boards, the new one and the old “defective” one without a hitch. Also tried with the laptop, and after erasing the updated firmware, it also worked exactly as advertised.
All I can think of that there is a disconnect somewhere with the USB 3.0 protocol since this resolution worked across two very different machines, and the USB 3.0 seems to be the common denominator. Hopefully this will help someone else out, as it has taken a few weeks and probably over 300 attempts to get this ironed out.
Now that the board is functional, I’m sure that I’ll be hitting you guys up for help with something else. Thank you in advance…

I have now tried an additional 4 computers - one linux box, one mac, and two windows that are older OSs than mine. Still nothing recognized properly, so I'm afraid its time to move on.

@dc42 , I purchased this thru Matter Hackers, so I'm assuming warranty it thru them, or is there an alternate that you would prefer?

So I have been playing with this some more with no positive results, but some results nevertheless.
For the most part, the Linux Bossa just will not connect at all. Occasionally, it will say that it cannot connect to ttyACM0, which seems to be a recognition of the port. I just tried changing permissions via chmod a+rw /dev/ttyACM0. I am now getting an error message of " Device Unsupported".
I really appreciate everyone's time in this venture tremendously, @dc42 ,@Danal ,@bearer . If this is just wasting time at this point, I'm fine with the warranty. If there is something else to be done, or something to be learned, I'll keep plugging away as long as possible. I fly home tomorrow afternoon, and can try to replicate this from my desktop. The desktop; however, was initially a lot more reluctant to make any connection at all, so that also might be a dead end.

@dc42 , I'm going to keep trying for a bit, but ultimately, yes, the warranty may be necessary.
I did just try to connect through Bossa under Opensuse and it doesn't recognize any connections at all.
If there is any troubleshooting that can be accomplished more easily with a Linux box, I'd love to give it a try first

@dc42 , I wired up the transformer and connected it, tried to flash the firmware again. It's a 12v 2A wall wart. The Bossa port as identified by the Device Manager has configured itself for a much higher throughput - 115k instead of 9600, as it was on USB. I'm assuming that the autoconfigure got it right, 8 data bit, no parity, 1 stop bit, no flow control.
Same result as before, with USB power only. Bossa has been sitting at 0% complete for about 45 minutes at this point.

@dc42, I am currently traveling to my jobsites so I haven't had access to a power supply. I did borrow a transformer from a site today though, so I'll wire it up and try that method.

@bearer, I'm glad the pi came up clean. I upgraded the pi before anything else, so I can't answer the question.