Restoring an old workstation - harddrive failure

[cncsnw]

You are running some PLC program, otherwise none of the memory bits would be set to 1.

CNC7 just cannot determine the name of your PLC program source, presumably because it is an old CNC7.PLC file with no header comment.

There is nothing useful to be learned by looking at error messages while you have power to the control cabinet turned off. That is just going to confound matters.

Is your control wired so that emergency stop shuts off logic power to the servo drive? It should not be, but Magnum/Phoenix controls often were done that way. If it is, then clearing faults is going to be troublesome, because pressing emergency stop to clear a fault will also cause a fault condition. The correct wiring would have emergency stop just open a PLC input (usually INP11) and also interrupt just motor power (VM+) going to the servo drive.

Since Magnum/Phoenix controls were wired in varying ways, and rarely if ever per Centroid recommendations, you will not have much luck matching your control with later M39 or M400 factory schematics. At best, those schematics will show you how the SERVO1 and PLC 15/15 could (and should) be wired. The only way to find out how yours is actually wired, is to trace the wires and draw your own schematic.

In your video, it appears that logic power to the PLC 15/15 board is also interrupted. That would be the 24VAC going into 4-position plug H4.

There are too many unknowns about your control cabinet wiring to troubleshoot this remotely. Unless you can draw a reliable schematic of how your control is actually wired, you are probably going to have to hire someone to help troubleshoot it on site.

[mavenblueprint]

Thanks Marc! Yes you are correct that it would have been too hard to diagnose remotely.

If it is, then clearing faults is going to be troublesome, because pressing emergency stop to clear a fault will also cause a fault condition.

Yup! This is something we experience and learned that in order to clear faults we had to be in the ALT+I screen and hit E-Stop again to clear the faults. Only then we could use the machine again.


I was able to find a person locally who works on maintenance in a factory and had enough electrical and machine experience to troubleshoot in person.

Good news, we were able to start it up and movement on all 3 axis! Basically it came down to wires were either loose or the pin connections were too weak. He went through the entire cabinet and tightened up all screws and expanded/adjusted any pins that were compressed and thus lacking in contact. This was perhaps the easy part.

Perhaps the final issue to debug is why the jogging X axis movement is set to full power despite the parameters set in CNC7 telling it otherwise.
* Y and Z axis jogging is as expected: press button once, the movement is incremental and the machine stops after the desired jog distance
* X+ or X- axis jogging is as follows: press the X+ or X- jog button once, the motors accelerate/100% power immediately and hits the end of the rail at full speed. The first time we had the machine running the speed was so fast I didn't have enough time to hit the E-Stop.

After the initial scare, we had to set move the spindles/motors to the opposite end of the jogging direction so we had enough time to hit E-Stop as we were adjusting the parameters in CNC7. We guessed and experimented with the "Jog Parameters" and clearly there is an effect by changing the X jogging parameters to lower values however never actually getting the jog to be, well, jogging.

Here's what the system has loaded initially:

Here's a piece of paper with what I can only assume is what Centroid provided:

We tried above numbers, seeing Delta VMAX is 0.550 instead of what was in CNC7 set to 3.0000. That didn't seem to make as much difference as setting everything on X axis to:
Slow Jog: 2 in/min
Fast Job: 2 in/min
Max Rate: 2 in/min
Deadstart: 5 in/min
Delta Vmax: 0.5500

Above gave us just enough slowdown to hit the E-Stop but the jog is still not incremental but super fast.

The Motor and PID params match 95% between paper and what's in the system. There's only 1 or 2 values off by 1 in the Ka column.

Any suggestions on how to debug this issue ?

[cncsnw]

What you are describing is not jogging, but is a runaway.

Runaways happen either when there is a problem with the encoder feedback; or when the servo drive's output FETs are shorted through; or when the servo drive's current regulation for that axis is faulty.

Usually a runaway will be followed by a "full power without motion" or "position error" stall message. However, if the issue is a partial loss of encoder feedback, then you might get an extended runaway without triggering any of the stall conditions.

You can watch the encoder feedback on the PID Configuration screen, to see how many counts come in relative to how much the motor turned. If the encoder is working correctly, then you should see the "Abs Pos" value on the PID screen change by 8000 counts per turn of the motor shaft. If your configuration values from the tables you posted are correct (0.7938 servo motor revs per inch of travel on the X axis) then you should see about 6350 encoder counts per inch traveled.

By how much does the Abs Pos value for X change, when it moves by some approximately-measured number of inches?

[mavenblueprint]

What you are describing is not jogging, but is a runaway.

Runaways happen either when there is a problem with the encoder feedback; or when the servo drive's output FETs are shorted through; or when the servo drive's current regulation for that axis is faulty.

Thank you for teaching me the terminology

Usually a runaway will be followed by a "full power without motion" or "position error" stall message. However, if the issue is a partial loss of encoder feedback, then you might get an extended runaway without triggering any of the stall conditions.

Hmm we haven't seen any errors on the main screen aside from "453: Jogging while probe detected"

You can watch the encoder feedback on the PID Configuration screen, to see how many counts come in relative to how much the motor turned. If the encoder is working correctly, then you should see the "Abs Pos" value on the PID screen change by 8000 counts per turn of the motor shaft. If your configuration values from the tables you posted are correct (0.7938 servo motor revs per inch of travel on the X axis) then you should see about 6350 encoder counts per inch traveled.

By how much does the Abs Pos value for X change, when it moves by some approximately-measured number of inches?

Here's the PID screen and what we started with:

Current Jog Params:

Current Motor Params:

The video shows the value changes better than I could describe in words:

Z+ ~3300 sum PID ~10s; abs pos 1K
Y+ ~500 sum; PID ~3s; abs pos 2K
X+ ~28000 sum; PID ~128; abs pos 0 (zero)
There was a total of ~21 inches of travel likely half of that after the eStop was pressed.

Here's a screencapture from the final frame of X-axis output right before E-Stop cleared the values:

Here's the video walk through of the Z, Y and X-axis behavior:
https://youtube.com/shorts/5hIS6tv-oXE

[cncsnw]

So, you tried to jog the X axis, and the table ran away for about 21", and the encoder feedback changed by 0 counts.

You have a faulty encoder, or perhaps a loss of encoder feedback. It is a mystery to me why you do not get a "411 ... full power without motion" stall condition. Perhaps stall detection has somehow been disabled, or perhaps parameters 61 and 62 have been set to effectively ignore FPw/oM conditions.

You could replace the encoder on your existing servo motor.

You could just replace the servo motor, encoder and all.

If you suspect cabling, and your X and Y motors are identical, and they have connectors you can readily disconnect at the motor, then you could try swapping your X and Y motors to see whether the problem follows the motor, or follows the cable.

[mavenblueprint]

So, you tried to jog the X axis, and the table ran away for about 21", and the encoder feedback changed by 0 counts.

You have a faulty encoder, or perhaps a loss of encoder feedback. It is a mystery to me why you do not get a "411 ... full power without motion" stall condition. Perhaps stall detection has somehow been disabled, or perhaps parameters 61 and 62 have been set to effectively ignore FPw/oM conditions.

You could replace the encoder on your existing servo motor.

You could just replace the servo motor, encoder and all.

If you suspect cabling, and your X and Y motors are identical, and they have connectors you can readily disconnect at the motor, then you could try swapping your X and Y motors to see whether the problem follows the motor, or follows the cable.

Thank you once more. We tested the cabling and it appeared to be OK.
We swapped motors and it does appear the encoder is at fault since the motor did run (just too fast haha).

I've emailed EPC (Encoder Products Co) for a list of distributors for a replacement and haven't found anyone else selling them online with the specs on this model.

Do you know where one can order one outside of EPC or is that even possible?

[cncsnw]

The only thing you need to know is the bore diameter. It looks like either 1/4" or 6mm.

The replacement does not need to be a 755A, nor even an EPC product. It can be any hollow-shaft encoder that has 2000 lines, a 5V line-driver interface, and the same bore diameter.

If you buy a replacement encoder from a Centroid distributor, you can probably get it with the correct plug pre-installed as well.

[mavenblueprint]

According to EPC this encoder is 755A-01-S-2000-R-HV-1-S-S-N (flying leads / no plug ) aka "MODEL 755A - INCREMENTAL HOLLOW BORE ENCODER" and they sent me a distributor who quoted north of $360

Centroid has an equivalent for $240 for the QR12-2000-0-A-B-L-A-A (with plug) aka "1/4" 2000 line DC encoder w/ QR12 pigtail" ( plug included ) and here's what it looks like:

The plug that's inserted into the encoder was shipped unplugged, I plugged it in unlike the original encoder that was just a wire.

However, the wiring is different than the old plug which made me wonder: either the wiring is correct on the encoder side OR this is a generic configuration and it's up to the user to change the wiring. I'm going to email Centroid to verify.

To test whether it's just generic writing configuration I unplugged the Yaxis motor that I know works correctly and plugged in the Xaxis motor & now replaced encoder on the Yaxis wiring harness to test via wired pendant + jogging.

Rotating the X-axis motor + new encoder *does* send data on the "abs position"! So that's a step in the right direction. However, jogging (0.001) via pendant caused 2 things to happen:

1) I got an error "435 Y axis(2) runaway: check motor wiring"

2) I had my phone recording the motor (I didn't have a clear line of sight on it visually). I attempted to jog (incremental + slow+ 0.001" settings). The screen "Abs position" ended up going toward ~180000 and then I hit E-Stop just to avoid any issues.

Am I correct in asserting that the wiring is incorrect and I need to change the plug wiring to match what's on the motor cap/connector ?

[cncsnw]

Wire colors are not universal across brands. There is no reason to expect that Quantum will use the same colors for the same signals that EPC used.

See http://www.cncsnw.com/Encoders.htm for some tables of wire colors for EPC, Quantum, and others.

If the axis runs away when you try to move it, chances are that the direction of the encoder counts feedback does not match the direction of the power. Whatever direction the motor shaft rotates in response to positive PID output, should be the direction that causes the encoder counts (Abs Pos) to count positively. On Centroid DC servos, that is usually right-hand rotation (CW as viewed from the back, or CCW if looking at the shaft face).

[mavenblueprint]

Wire colors are not universal across brands. There is no reason to expect that Quantum will use the same colors for the same signals that EPC used.

See http://www.cncsnw.com/Encoders.htm for some tables of wire colors for EPC, Quantum, and others.

If the axis runs away when you try to move it, chances are that the direction of the encoder counts feedback does not match the direction of the power. Whatever direction the motor shaft rotates in response to positive PID output, should be the direction that causes the encoder counts (Abs Pos) to count positively. On Centroid DC servos, that is usually right-hand rotation (CW as viewed from the back, or CCW if looking at the shaft face).

"in response to positive PID output" - what happens if the PID output is "OFF" instead of a number?

Just to make sure the wiring is correct I did comparison between the old encoder and the new encoder. Digging into the pinout specs for both EPC 755A encoder and QR12 encoder and based on your info on http://www.cncsnw.com/Encoders.htm it appears the wiring is correct. I did attempt to swap the A/A' and B/B' pairs per QR12 spec sheet just to verify with the same result where PID was "OFF" and runaway error as before ( see last screenshot ):

### Hand Rotation
Looking at the servo shaft: CW rotate from 10 to 10 oclock position (full rotation)
* PID: OFF
* Abs: -8083

Looking at the servo shaft: CCW rotate from 10 to 10 oclock position (full rotation)
* PID: OFF
* Abs: 8033

### Jog from pendant
Jog on Z+ axis for 0.0001 outputs
* PID: 2 or 3
* Delta: 0
* Abs: -4

I assume above is as expected, based on your last message, so now testing the X-axis motor + the new encoder while connected to the Y axis ( where everything is working OK) wiring harness:

Jog on Y+ axis for 0.0001 outputs:
* PID: OFF
* Delta: 182
* Abs: -104404

I get the runaway error once more but PID value does not change at all. Does this indicate a bad motor since Y-axis is working correctly otherwise and a new encoder is installed ?