U3K-DN drive E55 error

[pimpim32 0]

We have made about an year ago one machine with an U3K drive comunicating with ML1500 over DNet. After 5 months customer came back with the fact the drive giving error E55 at cycling power. From AB customer service they told us that it could be power supply (I admit, I was having about 5 relays in same 24VDC circuit) Ok, put new power supply only for DNet, changed the drive everything ok. Now after about again 4-5 months same error. I am thinking that maybe the program is writing continously to EEPROM, but it wasn't done that way, also we followed AB lab. Drive : 2098DSD - HV150X-DN PLC : 1764 - LRP ML1500RS - 232 I am attaching all programs related and also AB lab for connecting an U3K to ML1500 over DNet, hoping maybe somebody can see the problem. Thanks for your help, Marian U3K.ZIP

[jstolaruk 9]

E55 is not a documented error code in the manual (reserved). What did A-B say it was for?

[pimpim32 0]

A-B told me that it was for "Personality EEPROM data corruption" and is noise related, when they found out that I used relays in same circuit with DNet they declared cannot be anything else.As being far from an expert in DNet I accepted the answer, put a new power supply dedicated for DNet and the drive changed under warranty. After my discussion with them on knowledge base appeared technote E10542878 I do not know if it was related to me as my axis didn't trip, the error coming up only at powering up. E55 in book is under reserved. However if we take a look at parameter instance 150 Get Fault history errors have same numbers as in error code and at 55 we have "User NV Checksum" Search text on AB knowledgebase with NVMEM came up with four technotes, all related to U3K and DNet. I do not know if they were there 4 months ago but sure they are now. When I made the program I made sure not to write to NVMEM ( instance ID 9, byte 4 bit 6 always 0) but now they are saying also parameter 114 should be set to 1. I do not need to write to NVMEM on operation, only on setup when dowloading Ultraware file. Except those two things is there anything else to make sure nobody is writing to NVMEM? Also do they have somewhere a counter with the number of writes at NVMEM? (And still I can't make the connection between noise and NV checksum)

[jstolaruk 9]

When you say that you are using relays in same circuit as DNET, what does that mean exactly? What I'm getting at is that the error that the drive is reporting may be erroneous, but it does point to something it doesn't like. Can you describe exactly how the relays are connected or interacting with the DNET? I am currently commisioning a project with (4) Ultra 3Ks using DNET and the panel is filled with starters, soft starts (200hp), and relays within inches of the DNET and Ultra and am not experiencing any problems. Can you post the electrical drawings?

[jstolaruk 9]

Nothing jumped out at me as being irregular in your logic. I use the same assembly objects with the Ultra and it looked OK to me.

[pimpim32 0]

Nor to me ... However I believe something is writing to NVMEM after or before full powering up/down hence checksum is not the same anymore, hence error. I will ask the guy to change parameter 114 from 0 to 1. I have seen on internet some sites about EEPROM's corruption when powering up/down due to some reset procedures. What I want to make sure is from my part I am not writing anymore at NVMEM during operation, or powering up/down.

[pimpim32 0]

First power supply was Weidmuller. Second what I added only for DNet is also Weidmuller, but only 1A. Grounding is done not through the plate, but separate grounding wires. Termination resistor they are there, but now I do not remember if they were metal film or carbon. Do you think will make a big difference if yhey are not metal film?

[jstolaruk 9]

Personally, NO, but I've had people tell me with more experience that it can make a difference. I have had servo applications where a full grounding of the drive chassis made the difference but I recall it was with Lenze drives, not A-Bs. Its definetly application dependent.

[pimpim32 0]

Thanks jstolaruk for your help. First word from my supplier guy is to flash-upgrade the firmware ( honestly he said that also first time, but my customer said he has no time for downtime and asked for a replacement). Still waiting for AB guys.