Software basics for a robotic-cell story Essay

Software basics for a robotic-cell story

“If you watch our demonstration cell,’ says Gary C
Schatz, Manager, advanced manufacturing planning, Turbine Components
Plant, Westinghouse Electric Corp, Winston-Salem, NC, “you’d
probably say you had seen the same thing in Japan three years ago. But
if something should go wrong, then our system would demonstrate
capability you’ve never seen before. It can correct for its own

“And we’ve added the ability to change rules and add to
the data base by editing, not stringing wire. We’ve recognized
that we don’t know what’s coming next, so we are prepared for
unexpected variables.’

Schatz says that most automated factories and FMS cells are not
nearly as sophisticated as the publicity leads you to believe. Even
some really big names in the business do nothing more than tie together
various machine tools with conveyors, automatic loaders, and robots,
using simple hard-wired connections between them. If anything goes
wrong, they can’t react intelligently–except to stop. Most FMS
setups are serial in concept, but are hard wired in practice.

Communications: hard wired versus software

Hard wiring is both simple and complex. It’s simple because
much of the control is still basic limit-switch technology. That is,
when Machine A is finished with the workpiece, it snaps a switch to
signal Machine B to take over. Most of the control still resides in a
local NC, CNC, PC, or other control at each individual machine tool.

But a hard-wired FMS system is complex, because each machine must
be wired to all other machines in the cell or group. If you add a new
machine, you must wire it to all the other machines. No on machine or
computer has overall control.

Software communications, on the other hand, are software driven.
Such systems are easy to hook up and easy to diagram. Instead of
connecting each machine to all other machines, you wire each machine to
a central computer– and change the software program. The computer does
all the communicating, and much of the control, for all the machines.
If you add a new machine to the cell, just wire two lines to the
computer (send and return).

If something goes wrong with a serial system, the computer can come
up with a repair solution. That’s the big difference. It does
more than just issue start, stop, and operation-finished signals.

But, of course, programming is a bear.

The goal of engineers under the direction of Gary Schatz and J
Isasi is to develop a cell that will process 1000 workpieces without
manual input or intervention –strictly unmanned. At this writing, the
GFM forging machine is doing fine under its own CNC operation, pounding
or swaging hot bars from a rotary-hearth furnace into preforms for
turbine blades. (Sometimes this is called preforging.) The machine is
remarkable in itself. Even more spectacular will be software control of
the entire cell, including two robots, the furnace, forging machine, and
related inspection and second-operation stations.

Dueling robots

All of the machines are in place, the computer works well, and the
robots are ready for action. Then why isn’t the system working to
full capacity under full software control? Very simply, there’s a
language barrier–even snobbery between the different levels of machine
controls. For example, the controls for the two robots have much lower
intelligence than the CNC units driving the machine tools in the cell.
The robots in fact will try to move in the same space, colliding with
each other, unless given counterinstructions by the central computer.

Putting it another way, no matter how good the programmer of a
conventional cell is, once the cell becomes complex, he or she cannot
possibly cope with all potential interactions. This is especially true
when machines or part geometries change. Programming for a bigger
preform, for example, could cause a robot collision if the robot must
reach further in space. With a smarter programming language and
simulation software, the computer can warn the operator that danger

The computer can certainly keep track of such mundane details as
robot positioning, but in the new setup, it must also constantly
translate from computer language to robort language. It must also
translate from Pascal to machine-control language, ladder logic, or any
other language used by the individual machines in the cell.

Beyond this, the central computer acts as a cell interface unit
(CIU) that controls the destiny of the cell. It must know everything
that is going on in the cell, so it can make command decisions. The
sophistication of control is similar to that of a full CNC compared to
an older NC machine control. Old NC is nothing more than a simple tape
reader with discrete logic control, whereas CNC is programmable logic control. In the Westinghouse setup, the various parts of the FMS cell
communicate to the CIU in the same way the various parts of a single CNC
machine tool communicate to the control’s central mainframe

This takes much computing time and tremendous programming skill.
And, of course, it’s the programming that takes the most time and
still needs perfecting. The software, being developed by
Carnegie-Mellon University, must rune the system smoothly and be easy to
change and reprogram for new operations and new equipment. When
perfected, it will help control a variety of manufacturing cells, and it
will communicate with other management-system programs being developed
in the Robotics Institute at Carnegie-Mellon. The programs will manage
at a factory level, and the new language will use a data base with a set
of rules, operating with a set of grammatical constraints.

Accounting for failure

One reason for special languages, say the Westinghouse engineers,
is that even in the simplest cells using Pascal, Fortran, or APT, a
single failure of a tool or machine component will stop the program.
This is because the languages are procedural in nature. Although the
cell operating program may be very large, it is still not a language
interpreter. At any random statement in the program, the proposed task
is critically dependent on the previous tasks. If these previous tasks
were not carried out because of some machine or program error, then the
particular task in the statement of interest may be adversely affected
or not enacted. For example, in a “worst case,’ a billet
could be dropped at a random time and place in the cell.

In an old system, everything would stop. With the new software,
however, the cell could keep right on running, assuming the billet
didn’t roll over a power cable and sever it! The rule-based
language sets up program segments that will operate only when certain
preconditions already defined become true. The segments require only
that certain conditions be true, not that they happen in a certain
sequential order. In a sense, the new language can nandle several tasks
at once, whereas conventional languages do only one thing at a time, and
in an exact sequence.

Photo: Jerry Colyer at the command post. He says,
“Interconnecting CNC machine tools is more than matching RS-232
plugs and sockets. These merely match voltages; they do not guarantee
any sort of communication at all! Traditional cells put in hard stops
to prevent accidents; we try to put the stops in software.’

Photo: Elements of the cell shown here are the GFM chuck at left,
Machining Systems cropper-stampers to cut off the tip, and one of the
two robots. Items not shown include a noncontact vision-based gage
station, and the F&D rotary-hearth furnace

Photo: The GFM forge uses two hammers and controlled rotation of
the chuck to forge a red-hot cylinder into a turbine-blade preform. The
machine has its own CNC unit that communicates with the rest of the cell
through a central computer. Engineers had to overcome the lack of a
common EIA language before communications could proceed. An industry
standard is badly needed before future development of largescale

Photo: Layout of the GFM swaging or forging cell.


I'm Tamara!

Would you like to get a custom essay? How about receiving a customized one?

Check it out