EL6695-1001 to Beckhoff PLC

Module2 is a safety IO.... On the robot side order of the signals is fixed so you need to match it on the PLC side. Check SafeOp manual for mapping.

Module3 is a standard I/O... size of this area need to match size chosen on the robot end and it looks like you chose 512 bytes. if on the robot side you have 32 DINTs (each is 4 bytes), that means 32 groups * 4 byte / group =128 bytes are used and there is plenty of spares. order of data here is free. you can do anything you want, just make sure order is same on the robot side.

i am not sure i understand your question... data in one of I/O blocks is sequential. you can think of it as bit-array and you can group it any way you like. as with any array, each bit should be only mapped once.

elements location is determined by size of element(s) and their location in the data block. to access some specific location one can use name or index.

one can get exactly same result regardless if mapping is done bit-by-bit or byte-by-byte or whatever group size you like. i don't have time or energy to delve on basics or explain every possible scenario. if you have a specific problem, ask specific question and provide details.

your bus configuration uses correct device description files and so far you are good.

your wiring is not shown but EtherCat cable from CCU.X44 need to go to EK1100. (this is primary interface for EL6695) and the other EtherCat cable (from PLC) need to go to EL6695 module (this is the secondary interface for EL6695). and beside communication signals I/O node needs power. i hope (assume) this part is correct.

"I don't understand the signal transfer between the two devices."

all right... no problem...

do you understand the difference between inputs and outputs?

and do you understand how physical I/O would be used between PLC and the robot? (if you had to do this without fieldbus...)

outputs can be wired to drive inputs....

outputs are set/written by program (or manually if testing)

inputs are read only from programs perspective. it need to be set by something external...

therefore:

PLC outputs would need to be wired to robot inputs.

robot outputs would need to be wired to PLC inputs.

and if you have a lot if I/O between the two nodes, there will be a lot of wires...

using fieldbus simply replaces all the individual wiring so that you can use simple cable (only few-wires) to exchange many bits of data. but the signal direction still has to be observed.

to send a signal from PLC to robot, you would manually or programmatically set an output on the PLC side.

the top of your screenshot shows WoV mapping of robot inputs. this is correct.

the bottom portion of your screenshot shows also inputs... on the PLC side. have not worked with Beckhoff PLC software so cannot tell if this is correct.

but i see no outputs mapped on either side, meaning neither robot nor PLC will be able to send any signals to each other.

very good

Hey DP18,

as you mentioned, you were able to solve your issue. Currently I am struggling at the same point as you stated out in your question. Beckhoff is set up as secondary and KRC4 as primary. Further, I already tried to map some inputs/outputs in Workvisual (almost the same as shown in your posted figure). In Twincat I have also defined Input and Output variables in the plc section, and linked them to the corresponding Std.Output/Input of the KRC4 secondary.

But now the part, where I am currently struggling with: I don't exactly know, what the next steps are to get for example the actual position data of the robot and further proceed this data in twincat or in general see some data from the robot in twincat. Maybe you can give me a hint how to proceed on from my current situation.

Any help would be greatly appreciated.

Many thanks and best regards.

Quote from matt314

But now the part, where I am currently struggling with: I don't exactly know, what the next steps are to get for example the actual position data of the robot and further proceed this data in twincat or in general see some data from the robot in twincat. Maybe you can give me a hint how to proceed on from my current situation.

Well, to start with, what signals have you mapped in WV? Whatever $OUTs you have mapped to the PLC, if you force one on from the pendant (teach mode, deadman held, motors on are prerequisites), you should see the corresponding input on the PLC change state to match.

Likewise, whatever the first PLC output you mapped in TwinCAT to the robot, if you force it on in the PLC, you should see the corresponding $IN on the robot change state to match.

Quote from SkyeFire

Well, to start with, what signals have you mapped in WV? Whatever $OUTs you have mapped to the PLC, if you force one on from the pendant (teach mode, deadman held, motors on are prerequisites), you should see the corresponding input on the PLC change state to match.

Likewise, whatever the first PLC output you mapped in TwinCAT to the robot, if you force it on in the PLC, you should see the corresponding $IN on the robot change state to match.

I have attached some images (had to zip it because I can only upload one image/file), where the mapping of the I/Os is shown, and where I further assigned a value to the SIGNAL POS_X.

I already managed to send data from the robot to the plc in automatic mode (using the configuration shown in the zip folder), but for example if I want to actively send the robot a new position (x,y,z, ... coordinates) from the plc, the robot needs to be in aut/ext mode?
I think in order to get this work, I need to switch to aut/ext mode on the robot smartpad?

Many thanks

you can send data from PLC to KRC any time you like. that is just data transfer and it does not matter what the operating mode is or if robot is in EStop for example.

btw, position values are real but value you transmit is an integer. this means you will loose anything after decimal point. a workaround it to use floating point or fixed point. floating point requires conversion to floating type (REAL). fixed point is using integers but location of decimal point is assumed. for example one can multiply value by 1000 before sending, then divide received value by the same factor (1000 in this example). this does not need to be 1000, you can pick any suitable value (say 666) but it need to be same on both sending and receiving end.

System variable $POS_ACT_MES contains the "live" Cartesian position of the robot. With some caveats: after a program reset, or when there is no valid $TOOL or $BASE active, the values in $POS_ACT_MES will be Undefined.

You can transcribe this data into Signals during your program, or set up code in the SPS to do it constantly, but keep the above caveats in mind. If you try to copy an invalid value from $POS_ACT_MES into a SIGNAL, the program will halt on an error.

POS_X=$POS_ACT_MES.X is what you need to start with. Then:

POS_Y=$POS_ACT_MES.Y

And so on.

You may need to use ON_ERR_PROCEED immediately before each copy in order to protect against invalid data. Keep in mind that $POS_ACT_MES can change values out of sequence with the SPS, so you could get X and Y from the position on one scan, and values from a different scan (or no values at all) in Z,A,B,C.

that is if sending data from KRC to PLC.

in the other direction you would populate element values into variable of suitable type (such as POS) and use motion command to move robot to that point.

Hey panic mode and SkyFire,

thanks for your help and detailed description regarding my described problem.

The sending and receiving using the I/Os of the KRC4 is working now.

Meanwhile I also got in contact with the customer service of KUKA, and he suggested to use the robot sensor interface instead of using the I/Os of the KRC4 in order to send new position data to the robot from the plc based on calculations from external sensor data and for retrieving the new position of the robot.

Does some of you have experience on this topic, and could give me an advise? I am already reading through the manual of the robot sensor interface 4.0, since this is the version I have installed on the robot, and to get an idea of its functionality.

BTW. I hope it is fine to ask here in this thread, because at the beginning the original problem of DP18 was very similar to mine, otherwise I can start a new thread, in case I am violating some guidelines.

Many thanks and best regards

RSI is complex and advanced programming. Many threads dedicated to it in the forum archives. Only needed if you want real-time control of robot motion from an external source.

hi, have you found the solution. Maybe you should go to PDO setting of EL6695 1001 and check if the inputs and outputs are active in Workvisual.

Hi! Currently i am having problem whereby from beckhoff (secondary) i was unable to receive the output from KRC5 micro but KRC5 micro able to get the output from beckhoff PLC. any idea what goes wrong??