CrossRobotics Business Manager with Cross Company Motion Solutions. Specialties include all things robotics, machine design, electro-mechanical systems, servos, automation, mechatronics & manufacturing. Follow Andy @AndyCrossCo.
In an ever changing world, it has always surprised me how quickly some things change and others continue to persist. In the industrial automation world, this is no different.
When I started my career in automation back in the mid-90s, there were very discrete silos of automation. The sophisticated motion controllers of the time talked RS-232C and had a handful of I/O; barely enough to accommodate Limit/Home switches and allow for rudimentary BCD type handshaking to another controller. PLC's did one thing well and that was handle digital I/O. Asking it to do any real communication was painfully slow and limited.
Safety, what little of it that we had, was little more than a redundant limit switch built into some kind of sensing device. Vision (wow was that in its infancy!) wasn't better - the few players that were there were using line scanners and writing custom software that ran on rack based PC.
Then there was robotics: for those that could actually justify the cost, it took a small army to commission them and another army to keep them running. Each of these technologies had one thing in common: they were islands unto themselves. In order for them to interact, they had to coordinate their efforts with little more than the status change of an input or output, which was just a polite tap on the shoulder to say, "I'm ready now".
To increase difficulty, these various controllers were programmed in different languages, normally by different experts who were from different companies. As you can imagine, the overhead to build a machine was significantly greater, the time line to deploy them was much longer, the machines were bigger, slower, and they were typically designed to do a very limited number of things. Splendid.
Over the years there have been some changes, but as far as the automation that is running the majority of manufacturing in the world, having these silos of control is still very normal. We see it on a daily basis - a customer using a Rockwell Compact Logix for their machine control, a Parker ACR Multi-Axis Motion Controller for Complex High Speed Motion Control, a Fanuc Delta Robot for a high speed pick and place, a Cognex Vision System for quality control, and a mix of safety equipment to protect the operators.
That is up to five separate controllers that need to be configured, programmed, and debugged for a single machine station! Thankfully, one thing that has changed is that fieldbus communications like EthernetIP and EtherCAT now allow these controllers to carry on a full bore conversation vs just giving a polite nod every now and again via I/O. Admittedly, in some ways we have started to blur the lines a bit when it comes to controller capabilities. There are motion controllers that can do a fair job of doing some machine control, like a Yaskawa MP2300siec or Parker ACR9600. There are PLCs that can do a passable job of motion control like the Rockwell Logix Series or Siemens S7 and robot controllers like TM Robotics TSL that have a built PLC. As well, there are PLCs that are incorporating advanced safety control, vision systems that allow tighter integration with PLCs, and even industrial robot control modules like the Motoman MLX100 & 200 that can be programmed solely from RSLogix. So yes, we have made some progress.
For the first time, there is a viable option for being able to use a single off-the-shelf controller for simultaneous control of I/O, simple or advanced motion, temp control, and robots all with integrated vision and safety. Let me introduce you to the Omron Sysmac Automation Platform. For those skeptics that are asking, "Well, sure, it might be able to do all of that simultaneously, but how fast is it updating?"
Great question glad you asked! How does 1 ms or better sound?
A single machine controller and one software package to do what used to take three to five...think of what this could mean for a machine builder or end user! The impact of this is much greater than just the simplicity of having to know one software package (which in itself is pretty significant). A few keys for you to consider:
Learn one development package instead of five. We hear a common refrain from many customers, "if you don't use it, you lose it." If you are using the same development package, regardless of the type of application you are solving, how much more fluent in that package would you be?
You would not believe the number of calls we get from customers who have to keep up with multiple computers - used solely for programming a particular controller - because their different development packages can't coexist on the same PC or they don't work on a particular operating system. Crazy.
Although it is one of the more simplistic points, it certainly is important to the end-user who wants to get the most bang out of their floor-space-buck. This is particularly true if someone is using a delta robot or two on their machine. Has anyone ever noticed the small refrigerator-sized cabinet that comes with every robot? Now imagine you had eight delta's on a machine! You're talking close to 50 sq-ft of floor space just for standard compact robot controllers. Now imagine that situation when you are doing a machine upgrade and you are physically boxed in by other production equipment...
If you have the ability to control your entire machine from a single controller, you now have the ability to simulate your entire machine function in a single environment! Have you ever had to switch back and forth between two software packages to force I/O to verify functionality? Ever had to do that with five? That will eat up some time and likely mean you'll have to spend even more time troubleshooting when you are ready to commission the machine.
The major advantage to a single controller is you no longer have to accommodate the communication between your silos of automation. For instance, with separate controllers, if you want the PLC to fire an output every time Robot 1 retracts past 100 mm in the Z, you have to program the robot to tell the PLC when this happens and you have to program the PLC to look for this communication from the robot. Aside from the actual time delays, if you are doing this with I/O, although the logic is fairly simple, you end up paying for more real world I/O than necessary (as compared to just using internal tags) and you are limited in the information being shared between controllers.
If you are doing this over a Fieldbus, you get the joy of mapping and configuring the communications (it is rare that different vendors controllers talk out of the box) as well as setting up a 'heartbeat' to make sure you are still in communication. With a single controller, you eliminate these issues and recoup the time lost sending, receiving, and processing communications. This may not seem like a big deal until you start calculating the lost cycle time over the course of a year. The argument can get pretty strong pretty fast.
So now we are getting somewhere.
We are leveraging the processing power that has been available to us for the past decade to make our jobs easier and our machines more cost effective and efficient. Admittedly, the Sysmac solution isn't the best solution for every application, but for those where you would otherwise have to incorporate multiple control platforms on a production line or in a machine, it most likely is.
If you have any comments or questions, I look forward to hearing from you!