Yaskawa, Xaxis encoder error rate high "X-axis position error"

[rjtechserv]

All, Thank You for reading into this.

I'm thinking, I could have a tuning problem causing the X axis encoder to act erratic. would that make sense? Only the CentroidCNC side is erroring out. I've been fight this for a week likely getting lost in the shuffle.

Everything seems to jog fine most of the time. Servo's jog quiet. Yaskawa Sigma2 Inertia tuning works fine. But the high error rate I think causing the Xaxis to home erratic and randomly trip the "410- X-axis position error" Some during a slow feed home sequence; some while jogging or running.

We've had a bad run a two bad drives, tried swapping encoder cables. Power cable resistance check between phases and ground seems okay.

I think its tuning or Centroid side parameter that I don't understand yet. The servos seem to like lower speed loop and gain. (40) runs quiet.

Any idea welcome, Going to try encoder cable again... maybe with magnetic chokes?

I've attached the report, Yaskawa parameters, Error picture etc..

Thank you,

RobJ

[cncsnw]

If you have an error count that persists long after the axis has come to a stop -- as appears to be the case in your screen picture -- then your system is dropping/gaining outgoing command pulses, or returning encoder counts.

If it is only losing/gaining outgoing command pulses, then the DRO position will be accurate.
If it is losing encoder count feedback, then the DRO position will not be accurate.

In your picture, I am guessing you had just done some move that should have moved to X0.0000 (in G54, with no tool offset). The DRO says it is at X+0.1990. Where is it, really? If it is really at X+0.1990 (0.0995" to the plus side of wherever you set part zero), then the problem is with command pulses. If it is really closer to where you set X0, then the problem is with encoder feedback.

[rjtechserv]

One thing I've noticed is it wont home to zero it's always seems to be offset of zero not consistent.

Likewise, If I try to set the X to zero in part setup it won't set zero. Always close but off +/-.200" or less.

Marc, I'm dense on this a bit. Hate that you have repeat things so often but we appreciate you!

How can I detect which way is the communication problem? You think the Yaskawa to Centroid Oak cable? I may try swapping the X and Z cables..

Thanks,

RobJ

[cncsnw]

As an experiment, try this:
Power up.
Release emergency stop.
Press F3/MDI, so that both drives are enabled, but without any immediate movement command.
Press ESC or Cycle Cancel to close the MDI prompt.
Press Cycle Start to find home.
Press Alt-D to show Machine Coordinates on the DRO.

Is X at 0.0000?

If so, perhaps for some reason your X drive is slow to enable and to start responding to command pulses.

Carefully mark this position of the cross-slide.
Do whatever jogging or MDI moves cause an error to show up.
Use the F3/MDI prompt to run "G53 X0". That will cause the control to (try) to move X back to zero counts.

Does the cross-slide return to the same position it was at when it finished homing?
What does the DRO position (in Machine coordinates) say?
What does the Error count say?
What does the Abs Pos (encoder counts) say?

[cncsnw]

You could also check whether the problem is dropped command pulses or dropped encoder counts, by looking for the index pulse asterisk '*' on the PID screen. The PID data display will show an asterisk next to the axis label (e.g. "X*") when the encoder index pulse is present.

After homing, that asterisk should appear at, and only at, whole multiples of your encoder counts/rev (32768, in this case).

See if it does that, immediately after homing.

Then jog/move/run cycles as needed until you have accumulated a significant error (but not so much that it triggers "410 ... position error").
Then check again to see at what encoder count positions the asterisk appears.

If it is still at the same encoder ("Abs Pos") numbers, even with a large value in the Error column, then you have been losing command pulses. If the index pulse appears at different encoder numbers, then you have been losing encoder counts.

Yes, swapping Oak axis-interface cables between the two axes would be a good troubleshooting step.

If that does not lead to a conclusion, I would try swapping drives between the two axes (though I see that would be awkward, because you have one 1kW drive and one 2kW drive).

[rjtechserv]

Thanks Mark,

I'll try these things tonight. As always, very much appreciated! Great details, I think I understand the angle your directing me!

RobJ

[rjtechserv]

All,

So I've been working on this for a bit now. Swapped the Oak to Yaskawa cables and the problem stayed with the X axis.

The encoder index pulse stays in tune with the pulses per revolution multiplies after error. 32768 65536 131072 etc.

Machine homes the X erratically to odd locations. -.0130 -.0609 -.0160 .0246 etc..

So is this saying the Yaskawa drives are reporting encoder pulses as it should? The Oak is dropping the pulse train? Can't be the cables, the problem didn't follow.

What would be the suggestion? Have Centroid repair or replace the Oak?

Thanks,

Rob

[rjtechserv]

All,

I had another idea to try so I moved the X axis to the 3rd axis location. The x- axis still shows error. Now I'm confused for sure...

What does this mean?

Huh, befuttled,

Rob

[cncsnw]

Can you connect to the Yaskawa drive with SigmaWin, and check what the position error amount is? I.e., what does the Yaskawa drive think the difference is between the commanded position (based on the pulses in) and the actual motor position (reflected in encoder counts out)?

Usually, a properly performing drive will move as needed to bring the error to zero counts. However, it is conceivable that yours is not performing properly, to the point where it never drives the error to zero. If so, then it would "know" it was off position; it just wouldn't do anything about it.

[cncsnw]

Does the Z axis perform more or less as expected?

If so, and if that drive+motor+cables combination works properly whether it is connected as the first, second, or third axis, then that would eliminate the Oak as a source of the problem.