Kuka robot control with siemens plc

Just got PM from you about this. note that Personal Messages are PERSONAL, for discussions about ROBOTS, please use FORUM so that EVERYONE can participate and benefit from the exchange... don't be selfish.

and PMs should have subject too...

Regardless which PLC you use, same interface must be available on both PLC and on Robot to exchange data.

if your controller has I/O, you may connect them to PLC I/O. This will allow you to control robot from PLC in a sense that you may handshake some data and influence how robot runs but - robot programs are on the robot, not on PLC. Note that is not good way to communicate unless only few bits are needed. for volume of data one should use some sort of network or fieldbus.

Siemens PLCs are likely to have ProfiNet and/or ProfiBus option. On KRC4 you can add ProfiBus option through EtherCat interface (X44) and some hardware (bus coupler EK1100 and ProfiBus card such as EL6731-0010).

Kuka has many tech packages (add-on software). Tech packages can be used to simplify your tasks but you may of course choose to not use them and develop anything you need from scratch - yourself.

Most tech packages are paid options but - few are also free.

mxAutomation is a commercial product (paid option) so if you want it, you need to buy it. Purpose of mxAutomation is to program robot (including motions) using PLC software (such as Siemens, AB etc.).

mentioned I/O (64 safe io and up to 256 standard) are available IF your controller has ProfiNet option installed (this too is a paid option).

if your controller does not have ProfiNet, you either need to buy it or forget about communicating through ProfiNet.

Usually in PLC-KRC connections, PLC is master (controller) and KRC is a slave (device).
Master needs to have detailed scan list of the network (nodes with names addresses, io ranges etc).
This also means integrating Device Description File of each slave into DTM catalog of the master.

Device Description Files have different format and extensions depending on type of network:

if using ProfiBus, you need to use *.GSD or *.GSG files.
if using ProfiNet, you need *.GSDML
etc.

For simple data exchange (just a linear block) you may use generic file.

>I have seen that mxautomation is another way to do that but i cant find the global library. Do i have to buy that?

The S7 library is free ,but I think you have to pay the mxAutomation, this is a Option Package Technology for KRC4. The package includes free library.

you need to get KUKA GSDML file (installs with WorkVisual) and integrate it into TIA. read ProfiNet manual

Dear Panic Mode,

I don't think my question deserves an individual post since it is related to profinet communication. In few weeks I will be working on KUKA KRC4 latest vesrion and S7-1500. I have read all about configuring it, wokring on WorkVisual, importing GSDML file into Tia Portal, defining 256 inputs and outputs on WorkVisual and so on. They would like to have robot as complete slave to PLC, robot should only move to the predefined positions and PLC will control where to move, when to move, and also activating and releasing the gripper.

My question it what is the best way to prepare the program on the robot side for such master-slave communication. I was thinking of using interrupts for specific input sent form PLC, for example:

INTERRUPT DECL 10 WHEN $IN[6]==TRUE DO Gripping()

INTERRUPT 10 ON

Is this the right way or should I use CYCFLAG?

Any suggestions are more than welcome since I haven't been working with ProfiNET yet.

Thank you in advance!

Interrupts are probably overkill. They create a very real risk of interrupting the robot mid-path and sending it down a new, unpredictable path. This should generally be avoided except when absolutely necessary.

The normal mode of operation is to have the robot wait, at a known position, for a command, carry out that command, then wait for the next command. This makes the entire system more deterministic -- the program can only branch at certain fixed locations, instead of any random location along any path. In my experience, the latter usually creates more problems than it solves, and creates programs that become nearly impossible to reliably debug.

why not give a try to default way using CELL.SRC

Dear SkyFire,

Thank you for your suggestions. Thats an elegant solution indeed.

Dear Panic Mode,

I am not sure what do you mean by default way in CELL.src?

Thank you for update.

I think I found the solution in one of the previous posts on how to use CELL.SRC:

Understanding cell.src

Using this ledder and code like this every case could represent different robot program:

1 DEF CELL ( )

…

6 INIT

7 BASISTECH INI

8 CHECK HOME

9 PTP HOME Vel= 100 % DEFAULT

10 AUTOEXT INI

11 LOOP

12 P00 (#EXT_PGNO,#PGNO_GET,DMY[],0 )

13 SWITCH PGNO ; Select with Programnumber

14

15 CASE 1

16 P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )

17 ;EXAMPLE1 ( ) ; Call User-Program

18

19 CASE 2

20 P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )

21 ;EXAMPLE2 ( ) ; Call User-Program

22

23 CASE 3

24 P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )

25 ;EXAMPLE3 ( ) ; Call User-Program

26

27 DEFAULT

28 P00 (#EXT_PGNO,#PGNO_FAULT,DMY[],0 )

29 ENDSWITCH

30 ENDLOOP

31 END

What I still havent figure it out is how to connect signals such as PGNO thru ProfiNet? I am quessing that signal such as $Move_Enable can be easily connected to the input defined for ProfiNet, but I am not sure hot to use PGNO.

Hope my thinking goes in the right direction.

Thank you both for your help!!!

You need to take training or read programming manual for system integrators.

Once you get some IO shared between KRC and PLC (physical or fieldbus), they can signal each other.

Some commonly used signals are grouped under AutoExternal interface, where you can easily pick IOs for each of these that you plan on using. That includes handshake signals for program number etc.

Then in CELL.SRC simply call correct program when PLC tella to run program number X.

This is all in the manuals. But basically it's a two-step process.

First, set up your FieldBus (ProfiNet, in your case). This connects specific bytes from the ProfiNet driver to the robot's internal $IN and $OUT arrays. Say, for example, you configure the robot<>PLC ProfiNet connection for 16bytes both ways, and connect those 16 bytes to $IN[1] through $IN[128] and $OUT[1] through $OUT[128]

The second step is to link the various PGNO-related variables to particular $INs and $OUTs. For example, PGNO_FBIT is an integer that controls the first bit of the PGNO number sent from the PLC to the robot, and PGNO_LENGTH defines how many bits PGNO takes up. So setting PGNO_FBIT to 17 and PGNO_LENGTH to 8 would mean that the program number would take up $IN[17]-$IN[24] on the robot, and in the PLC would occupy the 3rd byte of whatever I/O was assigned to the robot connection.

There's a number of other PGNO-related variables that configure how CELL interacts with the I/O -- PGNO_FBIT_REFL, PGNO_PARITY, PGNO_VALID, etc. The CELL interface is quite flexible, you just need to set the options, and program your PLC to match. Then you need to replace the commented EXAMPLEx() program calls with calls to your own robot programs -- which CASE number you put the call into controls which PGNO value from the PLC calls which program in the robot.

Dear Panic Mode and SkyeFire!

So setting PGNO_FBIT to 17 and PGNO_LENGTH to 8 would mean that the program number would take up $IN[17]-$IN[24] on the robot, and in the PLC would occupy the 3rd byte of whatever I/O was assigned to the robot connection.

This is what I was missing from the manuals or not quite understand! Now everything is perfectly clear!!!

Thank you for your help!

Much appreciated!

Best Regards!

yes. you can set different length if needed. note that on PLC side this may be arranged differently

Hello to the members in this thread...

read about the prog no concept mentioned by respected SkyeFire.

i need a little help regarding "userdefined variables" in "$Config.dat" file.

For an external rotary stage when we define some variables in "config.dat" like

SIGNAL Rotary_POSITION $OUT[257] TO $OUT[288]

SIGNAL Rotary_SPEED $OUT[289] TO $OUT[320]and

REAL RotaryPOSITION=0.0;

REAL RotarySPEED=10.0

i am confused that the above mentioned $OUT[257] TO $OUT[288] is the same output we defined in the mapped io step using profinet between KRC4 and PLC.. sorry if i am going in wrong direction.

variable $OUT[] is an array of BOOLs.

when you are declaring signal, you specify which output (or input) is used.

if using range of outputs (or inputs), up to 32 BOOLs or bits can be used in same signal. but all of the bits must be consecutive (no skipping allowed). also range is specified LSB to MSB. if signals is 32-bit, then MSB is a sign, otherwise no sign is used.

Signal is just an alias or substitute name to access one or more I/Os.

for example on KRC4 you may have 8192 outputs or $OUT[1] to $OUT[8192]

some of those outputs may be used to control stacklight or beacon, perhaps $OUT[1] to $OUT[4]

some of those outputs may be used to control robot gripper, perhaps $OUT[12] to $OUT[13]

some of those outputs may be shared with PLC1, perhaps $OUT[65] to $OUT[256]

some of those may be shared with PLC2, perhaps $OUT[257] to $OUT[512]

etc.

if you want to send signal to one of beacon units (RGB + buzzer for example), you will need to turn an output that is wired to beacon (1-4)

if you want to send signal to gripper, you will need to turn an outputs wired to gripper (12-13)

if you want to send signal to PLC1, you will need to turn an output that PLC1 can read (65-256)

if you want to send signal to PLC2, you will need to turn an output that PLC2 can read. (257-512)

etc.

if you want to send value to a PLC2 that uses single bit, you can declare it as such (must be bits that PLC2 can read, so in range 257-512):

SIGNAL To_PLC2_ROBOT_READY $OUT[511]
SIGNAL To_PLC2_ROBOT_Waiting $OUT[507]

etc.

if you want to send value to a PLC2 that uses multiple bits bit, you can declare signal that addresses multiple bits (must be bits that PLC2 can read, so in range 257-512)

SIGNAL Rotary_POSITION $OUT[257] TO $OUT[288]
SIGNAL Rotary_SPEED $OUT[289] TO $OUT[320]

etc.

but you do NOT declare variable with same name such as

REAL Rotary_POSITION=0.0;
REAL Rotary_SPEED=10.0

using similar name is ok but probably not preferred: and likely to lead to confusion

REAL RotaryPOSITION=0.0;
REAL RotarySPEED=10.0

oh and SIGNALs are always BOOL or WORD (integer)

copying REAL value to a SIGNAL is same as copying REAL value to an INTEGER so rounding will take place.

RotaryPOSITION = 45.8
Rotary_POSITION = RotaryPOSITION ; 45.8 does not fit into integer type variable so result is rounded to 46
$OUT[3]=TRUE ; turns on one of the beacons, neither PLC1 nor PLC2 can see this
$OUT[66]=TRUE ; PLC1 should be able to see this, but PLC2 cannot see it
To_PLC2_ROBOT_READY =TRUE ; PLC2 can see this but not PLC1

got it sir.

Thanks alot for providing detailed description.. showing my cordial respect..

Hi all, this is probably related to the above.

I have a S7-315 controlling a KRC3. Not very proficient with the KUKA part. Basically the main part of the program is an FB1 S7-GRAPH, containing about 30 steps. I am trying to add an extra sequence, almost the same as, say S14-S16, but with a different gripper orientation. If I add the extra steps and transitions, all is well on the Siemens side(incl. the Sinamics servo attached to the KUKA), but the KUKA inputs are not allowing the transition and the robot just stands at S19- not going to S14a, S15a, S16a, and eventually to S17. Is there an easy way to get access to the KUKA inputs without having to learn the whole KUKA documentation?

Thanks in advance

Yes.

You only have to learn the part where access to input/output is described.

In most cases there are some spare i/O on the interface to plc, but you even didn't describe the way how Kuka and plc are connected. You only have to find the spare signals.