Powerflex 70 20-comm-R DPI intermittant failure

[robertmee]

Basic install, 9 Powerflex 70's talking via integrated 20-comm-R over RIO at 57K to CLX. I have one drive (incidentally, the last one, investigating whether that's a cause too), that very intermittantly (twice in 4 days) has lost the DPI port 5 (the 20-comm-R). The drive is currently configured to stop on this fault (whether it can be configured otherwise, I'm unsure as the AB manual doesn't list this fault as type 1 2 or 3). Since I'm monitoring the run bit from the drive, I fault out after a few seconds. It doesn't take a reset of the drive, so it appears that this fault is clearing within my 3 second timeout on the run fault.

My questions are:

Is there a safe way to add a delay to this particular fault condition (IE loss DPI for over x seconds) before internally generating a stop command, or is there an alternate and safe means of riding out this fault when it is a brief interruption. I certainly don't want to configure it to hold last state indefinitely in the case that I do have a complete RIO failure.

Lastly, all term resistors are in place, cabling checked, lower baud running, routing away from motor leads (as best as I can as all the 70's are in a Centerline MCC), is there anything else that might cause this intermittant failure? So far, it has only occurred twice on the one drive which happens to be last in line.

 

[bobrapp]

Simple questions.
Is the RIO link properly terminated (150 ohm resistors at both ends).
Are you using the proper "blue tube" cable?
Is there anything else on the RIO link?
Are you using and block transfers over this link?
Rack addressing - what rack assignment are you using?
What version is the DHRIO (versions earlier than the D series could problematic)?
RIO communications is one the most reliable forms of control and properly implemented should be trouble free.

 

[robertmee]

Simple questions.
Is the RIO link properly terminated (150 ohm resistors at both ends).
Are you using the proper "blue tube" cable?
Is there anything else on the RIO link?
Are you using and block transfers over this link?
Rack addressing - what rack assignment are you using?
What version is the DHRIO (versions earlier than the D series could problematic)?
RIO communications is one the most reliable forms of control and properly implemented should be trouble free.

Terminated - Yes, both ends
Blue Tube - Yes, standard Belden
Anything Else - 9 Powerflex 70's, nothing else
BTW/BTR - Yes
Rack Assignment - Octal 10 on this unit
DHRIO Version - Brand New Card

I agree and have never experienced an issue like this. Since posting, it has happended twice more on this one drive. I'm going to look closer again at the physical install.

 

[Andybr]

Robert.

A few years ago we had several instances of the same problem with 20-Comm-D modules. This was a known issue with Powerflex drives at the time and must have been resolved since because we have not seen the problem for some time. In our case the drive started seeing the 20-Comm-D as DPI port 1 instead of 5 and this conflicted with the HIM causing the drive to fault. The only fix was to replace the 20-Comm-D.

Andybr

 

[robertmee]

I hope that's not the case. These are all brand new, delivered in a Centerline MCC.

I did some further digging into the actual DPI event and it is 22, DPI Host Fault, whatever that means. None of the other drives are doing that, so it doesn't seem like it would be a Host issue which I assume is referring the CLX scanner.

 

[Andybr]

I doubt that it is the CLX module which is at fault. The DPI port is used for comm's between the 20-Comm-R module and the actual drive. The CLX is connected to the RIO side of the module. One quick thing which you could do would be to check that the small flexible PCB which connects the 20-Comm-R to the drive is properly connected to the drive. You will need to remove the screws which hold the module in place and move the module forward slightly as the connector is behind it.

Andybr

 

[msmassey]

I had a similar problem on a 700S. Ended up there was a bad cable connection on the internal of the drive. It would run fine for several hours and then absolutely fry the R-Comm card. After going through several cards, I 'made' AB send me a replacment drive and we have not had a problem since.

 

[gmferg]

Had similar problem with 20-COMM-D, replaced with new one and all was fine.

 

[robertmee]

Thanks for all the replies...I'll have an electrician check on the connection. Not an easy task since the drive is in an MCC which they've rated as a Class 4 Arc-Flash hazard. They have to dress in a Moon Suit just to open the door (which is why we paid extra to put the HIMs on the outside).

 

[bobrapp]

Terminated - Yes, both ends
Blue Tube - Yes, standard Belden
Anything Else - 9 Powerflex 70's, nothing else
BTW/BTR - Yes

ControlLogix is not as robust as PLC5 when it comes to communications and the DHRIO. When using BTW/BTR it is desirable to only have one BTR and one BTW each active with each RIO scan. I normally do this by including XIO instructions for all on the enable bits on each message rung. This insures that each will execute prior to allowing another to start.

Is it necessary to use the BTR/BTW in your application. All the drives I have driven with RIO have used the polled inputs and outputs only.

Bob