Smart MCCs

Status
Not open for further replies.

nhee2

Senior Member
Location
NH
What are people's thoughts and/or experience with using digital controls in an MCC application. I have used network comms to monitor status of starters/OL etc. but have always performed the start/stop using a hardwired contact.

HAve others used network comms to start/stop motors and if so, are you happy with it - if not, why not?
 

tom baker

First Chief Moderator
Staff member
For new applications I would use Ethernet/IP for communications, its the de facto industrial control standard. We network and control our VFDs via Ethernet, there are Ethernet overloads with I/O that the start stops can be connected to.
Ethernet will allow you to bring back any of the drive parameters, motor info etc.
But you need someone who is knowledgeable about networking and troubleshooting,
AB/Rockwell has a lot of information available on this.
The buzz word is "the internet of things"
 

nhee2

Senior Member
Location
NH
Thanks.

To be clear - i am talking more about controlling non-reversing starters via networked starters (such as AB E300). I understand your comment on VFDs. For whatever reason i would be more likely to use network comms to a VFD than a 'traditional' starter. Which admittedly really doesn't make any sense, but that's why I asked the question.
 

Jraef

Moderator, OTD
Staff member
Location
San Francisco Bay Area, CA, USA
Occupation
Electrical Engineer
I do Ethernet I/P now almost exclusively. The idea that hard wire is somehow “safer” doesn’t fit with my experience. I’ve run into far far more mistakes in hard wiring than I have ever seen in network control. When people were standing next to machinery all the time and interacting with it, hard wire control was fine because if anything went wrong, a human was there to intervene and trained on the complexity and interoperability of the entire system. But those days are gone now, those jobs have been eliminated. So when something goes awry, all that complexity is being handled by the control system anyway and hard wiring just means it takes a long time to find and repair a problem. A properly trained technician can find and fix a network control issue very fast, partly because if properly set up (using managed switches), the network will TELL you right where the problem is. Do you try to find and fix it in a solid state OL relay? No, you swap the bucket out and take it to the bench to diagnose later when you have time.

My old partner (now retired) famously stated to me once in front of our rock plant customer, “If I can’t check it with a Wiggy, it ain’t worth sh*t!”. The end user decided to go with an Ethernet MCC anyway and they love it. The plant has never run more trouble free in its 40 year history.

That said, I also believe in having an HOA switch on each starter, because bump checks are a PITA over network control. Then having the HOAs give people that necessary “warm and fuzzy” feeling of control should the network go down. It’s not likely realistic that you can operate a complex system that way, it’s more of a placebo effect.
 

Ingenieur

Senior Member
Location
Earth
for control functions like start/stop, etc ok

for safety functions like ol's, they must override all other control and be hardwired imo
eg, high limits, e-stops, methane gas shutdowns, fire, etc

we require do's to be contact type, not solid state
in most cases we require a seperate safety relay/processor if the plc is used for safety functions
 

petersonra

Senior Member
Location
Northern illinois
Occupation
engineer
I like the idea of ethernet control. it is a little pricey but it actually makes the install simpler and adds a lot of diagnostics that you probably would not bother with otherwise. it reduces the human factor a lot which is where most mistakes get made.

i would say to skip on devicenet if it is offered to you though. Especially if it is an AB Devicenet product. I have had pretty good luck with other DN products but it seems like everytime I use an AB DN product I have trouble somewhere. Devicenet is pretty much obsolete anyway so why invest in something that is all but obsolete. Might as well buy a bunch of PLC2s on eBay and use them. :)
 

nhee2

Senior Member
Location
NH
thanks to all for the input. I agree with the points regarding H-O-A switches and hard-wired interlocks for independent interlocks/protections.

philosophically the Ethernet smart starter not much different than sticking a Flex IO module in the MCC and hardwiring into the motor circuit. The smart starter seems simpler and likely as/more reliable.
 

Jraef

Moderator, OTD
Staff member
Location
San Francisco Bay Area, CA, USA
Occupation
Electrical Engineer
for control functions like start/stop, etc ok

for safety functions like ol's, they must override all other control and be hardwired imo
eg, high limits, e-stops, methane gas shutdowns, fire, etc

we require do's to be contact type, not solid state
in most cases we require a seperate safety relay/processor if the plc is used for safety functions
In any Intelligent MCC, the smart OL relays are still hard wired into the contactor and function as an OL relay regardless of the network status. Likewise any I/O connected to them. The only exception is, as you say, Safety relays. You can already do STO on VFDs over the network on some of them and it's coming soon to an OL relay near you, likely next year..

I like the smarter ones like the E300, because I can write a little mini-program in them (like those "smart relay"/micro PLCs) so that all of the I/O associated with a starter goes into the OL, then that ports it up to the network. The first line of logic in the OL relay program is to check the network status and if the network is live, it jumps the other programming. But if the network doesn't respond, the program in the OL relay takes over and does what the network would have done with regard to the associated I/O. Case in point is a Pump Control Valve, which requires inputs from limit switches and an output to a solenoid plus a timer function. I wire all of those to the OL relay, then if the network goes down, the OL relay internal program still operates the PCV correctly. Saves me from having to add control relays and timers to the starter bucket.
 

Jraef

Moderator, OTD
Staff member
Location
San Francisco Bay Area, CA, USA
Occupation
Electrical Engineer
I like the idea of ethernet control. it is a little pricey but it actually makes the install simpler and adds a lot of diagnostics that you probably would not bother with otherwise. it reduces the human factor a lot which is where most mistakes get made.

i would say to skip on devicenet if it is offered to you though. Especially if it is an AB Devicenet product. I have had pretty good luck with other DN products but it seems like everytime I use an AB DN product I have trouble somewhere. Devicenet is pretty much obsolete anyway so why invest in something that is all but obsolete. Might as well buy a bunch of PLC2s on eBay and use them. :)
Yeah, DeviceNet had it's day and that day has passed. When there was little else to choose from, it was the best thing going. One big advantage it had in its heyday was that the DN cable was rated for 600V, where other network cables were not, so you had to have separate wiring channels. But it also came with too much trouble; network wiring / trunk / branch cable sizes, power supply distance issues, terminators, Tees, blah blah blah. Once you got the hang of it, it was OK, but that took a LOT of on the job learning. I tried Profibus for a while with Siemens, but the support for it here in the US was just never there. Ethernet I/P is much more universal now and has taken over in North America.
 

Ingenieur

Senior Member
Location
Earth
we require ol and safeties that require local to the load manual reset
no remote reset
eg, from the surface to an underground belt starter

everything is monitored by plc

similar to elevator control where hardwired safties are required to remove power from the motor/controller

if sil level 3+ can be certified (by a 3rd party) we allow automated control
doesn't happen, too $$$

everything must be failsafe
broken or shorted wire
loss of comm/siezed processor
loss of power, low voltage
even hardwired systems must have 1 level of redundancy, most have 2
 

petersonra

Senior Member
Location
Northern illinois
Occupation
engineer
In any Intelligent MCC, the smart OL relays are still hard wired into the contactor and function as an OL relay regardless of the network status. Likewise any I/O connected to them. The only exception is, as you say, Safety relays. You can already do STO on VFDs over the network on some of them and it's coming soon to an OL relay near you, likely next year..

I like the smarter ones like the E300, because I can write a little mini-program in them (like those "smart relay"/micro PLCs) so that all of the I/O associated with a starter goes into the OL, then that ports it up to the network. The first line of logic in the OL relay program is to check the network status and if the network is live, it jumps the other programming. But if the network doesn't respond, the program in the OL relay takes over and does what the network would have done with regard to the associated I/O. Case in point is a Pump Control Valve, which requires inputs from limit switches and an output to a solenoid plus a timer function. I wire all of those to the OL relay, then if the network goes down, the OL relay internal program still operates the PCV correctly. Saves me from having to add control relays and timers to the starter bucket.

I did not know you could write code in the OL relay modules. I will have to remember that. Might come in handy some time.
 

Ingenieur

Senior Member
Location
Earth
eg
we do not allow the vfd internal ol's to be the only ones
we require an external ol pack
it trips the vfd feeder, not the vfd
we allow the internals to be used but set lower, but still no auto reset

we load test all vfd internal safeties for a given size/model
once tested that drive is approved and can be used without further testing (although the overall system it is used in is tested)
 

petersonra

Senior Member
Location
Northern illinois
Occupation
engineer
eg
we do not allow the vfd internal ol's to be the only ones
we require an external ol pack
it trips the vfd feeder, not the vfd
we allow the internals to be used but set lower, but still no auto reset

we load test all vfd internal safeties for a given size/model
once tested that drive is approved and can be used without further testing (although the overall system it is used in is tested)

UL tests the internal OL function in VFDs here. If UL: says it is good, it is good.
 

Ingenieur

Senior Member
Location
Earth
Safety systems are now available in Ethernet, IE Allen Bradleys Guard Logix

we have seen some distributed controller based safety relays
the system integrators/mfgs have not used enet to transmit say a gas alarm to shutdwon a power system
it is cheaper, easier to maintain and troubleshoot if hardwired

the fact that power must be interrupted and a pilot ckt that holds a uv coil in is required on every ckt it is easy to hardwire
 

petersonra

Senior Member
Location
Northern illinois
Occupation
engineer
AB has safety rated remote I/O that can be networked over ethernet that is attractive in many cases.

it seems like safety stuff gets more complicated as we try and integrate more and more safety features to protect fools from themselves. it is much easier to do this in software than hardwiring much of the time.
 

just the cowboy

Inactive, Email Never Verified
Location
newburgh,ny
When HMI's first came out.

When HMI's first came out.

I remember this same type of discussion in the 80's when HMI's came out. Do you put start/stop control on the HMI or hardwire it.
I did my first big project for batch control back with PLC 2 and Advisor PC from AB. Went with 48 sets of start/stop buttons and just use advisor for batch and display.

I also remember the same thing in the 90's with PLC5 and DH+ do you send start/stop over it. The answer I found out was NO not without proper handshaking.

Same thing now with Ethernet/IP

Cowboy
 
Status
Not open for further replies.
Top