Controlling Kuka With Siemens PLC Without MXAutomaion

Yes.

Set up some group i/o, one group for each coordinate, send actual position over group outputs to plc, calculate position, send position over group outputs (view from plc, inputs view from Kuka) to Kuka.

On Kuka write a program that reads new positions and move to them.

There should exist some examples here in the forum, as this is done many times from many programmers. Just search for it.

not sure what the application is but my feeling that this is going to be ambitious for someone with limited robot experience. for example transmitting position value is not very practical.

singe position element is 32-bit value so exchanging FRAME means 192 bits. and some moves are axis specific, so that is another 192 bits. and FRAME or POS only makes sense when tool and base are known. it does not take a genius to see that a lot of I/O is quickly consumed just to specify target position. so one need to be very selective in what info is to be transmitted.

next, PLC does not have math capabilities to do anything complex. sure one can write own routines but have you looked at things like geometric operator and instruction like INVERSE?

and assuming you have all math functions you need implemented, they can only work when having valid data. but that means transmitting even more values. not to mention that any data exchange is bound to have delays. and that will limit what one can do with multiplexing.

to put it simply, there is a reason this functionality is put into instructions that are external library and not taxing the PLC interpreter.

it may be better and easier to exchange simple handshake signals and let the robot take care of robot things. this is common in places like material handling.palletizing... all that PLC need to do is tell robot what to do (each instruction is another bit) and index values. this is easy to confirm and makes things more portable in case one need to use a different robot (or robot brand).

Panic Mode is correct but on top of that there is a speed issue.

If you post the coordinate from the PLC to the robot, the robot only cycles so fast (4ms?). You need to read the data, convert it to a REAL, confirm the data back the PLC, and then Read new data again. On top fo it you have a cycle or two going each direction for data handshaking to control data flow.

Depending on the length of your moves, and the velocity at which you make those moves, the cyclic response my be too slow to not only keep up but to keep ahead.

T

Quote from kukauser1

We are trying to control our KRC4 Kuka robot with Siemens S7-1200 Plc.

1st question: what communication options does your KRC4 have?

But if you use an external camera that is connected to the PLC, you do not have other options for transmitting the target locations to the KUKA controller. You have to send the X Y Z and Rotation angle using the 32 bit signals. Right?

Quote from Koppel

But if you use an external camera that is connected to the PLC, you do not have other options for transmitting the target locations to the KUKA controller. You have to send the X Y Z and Rotation angle using the 32 bit signals. Right?

Not necessarily. I've done it in the past with 16- and even 8-bit signals. It depends on the range and resolution the application requires.

it also depends on type of connection. signals are tied to IO points. IOs points are tied to a fieldbus and are refreshed cyclically. this is convenient when the other side is a PLC for example. but... that is not requirement... camera data does not need to be transmitted cyclically or through IO. it is not unusual that this exchange is done through TCP/IP and have target variables that are not some IOs. vision systems may connect to KRC through EKI for example.