A robot package that puts together hardware, including the 4-axis IRB 460 robot shown here, and software for automating high-speed, end-of-line palletizing is easier to program and integrate into existing lines. (Source: ABB)
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.)
Here's what I'm wrestling with, Al. Do users really know how to do optimal configuring of the robot's movement? Isn't this why they hire system integrators?
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.
By experimenting with the photovoltaic reaction in solar cells, researchers at MIT have made a breakthrough in energy efficiency that significantly pushes the boundaries of current commercial cells on the market.
In a world that's going green, industrial operations have a problem: Their processes involve materials that are potentially toxic, flammable, corrosive, or reactive. If improperly managed, this can precipitate dangerous health and environmental consequences.
With LEDs dropping in price virtually every year, automakers have begun employing them, not only on luxury vehicles, but on entry-level models, as well.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
3 
