How to receive integers frpm PLC to a KR10 R1420 KRC4 V8.3

and i would like to have BatMan's or IronMan's resources.

what robot, what plc.... read READ FIRST
are you in correct forum?

are you familiar with SIGNAL declarations?
Also 15.55 is not an integer.

Quote from Doe

At first it was a little wrong written it should be 10, 15, 55 NOT 15.55
15.55 is not an INT, so much I know.

But to clarify, I have changed the Topic

And it is possible to make a change in the robot to be able to handle integers and Real
Got this shown on education at KUKA, but this I have managed to forget

SIGNAL Var_1 $ IN [100] TO $ IN [116] (word)

but if I do this the robot will still want it in binary from the PLC. That is what I want to change.

If the PLC sends 10 to the robot. will the robot read this as 10 (Ten) or 2 (two)

Display More

Okay, so i am going to try and make it as simple as possible. panic mode correct me if and where i am wrong.

Communcation between your controller and your robot is bit based, at setup you configure how many bytes are allocated to the plc for communication and the same on plc side for the robot.

To send the value of 10 from plc to robot. The plc will make use of int to byte, real to byte or whatever and it will be converted to and array of bits/bytes. Thats just how it is, use it. robot side you will declare a signal range like panic has stated and variable type of int/real ....... whatever you need to be and it will come up as a number in that variable.

If you need +/-, make use of a parity bit to indicate if the value is positive or negative and so transform your variable accordingly...

Check the photos attached, that should make sense.

EDIT: Sorry i see now my attachments was duplicates, fixed it now

[size=1em]exactly....[/size]

[size=1em]digital computers represent data in bit form. each bit is 0 or 1. mor bits can be used together to represent larger values. computers cannot tell what the group of bits represent, because they all just bunch of 0 and 1.[/size]

[size=1em]when you have numeric value such as 19 for example, it's memory representation will be still some sort of binary but bit pattern will be different based on used encoding scheme.[/size]

[size=1em]19 = "00000000000000000000000000010011" in BCI[/size]
[size=1em]19 = "00000000000000000000000000011001" in BCD[/size]
[size=1em]19 = "00000000000001000000000000000000" as hotcoded 1-of-N[/size]
[size=1em]19 = "01000001100110000000000000000000" 32-bit REAL[/size]
[size=1em]etc.[/size]

[size=1em]memory is always storing data in binary and that means bunch of 0 and 1, regardless or format or what the data represents (number, string, image, MP3 file, video, excel spreadsheet or whatever).[/size]

[size=1em]in order to know how to interpret those groups of bits, one need to know not just the value but also used format.[/size]
[size=1em]BCI is the most common but clearly it is not the only way to represent data.[/size]

[size=1em]When your PLC has register with value 10, this is most likely stored in BCI format.[/size]
[size=1em]When PLC sends this value to outputs, each bit will be setting or resetting one output.[/size]

[size=1em]if PLC is connected to KRC controller, then KRC controller can read those bits as series of bits on it's inputs.[/size]
[size=1em]But to interpret what they mean, it is not enough to have value, KRC also must know what format is used because without it, it cannot correctly interpret the data.[/size]

[size=1em]to create BCI coded signal use declaration such as[/size]

[size=1em]SIGNAL TEST $OUT[1] TO $OUT [8][/size]

[size=1em]For example enter this in a $CONFIG.DAT[/size]

[size=1em]Then open variable monitor and type TEST.[/size]
[size=1em]You can write different values to it and observe bit pattern that those outputs take.[/size]

[size=1em]Same is if you use inputs instead of outputs in your signal declaration and let PLC control them.[/size]

[size=1em]when you declare new variable, you specify number of things:[/size]
[size=1em]- name (used as handle to access the memory location)[/size]
[size=1em]- size (in bits)[/size]
[size=1em]- format (how data is organized in those bits)[/size]
[size=1em]- scope (how far this variable can be seen or used)[/size]
[size=1em]- life (when this variable can be accessed)[/size]
[size=1em]etc.[/size]

[size=1em]This is one of the fundamental concepts in computing. When you understand basics, programming in any language becomes straight forward, the differences in languages become just matter of syntax. it does not matter what platform you work on (PLC, robot, MCU, or whatever). it does not matter what language you use (ladder, KRL, c#, or whatever).[/size]

Quote

[size=1em]t if I do this the robot will still want it in binary from the PLC. That is what I want to change.[/size]

[size=1em]what you want is irrelevant. you cannot change reality (...unless you are Adam Savage).[/size]

[size=1em]it looks like you understood so far how SIGNAL groups bits on the KRC side but not how to do the same on PLC side. [/size]
[size=1em]it would me much easier to communicate if you actually could formulate question and state some facts. [/size]
[size=1em]fact is we have no idea what PLC you have. this is not helping...[/size]

[size=1em]Then open variable monitor and type TEST.[/size]
[size=1em]You can write different values to it and observe bit pattern that those outputs take.[/size]

[size=1em]Same is if you use inputs instead of outputs in your signal declaration and let PLC control them.[/size]

[size=1em]when you declare new variable, you specify number of things:[/size]
[size=1em]- name (used as handle to access the memory location)[/size]
[size=1em]- size (in bits)[/size]
[size=1em]- format (how data is organized in those bits)[/size]
[size=1em]- scope (how far this variable can be seen or used)[/size]
[size=1em]- life (when this variable can be accessed)[/size]
[size=1em]etc.[/size]

[size=1em]This is one of the fundamental concepts in computing. When you understand basics, programming in any language becomes straight forward, the differences in languages become just matter of syntax. it does not matter what platform you work on (PLC, robot, MCU, or whatever). it does not matter what language you use (ladder, KRL, c#, or whatever).[/size]

Quote

[size=1em]If the PLC sends 10 to the robot. will the robot read this as 10 (Ten) or 2 (two)[/size]

[size=1em]This has NOTHING to do with KRC4. it is entirely up to PLC programmer to choose how the bits are transferred from some PLC variable to a group of PLC outputs. PLC programmer can choose to use something simple like BCI or create own format whatever that may be. [/size]

[size=1em]one can do it using series of coils (bit-by-bit), using loop, using block instructions (MOV, MVM, AND, OR, XOR..) etc. [/size]

[size=1em]one thing is sure, we cannot read mind. so you may want to bread READ FIRST and be specific. i keep repeating that statement but apparently many people don't get it. they think that because they cannot think of something, there has to be only one way to interpret it. that is wrong.... VERY wrong.[/size]

[size=1em]just read about Niels Bohr barometer challenge.[/size]

btw. SIGNAL on KRC uses BCI format.
if PLC presents data in different format, it can still work of course but you would need to write own code to interpret the format.

rhino, I don't know a simple way to achieve this, but You can create a function to do that.

So, based on Your screenshots, I suppose You already have the digital input group called Wheel_Offset inside Your $config.dat, right?

Ok, now You need to create a REAL variable.

Lets call it RhinoReal

So, in Your $config.dat, You must add.

DECL REAL RhinoReal

Now You need to create a .src file. Lets call it ByteToReal.src (or whatever name You want)

&ACCESS RVP1
&REL 1
&PARAM EDITMASK = *
&PARAM TEMPLATE = C:\KRC\Roboter\Template\FunctionVorgabe
DEFFCT real ByteToReal(n:in )
decl int n,ofs
decl char buf[4]
decl real f
ofs=0
cast_to(buf[],ofs,n)
ofs=0
cast_from(buf[],ofs,f)
return f


ENDFCT

Now, You can call the ByteToReal function inside Your user programs, and put the converted value inside RhinoReal variable.

RhinoReal=ByteToReal(Wheel_Offset)

Quote from massula

rhino, I don't know a simple way to achieve this, but You can create a function to do that.

So, based on Your screenshots, I suppose You already have the digital input group called Wheel_Offset inside Your $config.dat, right?

Ok, now You need to create a REAL variable.

Lets call it RhinoReal

So, in Your $config.dat, You must add.

Code

DECL REAL RhinoReal

Now You need to create a .src file. Lets call it ByteToReal.src (or whatever name You want)

Code

&ACCESS RVP1
&REL 1
&PARAM EDITMASK = *
&PARAM TEMPLATE = C:\KRC\Roboter\Template\FunctionVorgabe
DEFFCT real ByteToReal(n:in )
decl int n,ofs
decl char buf[4]
decl real f
ofs=0
cast_to(buf[],ofs,n)
ofs=0
cast_from(buf[],ofs,f)
return f


ENDFCT

Display More

Now, You can call the ByteToReal function inside Your user programs, and put the converted value inside RhinoReal variable.

Code

RhinoReal=ByteToReal(Wheel_Offset)

Display More

Yes so the signal range is declared in config.dat
For my purposes i only needed an INT, so the binary signal range is loaded into the declared integer and i basically get that value sent from the plc and captured through the signal range into my local variable called PLC_offset

But "Doe" wants the plc to just send him "2" and not in a binary format in as signal range does where it will send e.g. "00000010" which does not make sense.

For a real number check photos what i have done there

every PLC has way of viewing data in different representation format (decimal, binary, hex, octal, ASCII..).
changing view does not change value, it changes the way value is represented.
we all do this every day with time ( "15" means 3PM, "22" means 10PM).

it would be good to know what PLC you use. then we could offer some concrete help.

for example if your PLC is AB, you may do something like

MOV N7:0 O:3

Where N7:0 is register holding your integer value and O:3 is output range.

but this only works correctly in case all outputs are properly aligned...

one way that works for any scenario or configuration is to transfer value but by bit.
Because ultimately, all digital data is stored as one or more bits...
And PLCs are particularly suited for processing bit information.

for example:

XIC N7:0/0 OTE O:3/2
XIC N7:0/1 OTE O:3/3
XIC N7:0/2 OTE O:3/4
XIC N7:0/3 OTE O:3/5
XIC N7:0/4 OTE O:3/6
XIC N7:0/5 OTE O:3/7
XIC N7:0/6 OTE O:3/8
XIC N7:0/7 OTE O:3/9

This also works when outputs are not properly aligned:

XIC N7:0/0 OTE O:3/14
XIC N7:0/1 OTE O:3/15
XIC N7:0/2 OTE O:3/16
XIC N7:0/3 OTE O:4/0
XIC N7:0/4 OTE O:4/1
XIC N7:0/5 OTE O:4/2
XIC N7:0/6 OTE O:4/3
XIC N7:0/7 OTE O:4/4

But... one can of course complicate things, for example shuffle bit order or even make some bizzare formats.
For example bits out of order:

XIC N7:0/0 OTE O:3/9
XIC N7:0/1 OTE O:3/3
XIC N7:0/2 OTE O:3/4
XIC N7:0/3 OTE O:3/5
XIC N7:0/4 OTE O:3/6
XIC N7:0/5 OTE O:3/2
XIC N7:0/6 OTE O:3/8
XIC N7:0/7 OTE O:3/7

For example bits could be distributed:

XIC N7:0/0 OTE O:2/11
XIC N7:0/1 OTE O:2/3
XIC N7:0/2 OTE O:3/14
XIC N7:0/3 OTE O:3/6
XIC N7:0/4 OTE O:1/9
XIC N7:0/5 OTE O:2/4
XIC N7:0/6 OTE O:3/8
XIC N7:0/7 OTE O:3/0

This can also be used on purpose to change bit order if needed (byte swapping).

One can of course do this using word-level instructions too but chances are some people will not be able to understand it.

Now that the number from some PLC register is sent to outputs, one side is done.
Next is to read the data on the robot side.

if bits are properly ordered and aligned, one can simply use SIGNAL, no conversion is needed.

DEF Check_PLC_Value()
SIGNAL PLC_VALUE $IN[100] TO $IN[107]
MSGNOTIFY("PLC value is %1" , , PLC_VALUE)
END

But if someone did some shuffle on PLC end, one need to account for it in code on the robot side.