Pflex 70 Comm Loss

Hey All.

First time with a PFlex 70.

This week I opened the drive, added a safety module, added the 20 comm e module, and put in into a PLC project. It was simply a test project, it went well, no issues. I was online with the drive and controlling it.

Today I added this drive to my real process. It came in already at firmware 5 so no flashing required. I added it to the PLC project, no problem, downloaded my project to the PLC, powered up the drive and all is good. In my controller organizer, it is ok, no yellow triangles. I can click on the drive properties and see that the drive is owned, in run mode with no faults, also I have a module identity match.
Now I go to the drive tab and it connects no trouble. At the top of the page it says Connected in green and I can see that there is a 20-comm-e on port 5 and 20-him on port 1. However, there is a red "Comm Loss" just under the revision portion of the display. I have tried defaulting the drive memory parameters and uploading from the drive to the PLC thinking I might have given it a bad parameter but no luck.

Software is RSL5K V20.18
Drive is PFLEX 70, EC-E, 50 horse power 600 VAC.

I have attached a few pics to help tell the story.



I cant call Rockwell till Monday so I'm looking to see if anybody has run into this before.

Any help is appreciated.



Thanks

You can check to see if this is a network or configuration issue by doing the following:

Get the drive on the network.

Start-->Run (or windows key + r)
type "cmd"
type ping -n 1000 <IP address of the comm-e module>

Go grab a cup of coffee. It will take a while, and it may "stop" on the last packet and not give the report. Just hit CTRL + C at this point and you can break out and see your packet loss %. You should have zero. It will also give an average time, highest and lowest latency. This will help you test the overall connection so we can start narrowing down the issue, and determining if it is configuration or network related.

Anywho, we will also want to see what processor/network adapter you are using and a bit more info on the network connection (as mentioned above. Simple switch to connect components in cabinet, across a plant floor, etc)

I have seen everything from a bad ethernet port, to a switch port forced to 10MBPS half duplex causing comm drops to a bad pair of crimpers not completely crimping a pin on the RJ-45 jack.

My vote is for this being a software issue with the embedded drive configuration applet inside Studio 5000.

If the drive isn't actually faulting, and the I/O connection is steadily in a RUN mode, then it's probably not a network integrity or performance issue.

Unfortunately I don't know what to recommend with regard to the software not being able to connect to the drive. It's as though the path that the embedded drive manager applet is following doesn't lead to the drive itself, while the path encoded into the I/O tree does.

Ken Roach said:

My vote is for this being a software issue with the embedded drive configuration applet inside Studio 5000.

If the drive isn't actually faulting, and the I/O connection is steadily in a RUN mode, then it's probably not a network integrity or performance issue.

Unfortunately I don't know what to recommend with regard to the software not being able to connect to the drive. It's as though the path that the embedded drive manager applet is following doesn't lead to the drive itself, while the path encoded into the I/O tree does.

Click to expand...

I agree with you as well here Ken, but this is an easy task to eliminate this issue. I have had problems with the COMM-E's getting buffer overflows in the past and having poor response times, though the software should take care of that. Plus, I'm pretty sure the drive would only fault out on COMM loss if you set it to, otherwise it maintains it's current speed and status.

Good points !

Yes, the COMM-E was notorious for not handling multicast rejection as well as it could. Systems that used IGMP filtering had no problems (because the COMM-E never saw the multicast traffic) but systems that used unmanaged or misconfigured switches did. The advent of default unicast I/O has largely eliminate those issues.

The default behavior of the drive on I/O connection loss is to fault, of course. OP could check that. But the connection status (visible onscreen in Studio 5000 and in software readable with a GSV) will still change if the I/O connections are faulting. The runtime of the I/O connections will also be visible in the Connections tab of the built-in Ethernet webpage for the controller.


The 20A-DG01 DriveGuard safe torque off module isn't involved with the communications, but any time you disassemble something there's a chance that a ribbon cable got loose.

Ken Roach said:

Good points !

Yes, the COMM-E was notorious for not handling multicast rejection as well as it could. Systems that used IGMP filtering had no problems (because the COMM-E never saw the multicast traffic) but systems that used unmanaged or misconfigured switches did. The advent of default unicast I/O has largely eliminate those issues.

The default behavior of the drive on I/O connection loss is to fault, of course. OP could check that. But the connection status (visible onscreen in Studio 5000 and in software readable with a GSV) will still change if the I/O connections are faulting. The runtime of the I/O connections will also be visible in the Connections tab of the built-in Ethernet webpage for the controller.

The 20A-DG01 DriveGuard safe torque off module isn't involved with the communications, but any time you disassemble something there's a chance that a ribbon cable got loose.

Click to expand...

Right on with this one! Either way we are both shooting in the dark until he gets us some more info, though. If I had to choose though, I would go with your assessment as you have been at this many moons longer than me.

Hey All.

So, It seems ok now. I closed the software Saturday morning just after posting my troubles here on the forum site.

After a couple hours of noodle scratching, testing network cables, uploading, downloading and really just grasping at straws I left for the day feeling defeated.

I decided to log in that night since I had some spare time and my plan was to delete the drive from the project and start over as I was certain that I must have done something wrong. To my surprise, when I got online with the drive, it was happy now. It connected the first try. Since then I have been connected continuously and I have went offline and online several times just to make sure it is good. I can adjust parameters and it seems normal.

I have yet to actually run the drive but so far it looks promising.

So I m not sure at this point what the problem was. Simply closed the project, checked it into asset center, checked it out of Asset Center and re-opened it. I do thank you for the advice and if this drives does anything else out of sort I will post it.

Thanks Again.

NOT SO GOOD AFTER ALL!!!!

So, now it will not connect to the drive at all.

I spent the morning connected to the drive, going over motor parameters and interlock logic and such. i gave the drive a successful start command from the HMI and it started. Then I stopped it. I then noticed that my software gave me a "fatal application error encountered message" and the software was frozen. I re-started the software and now, I cant get to the drive parameters anymore.
It still is being controlled by the PLC and HMI ok, it still shows up ok in my project manager, it still connects and says that it is owned, ready, not faulted and so on, but when I try to open the drive parameters, it gets stuck on the "correlating with online drive, trying to connect". It just sits there with the progress bar only about 5%. I can still connect using CCW though and can go online and see all the parameters with CCW.

What is going on here????

Any help will be appreciated.

Thanks

I figured out that with a computer re-boot, I can open the RSL5K software and successfully connect to the drive, a few moments later, I get the fatal application error, and I can then do nothing but re-boot the computer to re-connect to the drive.

This only happens when connecting to this drive, I can connect to any other through the software trouble free.

Thanks

Rockwell says.... I have downloaded the wrong AOP to my PC.

I used RA_DrivesAOP_Ver_4.09

When I should have used RA_DrivesAOP_Ver_4.08.

There ya go.


They say that now I have to jump through 100 flaming hopes to get the wrong AOP off of my PC but they are supposed to be giving support on that process as well later today.

I hope this all goes well!

Lesson learned, READ THE RELEASE NOTES, then,, READ THE RELEASE NOTES AGAIN... Then review the release notes.

Thanks All.

Not over yet...........

SO based on this little piece snipped from the install notes of the AOP in question here..

** IMPORTANT **
((((((There are three known issues associated with this version:

Limitation of Use to RSLogix / Studio 5000 v20 and later
v16 to v19 of RSLogix 5000 cannot be used with the v4.09 AOP and must not be present on the user’s PC. An anomaly in RSLogix 5000 may result in errors when creating and editing a drive. A warning message is displayed prior to the install.

Temporary Workaround: None.
Solution: A v4.10 AOP will be released to the PCDC after the fix is available.)))))

This is how AB tech support determined that I likely had installed the wrong AOP. They were going to call me back later yesterday afternoon with the right people to try and help me straighten my computer out. They did call me back much later, but they are now telling me that they are not so sure that the AOP is the culprit anymore. They said since I am using version 20 of the software, than technically it should work anyway. So now I am waiting for them to call me back today to take another crack at this.

I don't get the warm and fuzzy feeling that Rockwell is even sure what's going on with it as the call from them last night was that they were thinking anti virus software could be casing some issues.

Thanks for the updates. Hang in there. AB tech support is pretty good at what they do. Every time I have used them they have ended up solving my issues.

So,,, After much head scratching and several calls to and from tech support I think its solved.

They thought at first it was the AOI I downloaded, not so. Then they suggested that it was my anti virus software. We determined that was not so. The last thing we tried was to go to the folder called TEMP and delete all 976 files that were living there. Now it is working just fine.

So I'm still wondering what caused the whole issue... Was it the AOP I downloaded after all, leaving something in that temp folder that logix didn't like?

What are these files anyway?

Thanks

I think it is a firmware/software glitch; the AOP should contain all the information the software needs to connect a system to the respective device's firmware.

This is generally true across the entire RA/AB platform.

However, sometimes, there is a disconnect between the team Allen-Bradley and the Rockwell Automation one and, even if the "right" AOP had been installed, the software and/or system cannot fully functionally connect to the peripheral device.

I've encountered quite a few instances where I had to use the Match Drive feature of the VFD Module install applet and Upload a VFD database in order to properly add the device to a system.

Perhaps I will try this feature out. I have not used the Match drive button. I have always been able to get the database from the web. Looks like some research is in order. I have never used it simply because I don't fully understand what its going to do. Does it match all the drive parameters?