Chip,

The attached spreadsheet has some details on the tests using your config files.  The MachCarl_Test_1.xml clearly performs the best.  When I set it to Exact Stop, it performed even better.  It looks like I need to stay around 10 IPM as anything higher starts to exaggerate the errors.  If I can get consistent runs with this configuration, it will be acceptable for what I'm doing right now which is only cosmetic for the gear crossings.  I cut the gear teeth by hand using a Carroll Dividing head.

Sage,

I swapped the Z driver cable with the X driver cable and it would not run.  I went into the config and swapped the ports for Z and X also.  I may need to put in a different resistor for the driver since my Z axis uses a Nema 24 and my X and Y use Nema 34s.  I moved the Z driver cable to the Y stepper and it moved in one direction but not the other.   Other than the resistor, I can't think of any other changes I would need to make.  Not sure what this means but it wasn't what I expected.

Best Regards.

Carl

I guess you're getting confused with all the suggestions from everyone.
What I suggested was to put Z in place of either  X or Y IN YOUR G-CODE.
Not to swap cables drivers ports etc.

If Z was moving in plce of one of X or Y and the table still ended up out of position in the remaining axis, it might say something about where the errors are generated. Software or hardware. I can't remember my initial line of reasoning. If nothing else it might reveal some new clues with minimal efort.

You might also try removing the configuration all together for either X oy Y so no pulses are actually generated and run the code to see if the remaining axis comes back to the proper position properly. If it passes it might indicate the software or something related is not able to generate pulses simltaneously properly for two axis or the parallel port miht be browning out with marginal signals becasue it can't produce pulses on two pins properly.

And then you might extend that a bit to configuring both axis back in and remove the electrical signal to one of the axis. If this works it might indicate the software is fine but there is some cross talk or confusion in the signals going to the drivers or out the cables.

Sorry for the confusion.

Sage

Sage,

Yes, I was definitely confused but your suggestion was a good one.  I ran the program with just the X-Axis connected (the y and z were disconnected at the breakout board.  I ran 6 tests and the X axis was very close with the respective runs showing 2, 2, 3, 3, 3, 3 on the dial indicator after each run.  So the X-Axis was repeatable.

When I did the same test for the Y-Axis, it was a little off but not by much showing 0, 1, 1, 2, 3.5, 4 on the dial indicator after each run. 

Looks like I will need to start hunting down interference problems.  Not sure how to do that so any suggestions would be greatly appreciated.

Thanks again for your help.

Best Regards.

Carl

So, if you are saying that it wasn't perfect for the remaining axis by removing the signals from the interface board then the problem must be back further i.e. a the parallel port or the software. (well actually it could still be mechanical but I don't think it would be progrssive if it was).
 You might try connecting everything back up and try the other suggestion of disabling one axis in the MACH3 configuration so it does not even generate pulses. I think the g-code should run anyway. I might be wrong on this.
 If it runs and the axis remaining does not have any errors then there could be something wrong with the parallel port or the ability of the sofware to activate it properly. Maybe something like the TTL logic and it's power supply on the parallel port gets messed up generating pulses on two drivers on the same chip - I know I'm grasping here but you obviously have a unique problem.
 I can't recall if you said you tried a different computer or even what computer you are using. I know some laptops (and even some desktops) have compromised versions of a parallel port hardware - at least by the old fashioned standards.

Just some suggestions.
 
Sage

I'm not sure this is even worth posting as it may just add more confusion to the equation but here goes. 

I moved the y output on the breakout board to another set of outputs for the step and dir pulses and ran a perfect test three separate times.  I did not have the z drive hooked up.

I then hooked up the z output to the original location of the y outputs on the breakout board and noticed that the Z drive had a progressive error.  However, the y and x axis were still corrrect which seemed odd to me based on previous testing.   I then moved the z ouput to some odd ports on the board but it would not run the stepper properly.  According to CNC4PC, it should work on the ports I'm using.

This appears to be where the problem is occuring.  When I did the original testing on the x and y axis, I did not have the z axis compeleted yet so did not realize there was a problem until after cutting my first gear crossing which included the z axis.

More testing tomorrow if I have time.

Best Regards.

Carl

Probably makes things a lot clearer. Did you ever hook direct missing out the BOB? Certainly sounds like another bad CNC4PC Opto problem
Hood

 Your description can be interpreted in a couple of ways (I think)

You wrote:
>>>I moved the y output on the breakout board to another set of outputs for the step and dir pulses and ran a perfect test three separate times.

Does this mean you moved the original BOB Y-axis circuitry to another parallel port output?
OR
You selected another complete path including software configuration, parallel port output AND BOB circuitry.

If the former then the BOB must be ok and the parallel port is at fault.
If the latter and you're using another parallel port AND BOB circuitry then it could be either of them at fault.


As Hood points out it is most likely the BOB and, as he suggested, it might make sense to bypass the BOB altogether and connect the drivers direct to the parallel port and be sure it works. If you really need the BOB (recommended for inputs at least) then systematically introduce it back maybe one axis at a time to see if and when it causes problems.

If you think the BOB ciruitry is bad for one axis then ONLY move that circuitry to be driven by something else. Not sure how much flexibility you have to do that but if the problem seems to follow the BOB circuitry then you have the problem. Alternately if the problem seems to move to whatever is being driven by a particular parallel port then that's likely the issue.

Sounds like you are on the right path. Keep testing. Follow the fault and determine what is common with each faulty configuration. Don't make huge changes and be thrown off by completlely new results (i.e. the Z-axis move to something new).

 I'm now confused by your original analysis (way back) that either axis was fine when it was run individually and that it was only a combination of running them both together that caused the errors to appear. Not sure about that.
 
Sage

Hood,

I have not bypassed the breakout board yet.  I will be trying that soon but will finish some more testing before going to that step.  I'm still not sure I understand how to hook up the 5v supply.  Based on some previous posts it sounds like I need to hook the negative side of my 5v source to one of the pins at or above pin 18 and the positive side to the gecko drive's common pole.  I'm hoping I can use 1 5v supply for all three drives but still not sure about that either.

Sage,

The CNC4PC board uses pins 1 through 9, 14, 16, and 17 as output.  I had originally connected the drives as follows:

X-Driver Step   -   2
X-Driver Dir                   -   3
Y-Driver Step   -   4
Y-Driver Dir                   -   5
Z-Driver Step   -   6
Z-Driver Dir                   -   7

When I disconnected the Z-Driver and connected X and Y (modifying the motor config accordingly) as follows:

X-Driver Step   -   2
X-Driver Dir                   -   3
Y-Driver Step   -   8
Y-Driver Dir                   -   9

I ran the full gear crossing program 3 separate times and it was spot on.  Not even a thousandth off when done each time.

I then connected Z (modifying the motor config accordingly) backup as follows:

Z-Driver Step   -   2
Z-Driver Dir                   -   4

Unfortunately I walked away during the 9 minute program and the Z drive crept down into my work piece and ruined my Starrett edge/center finder.  It was at this point that I realized I definitely had a problem with noise or interference. 

I now need to repeat my tests and start checking other pins on the breakout board to see if I can possibly find another configuration that will work.

Ultimately, I am going to bypass the board.

I think you are referring to my point that I could run just the X stepper alone and it would do all moves without error.  I could then run just the Y stepper alone and here again it would do all moves without error.  It was only when I did combined X/Y moves together that I would begin to notice the errors.

What confuses me is the fact that Mach is 2.5D.   The Z axis doesn't move while the X or Y axis moves so I'm not totally sure I understand where the noise/interference is coming from?!  But I agree that it appears to be the breakout board or parallel cable.

I may not get all the tests done tonight but I will post my findings when I'm done.

I can't thank everyone enough for keeping with this thread and helping me along.  It was been very frustrating at times.

Best Regards.

Carl

Carl,
   I don't know if anyone has brought this up yet, but how is your system grounded?  Early on, my system was losing steps, in part, because of poor grounding.  It's important that you have a very solid, single-point ground for everything.  This one point should be the ground for the line cord, the motor power supply, and the +5V and +12V power supplies for the CNC4PC board.   You should have a single lug securely tied to the electronics case with individual wires running to the various devices from that one point.  NEVER daisy-chain grounds from device to device.   DO NOT ground the PC to the electronics case.  The only connections to the PC should be the parallel cable signal pins, and the USB cable that provides power for the PC-side opto-isolators.  The PC ground should not be connected to the electronics box ground.
   Also, you should be using shielded cables for any limit switches, e-stops, etc., and those cables should have their shields connected to that solid ground ONLY at the electronics box end, NOT at the switches, etc.  Shielded cables for the steppers also would not hurt, as long as you connect the shields as above.
   What rev of the CNC4PC board do you have?  If it's an early one, you really should get an updated one, as there have been a LOT of design improvements made.  My rev 2.0 board was very unreliable in my system.  It drove me crazy for weeks!  The rev 7.0 board I now have has been bullet-proof.
   If you want to bypass the CNC4PC board entirely, wire the PC parallel port connections directly to the Geckos (they're internally opto-isolated), and wire the +5V from the USB cable to the "common" terminal of the Geckos.  That's all you need.

Regards,
Ray L.

Hi Carl,

I see in your earlier post that you had problems setting the pulse number and saving it.  Have a look at my posting http://www.machsupport.com/forum/index.php/topic,2658.0.html - I  also had a similar problem with a Dell Notebook.  I am running in Sherline mode and all is going well.  I guess that it is a Dell specific problem!

Alan