Hi, again Roger.  Yeah, its hard to do remote diagnostics.  Now to your questions.
1)  4 + wires to Gecko positive terminals.
2) 12 wires...  4 to negative on Geckos, 4 to signal wire shields - at Gecko end only, 4 to stepper wire shields - at gecko end only.
3)  The breakout board is a PMDX 120.  Older model, now considered "legacy". It has its own mains power supply, the transformer in the lower left of the board.  It is driven directly from the Computer.
I removed the temporary earth strap, but there is still continuity from the Cap to chassis.  I don't know where. 
According to the manual the breakout board AND the Geckos both use optical isolation. 
It is on the floor, but accessible.  Looks nice but don't work so well...  I'm wondering if one of the components - BOB, Transformer, ?, could be shorting to ground...  I'll have to try checking.

Don

I removed the temporary earth strap, but there is still continuity from the Cap to chassis.  I don't know where. 

Just an observation but I think you should pursue this.

Tweakie.

I removed the temporary earth strap, but there is still continuity from the Cap to chassis.  I don't know where.

OH?? As Tweakie said, pursue this one. It might be rewarding.

>

According to the manual the breakout board AND the Geckos both use optical isolation. 

Nice. And good.

Cheers

I will.  It seems incorrect for there to be a short? or connection to ground that shouldn't be there.  I removed the connector blocks from the Geckos, and then checked from their pins to ground.  The short is not there.  I'll start disconnecting things and testing untill I find something.  Thanks, Don

I've been busy.  I did find that the A-axis gecko exhibits a continuity from the negative power input to chassis.  None of the others does.  Hmmm. 
I removed ALL the wiring for everything and hooked up only the X axis.  I set the gecko and the PMDX BOB to 0V common.  I hooked up only the x-axis signal wires.  I hooked up only the + and - power wires to the x-axis gecko.  I hooked up only the x-axis motor.  There, very simple.  No shields hooked up, just the wiring for the one drive.  I have noticed that the computer MOBO has parallel port shield to chassis continuity, but that doesn't surprise me. 
Result?  Offsetting behavior.  .005" in 50 repititions of the diagonal program.  I started hooking up shields to the power supply negative terminal, all to no avail.  I tried playing with the step and Dir timing in Motor Tuning, trying values from 0 to 15 us but that had no affect either.
I tried to run the x-axis only program and it offsets the same .005" per 50 repetitions also.
This also occurs with my cheater cable feeding the gecko signals directly from the Parallel port.  So, I'm pretty sure the PMDX BOB is not causing any of this. 
With only one axis hooked up, where could the problem be. 

OK, so even with just one axis hooked up you are seeing the creep. I make the creep 0.0001" per cycle, right? Just possibly that is the resolution of your axis?

I am now 99% convinced that this is a bug in how Mach handles multi-axis moves, at least with the Gecko drives. Changing the Dir signal is causing a change in the state of the Step signal which is effectively injecting a single step. The consistency of your results precludes random noise imho.

Checks to run:
1) Verify that this produces the same amount of creep despite having moves of 0.25", 0.5" 0.75"...
2) Verify that N cycles produces a creep of N*0.0001", where N=50, 100, 150, 200 ...
3) Check to see what the single step resolution of your machine is.

If both of these produce positive results, then you have a good case for going to ArtSoft with the data and requesting a check of the code.

A further rather cunning test is as follows, and it assumes that your resolution is 0.0001". Repeat the 50 cycle test for 1.0000", 1.0001", 1.0002" ... See if there is any variation in the creep as you move through the single-step increments. What you will be trying to do here is to alter the state of the Step signal when Dir is flipped. This may or may not produce interesting results - hard to say at this stage.

Making your wiring really clean is worth doing of course, but it seems you really have two separate issues here.

cheers

Hi, Roger.  The steps per unit on my machine is 20000.  5 thread per inch ball screws.  1:2 reduction belt drives.  200 steps per revolution motors.  10 microstep settings on Gecko G212 drives.  Single step resolution of the machine is theoretically .00005"  of course the mechanicals aren't that precise.  My tests of "backlash" have shown about .0003" or so. 
I'm getting a consistent "overshoot" on the way back to Zero such that it returns beyond 0.000.  Each cycle seems to move the offset .0001".  Only by raising the number of iterations can I see it on my machine dials which are calibrated in .001" increments.  If I run the loop 50 times, I get .005 past zero. 100 times, I get .010 past zero.  etc.
I have set the system up with ONLY the x axis connected, the logic set to 0V common, ( so the parallel port can run the drive directly) and with or without the breakout board the result is the same.
I believe this computer is using the current lockdown version of Mach3.  The only thing common to this setup is the license key and the drive system.  I'll try to include a picture of the current setup with my cheater cable. 

Current setup with only the X axis hooked up.   

Single step resolution of the machine is theoretically .00005"  of course the mechanicals aren't that precise.  My tests of "backlash" have shown about .0003" or so.

One pulse at each reversal gives 2*0.00005" = 0.0001" per cycle. As predicted.

Each cycle seems to move the offset .0001".  Only by raising the number of iterations can I see it on my machine dials which are calibrated in .001" increments.  If I run the loop 50 times, I get .005 past zero. 100 times, I get .010 past zero.  etc.

If this applies to 150 iterations and 200 iterations, we have a software bug - or a strange interaction between Mach3 and Gecko. I favour the plain SW bug.

Document fully and report to ArtSoft.

Cheers

I just ran some more tests. Changing line 5 from G1x+.1 to G1x-.1 does not change the direction of the offset.  it still moves +.
+.005 in 50 repetitions.
+.010 in 100 reps.
I set the line 5 to read G1X+.00005 and ran the program with the loop set for 100 reps.  No movement was detected at all.  None!.
I set the line 5 for X+.00010 and 100 reps yields +.010 offset.
Set for x-.00010 yields the same +.010 offset.  Hmmm.
Now for the wierd one.
I set the line 5 to read G1X+.00015 and ran the 100 reps.  the offset looked like almost .0110"!!!
So I ran it again and again - a total of 10 times.  Offset is .110 total.
When it runs the program, the movement sounds sort of stuttery, unlike when it is actually moving some distance.