Al, when you talk about the goal of eliminating the need to write robot application software, what does that mean? Does the user just answer a few software-based questions, fill in a few parameters, and then go? Seems like the robot's motion wouldn't be very ideally-suited to the task that way.
While there are some application-specific packages being developed with the goal of limiting user programming, the bigger trend in automation software is the development of software objects. These objects are reusable, configurable functions that are supported by powerful integrated development environments but still require programming expertise. Of course, companies that build specific types of machines have their software base and expertise in specific application areas but it doesn't go as far as the ABB solution which is offering really a turnkey package for palletizing.
Yes, Apresher, it seems the goal for much of the new automation hardware is to relieve the end user of customer programming. So much of the new product introductions seemed to be designed for quick and easy deployment. Not a bad trend.
ABB is leveraging its experience in writing palletizing applications with this software and robots/grippers specifically targeting these types of projects. By putting the major focus on ease of use, this approach reduce the need for custom programming but I would be surprised if they couldn't make adjustments to fit a specific customer requirement. This is a very intriguing product that has a goal of virtually eliminating the requirement to write robot application software for the user. Definitely a trend; the key is application software that can be deployed to meet a range of customer needs using the standard software product.
I'm not sold on this being a great idea. There are nuances to robot programming that cannot be included into a software package. Proper selection of motion type, termination type, look-ahead, etc. are part of robot programming. Programming a robot is easy. Programming a robot well isn't.
The best examples that I have are with CNC machining. I saw a demonstration of an aluminum part being machined, and I could hear the machine was being over-driven. After the cutting cycle ended, I reached into the machine to inspect the chips to see how hard the cutter had been working. I pulled out a blob of aluminum. The software had allowed the tool to be driven so hard that it melted the aluminum instead of cutting it. I saw another application where the software allowed a 9/16 drill bit to be plunged through 1/2 thich aluminum. The proper sequence would have been: center drill, pilot drill, finishing drill. Oh, the reason that I was there was they had destroyed the bearings in the spindle because the drilling reaction load was too large.
This robot package adds to a recent trend in automation -- devices that include the intelligence inside, making it easier for users to deploy the package. We're seeing this in a wide range of automation equipment. This is the first time I've seen it with robotics. It's a great idea -- make the device or package more intelligent on the inside and less complicated on the outside.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.