Powerflex 700 drive issue

Hello,

I am having an issue with a Powerflex 700 drive faulting intermittently (but regularly) on port adapter 5 (code 75). The fault text says, "Check DPI device event queue and corresponding fault information for the device." I am using a 20-COMM-E adapter and the event queue indicates a Code 25: EN Close Flt followed by a Code 26: EN Idle Flt whenever the drive faults. Not being an expert with Ethernet, I can’t seem to find anything wrong. Everything appears to be configured correctly and the connection works for different periods of time (but only a few minutes, max.). I have isolated the network so that only the PLC, one drive, and my laptop are connected (I thought the plant internet connection may have been causing the problem). The IP addresses and subnets are all OK and BootP is disabled. Parameters 51 and 53, EN Rx Errors and EN Tx Errors, respectively, are both zero (though at one point, parameter 49, EN RX Overruns, was non-zero – it is zero now and I have a fault). This has been incredibly frustrating so any help would be greatly appreciated. Thank you.

I would replace or switch the 20-comm-e. I recently had the same problem with a 20-comm-r and it was the module.

While I won't discount the possibility of a defective 20-COMM-E, the fault codes you are describing point to the Ethernet network, not the module itself or the connection between the module and the drive.

Check the firmware revision of your 20-COMM-E and your PLC's Ethernet module, and of course check the controller if it's ControlLogix for the infamous 2007 "Atmel 64" issue. That caused me more than a few headaches on EtherNet/IP drive systems before the problem was characterized, because I was chasing noise and 20-COMM-E's instead of looking at the PLC.

A DPI module that itself faults (like with a defective power component or an internal microcontroller fault) will show up as an error code 8x (85 in your case). A fault that happens when the DPI module gets a logical connection failure on the Ethernet side gives you a 7x (75 in your case) fault code.

Check the Ethernet diagnostics on the web page for the PLC's Ethernet module. You want to check both the media and port statistics as well as the I/O Connections page, which will show a connection uptime timer as well as an important "lost packets" counter. Anything but zeroes in those counters is important.

It's actually encouraging that you get a fault every few minutes; it tends to point to something badly broken, rather than something happening very intermittently.

Tell us more generally about this drive and its circumstances; was it running well and then began to fail ? Are there other similar drives on the network running correctly ? Is this a first-time startup of this drive ?

Thanks guys for your replies. Jac, I got your reply almost immediately and swapped out the card with another from a drive that they blew before I arrived on scene (hopefully the card is OK and I realize I may be substituting one bad card for another). I was hoping to let you know how it went but I ran out of time before I had to leave for the day. I will continue tomorrow.

Ken, thanks for your detail (you've helped me many times before with answers to others as well as myself). I too tend to shy away from blaming the hardware, but if there's a precedent, I will definitely consider the possibility of a malfunction. What I can tell you at this point is that the machine is using a compactlogix controller (1769-L32E) v19 firmware, and is connected via Enet to an IPC running FactoryTalk View 6.0, two Powerflex 700 VC drives (1 and 3 HP), and a pair of Micro 1200's (I've disconnected these for now) as well as their office network (which I have also disconnected and reconnected several times with no effect).

In switching out the cards, I did notice the original card was a 3.004 rev, while the 'new' one was 4.001. The new one enabled unicast (which I read in one of the manuals is recommended). It took several downloads to get the new IP to take but I couldn't get the subnet to take. I noticed that BootP was enabled, and while I would disable it, it didn't seem to take either. I went through the procedure of resetting the card after the changes both with parameter 20 of the 20-COMM-E, and by cycling power to the drive. I will try again tomorrow as I was getting pretty tired at this point, having skipped lunch.

I did get both error codes 75 (all the time) and 85 (when I started messing with settings and cycling power). After switching out the card, it didn't fault again, but looking at the diagnostics page of the 20-COMM-E, I wasn't sending and receiving any packets either. I still have the BootP issue to resolve.

I did look at the PLC diagnostics page and while I don't remember the settings you specified (as there are many parameters), I'm pretty sure there were no lost packets - that's one thing I was looking for. Again, I will look at this fresh tomorrow.

This is a fresh startup of a prototype machine, though I'm told the previous programmer (who has since left the company) had things jogging around. I'm not so sure. One other issue, they are using a Phoenix Contact Lean Managed, 8 port switch. Again, my experience with ethernet is limited, but I have used this switch before, and it had to be configured correctly. They are telling me that the switch was mounted and no changes were made (Phoenix told them they didn't need to change anything). I was unable to connect to it's web page to verify any settings. I will try this again tomorrow as well.

Thanks again guys. I hope I didn't blather but I wanted to give you as much detail as possible.

I always set up my 20-COMM-E modules using the HIM module on the drive, so that there is no question about pending/applied parameters or state conflicts.

Error 85 is typical when you reset the 20-COMM-E using the HIM module or otherwise reboot it, so don't sweat that. That error code indicates that the drive can't talk to the peripheral over DPI, whereas Error 75 indicates that the drive is talking to the peripheral, but the peripheral is not talking to the network.

I like those little Phoenix LM switches; the -E versions have the IGMP Snooping and Querying turned on out of the box.

http://www.phoenixcontact.com/automation/32119_32472.htm

While the 20-COMM-E has less capabilty to reject extraneous multicast traffic, just one other drive won't cause it problems. Either verify IGMP Snooping and Querying, or use Unicast.

There have been two common problems with the 20-COMM-E in the past six years or so; there were some bad voltage regulators in 2004 between date codes 0904 and 2704, and there was firmware revision 3.001, which should have been sent to bed without its supper.

The version you have, 3.004, should be solid.

A diagnostic question: do the drives fault when neither drive is running ? The Ethernet traffic doesn't change when the drives run, but the electrical noise in the environment certainly does.

And the I/O connections:
Conn S# / UpTimeRcv/XmtConnection IdSourceDestMulticast AddressRPILostSize17(Loc) 2(Rem)Rcv0x810201192.168.100.209 (T)192.168.100.2085 0 1600h:24m:14sXmt0x33340000192.168.100.208 (O)192.168.100.2095 16

Sorry about that. The thread is not maintaining the formatting. Basically the I/O connections page is indicating zero lost connections.

Not a bug, a feature

Let's take a big step back and think a bit.

The PowerFlex drive can can respond to two different status conditions involving the 20-COMM-E; Comm Idle and Comm Fault.

The default behavior of the drive is to fault (with an F75 code) if either of those conditions occurs. You can also set it to stop, or to carry on running in the last state, or to set a specific set of DPI parameters. I once configured a drive to run in reverse at 25% speed in the event of a communications fault.

If the PLC is placed in Program Mode, the I/O connection over Ethernet goes into an Idle state, and the drive will perform the action described by the Comm Idle Action parameter.

If the PLC is powered down or a new program is downloaded, the I/O connection over Ethernet goes into a Timed Out, then Closing, then Retrying state. From the drive's perspective, any of these are a Comm Fault condition and it will perform the action described by the Comm Fault parameter.

So now that we've taken a big step back: Could these faults just have been happening because you're commissioning the machine, and therefore often downloading and cycling power ?

I used to get that sort of complaint all the time from users: "These drives were always faulting during startup, but now they don't do it anymore" because the drives would correctly fault whenever somebody did a download, but they weren't noticed to be faulted until somebody went to start them.

The simple solution that I use is to set the Comm Idle and Comm Fault actions to "Stop".

Well, I appear to be up and running. The Idle Flt Action and Comm Flt Action are indeed set to fault. I understand what you mean about the constant downloading and power cycling causing problems. I have to make that argument to customers every now then myself. In this instance, however, that was not the case. I was getting strings of Error code 75 (Code 25: EN Close Flt followed by a Code 26: EN Idle Flt on the comm card) and the drive was just sitting idle (the other drive is still out for repair). I was downloading and cycling power to try to get it to stop faulting. It appears to be a bad comm card after all. I am going to try it (the old card) again with the other drive and double-check all the settings before I write it off. The only real differences between the two cards was the firmware revision and the setting of unicast on the new card. Perhaps I should flash the other card with 4.001 firmware.

The only problem I'm left with at this point is that Rslogix freezes if I'm connected to the drive too long. Any thoughts on that one? I didn't seem to have this problem for the short time after I installed the new card and still had BootP enabled.

Fault Code 75 ( PORT 5 ADAPTER)

Hello guys,

I get Port 5 Adaptor FLT#75 many times on PowerFlex 70 VFD. After reset VFD, it goes away. But happen once in 2 week.

My VFD is connected to 1771 - SDN module via DeviceNet

I am new graduate and not much experience in DeviceNet....

Need Solution.....

Thanks a lot guys...

RAJ, can you find out the firmware revisions of your 20-COMM-D card on the VFD? There were some known issues with certain older revisions that may come into play here.

Also, since your drive is a PF70 on DeviceNET, even though the error codes are the same, it is actually quite different than the PF700 on Ethernet, so a new thread may be in order.

Raj, please navigate to the main Q&A Forum page:

http://plctalk.net/qanda/forumdisplay.php?f=2

On this page, right at the top, there is a large green "Start a New Thread" button.



Use that button to create a completely new thread to discuss your new topic.

Moderator request: Please do not respond on-topic to this thread. Wait for Raj to create his new one.

New Thread

I created new thread ...

http://plctalk.net/qanda/showthread.php?p=580123#post580123


Thanks guys

Similar PF700 Issue

This post is almost exactly same issue I am experiencing with a few different details: System has been in place for 4+ years with no problem...There are 2 (nearly identical machines) that each have 6 Powerflex VFDs (5)( PF700 & 1 PF40) all communicating over an Ethernet Network... Problem started about 5- 6 months ago...When the fault occurs, it is for Port5 Adapter error.... The fault can occur a couple times within a few minutes, or it can be days in between 9but typically no longer than a week without a fault)...When the fault does occur usually multiple drives in each machine are affected (but not always all of them) and usually faults occur in drives of both of the machines at once...When the machines are disconnected from the Plant network there are no faults. (big clue I know!)..No other equipment on the plant network has these type of issues...The plant network consist of about (60) other AB devices including PLCs, HMIs, & VFDs and (of course) Data collection...for some reason only these (2) machines are affected...

So it seems apparent that something is causing the drives to fault when connected to the plant network, but I am not sure what the cause could be or even how to begin measuring or isolating the problem...Any help is appreciated .