Safety of disconnect vs. current switch monitoring for motor control

General Discussion
1

An electrical design/controls question:

In new installations, we’ve monitored all motor disconnects (MCC as well as local) via auxiliary contacts for years now and programmed PLCs to turn motors off when a disconnect is off and prevent turning them on until given a start command after disconnect is back on. This avoids unexpected starts when turning on a disconnect (contributing factor to some fatalities) as well as allows the HMI to indicate exactly why the motor won’t run (for example: “MCC disconnect off” or “Local disconnect off”).

When integrating new equipment into existing plants, this turns into more of a pain than it seems it should be. Often existing disconnects don’t have auxiliary contacts, long and inconvenient cable runs are required, and the main MCC breaker (upstream power) is often not easily monitored (while not the most likely scenario, turning on upstream disconnect could potentially cause on unexpected start if not monitored). It all can be done, but it tends to throw a monkey-wrench into standardization. Getting local personnel to actually get the disconnect monitoring in place often takes more follow-up from engineering than any other part of the job! So we’re looking at using current sensing relays mounted in the MCC immediately after the starters instead of disconnect monitoring.

Pros:

  • Simple install: one small item with two wires to add into MCC below each motor starter.

  • Economical: adding a conductor for $20 current switch to motor control cable we already run will cost less than getting a cable run for local disconnect monitoring, let alone replacing existing disconnects that don’t support auxiliary contacts.

  • Complete upstream & downstream monitoring: Prevents motor run (based on PLC programming) when 3-phase power is disconnected anywhere upstream or downstream of motor starter (for example, MCC supply and local disconnects at top and bottom of a bucket elevator).

  • Increased standardization: one input and associated fault does the job regardless of layout in plant where the system will be installed (otherwise, some would have one disconnect input for a motor, while others may have 2 or 3).

Cons:

  • Less specific fault info: HMI can’t point to the specific disconnect that is off. For example, “No current flow - check MCC & local disconnects” instead of “MCC disconnect off”.

  • No fault until start attempted: The fault would be triggered when current was checked a few ms after start command rather than when disconnected was turned off.

  • Turns motor off when disconnected, but doesn’t prevent start attempts which allows very short window for disconnect to turn on motor: This would be like motor starter auxiliary contact monitoring; it doesn’t prevent starting the motor, it just turns it off again in a few ms if there is no current flow. We’re not trying to prevent starting a motor while disconnected (it won’t start–that’s what the disconnect is for). We do want to make sure it cannot be left on while disconnected so that it starts unexpectedly when disconnect is turned on. Using this method, a start attempt nearly simultaneous with disconnect re-engagement could result in disconnect turning on the equipment, though that risk is limited to a window the size of the necessary delay for current sensing (based on one switch, we’re looking at ~200 ms + ~ 20 ms for PLC response). This is nearly–but not quite, I think–equivalent to the risk of disconnect being turned back on and run command being issued nearly simultaneously using the disconnect monitoring method.

We’re thinking of monitoring only one of the 3 phases for current. However, it seems this should be as reliable as monitoring auxiliary contacts in disconnects, and probably more so in some cases (non-permanently attached auxiliary contacts, or more disconnect locations than are monitored).

The less specific and delayed HMI fault display looks like a reasonable trade-off for the benefits above as long as we’re not missing something that would reduce safety. The third con is more concerning, though still likely safer than not monitoring all disconnects. We’re aiming to increase safety–as well as the other benefits–and want everyone to go home to their families well every day. While I was not involved in the controls design, programming, or incident, I’ve been to the funeral of a friend nearing retirement (while I was just starting my career) who was killed in an incident that would have been prevented if the PLC had turned off the motor when the disconnect was off (there were other factors too). I doubt the new worker who was sent to turn on that local disconnect will ever forgive himself for what he saw in the next second, though he was just doing as instructed.

What do you think of monitoring current rather than disconnects? Anything to add to the comparison above? Other suggestions?

1 Like
3

I would excise the word “Safety” from your description and your justification for this, as OSHA will clean your company’s clock if your lockout/tagout/zero energy procedures rely on such a status indicator. Such interlocks are equipment anti-self-destruct provisions, not personnel safety. If your application requires true safe-off electrical energy control, you definitely need suitably rated components, like true safety PLCs, and all of the safety-rated contactors that go with them.

That said, I would encourage you to use zero-speed switches (nc) on your driven equipment in your motor starter state machine/seal-in logic, as even a motor with a broken coupling will draw current. Modern VFDs know what their output load is, so they wouldn’t need this.

Anyways, OSHA mandates, via reference to NFPA79, that restart after a fault requires an operator action (pushbutton, whether real or HMI) in addition to whatever action clears the fault/restores power. Any circuit that would resume motion on closure of a disconnect is already in violation. Traditional starter “buckets” have their own control power transformer downstream of their disconnect, requiring an isolated “start” contact from the control system, specifically to open the starter contactor with power loss, breaking the control system’s seal-in.

3 Likes
4

Thanks for the reference to http://www.plctalk.net/qanda/. I’ve found useful stuff there in the past–mostly related to Allen-Bradley PLC woes–but haven’t been there in a while and didn’t think of it; may need to sign up for a membership so I can post there.

5

Thanks Phil; I fully agree. I was thinking of "safety" in the more general form of putting up a convex mirror at an intersection with poor visibility, not the specialized meaning it has in industry. The standardized machine where this idea came up uses control reliable safety circuits (safety PLC, safety sensors, redundant safety contactors) for the motors we need to protect operators from without requiring lockout. The safety system ensures control reliable stop of these components based on safety sensors related to personnel location during operation. Maintenance, on the other hand, has to follow isolation/lockout/tagout procedures (which would also have prevented the fatality over a decade ago in a different sort of machine I noted in initial post).

Yes, zero-speed switches are a great way to make sure things are running all the way to the last component--for instance, that the tail pulley of a conveyor is rotating as expected before starting the upstream conveyor. We make extensive use of these elsewhere.

Absolutely. This is the reason for disconnect monitoring. (Incidentally, it seems local disconnect monitoring is often overlooked based on a variety of installations I've seen.) We monitor circuit breaker, overloads, and contactor. It's the "local" disconnect switch(es) (not circuit breakers) somewhere along the 3-phase cables between motor starter and motor as well as 3-phase disconnect(s) upstream of motor starter that we've found a pain to get integrated in some cases.

While not applicable to the standardized machine which brought this up, in other cases, local disconnects rated for motor control/starting have been used by maintenance to operate the machinery locally on old hard-wired control systems (for instance, jogging a bucket elevator between locking out and replacing buckets). Like many other control systems I've seen, they turn the motor on, the control system (hard-wired or PLC) is not aware the unmonitored disconnect downstream of starter is off so contactor remains engaged (until a zero-speed switch, if present and not bypassed, turns it off). What we do with disconnect monitoring going to PLC based control would by default prevent using a local motor control/start rated disconnect like this.

Thanks again for the feedback; I like to gather as many perspectives as possible on an issue. At this point, we're still specifying disconnect monitoring (which based on standardized in-house PLC instruction blocks does prevent starting equipment by closing monitored disconnects) and adding the current switches as backup to quickly clear start command if no current is flowing. I'm doubtful about replacing disconnect monitoring with this.

I think this point hits the nail on the head:

Disconnect monitoring prevents this at the level of reliability of the disconnect monitoring. If lockout/tagout procedures require verifying the control system recognizes disconnect, the disconnect monitoring also gets tested with every disconnect occurrence. This is obviously not a control reliable safety system as it is single channel, not self-testing, and doesn't necessarily fail to a safe condition. But it allows PLC logic to meet the requirement that a separate start action must be performed after closing the disconnect. Zero-speed switches--much like current switches under discussion here--almost meet this requirement. But due to the fact they sense only a byproduct of disconnect (or other issues) and require a (brief) run attempt to test, they do not always prevent resumption of motion on closure of a disconnect. Instead, they only limit the window during which this could happen.

On a side-note, I really like control reliable safety systems. I'm much more comfortable walking onto a conveyor with appropriately designed self-testing safety that I'm familiar with than onto one I've added my lock to the disconnect for but someone else threw the disconnect on. Disconnects can fail, and teaching people how to recognize failure is great, but making it so they don't have to is even better. And operators aren't supposed to have to use disconnects for normal production tasks.

1 Like
6

Great overview. Couple notes:

One of the reasons I prefer the traditional MCC + speed switch design is it is compatible with operator verification of proper disconnect operation by attempting a jog operation. This catches both welded contacts in a disconnect and the complete screw-up of opening the wrong disconnect. Placing the disconnect’s aux contact in the control system’s interlock string interferes with such double-checks. All the major corporations I do business with have such double-checking in their ZES procedures.

I do recommend aux contacts in downstream disconnects when VFDs are involved, with early-break construction. Fancy IGBT output stages are vulnerable to flyback if a contactor is opened under full load – the early break aux contact will save them.

One question: how does a speed switch’s response time create a possibility of motion on reclose? It seems to me that any way that would be possible requires some other failure in the state machine’s anti-tie-down logic.

1 Like
7

Thanks Phil. I believe testing/verification of lockout--such as attempting a start/jog--is mandatory, at least in our jurisdiction. What we've done is allow operators to bypass the disconnect interlock for the purpose of testing a lockout. Running indication on HMI is only on when PLC is turning on output to run, so a successful test requires that the HMI shows the motor as running. The weakness to this method is that operators can leave the disconnect monitoring bypassed when it should not be. Perhaps it would be better to have a lockout test mode that briefly bypasses everything for the motor and attempts a jog, but does not allow leaving things bypassed. Or just auto-clear disconnect bypasses in x seconds.

The goal is to facilitate clear verification of lockout and leave as little room for error as possible. Different circumstances may indicate different solutions. You could, for instance, put phase lamps on disconnect and connect them upstream of it to verify that power is actually being sent to disconnect for test. Or put them on disconnect and connect downstream. Then the procedure is to verify lamps are on and that they turn off when disconnect is opened (works well for a disconnect upstream of a bunch of starters to lockout an entire machine. Or even safer, put phase lamps upstream and downstream of disconnect to rule out power being lost for another reason simultaneous to disconnect opening; you watch downstream lamps go out when opening disconnect and observe that upstream lamps are still on.

This makes a lot of sense for VFD protection when the disconnect is used as an E-Stop (not something that should be happening, but anything that can happen eventually will).

Good question. Here's how I understand it;
PLC preventing start based on disconnect aux contact open:

  1. Disconnect opened: PLC turns off run output immediately opening motor starter contacts if they weren't already open (normally you'd shutdown before opening disconnect).
  2. Disconnect open: PLC clears start command before running the code that would act on it (no single scan jog)
  3. DIsconnect closed: PLC allows start command. In our case, this means an operator initiated start command in maintenance or hand mode operation, or an operator initiated resume command in auto mode operation.

In the monitored disconnect scenario above, there is no point at which reclosing the disconnect will cause a start--though it is possible it will appear as if it did if a start command is initiated nearly simultaneously to reclosing disconnect.

Thinking about this, it may be a good idea to enforce something like a five second delay after disconnect is closed before allowing a start in PLC logic. This would definitely have saved my friend, despite all the other errors that let to his death. The guy who closed the local disconnect immediately re-opened it as the guy in the equipment was in sight less than 4' away and yelled. (He had tragically and incorrectly considered the disconnect to be under his immediate control so it didn't need a lock.) Unfortunately, one second of run time was one too many.

PLC clears run command based on zero speed or current switch (no monitoring of disconnect):

  1. Disconnect opened: Shortly after disconnect opened, zero speed or current switch causes PLC to turn off run output which disengages motor starter.
  2. Disconnect open: As PLC is not aware of open disconnect, operator may clear zero speed / current switch fault and attempt a start. Motor will not start because disconnect is open, and the zero speed / current switch fault will come up again. However, the motor starter closes for the duration of the zero speed / current switch fault delay allowed for zero speed / current switch response time. I expect this would generally be 250 ms+,
  3. DIsconnect closed: Operator gives start command and motor starts as expected.

This scenario still makes start on reclose very unlikely, but not impossible. The motor starter closes and remains closed for the delay allowed for run verification from zero speed or current switch. That delay is the window during which closing the disconnect would cause a start. Assuming there's not a big delay on the zero-speed switch, the window should be small. But the window is not completely closed. If a start command is initiated with disconnect open and disconnect is closed before that delay passes, the motor will be energized. Depending on timing, the zero speed / current check may still stop it, but not before it has run for whatever was left of the delay. Or it may start and continue running. Either way, it falls into this category--though admittedly rarely:

In summary, it seems to me that if a zero-speed switch were acceptable in place of local disconnect monitoring, a current switch would be too. But I suspect if someone managed to win (lose) the lottery on this little window, OSHA wouldn't consider either option acceptable. That said, the level of risk looks to be very similar to the level of risk of a start command from a central control room being issued simultaneous to disconnect close. The latter may be avoided by requiring disconnect closed for a few seconds before allowing run (continue to clear start commands during this time).

Please let me know if I've missed something above.

8

The only algorithm for anti-tie-down that I deploy is one where the enabling interlock string cannot become true after an interruption (including normal stop) until all start/jog command sources are false. Conceptually similar to the contactor monitor and K3 on a safety relay.

9

That algorithm makes sense. With that setup and no local disconnect monitoring, what happens next in this sequence of events?

  1. Motor turned off. All start/jog command sources false.
  2. Local disconnect opened.
  3. PLC doesn’t know local disconnect is off as it is not monitored. Jog command given to test de-energization. Motor starter closes to start motor.
  4. Zero-speed fault occurs after short delay (to allow time for non-zero speed in successful start). Motor run command cleared and starter opens. All start/jog sources false.
  5. Operator clears zero speed fault and attempts to start motor. Like in #3 above, motor starter closes, though motor is not actually energized as local unmonitored disconnect is still open.
  6. Within the short window before zero-speed fault, local disconnect is closed.

In this scenario, what prevents motor start when disconnect closed in step 6 if the disconnect is not monitored?

10

Side note: While not applicable to the main topic here (preventing start by re-closing disconnects), I ran into something yesterday that looks like a good solution for testing de-energization of upstream supply to a group of motors (MCC / machine):
Verisafe AVT

I figured I’d throw this in here as it’s a much better solution than phase lights mentioned in one of my posts above.

11

Motor will start. Across the line starting should have a non-zero speed detection within a fraction of a second, though, so the window of opportunity is very short.

1 Like
12

Thanks for confirming @pturmel. This is the small window I was referring to in posts above. If we replace disconnect monitoring with current switch or zero-speed switch, we crack a small window of opportunity open to start on reclosing disconnect. The answer ended up in my original question when I edited in the last two cons a while after posting; it just took discussing it to get it really clear in my mind. Thanks again for the input.

From what I’ve seen local disconnect monitoring is not exactly ubiquitous, so this risk window is very common. And the window is opened much wider on equipment that doesn’t have a zero-speed switch or other input to turn it off when it fails to run with starter engaged. I’m pretty sure the latter case is unacceptable by any standard. Going by the letter, it seems the former would be too, but it is so close to identical to the risk of simultaneous disconnect close and start that I’m not sure where the line would be drawn when we’re dealing with fractions of a second.

I think at this point we’ll continue specifying monitoring for disconnects, as well as adding a delay between disconnects closed and allowing start. In cases where we don’t control the whole installation (machine that gets plunked into existing plants) current monitoring looks like some affordable insurance for installations where there’s no other need for a zero speed switch and installation of a zero speed switch would be significantly less convenient and/or likely to be bypassed.

I’m curious if there is some kind of exception to the standard that allows not monitoring local disconnects (it does complicate testing of de-energization), or if it’s just a common oversight.

13

You have to monitor something, or you can't meet the NFPA79 no-restart-on-close specification. I personally do not like disconnect aux switches, as they don't help you if an upstream device opens and recloses. A control power transformer just ahead of the starter or starters, used for all starter coils, with monitored starter aux contacts, handles all upstream cases.
I encourage customers to avoid local disconnects (between starter and motor) due to the monitoring complication. I greatly prefer SIL3 energy control for anything that might involve an intermediate energy state.