AB Ultra 3000 Servo E55 Fault

[ponycar17]

I'm writing because of a recurrent AB Ultra 3000 Servo Drive E55 fault in one application in our facility. When the fault occurs, the drive is out for the count. Parameters can be reloaded using Ultraware, but they will be lost on the next power-down cycle. From what we can understand (per AB), this is a non-recoverable, generic fault.

The affected drive is a 3 kW Ultra3000 with DeviceNet communication and 24VDC control input. The motor connected to the drive is a PML series AB servo motor.

An identical drive sits beside this one in the same panel, on the same backplane, with all identical components except that it has a smaller motor and controls a different area of the machine. Also, the smaller motor application doesn't have DeviceNet parameters written to it very often; the larger one does... We have verified that the memory being written to doesn't have a limited number of writes available, as with an EEPROM. 24VDC IO is routed in the same panduit to a Flex I/O system on the back side of the panel for both drives. We do not get the fault on the drive with a smaller motor.

The same drive application has failed throughout the plant with the same E55 fault, so this isn't an isolated problem.

Do any of you have any brainstorming ideas to throw out concerning the problem?

Thanks in advance! All help is appreciated!

 

[controlsdude]

Is their a way to download the devicenet configuration into the drive on power up? This would be before you give the DevicenetCommand.Run bit to on. Not that familar with the Ultra3000 devicenet.

Can you battery back up by UPS the Devicenet Scanner Card Rack so that the devicenet network is on during power cycle off?


This is a bunch of ifs not knowing your setup or design.
If you cannot download drive config on power up! and If you have a contrologix processor.
Use the Motion module configuration to hold its config then use the sercos network to download its config.

Have you considered using Sercos network instead of having the drive on Devicenet? This way you can download the drive configuration on power up. This would be fiber and can be easily installed by plastic fiber ( premade cables) if the distances are not too long, otherwise its the glass and then you have to polish the ends.

Just a thought.

 

[ponycar17]

Controlsdude, something you said sparked an idea out of one of my coworkers. The system always fails on power-up, and only one drive fails. The drive that fails is the first in the scanning sequence on the DeviceNet. My coworker suspected that the DeviceNet may be trying to write data before the drive is ready, and therefore corrupting the drive. He surmised that we may delay the DeviceNet scanner enable signal by 5-10 seconds on power-up since we already have to wait for our PanelView to boot up. Whether this is correct or not, we don't yet know, but at least there is some sound logic behind it.

Unfortunately Sercos is not an option. This is a packaged system from our central engineering group, and we have our hands tied on a plant level.

Thanks for the suggestions!

 

[controlsdude]

So was this the problem?

I have been away, but if you could get the ready signal back from the drive or/and good comms to that drive, that would be a guarentee that when that event happens, then you would be able to download the configuration to the drive. Maybe that would be an additional failsafe on download of config to drive.

 

[pimpim32]

Any lights on this matter?

One of the application I have done before used an U3K drive with 1326AB servomotor. After 5 months the drive came up with E55. AB customer service told me E55 is noise related. I replaced the drive and second time made sure no extra noise exists in 24VDC for dnet. After another 5 months E55 came back again. Now I gave a bunch of things for the plant maintenance guys to do but they never told me if they did anything. ( I am in Toronto and the client is somewhere in Nebraska) From one year now never heard of them.

However I would like still to know what's the cure/cause for the E55.

Thanks
Marian

 

[ponycar17]

pimpim32,

We have had MANY of these U3K drives fail and have talked to Rockwell extensively regarding the matter. Their initial response was that E55 is a "catch-all" fault, and usually was a result of noise. After some further analysis (some of which we are still awaiting to hear back from), they found that a bad batch of EEPROM chips had been installed into the U3K drives with date codes prior to 2006 (I believe that's correct). These EEPROMs were failing and causing E55s, which led AB to believe that the memory had been corrupted because of noise or repeated writes. That was not the case. Now, even after their claims of no problems past 2006 (I believe that's the date), we're still having drive failures for drives produced after 2006... There's no word back on the detailed analysis that we asked for. If you ask me, AB has handled this situation very poorly, as they have with another drive we've experienced problems with recently. It's like we're having to guide them to the problem in most situations as of late...

 

[pimpim32]

Thanks Pony,

This application being my first with U3K as well as with DNet, I could not at that time to argue much, as it could have been a mistake from my part.

I am not an expert in EEPROMs either, however all info I gathered about Data Personality Corrupt leads to the fact either something is writing too much to EEPROM or is writing before checksum verification.

So you coworker looks like had a good idea to delay the scanner for a couple of seconds. Did it happen again after that?


Another thing they told me, my supplier technical guy, was to flash the drive to the latest and greatest firmware. Did you flash them ?

Anyway now from what you are telling is either as you said some bad EEPROMS, or they have poor written firmware for data management on EEPROM, but still they should do something from their part and give us a fix, not just to say that it noise related and is our problem to supress all the noise.


Regards
Marian

 

[controlsdude]

I have had dcomm cards for devicenet go bad on vfd drives. Their has been some issues but no response from AB on why the dcomm cards go bad. Their usual response is noise on the line. I believe all the devicenet was routed away from other voltages as much as possible. I mean if you look at the connections they are very close to each other, low voltage, 3ph line in, vfd 3ph out, and the comm card. Their must be some isolation issues on the front end of the dcomm card to make it blow its devicenet comms +/-.

I have used devicenet download on vfd drives and seems to work very well in version 16 release or version 8 rsnetworxs for devicenet. I believe their was a problem with prior releases on it but that is not saying much.

I have not updated firmware on drives but on all their cards and processors. I believe it would work the same on control flash. I usually try not to change the firmware but update the software that I am using, its a vicious cycle.