KUKA KR150 R2700-2 KRC4 - Points offset through HMI Easy

Hi Skyefire,

This looks like exactly what I am trying to do! Where would I declare the variables ‘X_ofs’ ? And what type of variables are they, INT?

Im transferring data between Beckhoff PLC/HMI & KUKA KRC4, using EL6695 EtherCAT bridge. Have everything working in EXT and just need to offset placing position on a pallet depending on size of product to be placed.

Thanks!

Quote from SkyeFire

KRL does not accept variables inside the {} of a STRUC type variable. As such, what you want to accomplish needs to be a multi-step process:

Code

DECL FRAME _fOffset

_fOffset = $NULLFRAME
_fOffset.X = X_Ofs
_fOffset.Y = Y_Ofs
_fOffset.Z = Z_Ofs
_fOffset.A = A_Ofs
_fOffset.B = B_Ofs
_fOffset.C = C_Ofs

LIN Point : _fOffset ; apply Offset in Tool coordinates

LIN _fOffset : Point ; apply Offset in Base coordinates

Display More

The variables have to be real.

You can't send real variables over the bus system, only integer.

Integers only use sign automatically when they are 32 bit long.

You can convert the reals to integer (multiply/divide them with 10 or 100 before/after transferring).

Or you can send reals on 4 bytes and convert them on robot to real reals by type casting

This all is already discussed here in the forum for many times.

Quote from SamReynolds

This looks like exactly what I am trying to do! Where would I declare the variables ‘X_ofs’ ? And what type of variables are they, INT?

They could be DECL'd anywhere, depending on how you handle them -- just has to be within scope. So, either DECL'd locally in the subroutine, DECL'd in the .DAT file of the module you're using them in, or DECL'd Globally in another module or $CONFIG.DAT.

They can be INT, but for precision they should be REAL.

Quote from SamReynolds

Im transferring data between Beckhoff PLC/HMI & KUKA KRC4,

In that case, hermann has it pretty much covered. You can create custom SIGNALs in KRL up to 32bit, but SIGNALs can only be INT (or BOOL, for a single-bit SIGNAL). So you would have to "massage" the values on both ends -- multiply by 100 in the PLC, send the integer portion of the result to the robot, then divide the integer value the robot receives by 100 to put the decimal point back in the correct place.

So in this case X_Ofs might be DECL'd REAL in the module .DAT file, along with a SIGNAL X_Ofs_From_PLC, then assigned in the .SRC file like:

(in the .DAT file):

SIGNAL X_Ofs_From_PLC $IN[1] TO $IN[16]

DECL REAL X_Ofs = 0.0

(In the .SRC file):

X_Ofs = (X_Ofs_From_PLC/100.0)

The '.0' is important, b/c in KRL, INT/INT division always generates an INT result. To get a REAL result, you need INT/REAL.

Hi Guys,

Thanks so much for the response! I'll try this today, apolgoies on the delay ive been on holiday.

On this specific project I'm using an odler EL6695 which only allows me to assign 32 DWORDS, so i'm covnverting a word to DWORD in beckhoff to fill the 32nd DWORD to allow me to address it in workvisual.

I'm hoping in doing this i can use the 32 bit signal as below instead of SIGNAL X_Ofs_From_PLC $IN[1] TO $IN[16]....?

SIGNAL X_Ofs_From_PLC $IN[1] TO $IN[32]

DECL REAL X_Ofs = 0.0

(In the .SRC file):

X_Ofs = (X_Ofs_From_PLC/100.0)

Thanks again and i will report back.

Thanks

Sam

Hi,

So this didnt work, i'm not sure how to isnert images on here so i'll explain.

I wrote this in the .DAT FILE

SIGNAL X_Ofs_From_PLC $IN[2017] TO $IN[2048]

DECL REAL X_Ofs = 0.0

(In the .SRC file):

X_Ofs = (X_Ofs_From_PLC/100.0)

All i'm looking to do at the moment is monitor the variable and see if it changes when i change it at the PLC side. When i monitor the variable it never changes from '0'.

I'm sending the signal as a DWORD from Beckhoff PLC which according to Workvisual is received as USINT in KUKA. Monitoring the Beckhoff outputs, the DWORD is reading 100, but monitoring the variable i get '0' and monitoring the inputs that are grouped together to form the DWORD $IN[2017] TO $IN[2048] I dont see any changes at all?

I'm only monitoring SIGNAL X_Ofs_From_PLC just to check that data is being received.

When I monitor X_Ofs it only ever reads 0.0 also, but presumably that is becasue we have set it to 0.0 in the INI? I dont quite understand why we have to do that?

This is my first time transferring anything other than boolean so apologies if i'm missing basic stuff.

Thanks

Sam

Is your mapping ok?

Your posts show signals using io 1-32 as well as 2017-2048 but you said you mapped 32 elements:

32bytes * 8bits/byte=256 bits.

32dword * 32bits/dword=1024bits.

Hi,

I am transferring one DWORD which is 32bits, mapped to

I wrote this in the .DAT FILE

SIGNAL X_Ofs_From_PLC $IN[2017] TO $IN[2048]

I wrote the exact detail in my last reply?

I tried declaring the beliow in the confg.dat file

SIGNAL X_Ofs_From_PLC $IN[2017] TO $IN[2048]

DECL REAL X_Ofs = 0.0

and

(In the .SRC file):

X_Ofs = (X_Ofs_From_PLC/100.0)

then monitoring X_Ofs and it never chages from 0.

Ive sent a number of diferent values from the plc and it doesnt change?

Thanks again

Sam

Can you see the digital inputs screen? And look if some bits change the state?

The last time I did it, I had to create a group of this signals (32 bits used in config.dat) in work visual and define as DINT, the same in beckhoff. It Enable you receive negative numbers.

Quote from Visentainers

Can you see the digital inputs screen? And look if some bits change the state?

The last time I did it, I had to create a group of this signals (32 bits used in config.dat) in work visual and define as DINT, the same in beckhoff. It Enable you receive negative numbers.

I have them grouped as DWORD on the bridge side and hten mapped to 32 inpits on the KUKA side. No inputs in the range that i have mapped are chanign thought. this seems to be the issue. The PLC is showing that it is sending the value but KUKA does not seem to be receiving. There are comm's between the two as i am sending other signals fine.

How do i add images in here?

Look to Attachments button under the write box.

When i press add image it just says source and link?

Brute-force approach: create a quick program in the PLC that flips that DWORD between 0 and 1 on a 0.5 or 1-sec interval. Then page through the $INs until you find the bit that's flashing. Then do the same for 0 and 256, which should identify the first bit of the second byte, then 65536 for the 3rd byte, and 16777216 for the first bit of the 4th byte. That should eliminate any confusion about addressing.

If you can't get any $INs to change state, then there's something more basic wrong. But usually in that case, you'd be getting error messages. I would try mapping the $INs as simple bits, rather than using the WoV word/dword stuff, and see if any values (even wrong ones) can be transferred.

Quote from SkyeFire

Brute-force approach: create a quick program in the PLC that flips that DWORD between 0 and 1 on a 0.5 or 1-sec interval. Then page through the $INs until you find the bit that's flashing. Then do the same for 0 and 256, which should identify the first bit of the second byte, then 65536 for the 3rd byte, and 16777216 for the first bit of the 4th byte. That should eliminate any confusion about addressing.

If you can't get any $INs to change state, then there's something more basic wrong. But usually in that case, you'd be getting error messages. I would try mapping the $INs as simple bits, rather than using the WoV word/dword stuff, and see if any values (even wrong ones) can be transferred.

My issue is the way the birdge works, i'm sending signals already to the robot and its sending DWORD, so to get it to work i have to use one fo the DWORDS thats already being sent but not being used. This is because the process image of this particular bridge only can only be set to receive 0-32 of a certain data type and i need it to be DWORDS for the amount of inputs i'm sending, i think.

I'll give this a try now though.

Is the syntax i wrote in the previous comments correct?

it does not matter if the data is DWORD or bytes or scattered bits as long as it is mapped correctly. this is only the transport layer and packaging is not all that important. you can have one side reading 32 bits as a single DWORD and other side that is sending data as another (different) 32bit group, maybe a DWORD, maybe 2 SINT, maybe three bytes + 8 single bits, maybe SINT and USINT, maybe two chars and a word...

so the important things is that:

a) SIZE of data on send/receive ends matches (same number of bits, format does not matter)

b) when you turn bit on/off on one side (PLC) you see one bit in the robot doing the same thing (confirmed exchange).

c) that you have enough of bits to exchange information (if you need 32 bits, you need 32 bits but they do not have to grouped together - although that is always nice).

once you have the data exchanged / transmitted, we are DONE with the transport layer.

next it is up to your program to interpret it correctly. and as mentioned, you can choose to look at data in different ways (single bits, grouped bits : byte, char, word, int, dint usint, sint, real...)

all of this can be massaged into correct form in the program alone. however, if mapping is done well, programming effort is significantly reduced or even eliminated.

to see if anything is changing, do as already suggested - make a PLC program that changes values. normally i just increment the value or maybe add rollover protection but on 32bits that is hardly needed. then on the robot side look at the inputs to see which ones are changing. or to see them all at once, open variable monitor, enter $IN[] as variable name. without number inside square brackets, it will show the state of ALL inputs.

or... post some screenshots of your PLC side and robot side mapping.

about offset syntax, you need to declare offset frame

DECL FRAME MyOFFSET ; add it at the bottom section of the $CONFIG.DAT

and populate it by offset values (to do it continuously you can put this in Submit)

MyOFFSET.X = X_Ofs

MyOFFSET.Y = Y_Ofs

MyOFFSET.Z = Z_Ofs

MyOFFSET.A = A_Ofs

MyOFFSET.B = B_Ofs

MyOFFSET.C = C_Ofs

then in your programs use something like

LIN XP1:MyOFFSET ; if offset is in the tool frame

LIN MyOFFSET:XP1 ; if offset is in the base frame

you can test that without PLC connection

Hi Guys,

I realised my issue was down to a mapping problem on workvisual, for some bizarre reason i only had 58 DWORDS mapped not 63, as soon as i fixed that i can now read the value of X_Ofs!

So now i will try to program the offset. I'm using the base frame in this instance and i want to offset the placeboards position, so i'd do the following?

I already have the below programmed and reading fine.

SIGNAL X_Ofs_From_PLC $IN[2017] TO $IN[2048]

DECL REAL X_Ofs = 0.0

and

(In the .SRC file):

X_Ofs = (X_Ofs_From_PLC/100.0)

Now I will add the below to config.dat?

DECL FRAME MyOFFSET ; add it at the bottom section of the $CONFIG.DAT

MyOFFSET.X = X_Ofs

MyOFFSET.Y = Y_Ofs

MyOFFSET.Z = Z_Ofs

MyOFFSET.A = A_Ofs

MyOFFSET.B = B_Ofs

MyOFFSET.C = C_Ofs

Whereby each of the X/Y/Z offsets are signals being sent from the PLC?

And to offset the position i want to offset i'd use the below in the program .src file?

LIN MyOFFSET: Placeboards ; if offset is in the base frame

Thankyou again for all your help, i've learnt so much here.

Thanks

Sam

Quote from SamReynolds

Now I will add the below to config.dat?

DECL FRAME MyOFFSET ; add it at the bottom section of the $CONFIG.DAT

MyOFFSET.X = X_Ofs

MyOFFSET.Y = Y_Ofs

MyOFFSET.Z = Z_Ofs

MyOFFSET.A = A_Ofs

MyOFFSET.B = B_Ofs

MyOFFSET.C = C_Ofs

Display More

Nope, you must add these lines only in the src file, only the frame declaration has to be in the Dat file.

MyOFFSET.X = X_Ofs
MyOFFSET.Y = Y_Ofs
MyOFFSET.Z = Z_Ofs
MyOFFSET.A = A_Ofs
MyOFFSET.B = B_Ofs
MyOFFSET.C = C_Ofs
LIN MyOFFSET: Placeboards