ABB programme first time

[gouch]

Hello,

I have to do a demo program on an abb robot. I have not programmed an abb robot before but I have used kuka robots before. I want to be able to create a new program, enter in 4 moves to go around in the shape of a square, maybe cut the corners to speed up the cycle. I want to use an input to be able to time how long the cycle takes. I will run the robot cycle from the pendant.

I have nearly no knowledge about doing this on an abb controller. Any help to start me off would be appreciated.

The robot controller is an IRCS5 M2004 controller.

[SkyeFire]

Well, you should have gotten some CDs with the ABB programming manuals with the controller.  Also, a CD for installing "RobotStudio Online."  It'll run without a license key, and lets you program in RAPID language much more easily than on the pendant, as long as you connect using an Ethernet cable (you'll need to set up your laptop to "obtain IP automatically", as the IRC5 actually has a built-in DHCP server).

Programming isn't too strange from a KUKA perspective.  The big difference is that where KRL usually divides everything up into separate lines of code, RAPID usually works by adding multiple option switches (prefix'd with '\') at the end of a command.  You can have some pretty long lists of options.

So, a Move command in RAPID can look like this:

Code:

  MoveL R1_Appro_Rack, v500, z10, toolgrip1\WObj:=Rack_Base; 

Where MoveL is a Linear Motion commdn, R1_Appro_Rack is the name of a RobTarget position variable, v500 is a "speed" variable, Z10 is an accuracy/approximation variable, toolgrip1 is the TCP active for this motion, and the \WObj:=Rack_Base is an option switch setting the active Base (or Work Object in ABB-speak) for this motion.

Major differences from KRL: 
every line MUST end with a ; symbol, except for special cases like IF, ENDIF, etc.
Some of these option switches are, well, optional.  Some aren't (that is, you HAVE to have SOMETHING there).  Some are mutually exclusive.
There's a number of Z and V variables that come pre-made, but you'll need to create your own.  Fortunately, this is pretty easy.
RAPID doesn't have separate SRC and DAT files.  Instead, you can define variables at the top of a .MOD file, before you start adding executable code with PROC()/ENDPROC.  Unless declared with LOCAL, all variables are treated as Global (at least to the Task level).
RAPID uses XYZ and Quaternions, rather than XYZRxRyRz or any Euler variation.  Don't try to understand Quats, they're not human-readable, just remember that RAPID includes some built-in fuctions for converting between Euler and Quats, and you can have the teach pendant display either way. 

[cdenizden]

Dear All,
The quaternions are the best way to modeling a robot.
Q=[q1,q2,q3,q4] or Q=[v,w]
Point, P=QxDxQ*.
D is joint lenght.

Regards,
Cengiz Deniz

[gouch]

Thanks skypefire for your advice. I dont actually have the robot in my workshop. I have to go to the customers and do a trial on a product with a robot that I have never physically seen or programmed at all. I will read up the manuals but it is very hard to be able to arrive at the customers demo robot and be able to program it having just read the manual.

Your advice has given me a good deal of pointers on what I need to learn and be familiar with. The customer doing the trial has no experience with abb robots either so it will be fun anyway.

[gouch]

Could the robot require calibration. Do you need a tool to carry this out. I assume its a similar method to calibrating the kuka robots.

[MotorCitySTI]

It should be fine. You may need to update rev counter depending on how long it has been powered off. If you need to fine calibrate the robot it requires hardware.

Here is a simple program that will execute four moves while the boolean is True.

MODULE Main
  !--------------------------------------------------------------------------------------
  !  Start of the DATA Declarations
  !--------------------------------------------------------------------------------------
  ! tooldata
  !--------------------------------------------------------------------------------------
  TASK PERS tooldata tGripper:=[TRUE,[[-309.469,11.2227,420.133],[0.745406,-0.0820019,0.0899695,-0.655401]],[8,[-84.7,43.7,141.6],[1,0,0,0],0,0.265,0.179]];
  !--------------------------------------------------------------------------------------
  ! Robtarget
  !--------------------------------------------------------------------------------------
  TASK PERS  robtarget pMove1:=[[796.71,962.24,1111.52],[0.0636996,-0.00726073,-0.00773251,-0.997912],[0,1,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
  TASK PERS  robtarget pMove2:=[[796.72,1421.31,1111.52],[0.0636922,-0.00725793,-0.0077347,-0.997913],[0,1,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
  TASK PERS  robtarget pMove3:=[[775.21,1421.75,1137.71],[0.0649999,-0.00680602,-0.00756012,-0.997833],[0,1,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
  TASK PERS  robtarget pMove4:=[[769.36,1421.79,1167.05],[0.0655839,-0.00643649,-0.00717093,-0.9978],[0,1,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
  !--------------------------------------------------------------------------------------
  ! Boolean
  !--------------------------------------------------------------------------------------
   PERS bool bRobotRun:= FALSE;
  !--------------------------------------------------------------------------------------
  !  Start of the MAIN program
  !--------------------------------------------------------------------------------------
  PROC Main()
    !--------------------------------------------------------------------------------------
    !Main Loop
    !--------------------------------------------------------------------------------------
    WHILE TRUE DO
      !--------------------------------------------------------------------------------------  
      TPWrite "Waiting for motion command";
      WaitUntil bRobotRun = TRUE;
      !--------------------------------------------------------------------------------------
      !Movements
      !--------------------------------------------------------------------------------------
      MoveJ pMove1,v5000,z200,tGripper;
      MoveJ pMove2,v5000,z200,tGripper;
      MoveJ pMove3,v5000,z200,tGripper;
      MoveJ pMove4,v5000,z200,tGripper;
    ENDWHILE
  ENDPROC  
ENDMODULE

You should be able to load  this if you copy it into a text editor and save as MAIN.mod

[gouch]

Thanks,

Thats a big help.

What condition is the while loop waiting to be true."WHILE TRUE DO".

What mode should I select to run the program?

How are programs generally loaded. Is there a chance that a default program is already selected to open and run on the robot when powered up on is a specific run mode?

[SkyeFire]

WHILE TRUE DO is a "cheat" for saying "do forever."  Sort of like WHILE (1-1=0) DO.

Mode?  ABBs only have two modes, unlike KUKAs.  Definitely work in Teach until you're sure you can run in Auto okay.

One thing to be aware of:  ABBs can be set in "Loop" mode, where they will keep re-looping the selected program even if that program doesn't have a loop.  In this mode, every time the program pointer hits the end of the program, it will jump back to the first line and keep running. 

Also:  unlike KUKAs, when you hit the "Play" button on the teach pendant, and let it go, the robot will keep on going until you hit the Stop button or release the deadman.  It's a bit of a surprise to people with KUKA backgrounds at first.  If you want to single-step, use the button that looks a bit like the "next track" button on a MP3 player.

The joystick will take some getting used to.  It can only control three axes at a time, so in Joint mode, you have to select (using the Gears icon in the bottom right of the screen) either Axes 1-3 or Axes 4-6.  Left-right controls the first axis of the group, up-down controls the second, and twisting the stick controls the third.  If you need the robot to stop jogging quickly, LET GO OF THE STICK!  Many people try to reverse the stick instead, which causes the robot to "drift" for a good second or so before it changes direction. 

There's a way to select a default program, I think, but I don't believe it's configured from the factory. 

[gouch]

Thanks for your advice. I picked up an abb pendant for the first time yesterday and it is a little strange after being familiar with kuka. I got the progam below setup. flag1 is not used yet so never goes true. The robot program may be run when im not there so I wanted to force the user out of automatic mode and only run in manual mode.

I deleted the program that was on the robot when I created my new program. I selected dont save I think when creating my new program.

PROC main()
      WHILE flag1 = FALSE DO
         IF OpMode() <> OP_AUTO THEN
            MoveL mid_return, v800, z50, tool1;
            MoveL above_pick, v800, z100, tool1;
            MoveJ pick, v800, fine, tool1;
            MoveL drop, v800, fine, tool1;
            MoveL above_drop, v800, z20, tool1;
         ENDIF
      ENDWHILE
   ENDPROC

[gouch]

There is a digital input output module in the robot controller. Can somebody give me advice on how to configure this. Ive looked in the EIO.cfg file offline using notepad but it doesnt make any sence in that format. Is there a viewer which is required to look at it.

[luetin]

The eio.cfg is a plain txt file, I normally use ultraedit to open them to get the formatting correct. Maybe it can be formatted in notepad as well, I'm not sure.
http://www.ultraedit.com/ they have a 30-day trial for download there.

You can also use robotstudio for online editing with the robot. The online part of the program is free and can be downloaded at http://www.abb.com/product/ap/seitp327/049ffeb82687791ec12574b9004958cf.aspx

About declaring the input module you can search this forum for generic device and it will point you in the right direction I think.

[SkyeFire]

EIO.CFG should come up fine in NotePad.

If UltraEdit is too expensive, NotePad++ is free and has a lot of the same capabilities, if less polish.

This is what a trimmed-down EIO file looks like from one of my backups:

Code:

EIO:CFG_1.0:5:0::
#
EIO_BUS:

      -Name "Virtual1" -ConnectorID "SIM1"

      -Name "DeviceNet1" -BusType "DNET" -ConnectorID "PCI1"\
      -ConnectorLabel "First DeviceNet"

      -Name "DeviceNet2" -BusType "DNET" -ConnectorID "PCI2"\
      -ConnectorLabel "Second DeviceNet" -DN_MasterAddress 63 -DN_BaudRate 250
#
EIO_UNIT_TYPE:

      -Name "Virtual" -VendorName "ABB" -ProductName "Virtual unit"

      -Name "DN_GENERIC" -BusType "DNET" -DN_ExplicitMsgEnabled \
      -DN_C1OutputSize -1 -DN_C1InputSize -1

      -Name "d651" -BusType "DNET" -VendorName "ABB Robotics"\
      -ProductName "Combi Unit" -DN_VendorId 75 -DN_ProductCode 25\
      -DN_DeviceType 100 -DN_ExplicitMsgEnabled  -DN_C1Type "COS"\
      -DN_C1OutputSize 5 -DN_C1InputSize 1

      -Name "IRC5_DN_SLAVE" -BusType "DNET" -VendorName "ABB, Inc."\
      -ProductName "5136-DNP-PCI DNSCAN" -DN_VendorId 8 -DN_ProductCode 12\
      -DN_DeviceType 12 -DN_MajorRev 2 -DN_MinorRev 16 -DN_C1Interval 50\
      -DN_C1OutputSize 16 -DN_C1InputSize 16

      -Name "DeltaPoint" -BusType "DNET" -DN_VendorId 20 -DN_ProductCode 27\
      -DN_DeviceType 12 -DN_C1OutputSize 1 -DN_C1InputSize 4
#
EIO_UNIT:

      -Name "WaterSaver1" -UnitType "DeltaPoint" -Bus "DeviceNet1"\
      -DN_Address 13

      -Name "IPCSimBoard" -UnitType "Virtual" -Bus "Virtual1"

      -Name "Node10" -UnitType "d651" -Bus "DeviceNet1" -DN_Address 10

      -Name "PLC_IO" -UnitType "IRC5_DN_SLAVE" -Bus "Virtual2"
#
EIO_SIGNAL:

      -Name "g1_flow1_ok" -SignalType "DI" -Unit "WaterSaver1" -UnitMap "0"\
      -Access "ROBOT" -FiltAct 300 -Invert

      -Name "g1_air_ok" -SignalType "DI" -Unit "WaterSaver1" -UnitMap "5"\
      -Access "ROBOT" -FiltAct 300 -Invert

      -Name "g1_temp_ok" -SignalType "DI" -Unit "Node10" -UnitMap "6"

      -Name "RobotClrZone1" -SignalType "DO" -Unit "PLC_IO" -UnitMap "88"\
      -Store
#
EIO_CROSS:

      -Res "g1_water_ok" -Act1 "g1_flow1_ok" -Oper1 "AND" -Act2 "g1_flow2_ok"

      -Res "ext_override" -Act1 "skip_proc" -Oper1 "OR" -Act2 "reweld_proc"
#
EIO_COMMAND_TYPE:

#
EIO_ACCESS:

#
SYSSIG_OUT:

      -Status "MotOnState" -Signal "motor_on"

      -Status "CycleOn" -Signal "cycle_on"
#
SYSSIG_IN:

      -Signal "StartRobotCC" -Action "MotOnStart" -Arg1 "CONT"

      -Signal "ResetErrorCC" -Action "ResetError"

Basically, in EIO, you create Buses and give them names.  You create module types and give them names.  Then you create actual modules, with addresses, on those buses and give them individual names.  Then you assign names to the signals for each of those individual named modules.  Then you can do things like perform Boolean logic operations between signals (in the EIO_CROSS section) without having to use program code.  And there's a section where you can connect System Status flags to particular I/O signals.