Welcome to LinuxCNC.org

I don't even see an unhome pin in halui and the unhome menu is disabled when running...

John

A comment from the developers mailing list was:
"Spurious unhome in a move sounds pretty broken. What does memtest86 think of the system?"

I would add debounce for all input signals. Seems illogical but I remember I've had simmilar problems and this solution worked.
www.linuxcnc.org/docview/html/man/man9/debounce.9.html

micges wrote:
He only has one input signal.
net estop-ext <= parport.0.pin-10-in

I guess if he has VOLATILE_HOME then it _might_ be possible to have e-stop trigger unhoming without actually e-stopping.

Is the external e-stop actually connected up? If not then I would suggest commenting-out that line of the HAL. ("#")

I've just checked - on abort there is always executed unhome(-2) which unhomes joints that are volatile. And code checking if joint is moving is always executed regardless of volatile setting. so debounce of external enable signal could help.

The E-Stop is connected, but I can disable that pin to see if it helps (now that I come to think about it, this stepper controller has been known to have some sort of internal clock/pulse signal that sometimes comes across the e-stop; I never had a problem on my old computer, but that's not to say it isn't an issue here). If it works I'll try to adjust the debounce with the input activated.

cncbasher wrote:
The power supply and stepper drivers are an old (circa-80s/90s) proprietary board that came with the machine (Light Machines Corp LMC0200). It was originally set to run with proprietary software through a proprietary pci card; I have it running with LinuxCNC through a parallel port using a custom adapter cable to get the correct signals to the correct pins. Kind of thrown together, but it's worked using another computer for quite some time now.

I will try to run memtest86 tonight as well.

Thanks for the all the help so far guys.