UCCNC does not execute G-code files.

[LBayZG]

To A_Camera. Yes I do have an oscilloscope, but it's currently loaned out to a friend. It will take a few days to get it back.
From what I can remember while I was developing my CNC controller, the 12v power supply was stable, but it certainly cannot hurt to re-check it.
The current 12v power supply is capable of 75 Watts. That means it can supply 6 amps.

To CT63. There is no 'analysis paralysis' as you call it. I am first focussing my efforts on all avenues which are simple to do, and do not require any additional capital expenditures.
"Trying a different power supply... only takes a few minute..." is not as easy as you may think. I would need to purchase (mail order) a new 12v power supply.
That takes time, and more importantly - money.

Neither is it a simple matter of hooking up to my 24v power supply. That voltage exceeds the design limits of my limit-sensor buffer circuits and my charge-pump control circuits. Doing so would burn them out. And then I'm spending another whack of money, not to mention needing more time to rebuild.

Before I go rushing off to spend money, I will wait for the return of my oscilloscope and check the output of the power supply.

Further - I am not 'jumping' between laptop and desktop. I am comparing two machines and how they differ in their interaction with the UCCNC.
Yes, the laptop works, but it is totally unacceptable as my permanent controller. I must get the desktop machine working correctly.

Right now, I have reduced everything to two setups. The laptop hardwired (it works) and the desktop hardwired (does not execute g-code).
Comparing the differences between the two, and focussing on those differences can help illuminate what the problem is.

You mentioned something about "statistics monitor located profiles page" and "check communicative loop latency".
Now you are making assumptions. I don't know what you are referring to or how to check this.
Some instructions would be appreciated.

[ger21]

For $10 you can get one of these to power the UC400.
http://www.ebay.com/itm/Power-Supply-Ad ... Swa~BYdqf3

You don't have to change anything in your system. Just remove the 12V supply wires from the UC400.

[cncdrive]

To check the Loop latency is a good idea, I should have say to check that in the first place.
I'm attaching a picture so you can see where you can find that window.
Press the Yellow Statistics button to see the communication loop latency graph.

The graph shows how the high priority communication loop of the UCCNC is going on the PC,
if this shows high values, out of the max. 20msec range then that is a problem.

[CT63]

Ok... Let's try this again.

You already have a 24v power supply running the steppers. Nothing to buy. Disconnect the 12v supply from the ETH400 and tap off the 24v ps only to the ETH400. Leave the stepper driver connected to the 24v too. Leave the other home build electronics on the 12v ps. Now the ETH400 and steppers are isolated from the other components. Try running the machine and see if you still have the lag problems.

The other thing is connect the two DC ps commons (-) together then to a solid ground. Right now you have two ps (12v & 24) isolated from each other and the DC outputs can "float" and be operating at different 0V levels. This can induce harmonics and ground loop currents that lead to strange problems. I've seen this many times on industrial PLC control systems. It's standard practice on industrial control panels with more that two ps's to always connect dc supply commons (or the neg terminal) together. This is a hard concept for non electrical people to grasp.

Open UCCNC ---> Configuration ---> Profiles
Look for the yellow "Statistics" button. Click on it and it will open up a graphics window that will show the communication loop latency timing. It should be fairly consistent and near 0 ms to probably not more than 10ms max. If you are getting large spikes or flat line dwells something is messing up the communications string.

[CT63]

Another thought...

If the laptop works ok but the desktop isn't, the only other difference is the laptop isn't electrically grounded while the desktop is grounded. By that I mean the laptop power supply is isolated from ground. Could be the Ethernet cable is carrying a ground loop from the desktop through ETH400 and 12v PS. Easy fix is ground the power supplies as I mentioned in the last posting.

[LBayZG]

To CT63:
As a matter of fact, I am one of those 'electrical people'. When you alluded to ground loops, I could only slap myself for not thinking of that.

1) I tied the two power supply grounds together. This did not make any difference.

2) Next, after careful review, I figured that I was able to power the UC400ETH directly off of the 24 v power supply. Since it's only output is at 5v, I could leave everything else unchanged.
This too did not make any difference.

3) Your second note mentions that the laptop has a floating ground. This made me remember that the desktop and the network switches are powered through a UPS.
I will scrounge up an extension cord and see if I can power the CNC from that same UPS, so at least is shares a ground with the desktop. The UPS should have enough VA to carry the extra load.

I will keep you posted.

PS: Now that I know about it, I have been checking the loop latency through all of these tests.
So far it pegs at the top of the display (~20ms) for every single action performed by the desktop, whether running the test file or doing simple jogging.
Common ground and 24v changes notwithstanding.

[LBayZG]

Okay, I did the test.

CNC and desktop both running from the same UPS.
UC400ETH is powered at 24v.
Grounds tied together on the two power supplies.
Desktop and CNC are directly connected to each other using a crossover cable. No network switches.

There was no change.

Observations:

When I run the test program, the latency pegs at the top of the display, at 20ms and stays there until the code has finished executing.
When the code finished executing (eg: it reaches the end) the latency instantly drops back down to a very small value.
The tool starts moving at the moment the latency drops down.

[LBayZG]

I am including a snapshot of the latency status that shows after I start running the test file.

[ger21]

Here's what mine looks like with g-code running.

[LBayZG]

So the question is, what could be causing my computer to experience such large delays.

Is it my computer, the UC400ETH, or some synergy between the two?
Or perhaps this is not the 'smoking gun', but just a red herring.