Safety of disconnect vs. current switch monitoring for motor control

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