What's new
What's new

Hardinge T42 Conquest "971 NMI occurred in SLC"


Dec 26, 2023
Hardinge T42SP Conquest
GE-FANUC 18-T Controller

I'm chasing myself in circles trying to repair this machine...

The original issue was a controller crash. Which would stop the machine and throw up a system alarm (have to cycle power to reset).
"971 NMI Occurred in SLC" Occurred when trying to cut with the main and sub synced.

Once the machine is back on the system alarm is gone. When trying to run my homing program, it will then alarm on the sub trying to G28V0.
"405 Servo Alarm (Wrong ZRN)"
Go through parameter 1815, for Y, AZP, reset home. Then okay.
End of first complete part, typically during the sub movement, 971 NMI crash

The alarms on the CPU:
Stauts: 2nd light green
Alarm: 2nd light red
which equates to "Other System Alarm" (thanks for nothing)

I've made a number of changes
-With each one I could run for a few hours, then the first part on the next day - NMI 971 controller crash.
1. Swapped the CPU board.
2. Swapped the power supply board.
3. Cleaned all the chips out around the Y-axis Pulse encoder. Worth mention, the belt from the motor to the ball screw has been replaced twice in the last 14 months.

This morning I tried the old board and had problems with the turret. Went back to the 2nd board, 1815 home position for the sub. Can run again but...
I'm avoiding sending the sub home completely. Sending it back to Y15.0 after each cutoff (FWIW home is Y15.875).

If seems like there is feedback of the home position that is not being relayed correctly.
Or the actual location of the sub is too far off the expected location.
PCB for Y axis? Pulse encoder? Cable?
Ball screw not moving completely freely to the end of travel?

FANUC says control hardware, Local Tech says pulse encoder, Electrician says I/O issue.
Diagnostics 200-206 all 0s

Why intermittent? Why will it run for a period with one change then not work the next day? Completely different change and same result.
It doesn't make sense!

HELP me.
I don't have any experience with that alarm that I can recall.

So, by sending your sub "home" to Y15.00 solves your problem?
Or ???

I have not had that problem on my T51, but - I have had that issue on my Twin Turn 65...
It took me a while to figger it out, but when I set my home position for the sub, it turned out to be setting on the hard stop when home.

Now on this machine (TT65) I have an un-coupler on that axis that the T machines didn't have on their subs, and so I think that I was uncoupling mine. But if that would have been my T51, then I would have expected to end up with a Y axis overtemp alarm. ???

IF going to Y15.000 solves your issue, then I would put it in E-stop and then run the screw by hand up to 15.875 and then a bit more and see if it feels like you are up agginst a hard stop. If so, just edit your Y axis ZERO routine to give you a bit more room there. I edited my routine by 1/8" on my TT65 and those troubles went away, and made room for new ones. ;)

This could possibly explain your belt issue as well?

If that has nothing to doo with your issues, then you may want to look at fetchin a new encoder cable. For an intermittent encoder issue, I would look at the cable first, but as I understand - worn bearings can make the encoder flutter a bit. But we both know that _ that encoder hasn't seen much movement over it's life - compared to almost any other encoder on the machine, so ... But you can git the encoder rebuilt, or maybe just new bearings from a place in Chi-Town for a few hundred bucks or so.

Or it could be in the amp. You could likely pick up a used one off ebay to compare.


Think Snow Eh!
I've come up with a number of work-arounds to avoid the crash but still have not gotten to the root of my problem.
I made a warm-up program to move all the axis back and forth, up and down, rotate the turret, repeat. Helps get me jump-started.

I swapped the encoder cable on my x-axis with a cable from another machine. Indications were that somewhere the X-axis and Turret index cable were possibly interfering with each other. Not the solution.

Today, I attempted to have the main spindle on while doing the warm-up program and it caused a crash at the first tool change.
Which led me on a new path.

If the spindle is turning while trying to index - crash.
If I index, turn on the spindle, move, turn off the spindle, index. No crash.

Which links to where I originally saw the problem- I was using the main and sub synced. Therefore, I was no longer turning off the spindle when indexing, since the two spindles were synced.

Makes me think the machine vibration from the bar stock spinning is causing a connection issue somewhere?