Intro to ABB Programming

Introduction
How Basic?
First time?
Can you spell ABB? How ‘bout “robot”? (Did you know that ABB stands for Asea Brown
Boveri – a merger of the Swedish Asea and the Swiss Brown Boveri companies in 1988?) Do you know
the difference between a resolver and an encoder? (Do you care?) Can you re-commutate an axis motor?
(I can’t) You’re probably somewhere in between. Hopefully you’ve had the ABB Robot Basic Training
course, but if this is your first opportunity to get “up close and personal” with one of these orange robots
(injection press robots don’t count), we can adjust the presentation accordingly. Emphasis will be on the
(Swedish) “non-paint” robots – most information will carry over to the (Norwegian) painters, too… but
there are differences.

Tweak or build?
What level of expertise do you seek? Obviously I can’t teach you more than I know (which is
why paint robots receive so little discussion in this course), and time won’t allow complete coverage of
every robot program in the plant. This course is intended to help you feel more comfortable around a
teach pendant and confident enough to adjust a point on a waterjet, router, or pushnut robot program.
Along the way, we’ll discuss what makes up the program instructions and maybe build or modify a
routine or two. Hopefully, the training will be adequate to allow you to generate an entire module (or
program). Ultimately, what you learn will depend on how often (or whether) you get to use the training.
Practice, practice, practice… Also keep in mind that ABB spends a week covering basic programming, and
doesn’t necessarily go into some of the depth we will.

The Chicken or the egg?

Where to begin – do we start by stepping through existing programs or do we explain the
instruction set first? Do we explain the program structure or define the components? Do we first discuss
data types or kinds of data? Whichever way we go, we’ll find something that should have been covered
before we got to that point or something that will (hopefully) make more sense later.

But you said…

I’m passing along what I’ve learned from the School of Hard Knocks. Unlikely as it may
seem… I might be wrong (or maybe you just misunderstood what I was trying to say). RTFM – that’s
Read the Fine Manual. There is (or should be) a copy of the Rapid Reference Manual in the
Maintenance Library. Each robot comes with a complete set of manuals; hopefully there are a few extra
copies available, too. These are written by the people who designed/built the robots. The information is
more complete (sometimes too complete), and there are many more instructions available than this
course will cover. I apologize if the training material is too conversational and not textbook-ish enough
– I never claimed to be a teacher (or an author).
Moving around
The joystick
Which way is which? Why does this one have a lever and that one have a blue cord? Why does
this robot drive backwards?
C5.3 paint robots and early S4 robots had a (heavy) teach pendant with the joystick coming out
of the right side. The old weld robots (now FIP robots) had this style, but somewhere along the way,
they were converted to the new style (joystick mounted on top). Aside from the old (C5.3) paint robots,
only the ex-weld robot now sitting on Cell 10 has a side-mounted joystick – and it will work with the
new style pendant. Having never tried, I couldn’t say if an S4 paint robot pendant will fit a C5.3 robot
(or vice-versa).
Paint robot teach pendants are made intrinsically safe. They are not backlit and can be identified
by their blue cord (at least until the cords get discolored by paint, solvent, etc.).
As far as driving is concerned, one of the major differences between painters and “others” is that
paint robots follow the joystick when driver is standing beside the robot, other robots follow the teach
pendant when driver is facing the robot.

Coordinate systems
Base
This is the way the robot would see things. It is normally the same as World – unless robot is
inverted (or mounted on a sloped or vertical base – only newer robots can accommodate).

World
This is the way the programmer would (ordinarily) see things. X+ is forward (away from the
power connector on the robot), Y+ is to the robot’s left, and Z+ is up. (Right-hand rule – thumb up,
pointer forward, “the” finger left).

Work Object
Remember that “Chicken or egg” discussion? Here’s one area where it comes into play. We’ll
build work objects later, but notice what effect it has on robot motion. If the work object has been built
on a slope (GMX base panel, GBD, 272TC) or vertical (SCC, new consoles), the robot will track (move)
accordingly. It should also be pointed out that points are based on the work object coordinate system, so
Z+ on a vertical work object is probably toward the robot (what would ordinarily be X-).

Tool
This can be a handy way to drive a robot, or it can be just plain confusing. Which way is right?
I generally try to teach the TCP (tool) so it approximates linear motion in World mode – although most
waterjets contradict my “standard”. It is possible to teach a TCP that emulates the paint robot “World”.
Drive carefully (slowly) to determine which way is which!
Motion Type
The motion type is selected by using one of the four keys along the right side of the screen.
There are three other keys in the column – the top is for screen contrast, the bottom two are
programmable (discussed later… maybe).

Robot/External axis

Unless an external axis is present and enabled, this key is “stuck” on robot. Should it be
necessary to drive an external axis (e.g. the rotating wall on most waterjets) this key will be of benefit –
however, it’s usually easier to step into the program and let it move the wall to a specific point.

Reorient

In theory, the TCP won’t move. In reality, a well-taught TCP doesn’t move much. This mode is
most useful to change head angles for cuts, etc. Because the TCP doesn’t change, the position remains
constant – only the angle is affected… in theory.
With axis 5 near zero (AKA “singularity”), axes 4 and 6 interact – axes spin opposite directions.
There are software options to get around the singularity, but it’s usually easier to flex axis 5 via a joint
move.

Linear

Motion is up/down, left/right, in/out. The robot tries to keep the tool at the same orientation.
Ordinarily a good thing, but moving from home position to the far side of a part can result in the head
trying to exceed its limits. Linear mode is also (especially) affected by singularity.

Axis by axis (joint move)

1=axis 1-3
Group 1 is the primary/major (heavy) axes. Curiously, the top button option refers to the bottom axes.
Axis 1 is the base, axis 2 is the hip (or shoulder) and axis 3 is the elbow. Because of the mechanical
connection between axes 2 and 3, moving axis 2 will make axis 3 move with respect to axis 2. Moving
axis 3 does not affect axis 2.

2=axis 4-6
Group 2 is the secondary/minor (wrist?) axes. On a hollow-wrist painter, these are all together, most
other robots have axis 4 as forearm roll, rotating most of the horizontal arm. Axis 5 is the wrist fold,
axis 6 is wrist roll.

Incremental

AKA “inch” mode, the incremental mode makes the robot take “baby steps” – the size of which is
selectable on the JOG page. The smallest baby steps are almost invisible to the eye, but the TCP
position monitor (also on the JOG page) shows that it is changing. This mode is valuable for highly
accurate positioning, or when the robot is dangerously near expensive tooling (like the laser unit).
Ordinarily, that accuracy is unnecessary, and if left in incremental mode (especially with fine increment
selected), the robot will appear to be unresponsive to the joystick. If the robot won’t respond to the
joystick, and doesn’t display any error messages (like E-stop, or other runchain messages), verify that
the increment mode is not selected.

Moving inside a program

Cursor vs Program Pointer

Even with small, modular programs, it is frequently necessary to “step into” a routine to make a
quick edit. The Edit key (2nd from left at top of screen) has options to: 4 Move to top of routine; or 5
Move to bottom of routine. In addition, the arrow keys can be used to move the cursor up or down
through the routine. Once a line is highlighted, it may be “executed” by pressing the

MoveJ vs MoveL vs MoveC

These motion instruction types (and their DO counterparts) are the most used. Because of the
effect on the TCP, these require additional discussion (even if it’s redundant).
MoveJ makes the robot move all axes in unison to stop at the target position. Because each axis
starts and stops at the same time (regardless of rotation required), the TCP motion can be unpredictable
(and hazardous if near a fixture or part). Little processing is required by the controller, so this is the
fastest mode. The MoveJ (well, actually the controller) isn’t worried about maintaining a TCP path, so it
is a good choice when axis 5 needs to change polarity, or another axis needs to rotate more than 90°.
For this reason, it’s a good idea to use MoveJ’s occasionally in a long program, to allow easier step-in.
MoveL makes the TCP track a straight line to the target position. This may mean reversing an
axis direction mid-path. Combined with large zones, MoveL’s can be used to approximate a curve.
Because the track of a MoveL is predictable, they are the most useful instruction for cutting. Their
downfall is the accuracy… if the robot can’t move to the target in a straight line, or if one axis must
move more than 90°, the robot will generate a configuration error and refuse to move (well, it will twitch
in the required direction). As a rule, the robot will refuse to change axis 5 polarity (move from +/- to -/
+). Near the singularity, axis 4 and 6 will rotate wildly to attempt to maintain TCP orientation. Even if
successful, the lateral motion may slow to allow the rotary motion to stay within velocity limits.
The MoveC is one (if not the only) instruction that has two targets. Motion is calculated from
current position, through the first point (on the curve, but not necessarily the midpoint), to the final
(end)point. A MoveC will take the shortest route – meaning it will travel no more than 180°. This
means a complete circle will require two MoveC instructions. Complex curves can be generated (the
TCP motion need not be planar), but SOME curve is required – the MoveC will not draw a straight line.
Stepping into a MoveC can be tricky – the controller wants to generate an arc from current position to
endpoint through midpoint. It’s generally safer to step to the instruction before the MoveC (pre-
position), then step forward. Once you start stepping through a MoveC, you must complete the arc
before backstepping. Backstepping is possible, but sweeps through the entire arc – not just to the
midpoint. Areas with multiple sequential MoveC instructions (the cluster area on topcovers, for
example) can be difficult to step into. One “trick” is to temporarily insert a linear (or joint) move just
ahead of the circular move. It can be removed (deleted) after editing is complete. At least one robot
seems to have a problem single stepping through circular moves – again, the trick is to copy the
midpoint to a linear (or joint) move, edit the point, and delete the temporary move afterward If absolute
“roundness” isn’t required (or desired), occasionally a MoveL with a large zone can be used in lieu of a
MoveC (eg. SWD’s on 222 topcovers). Resultant motion will be more parabolic, but a short parabola is
quite circular.

Program Structure
Modules
What is a module?
Data points may be moved (or duplicated) from one module to another. Duplicate names can be tricky
(or disallowed) depending on their scope (local or global). It’s generally safest to avoid duplicating a
point name.

Loading

Editing

Saving

Deleting

Instructions
Format
Probably the most common instruction is a Move. Various flavors are: MoveJ, MoveL, MoveC;
MoveJDO, MoveLDO, MoveCDO; TriggJ,TriggL, TriggC. The three basic types are joint, linear, and
circular moves. One additional type of motion instruction is occasionally used – the MoveAbsJ. This is
about the only motion instruction that uses a jointtarget instead of a robtarget (differences will be
discussed shortly). Similar to a MoveJ, it moves the robot so all axes stop at their specified angles at the
same time.
Motion instructions generally follow the same format and include the following information on
each instruction line:
Type of motion (MoveL, MoveAbsJ, MoveCDO, etc.)
Destination(s) (circular moves have midpoint and endpoint). Points may be named or embedded (the *).
Speeddata (usually one of the system constants v1, v100, etc, but variables or expressions can be used.)
Zonedata (distance from point before robot heads to next point – fine, z1, z100, etc.)
Tooldata (which TCP to use)
Work Object (optional) If work objects are to be used, they should be taught in the original program –
they are quite difficult to add (or change) later.

Editing program lines

Modifying
The up/down arrows generally (but not always) highlight entire lines of instructions. Sometimes
they move the cursor to the same point on the previous/next line. The right/left arrows move the cursor
between line elements (but can move to the next/previous line or highlight the entire line). The cursor
highlights a part (or all) of a line to be edited. The enter key can be used to present a list of options to be
selected. Highlighted elements can also be cut/copied/pasted. The robot generally won’t let you paste an
improper value (put speeddata where zonedata belongs). It’s also possible to enter a text mode to embed
“stuff” that is not offered as an option. Positions may be taught to the current robot position by pressing
the ModPos key (2nd key from right at bottom of screen). Most (but not all – our 6400 (ex-weld) robots
do not) robots have the “Are you sure?” verification before ModPos will modify the position.

Inserting
The teach pendant inserts a line after the current line. Highlight the line before where you wish
to insert, and then select the instruction from the Pick List (IPL). If the IPL box is not showing, select
(press) the Instr key at the bottom right of the screen. (Notice that the Special key has disappeared from
the top of the screen and the lower right key has changed to Test. To get back the Special key, press the
Test key.) There are several pages of instructions available – sometimes finding the one you want can
require some searching. Alternately, if that instruction has been used elsewhere, you can copy/paste, and
then modify elements as required.

Cut/Copy/Paste
The difference between Cut and Copy is that Cut deletes the line (or lines) of text after it is (or
they are) copied to the buffer (AKA clipboard). Once there, they remain in the buffer (on the clipboard)
until replaced – or the machine is rebooted. Paste inserts a copy of the buffer at the current cursor
position. So a line may be copied and several copies pasted back into the program. (FYI, it’s possible to
cut a line – or lines – from the program, run the program, then paste the lines back in. This is a common
technique on the Riveter to finish a part that faulted after the first few rivets.) In the Edit mode (IPL
window open), the two left keys at the bottom of the screen are Copy and Paste. The Edit key also has
options to: 1 Cut; 2 Copy; or 3 Paste.
Another useful Edit option is 6: Mark. With the cursor on an instruction, you may use the arrow
keys (up or down – NOT page-up or page-down) to highlight the block of instructions. This block may
then be Cut/Copied to the buffer, or Deleted.

Deleting

Line elements, entire lines, blocks of lines, or even entire routines or modules may be deleted by
highlighting them and pressing the Delete key. The teach pendant will respond with a Microsoft-like
“Are you sure?” to give you a chance to consider your actions. In addition, the Edit key usually has an
Undo option available.

Data
Kinds
Const(ant)
Constant data is defined at the top of the module with an assignment statement and the value
cannot be changed under program control (during execution). Named program points are generally
constants, but may be changed from the teach pendant with the modpos (modify position) key or edited
manually.

Pers(istent)
These are also defined at the top of the module with an assignment statement. If changed, the
assignment (initialization) statement is changed as well. Named program points may be defined as
persistent. Some of the MK robot programs use this “feature” to allow points to be adjusted from the
Operator Interface Panel (PanelView).

Var(iable)
Although defined at the top of the module with an assignment statement, variables may be
changed under program control. If the program is restarted, the value will revert to the default
(assigned) value. I generally prefer to execute an assignment statement before using a variable – that
way, I can check the program listing (via teach pendant) to see what value a variable should have.
Parameters passed to subroutines are usually passed as variables (although a few data types must be
passed as persistent).

Types (more detail than you probably want)

Robtarget
Appears in program line as either named point or embedded in the line (shows on teach pendant as *).

[translation],[rotation],[robot configuration],[external axes]]

[[x,y,z],[q1,q2,q3,q4],[cf1,cf4,cf6,cfx],[eax_a,eax_b,eax_c,eax_d,eax_e,eax_f]]

[[-155.23,102.61,345.77],[0.980716,-0.032636,-0.137471,-0.135033],[-1,0,-1,0],
[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]]

Orientation is dependent on current work object and TCP. Rotation is expressed as a quaternion,
configuration is the quadrant (quarter rotation), 0-90° is quadrant 0. cfx (other than 0) is used only on
the 5400 robot. Unused (inactive) external axes use the value 9E9.

Jointtarget
[[robot axes],[external axes]]
[rax_1, rax_2, rax_3, rax_4, rax_5, rax_6],[eax_a,eax_b,eax_c,eax_d,eax_e,eax_f]]
[[0,0,0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]]

Speeddata
AKA velocity - shows up in program line as named velocity: v5, v10, vmax.
Custom (or variable) velocities can be built.
VAR speeddata V:=[velocity_tcp, velocity_orientation,velocity_linear external axes,velocity_rotational
external axes];
VAR speeddata VELOCITY:=[1000,500,5000,1000];
Variable speeddata can be changed inside the program: V.v_tcp:=200;

Zonedata
How close to the programmed point all axes must be before continuing toward the next point. Zonedata
shows up in program line as named zone: fine, z0, z1, z5.
Custom (or variable) zones can be built:
VAR zonedata ZONE:=[fine point,path zone_TCP,path zone_orientation,path zone_external
axes,zone_orientation,zone_linear external axes, zone_rotational external axes]
VAR zonedata z2:=[FALSE,2,3,3,0.3,3,0.3];

Tooldata
AKA TCP, the tool data is based on the wrist coordinate system
PERS tooldata tGun:=[TRUE,[[119.406,-44.3262,366.111],[0.907688,0.063564,0.379997,-0.166328]],
[5,[85,0,90],[1,0,0,0],0.01,0.01,0.01]];

wobjdata
If no work object is specified, the system uses wobj0. As previously mentioned, it might be possible to
add (or change) a work object after a program is taught, but it is (at best) a painful, time-consuming
process.
PERS wobjdata woWOBJ:=[robot hold,(fixed) user frame programmed, user frame mechanical
unit,user frame ([translation],[ rotation]),object frame ([translation],[rotation])];
PERS wobjdata woTC_S1:=[FALSE,TRUE,"",[[0,0,0],[1,0,0,0]],[[1475,-534.573,510.82],
[0.999995,0.000303,-0.000191,0.003259]]];
robhold – the robot is holding the work object (stationary tool) TRUE/FALSE
ufprog – User coordinate system is fixed ( as opposed to a mobile system using coordinated external
axes) TRUE/FALSE
ufmec – a string that identifies the mechanical unit for coordinated motion, if a mobile user coordinate
system is used (ufprog =FALSE), "" otherwise.
uframe – the work surface or fixture. trans is the position of the origin, rot is rotation, expressed as
quaternion.
oframe – the current object (with respect to the table). trans is the position of the origin, rot is rotation,
expressed as quaternion.
The interaction between uframe and oframe is unclear (to me). I’ve seen both coordinate systems
taught to the same point, and I’ve seen one (or the other) left at [[0,0,0],[0,0,0,0]].
TCP (Tool Center Point)
Defining a TCP (tool)
Modifying a TCP
Switching between TCP’s

Work Objects
Defining a work object
X1 ->X2 sets zero point for Y and determines direction for X+. Y1 sets zero point for X and
determines direction for Y+. X1, X2, and Y1 all have (or set) Z=0, and thereby determine the plane for
Z=0. Right-hand rule determines direction for Z+.

Modifying a work object

Switching between work objects

Subroutines/Functions
Calling subroutines
Passing parameters

Pattern shift
Offset
RelTool
Pdisp
PdispSet

Basic I/O

Viewing I/O
Defining/renaming I/O points

System Operations
Reboot

Backup/Restore
Parameters
Rev(olution) counter update
ABB uses two resolvers (analog position indicators) per motor/axis to provide position
information. One (coarse) simply counts how many 360° revolutions the motor has made, the other
(fine) provides an indication of the partial revolution. Fine positioning requires calibration, and ABB
uses an electronic level to set up machines (although some technicians “cheat” with a dial indicator).
Unless a motor has been replaced, most non-painters won’t need recalibration. If a robot is moved with
the controller off (or the cable is disconnected), they can lose track of where they are.
There are alignment marks on the robots for each axis zero position. Except for axis 3 (which is
dependant on axis 2 position) most axes can be independently reset. Ordinarily, all axes requiring
update are reset at the same time. The robot is driven to the alignment marks. On the Miscellaneous
page:
Select Service.
Press the key at the top of the screen labeled “View”.
Choose option 3. Calibration
Press the key at the top of the screen labeled “Calib”.
Choose option 1. Rev Counter Update
Select the axes requiring update.
With enable button released, press OK (bottom right of screen).
After the rev counters are updated, select the Program window , Special-4, look for a routine

named Zero, CalPos, or something similar. Lacking that, you can either build one, or embed in an
existing program the line:
MoveAbsJ [[0,0,0,0,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]],v200,fine,tool0;
Execute this line. If robot moves slightly, it’s OK. However, if it moves from alignment marks,
that axis will need to be updated again. If repeated attempts are unsuccessful, that axis may need to be
recalibrated (and all programs touched up…)
Error logs and codes

Exercises
Exercise #1 – Move around
Explore the different Modes, Motion types, and their interaction. What happens to the tool as you
move left-right, or up/down?
How does tool orientation affect motion in Tool coordinate system? How is Re-orient different
in World, Tool, and Work Object coordinate systems?