Thanks, Ann. This trend is definitely here to stay but the key as you noted is the ability for vendors to leverage experience with specific applications. That enables them to move from programming an application to "configuring" the operation. It doesn't always work with every application for a variety of reasons. Configurable software objects is the more general approach that at least reduces software development time.
Al, thanks for the clear explanation. I think some of the confusion about drag and drop has arisen because some people are collapsing categories of programming between repetitive, well-known motions--in this case, what it takes to put things on a pallet--and the highly individualized motions that might apply to a particular installation. This reminds me a bit of some early discussions of "system-on-chip" silicon--no, we didn't put an entire computer on a chip, but we did incorporate on silicon a ton of functions that operate the same basic way across many applications. This is clearly a relatively new concept in robotics, and I suspect it's arisen because of the sheer number of installations--ABB is pretty darn big--and, as you mention, the fact that they're communicating with their own controller hardware.
Chuck, Companies might still use system integrators to implement these systems. But by using motion algorithms specific to palletizing movements, for example, already pre-programmed into a "standard" application package, the goal is to allow the user or integrator to configure movements for a specific machine rather than writing routines in the robot programming language. Another layer of software that makes it easier to implement the software, already written and defined in the language of palletizing, is the idea behind these types of packages. The caveat to a general trend in this direction is the complexity of diversity of application needs, plus in this case ABB is communicating with its own hardware solutions.
I would agree that it is a good idea to move to "drag-and-drop" 'programming', but I don't think we will get there soon.
I have spent over 30 years making automation systems work, mostly programming and debugging them. Applications come in many flavors, and if you don't properly categorize the application early in the design cycle, things can go very wrong. I think most medium to large scale automation projects that go wrong lost it somewhere in the analysis phase, and the canned programming tools I have seen don't help much with properly analyzing the required process.
For example, I was called in on a bottle packaging line several years ago. The line consisted of perhaps 8 or 9 conveyor segments, and some number of stations along the conveyor that did some operation to the bottles. The bottles were flowing in from the production line at some rate, and they had to get through the conveyors and get marked boxed, then packed out by robots. The system was "almost done". The problem was, it would not recover from process errors in a very graceful way.
Upon examining the code, it became clear that it had to be rewritten, because it was not going to be feasible to 'fix' it. The programmer had written the program as one big sequence, from bottles entering the system, to the final packout. If that sequence got interrupted (which was inevitable), the only way to recover was to completely empty all of the conveyors of product, and start over. So, if the boxer ran out of boxes, or jammed, the only solution was to completely empty the line (which was probably two hundred feet long, and might be holding thousands of bottles, boxed and unboxed) He did not recognize that each subsection of the system needed to function indepenently of the other subsections of the system.
The only way to fix this system was to properly analyze the system, break it into sub-systems, program each sub-system, and add the proper flow control logic between the sub-systems. Now the error recovery involves un-jamming the subsystem that failed, not the whole line.
I don't know if canned programming systems can ever solve this issue. (improper analysis of the problem up front). In fact, they tend to force you to do things in the way that the designer though you would need to do them, which may be quite different from what you really need. If you don't recognize this quicky and bail out, you can spend a lot of time going down a path that will never work in the end.
Canned programming systems can typically handle very simple applications. Ann mentioned vision systems. Vision systems are very good at counting large, uniformly sized black marbles that are nicely separated on a clean white tablecloth. The problem is, I haven't run into the customer that wants to do that. The demo applications only exist in the demo room, best I can tell. So, when you get to the real world situations, the canned programming many times breaks down because there just aren't that many simple applications. (If there are, I haven't had the good fortune to have seen many of them.)
A draftsman using CAD creates a drawing. CAD used improperly creates garbage. The same goes for spreadsheets, CNC programming and robot programming. The question becomes 'how good is good enough' ? The less you know about an application, the lower that bar becomes. This is just a dumbing-down of the application.
I don't know what the best analogy would be, maybe the difference between a painting, and paint-by-numbers. Which has more value, or commands more respect ?
Al, you're right on the money. "Programming" in the use-a-software-package sense meant here depends on a graphic user interface where the "programmer"--actually an operator--does a point-and-click form of "programming." This is not coding, but takes advantage of object-oriented software methodology that a programmer has used to create this type of software. Somewhat analogous to semiconductor system-on-chip design, it automates and puts under the hood all kinds of functions that don't need to be recreated every time.
Glenn, we've discussed this issue in a few other article comment threads. The idea is similar to the idea in machine vision or any other area of manufacturing and automation: simplify "programming" so instead of actual coding it's more like point and click, and operators can do it, instead of actual programmers.
Robot manufacturers have gotten lots of feedback from customers that robot programming is too complex, so providing easier to use solutions is an ongoing focus. We'll have to wait and see how widespread this type of approach becomes.
Chuck, The key is the pre-written routines specifically for palletizing which, I assume, users can configure for their specific application. The new software approach merges with the virtual programming environment of ABB RobotStudio which allows users to configure, simulate and program robots and grippers for palletizing solutions. Since users are also able to immediately download code into the robot, teach reference points in the work cell and get up and running more quickly, it is potentially a huge advancement in reducing engineering costs and lead times for palletizing projects.
New versions of BASF's Ecovio line are both compostable and designed for either injection molding or thermoforming. These combinations are becoming more common for the single-use bioplastics used in food service and food packaging applications, but are still not widely available.
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 radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.