The z-axis will only go one direction.  Sometimes it seems to reverse directions.  But when I press on the page up and page down keys the z goes the same way.

And it's the software because when I switch to another motor (axis) it will do the same thing.

What's going on with the Mach3 software?

The one thing you can be certain of it that it is not a fault within the Mach3 software.

Check that you have the correct pin# and Port# set for your Z axis Direction signal (Config / Ports & Pins / Motor Outputs).
Check that you do not have a conflict (duplication) of Pin numbers being used within the Mach3 settings.
Use a multimeter to check that the Direction signal of the Z axis at it's driver is changing between zero and 5 volts (approx.) when you use the page up / down keys.
Run the Smooth Stepper SCU and check all your settings.

Tweakie.

Does the software treat the z-axis any differently than any of the other axis?  In other words, is there any way possible whatsover that the software could cause the movement to only go one direction?  Like a feature or setting?  For example a homing feature that only allows it to go one direction until it's been homed?

Ok, I switched XML profiles and for some reason it's working but still doesn't work on the original profile.  It bugs me that I can't figure out why the one profile would make it only move one direction.  Ideas?

I think you may have answered your own question - looks like you had a corrupt .xml file (which is not that hard to do when using the Smooth Stepper if you make a number of config. changes too quickly).

Tweakie.

Ok, for my own education- how exactly does the XML file get corrupted?  IOW how do you prevent this from happening? 

And is it just with the SmoothStepper because this machine doesn't have a smoothstepper and had the problem.

But my other machine does have smoothstepper and also has the problem.

Thanks.

IOW how do you prevent this from happening? 

I am not sure you can actually prevent it from happening but on occasions when the .xml is being updated in 'real-time' then making a number of changes to the configuration in quick succession can often cause the problem.

On the other hand, when the .xml is only updated at program close it is very rare for a corrupt .xml to be created.

Tweakie.

Ok, I'll keep an eye on this, thanks.