By default, E3+ overload relays have a "reset" button that doubles as a "test trip" button

Long time, no blog!

At work the other day we came across an interesting situation. We had a motor that we just couldn't get started. Wiring was good, communication was good, no faults being recorded...but every time we hit the start button the motor instantly tripped.

Here's how we figured out the issue.

At Vanscoy, all of our big expansion project MCCs (motor control centres) use E3+ relays and DeviceNet for motor protection and control. These relays are like the circuit breakers in your house; they trip if there is too much current passing through them, but unlike your home's circuit breakers you can program them with more advanced and specific settings for different types of trips.

While in your house you switch a tripped breaker back to the ON position to reset it, these E3+ relays have a "TEST/RESET" button on the front. If your motor pulls too much current, the E3+ trips to protect the equipment, and an operator has to go hit the reset button to clear the fault.

(the faults are also re-settable over DeviceNet, so programmers can enable different behaviours like reset functionality with an HMI or a field stop button)

There is a programmable "Test Enable" parameter (#103) in the E3+ relays. When enabled, this parameter changes the changes the behaviour of the reset button on the front of the E3+ as follows:

• An instantaneous TEST/RESET button press clears the faults/trips from the relay and allows you to resume operations. 
• A button press >= 2 seconds generates a test trip, causing your motor (if running) to stop. 

A potash mill generates a lot of dust and humidity, and mechanical devices - including buttons - are failure-prone. What we had here was a sticky reset button that was maintaining a test trip. As soon as the motor was given a start command, it would trip. 

The solution was a two-parter:

1. Fix the sticky reset button (we don't want faults to be instantaneously cleared without properly understanding them) 
2. Disable the "Test Enable" parameter on the E3+ so that the "TEST/RESET" button could only clear faults, not generate them. 

Taking a step back, our problem was that we never bothered to understand what the "TEST" part of "TEST/RESET" meant - we had no idea this "Test Enable" feature existed, and didn't know the single button (that we thought was simply a reset button) had different functions. 

I think the "Test Enable" feature is a probably a good one. During construction and commissioning, being able to generate a test trip allows for testing the trip protection on the relay, as well as the functionality of any PLC monitoring the trips. 

But for anyone searching the 'net for E3+ relay info - I'd recommend that as part of a commissioning procedure, the "Test Enable" parameter be disabled as one of the final steps. This insulates plants from tricky-to-troubleshoot failures caused by sticky reset buttons. 

DeviceNet Troubleshooting

DeviceNet... she is a fickle mistress.

I am wrapping up a big expansion project at a Saskatchewan potash mine that included a pair of GE Fanuc RX3i PLCs, lots of IC694DNM200 DeviceNet modules on each PLC, many, many E3+ starters, and several Rockwell VFDs (700, 700H models). On this project we have encountered some frustrating and mysterious DeviceNet problems.

If you're banging your head against the wall with your DeviceNet network, or can't figure out how to get your PLC to recognize a node, here are my tips:

1. Search Google for "turck devicenet troubleshooting guide 2.2". Download the PDF. Read it from front to back. It is your new bible. Carry it with you everywhere and sing its praises. Most problems that you encounter while commissioning a new DeviceNet network (or making modifications to an existing network) can be solved with this manual's guidance.

2. After an unscheduled plant-wide power outage, we'd sometimes lose nodes - a VFD or E3+ that was happy a day earlier would disappear from the network entirely when everything was powered back on. Not visible on the PLC, not visible with RSNetWorx. On the Rockwell VFDs (on the 20-COMM-D module), the PORT light would be solid green, MOD flashing green, and NETA solid red. Check the following, in order of ease:

a. Power cycle the VFD/E3+/starter in question. Maybe it just needs a power cycle to register on the scanner (ie, your PLC).

b. Check the node address of every. single. node. on your DeviceNet network and make sure there are no duplicates. If someone has inadvertantly created a duplicate address by changing DIP switches, this will cause network problems the next time everything starts up. Make sure each node address matches what is configured in your PLC. You never know who has been sneaking around in your MCC, so don't rule this out.

c. If you are using auto baud rate on your scanner (PLC), power down your non-working node. Change the baud rate on the node from "auto" to match whatever the network is actually running at (125, 250, or 500 kbps). Power up the motor again. Does it work? Wow, magic. Power it down, set it back to auto baud, and power it up again. It should still work. This just happened to me a few days ago on a Rockwell VFD with a 20-COMM-D DeviceNet module. This was after replacing most of the hardware and trying most of the other solutions I've listed here.

d. Power cycle the DeviceNet network: make sure all DeviceNet power supplies are turned off (there can be multiple 24V power supplies per network, so keep your eyes open!). Caution: this impacts communication between all the nodes on your DeviceNet network and your PLC. I've seen nodes return to life after a network power cycle.

e. Power cycle your scanner / PLC. Caution: this impacts your whole process, in my experience it's only possible on a shut-down day or during commissioning. I've seen nodes come back from the dead after power cycling the PLC.


Got any other tips for fixing bad DeviceNet codes? I'd love to hear about them. Send me an email (neufeld@brahm.ca) or leave a comment on this post. Thanks and good luck with your networks!

Update Nov 2015 - In the past few years I've developed a much better understanding of DeviceNet... it's actually a reliable protocol, so long as it's installed and commissioned correctly. I am leaving this post online as a reminder of how frustrating it can be to work on a system that you don't have the proper experience or training on!

Commissioning

For the past week I have been working on our project site, commissioning equipment.

This means that construction builds or installs something, then our team fires it up and gets it running and tested.

I am working 16 hour days - but only because that is the maximum allowed by my employer. This makes for crazy shifts:
Saturday: 11am-1am
Sunday: 11am-4am
Monday: noon-3:30am
Tuesday: 1pm-5am
Wednesday: 2pm-6am
Thursday: 4pm- ???

See a pattern?

I haven't had time to see Robyn, my friends or my family since Saturday; I haven't even seen my roommate for more than 5 minutes this week.

On the upside, the work is very busy and I am learning a lot. I've probably learned more in this week than in the last year - it's just so hands-on, and there are so many problems to solve.

Despite the fun and interesting work, this is an unsustainable schedule. I am looking forward to things going back to "normal".

PS. Robyn and my parents are awesome; they both cooked a bunch of food for me that I've been bringing to site for my meals (since I have zero hours to shop, cook, or even do laundry).

Edit: I wrote this at 3:15pm in between a bowl of cereal, and going to work.