Kinetix350 Troubles, Again...

Hey Folks.
I'm having a little issue with a Kinetix350.

Long story short. I have burned 2 2097-V34PR5-LM in the past few months on the same machine. Why is not as important at this moment as how to fix.

The first time this happened, I had to put in a 2097-V34PR6-LM as it was what I had available to use. The only difference was the scaling parameter, it needed a different decimal value that the PR5. It worked just fine.

Once I received the new PR5, I proceeded to change it out when the downtime day actually came. I deleted the PR6, deleted the Axis, re-added it all but I had an issue. I couldn't get the PR5 to enable. Its status was simply start inhibited. I ended up running out of time with this and went back to the PR6, it worked just fine. Still is running.

Fast forward to Startup Sunday.
The machine is powered up and like a shotgun, the next drive in the row blows its smoke. This time, I have a new from the box PR5 to install, should be quick and painless right....

I install the drive, the only difference is the the firmware is now 2.004 instead of 1.01. So I change it in the module properties and download. Now, I'm in the same odd situation where I cant enable the drive.


After a couple hours on the phone with Rockwell yesterday, them on my system. We figured out that the configuration of my Kinetix drive in the project is good. We also found out that the configuration as we see it is correct for the Axis and motion group. What we see now is that there are no start inhibit conditions. By clicking on the Axis, I can see in the drop down tab at the bottom of my Controller Organizer, All the Fault bits say No fault, the Update Period is 6.0ms, the motor catalog is MPF-B320P-M, the Start Inhibited bit is "Not Inhibited" but the "Axis State" says its inhibited.

If I try to give it a MSO to enable, it errors the instruction and sends back a "Motion Error Code" of 82. This had the Rockwell guy confused.

He suggested that I delete all traces of the Axis in the program, delete the PR5 and re-add it all. I did exactly this and now I am exactly back where I was before I did it.

The other thing I want to mention. When I try to issue a motion direct command. It allows me to give it the MSO with no issue, It allows me to give it the MASR no problem, but when I try to give the MSO to enable, it says the drive is in the wrong state to accept the command.

If I go to my drive tab again, go to "Module Info" and I can see the following.

Major fault: None
Minor Fault: None
Internal State: Program Mode
Configured: Configured
Owned: Owned
Module Identity: Match
Protection Mode: None


Almost forgot..

Control Logix L71
Studio V30.11


Any help is appreciated!

Resolved.
OEM, AOI code was not completing, created a logic trap that would not allow the drive to enable.
Took Rockwell 3 plus hours, unsuccessful and the OEM a few more hours to figure it out.

Thanks for reading.

Just a suggestion for next time..

On top of the Motion Direct Commands and suggestion by Rockwell..

I would have made a blank program, import your hardware and then try and execute the MSO's in a routine for the relevant drive/ axis, this would have identified your program logic as the issue.

Which OEM AOI was causing the issue? Would be interesting to understand

collinsd70 said:

Just a suggestion for next time..

On top of the Motion Direct Commands and suggestion by Rockwell..

I would have made a blank program, import your hardware and then try and execute the MSO's in a routine for the relevant drive/ axis, this would have identified your program logic as the issue.

Which OEM AOI was causing the issue? Would be interesting to understand

Click to expand...

I honestly was thinking I had weird firmware issue or something of the kind. I suspected somewhat the logic was the issue, but given the time in operation, as a rule, I find it hard to blame logic for troubles usually. Especially on such a heavily engineered machine.
I set Kinetix up many times on my machines trouble free. This was a new drive out of the box. I could make it work on my bench but as soon as I went the the PLC in question, It would show the symptoms described above.


The issue was an AOI that the machine OEM wrote, not Rockwell. Its been running for almost 10 years now. This has been an issue twice now, both times, the OEM spent many hours trying to rectify, remotely of course.

My gut feeling, is that the servo drives are blowing due to the amount of power cycles this machine gets. About twice a week, production stops because this thing has decided it wants to stop a servo drive with no alarms, no clues as to why, it just stops and wont start. I don't even get to see it as its a panic when it happens and power cycling the machine is the go to move. Power Cycling in this case always works, until a drive blows up....

Iv stressed so many times to the managers that there is problem within this machine and the OEM needs to come fix it. That is forgotten about as soon as its running again. You know how management operates. Why take downtime to get it fixed if we can just call our guy and put him through hell for a couple days on it when it does **** the bed.

Of course it happens on Sunday, I tried to book a vacation day for Monday, all of it got trashed. Then come to find out, it was a US holiday and the OEM had no available tech support till Tuesday. So much fun.

Since you know its a problem with the AOIs from OEM, why don't you just take the code that is in the aoi and move it to a routine and call it at the line that the aoi is called from?
You seem very familiar with the code and in long run this OEM would probably not be used in future if you had your say.

I would do 1 instance of it and test the code, debug till you have it done. Then move to the other instances of the code where the AOI is used in program.

Jim3846 said:

Since you know its a problem with the AOIs from OEM, why don't you just take the code that is in the aoi and move it to a routine and call it at the line that the aoi is called from?
You seem very familiar with the code and in long run this OEM would probably not be used in future if you had your say.

I would do 1 instance of it and test the code, debug till you have it done. Then move to the other instances of the code where the AOI is used in program.

Click to expand...

I want them to fix it!

Its a machine I hate messing with given the massive amount of code built in.
I upgraded the processor one time. Long story short, If you don't know the combination of proper routines to enable and which ones to inhibit before the first scan, it will never start up again. I ended up getting the OEM involved just to get online and get the processor scanning again. I work with a lot of machines with a ton of code, this takes the cake as I get the feeling when looking at it, that they have done everything short of locking the code to make sure nobody else can follow it or understand the horde of custom AOI. I know its likely common practice for a high speed machine with code that applies to several models and one that costs about as much as a Ferrari, but its certainly a little above what I'm used to dealing with. Its one that doesn't give me grief often, but when it does its relentless.

When I look at L71 at studio version 30 I kind of cringe
I looked at compatibility matrix,
2097-V34PR5-LM drive and an L71
30.11 firmware
the firmware is retired. What does that mean?
Version of software is on the hairy edge of development before L8x processor.
It says its compatible but most of the matrix and subset of firmware to these two part numbers are either retired, limited, or known issues.
Would a L8x with that drive be a better solution? I know firmware for processors and drives has to be lockstep'd. Upgrading to an L8x for motion is a bit of a pain.