How can cobots and safety controllers work hand in hand?

Feb. 4, 2022
Safety is a journey to a better, more productive place

Despite our best hopes, we drag the baggage of the 2021 pandemic into yet another year. The situation is ever-changing, and it challenges all of us to make decisions that make the most sense for us and our loved ones.

While all of this might be overwhelming for some, I have found a refuge, of sorts, in the details of my chosen profession. Now this might seem somewhat odd to many of you, but in the world of automation there is order and, well, control over what we do and what the outcome will be.

Also read: Safety controllers handle increased devices

With the chaos we have been forced to endure for more than two years, finding something to focus on can unload the burden and give a sense of accomplishment.

Despite the challenges of the past two years, the need for automation has never been more important. Labor shortages, already trending before the pandemic, have presented a great challenge to manufacturing. Less production means lower stocks in the supply chain, further amplifying the need to continue to produce. One way to reduce the impact caused by the labor pool is to automate.

Traditionally, automation was a huge investment, but, with the rise of collaborative robots, companies have less expensive means of getting the tools they need to continue producing with less physical labor. Such is the case with my employer. We’ve experienced a distinct growth in the use of automation by creatively adding traditional large-format automation with a significant number of collaborative-robot applications.

An interesting side effect of this investment in our core machine base has been an exposure to technology in use by outside vendors. We are very proud of our ability to retrofit existing equipment, as well as build our own packaging machines and control systems where needed. That expertise arose from being in a somewhat remote area of the country and our dependence on a local labor pool. The old saying that necessity is the mother of invention truly applies in this situation.

The need for change, however, was obvious, and we have found some very good relationships with vendors that have allowed us to maintain our somewhat independent ways while bringing new technology to our manufacturing processes.

With the mix of new stand-alone machines and collaborative robots, we had an opportunity to have a second look at the use of safety controllers. These haven’t really been on our radar in the past 10 years as our existing equipment has always been stand-alone unit operations, and we could provide a good safety circuit by just using a safety relay and safety-rated door switches and e-stop buttons. Frankly, we were surprised to see safety controllers in use in the large stand-alone equipment, as well as the collaborative and conventional robot solutions.

In my previous experiences, safety controllers were an interesting technology but seemed rather cumbersome to use. As we got further into the details of our new equipment, it was abundantly clear that safety controllers have come a long way and deserve another look.

It makes sense to look at the makeup of a safety circuit before talking about a safety controller since they start with the same base components. Safety has advanced over the years, but the basic starting point is the use of devices to protect people from getting hurt while working around equipment.

Common devices would include an emergency-stop button or a door switch, while more technical items might include light curtains, anti-tiedown palm buttons, safety mats and area scanners. An e-stop button or door switch provides a means to interrupt the motion of the machine while the more technical items would sense the presence, or absence, of a person in the operating envelope of the machine.

Early safety circuits would connect all of these devices in series with each other and power a relay that, when energized, would allow a machine to operate. Removal of any one of the series of components from the circuit would immediately drop output power to the machine.

The evolution of the safety circuit was to make the output-power enable relay more intelligent where it would require a deliberate action to re-enable the function of the relay after it had been tripped, thus making sure that output power wasn’t automatically restored to the machine without a conscious decision on the part of the operator.

Further evolution came from the concept that if one safety circuit was safe, two safety circuits would be even better. Adding yet another layer of safety, the two redundant safety circuits would be monitored so that if either one of the legs of the dual circuits were to trip, without the other, the safety relay would still trip out and could not be reset until both legs were again functional. Think of a contact on an e-stop button where one contact changes state but the other does not.

Another layer of safety-relay function is to power two output circuits—relays—and monitor the status of both. If either one doesn’t drop out—a stuck relay condition—the safety relay can’t be reset. They must both be off before the reset button can be pressed.

Yet another layer of safety is to monitor the two incoming safety chains against each other to ensure that the making of the circuits are within a short time of each other. Failure to meet the minimum criteria would suggest that one or more of the devices in the chain is starting to fail and needs to be replaced.

As one can imagine, there is a lot of stuff going on inside the safety relay, but having everything in a series connection means that, while one might know that something in the circuit has failed or is failing, it won’t tell you what, exactly, has failed. Lengthy troubleshooting is then required to figure out where the failure is before being able to correct it. This is where a safety controller comes into the discussion.

A controller, in the programmable logic controller (PLC) sense, brings individual devices into a control platform where the programmed algorithm makes things happen. A switch turns on a light bulb, for example.

A safety controller starts with the same concept, where each safety device has its own definable input to the safety algorithm. Logic is written to decide what to do with each safety device, as far as how it will impact the output circuits of the safety controller. In this way, combinations of input devices can be used to create a zone on the machine where output power can be enabled and disabled, independent of other zones on the machine or process.

The great benefit of the safety controller is each input device can be monitored based on the type of device. Current acceptable safety standards for each type of device—e-stop button vs. a safety mat or light curtain—are loaded into the library of the safety controller allowing for automatic monitoring of the device in the background of the controller. Faults and warnings are automatically generated and can be individually annunciated accordingly.

Early safety controllers—these would be ones from more than 10 years ago, in my personal experiences—were just touching on the potential of this technology. Devices were generic in nature.

The latest examples of safety controllers host libraries of safety devices and configurations, specific to the actual safety device being used. This is very convenient when the safety devices are of the same brand of the safety controller. The programmer can select the actual device by part number and drag and drop it into the programming tool. Automatic code generation takes place to incorporate the newly inserted device into the safety controller algorithm.

The resulting control function can be completely tested in a programming environment, saving time during installation and commissioning. Most of this activity takes place in a pictorial user interface, making a specific knowledge of programming techniques less critical to utilizing the components and controller.

Some of this same functionality is making its way back into a traditional safety relay with the use of networks similar to IO-Link. Each safety device resides on a network with its own distinct address.

All devices on a particular network—typically there are two possible networks per safety relay—are daisy-chained, similar to the more traditional safety relay circuit, but each device, or node, on the network provides additional information to the safety relay related to status and performance of that particular node device.

Finally, many manufacturers are offering products where the safety controller is embedded in or replaces the conventional PLC or PAC altogether—one programming environment with all the benefits of both the safety controller and PLC/PAC.

I/O modules in the PLC rack can be either safety or conventional I/O or a combination of both. One more thing to watch for is the emergence of the prospect of intrinsically safe wireless safety. Now, for an old timer like me, this concept is a hard thing to digest. How can something be safe if there are no physical connections between the various safety devices and the safety controller or relay?

The continuous improvements to safety are all about protecting our people, and this trend shows little sign of slowing down. It’s definitely worth taking a second look.

About the author: Rick Rice
About the Author

Rick Rice | Contributing Editor

Rick Rice is a controls engineer at Crest Foods, a dry-foods manufacturing and packaging company in Ashton, Illinois. With more than 30 years’ experience in the field of automation, Rice has designed and programmed everything from automotive assembly, robots, palletizing and depalletizing equipment, conveyors and forming machines for the plastics industry but most of his career has focused on OEM in the packaging machinery industry with a focus on R&D for custom applications.