Kinetix 300 overtravel issue

Long story short, with PLC (L33ER)called absolute indexes, with code that "used to work" a strange overtravel condition has arisen with a recent code update having nothing to do with the servo tasks.

After trending we see a move where apparently the servo loses some encoder pulses as it travel way to far but the feedback shows it's in it's commanded position.

The next move it hits the over travel prox and faults. Always only in one direction!

The very weird thing is a softlimit adjustment seems to fix the symptoms on most machines, but again it has nothing to do with the move where it faults or the previous one where it loses position.

All this on only about 5% of the updated machines. Exporting and re-importing the code to eliminate any corruption solved nothing.

Slowing the moves down drastically solved nothing.

Stepping it through the indexes manually solved nothing.

All mechanicals checked and re-checked. Nearly all (but not all)machines will operate with a range of softlimit above and below the "problem" number.

Eliminating those registers and creating new ones solved nothing.

Rockwell says no known issues with Vs30 PLC firmware and the kinetix drives.

I am about at a loss other than re-generating the code from scratch.
Any ideas? I know it's tough not looking at the logic but it's IP so I can't release it on here.

Older versions of code both in 20.03 and vs30 work fine. sometimes (at least once) updating the symptoms appear and rolling back the issue stays! Sometimes reloading the code fresh fixes..... until a powercycle.

Do you have a spare motor/drive combo to rule that out of the equation? I've had similar issues in the past and the problem came from the drive. I wouldn't rule out the above even with new equipment either.

If you don't have spares, I'd move one of the drives over and see if the problem stays with the drive or the PLC; at least you will know for sure if it's your hardware or software.

Cheers,
Vlad

I am sure that has not been tried, I actually have never been to a location where the issue arose. I was until recently the engineer with the most involvement but others are now more likely to have to take this on. If I get a chance on a machine I will keep this in mind. Thanks

After reading your posting I can offer this it my apply it may not just a place to look

All the problems popped up after a change downloaded and it worked ok before the download
That in itself should tell you something
I am thinking that an encoder configuration has changed o some of the machines
Most position controls are looking for a quad signal
That’s A+ A- B+ B- Z+ Z-
It reads all 4 channels in yielding 4 pulses for every encoder pulse
But if the configuration changed to pulse and direction
The travel distance for each move requires twice as many pulses from the encoder to think it is at the set point. Remember that in motion / position systems the set points are converted to pulses scale by the pulse per unit (PPU) and control uses only the encoder pulses for all motion.
If you changed the configuration from quad to pulse and direction the number of pulses counted will be 1/2 the scaled PPU doubling the stop position for the set point
The fact that it only happened to some of the machines at with an update download means you should recheck the configuration after the download

Were the changes enough to effect scan time?

Check for task overlapping.