UCCNC does not execute G-code files.

[cncdrive]

That is very strange with your PC, I mean that it is doing the same unexpected things with the direct connection.
Honestly I don't know what can possible cause such issues, but will ask my collegue tomorrow about what tests could we make to verify what the problem is.
I have one idea for now is the power supply you using, what is the voltage on it? can you please verify with measuring if it has a constant 12 to 24Volts. (I don't know what voltage one you using).
I mean I remember a case when somebody used an 5V powersupply accidentally on the UC400ETH and had some similar strange things happened and that was because the 5V input voltage is not enough, it produces a too low voltage for the ethernet controller chip to work correctly, a low enough voltage to make it work erratic, but high enough that it still works to some level and the sympton was lost packets and strange happenings.

About your laptop: That's understandable that the connection can be unreliable with Wifi connection, generally we advice to avoid using Wifi, because it may not work reliably.
If you connect via direct cable connection instead of the wifi and if you run the Utility tool of the UCCNC and scan then does it see your UC400ETH controller?
If it does not see the controller then you have a physical connection problem or the LAN card in the laptop is not working at all (e.g. LAN card drivers are not installed or the device is disabled),
because the Utility tool communicates with the devices with sending out broadcast messages which means that all network devices must receive those messages, no matter where they are located on the network.
If the UCCNC saoftware can't communicate with the device is different and that also depends on if the network settings are correct, but not the utility tool, because as mentioned that sends broadcast messages,
so it must find your device if your network card is working and if the physical connection is OK.
So, the first thing to do is to check if the Utility tool sees your device or not, if not then check if your LAN card in the laptop is even working and verify if you using the correct cable for the connection and if it is connected correctly.

When you get the Utility tool to find your device then it will be time to check the connection parameters with pressing the Test connection button and see if it gives any error.
If there is an error then you should check what it is and make the LAN settings in the network card and the UC400ETH to match.
If that is also working then the connection should be working and then also make sure you have installed (copied) the license key file to the UCCNC folder and then run the UCCNC and then it should find and connect to your UC400ETH.

[LBayZG]

1) Here are the voltages.

12.13 v at the power supply terminals. The power supply is a Mean-Well SDR-75-12. Capable of 75 watts at 12 volts.
12.12 v at the UC400ETH power input.
12.11 v at the HDBB2 power inputs (pin35).
11.83 v Vout from pin 38 of the HDBB2. (I use this to power my Charge Pump / E-stop circuits and LEDs. This controls a DC SSR which turns on power to the stepper drivers.)

All voltages seem stable on my voltmeter.
I tried measuring the ripple using the AC voltmeter setting - but that was 0 v.

My voltmeter is a Fluke 117, which should be a quality instrument. Its calibration is not 'certified', so it might be off by a few millivolts.

2) I have managed to get my laptop working with a direct connection (instead of wireless). Even with the same configuration, it seems to move the machine much more slowly than my desktop does.

3) This leads me to consider one obvious difference between the two machines. The CPU clock rate.
a) The laptop, which does work correctly and does move the tool according to the G-code, hass an i7-2630QM running at 2.00 GHz.
b) the desktop, which does not work except for jogging, has an i7-2600 running at 3.40 GHz.

Could it be my CPU is running too fast? Affecting timing loops in the software.

I say this because when jogging, the desktop PC moves the tool 2-3 times faster than the same jogging commands issued by the laptop.
You already have both profiles, you know both machines are running the same identical configuration.

[A_Camera]

Your PC is not too fast. You can't have a too fast PC.

[CT63]

Seems the only common element is the 12vDC power supply. As it is your voltage readings are marginal at best. Try a 24V supply or if the 12v supply has a voltage trim pot try turning it up higher.

[LBayZG]

You misunderstood my message about my voltage readings.
The 12v power supply is strictly for the controlling electronics.
- The UC400ETH controller.
- The HDBB2 breakout board.
- My own buffer circuits, for the limit sensors and the charge-pump/e-stop controls.
All of these are designed to run at 12 volts.

The M542 stepper drivers have their own separate 24v power supply.
Since they are optically isolated from the control electronics, all is good.

[CT63]

Try connecting the ETH400 to the 24v power supply and see if that corrects the problem. Can't hurt. As I said, the only common component to both the laptop and desktop is the 12v power supply.

[LBayZG]

Actually, the UC400ETH runs on 5 volts. There is an internal voltage regulator which generates that from the supplied 12-24 volts.
Boosting the voltage to 24 volts might not 'hurt'. But neither will it do any 'better'.

Digital electronics is particular. If it were not getting enough power, then it would not work at all.
I certainly would not be getting it to perform the jogging that it does.

[ger21]

Boosting the voltage to 24 volts might not 'hurt'. But neither will it do any 'better'.

When you have an issue that nobody has ever seen, you don't know that.
I frequently see people on forums that can't get their machines to work, but seem to know what the problem isn't caused by. That's the wrong attitude to take, as what most people are "sure it's not the problem", is very often the problem.

[A_Camera]

Actually, the UC400ETH runs on 5 volts. There is an internal voltage regulator which generates that from the supplied 12-24 volts.
Boosting the voltage to 24 volts might not 'hurt'. But neither will it do any 'better'.

Digital electronics is particular. If it were not getting enough power, then it would not work at all.
I certainly would not be getting it to perform the jogging that it does.

You are right that there is an internal regulator, but it is not just about "getting enough power" it is also about the quality of it. While it may not help to increase the supply voltage, it may help to try another power supply source. Do you have access to an oscilloscope? If yes then you should check the quality of the incoming power. Even if the UC400 has an internal regulator I am pretty sure it requires clean 12-24VDC, or at least as clean as possible.

Right now nobody knows what the problem is, so we are all just guessing and checking the power supply or at least switching to another one, is a very simple and easy test and can definitely not hurt, it can only do better or no change, or making it worse if the new power supply is even worse.

[CT63]

I think the OP has a case of "analysis paralysis" and convinced himself what the problem can't be. Good troubleshooting is a process of elimination and everything is suspect until proven otherwise step by step. Trying a different power supply as I suggested, and only takes a few minute to do as A_Camera said. If nothing else it rules out the ps. Checking the AC component with a DVM on a dc switching power supply output is not a reliable test. Oscope is the only reliable way to check the dc voltage quality.

Another issue is the OP is jumping between laptop and desktop, between LAN, router & wireless. Too many variables in the mix. I would go with Ethernet hard wired from the desktop to the ETH400 only and try the 24vdc supply. Turn off Windows updates and antivirus programs running. Make sure Ethernet is setup right and talking to the 400. Open the statistics monitor located profiles page and check communicative loop latency.

Open task manager in Windows and see it something running in the background is eating up CPU time. Windows 7 update is known to hog CPU time and it's even worse in Windows 10.

The definition of insanity is doing the same things over and over and expecting different results.... A. Einstein