Hi, Dan
Nothing was connected to the D-sub 25 pin cable.  Just the voltmeter.  The plug is a male plug and plugs right into the parallel port.  I'll try measuring the voltage at the gecko terminal block while it is attempting to run...  Why would it work with the B.O.B. but not the Gecko?  Don

Don't know, Don, sounds like insufficient current. You will see it when you do the measuring. If the voltage drops noticeably when it is connected to the Gecko (probably to 2V or something) then you'll know the current is insufficient.

Dan 

Hi, Again Dan.  I still had the d-sub cheater cable hooked up from yesterday so I checked voltages at the Gecko terminals.
Voltage on Dir pin at computer startup goes to 4.8 V and stays there even after turning on the Gecko Power supply.  I started Mach3 and loaded the diagonal program.  While running, the voltage fluctuates between 4.3 and 4.8 volts on my meter.  I suspect slow meter response time...  I slowed the feedrate to F5 in the program, and now the fluctuation is from 4.6V to 4.9V on the direction pin of the gecko.  This being referenced from the com terminal.  I hope this is helpful in some way. 

Hi,again.  I was typing while you were posting.  Looks like insufficient current isn't the problem. But what could it be?
Don

Hmm... Don't know. The voltage should pull low - effectively 0V. Practically you'd measure something like 0.1V or lower.

I will give it a thought, but hopefully someone will chime in with an idea...

Dan

Hi everybody.  I installed the NetMos PCI parallel port card in the new Intel computer.  Installation went well.  Whew!  I'm not really a great computer geek, so these things sometimes worry me.

Voltage from the NetMos is +5 volts.  Duh!  A clue here.  My Geckos are set for +5V common!  No wonder they wouldn't run. 
I switched them over to 0V common, and hooked up my D-sub 25 cheater cable.  Now the machine runs.  But...
     Backwards.  Makes sense because of the direction polarity.  I switched it over in the motor outputs to get it right. 
      Errors...  The machine ran better than it had when running from the B.O.B. In 0v common mode.  However,  Both axes offset.  X axis +.005” and Y axis +.007 or so...Hmm.  I changed line 5 of the program to X-.1Y-.1 and ran the program.  Now X-axis returns to zero, but the Y axis is offsetting about .0025” each run of the program!
   Using 0V common, and no B.O.B. Changes the direction of the offsetting behavior, and introduces an apparent +.0025” offset per run of the program.

   I set everything back over to the LPT1 3.3V parallel port.  Geckos run...  with motor outputs page set for direction active low, the machine runs in the correct directions, but running the G1X+.1Y+.1 program, X axis offsets -.005” every time, but the Y axis offset has been irregular.  It seems to range from +.0075” to as much as +.0125 in the 50 iterations of the program!  Hmm.
   My brain is straining.  I realize that the irregularity may be coming from the same source that caused the machine to run jerky with the BOB set to 0v common, but I don't get why now with the machine going positive in both axes, the X axis consistently offsets -.005”  and the Y axis is offsetting + some amount more each run of the program.  I'm wondering if this is a noise issue as well as a program execution error.  Help would be appreciated.  Thanks for your continued support. 
Don

Don,

What happens if you swap the motor cables (running from the Geckos to the motors) of X and Y axes? Does the problem follows or still remains the same on same axes?

Dan

First of all, good electrical engineering practice would use 0 V as the common. Using +5 V (if I understand you correctly) is just not good practice. Possible, but unwise imho.

Now, the extra pulse at the end of every cycle, leading to a slow drift sometimes. Some thoughts:

When you move a single axis it is easy for the software, and my understanding is that you have no troubles here.

But when you move two axes at once with a G1 move, the software has to keep the two axes in sync. OK, it does this. But now consider what happens at the end of a pass, when you want to reverse the move. The software has to set things up for the two-axis sync again, in the other direction. Under these conditions it is possible for the software to reset the outputs and incur a single-pulse error on one axis. If you repeat this EXACT cycle you are going to get this single-pulse error every time - if it happens at all.

Note: this is a KNOWN PROBLEM in the CNC world.

Well, who is going to notice a single pulse? It's probably less than a micron or so. Ah, but what if you do this 100 times: the single pulses start to add up. Then you start to see an offset - sometimes.

OK: test this. Try cycling 1.000" 100 times on both axes and log the offset. Now try cycling 1.001" 100 times, and 1.002" and so on. See if the error comes and goes, depending on the EXACT measurement commanded. It will be interesting to see the results.

Cheers

Hi dan.  I will have to try that tomorrow.  Its getting toward 10:40 PM here in the Seattle ares and the kids bedrooms are right over the garage shop.  I don't want to wake them.   Are you suggesting that I swap the cheater cables from the parallel port to the drives?  I'll try that and report back.  Thanks for the suggestion.
Don

Hi, rcaffin.  I have tried 0V common and it runs terribly jerky with the breakout board.  Gecko suggested some years ago to use the +5V com. setting as it is supposed to reject noise better.  I'd like to know where the "noise" is coming from.  When I originally was having this problem I was using a move of 1.00 inches.  50 iterations of that took a long time, so I shortened up the distance.  I can see that if this was allowed to go on, a large part run might get ugly real fast.  Aren't computers supposed to do what they are told?  Don 
I'll try changing the program though to see if it has any effect.  Thanks for the suggestion.