Understanding of numbers in IOSYS.INI

Quote from martenH

[PBMASL]
;slave outputs
;OUTB0=3,0,x2 $OUT[1-16]
;OUTB2=4,0,x2 $OUT[17-32]
;OUTB4=4,0,x2 $OUT[33-64]
OUTB0=5,0,x1 ;$OUT[81-88]
OUTB1=5,1,x1 ;$OUT[89-96]

;INB2=2,0,x1 ;$IN[17-24]
;OUTB2=2,0,x1 ;$OUt[17-24]
;INW3=2,4,x1 ;$IN[25-40]
OUTW8=2,0,x1 ;$OUT[65-80]

Display More

Hold on -- this addressing only works if the robot is the PB master. The KRC2's PB Slave interface is always address 127. On the CP5614 card in the KRC2, one port is permanently in Master mode, and the other is always in Slave mode.

So, if the PLC is the Master and the robot is the Slave, first you have to:

1. Use the correct port on the PB card

2. Use address 127, as Hermann's example up thread has: OUTB0=127,0,x1 or similar.

With this IOSYS shown above, the robot is acting as Master to a PB Slave at address 2, and another at address 5. Is one of those the PLC?

Quote from martenH

I got it to work with sending byte's however when i try to send word bytes I dont recieve any signals from my KR2C to my PLC.

One thing to keep in mind: KRCs and Siemens use different byte ordering for multi-byte words. You'll probably need to resolve that conflict, either in the PLC setup, or in IOSYS.INI.

I figured out what was wrong I was adressing the wrong adress like you said in the plc. Apperently in the tranfer area adres 0 and it is 2 in the KRC2 when its 2 in need to add and offset byte of 2 in the second offset decleration. Once I found the right adress it was working perfectly without a problem. Now it is possible to send and recieve double word bytes with my input and outpus.

OUTDW8=7,4,x1
INDW2=7,0,x1

Hello guys!

If i would like to start my inputs from $IN[1008] is this the correct form?

INW63=7, 0, x16

OUTW63=7, 0, x16

I have 32 bytes IN and 32 bytes OUT with profibus communication.(i would like to reserve inputs and outputs from 1008 to 1264)

And i would like to ask one more thing. If i know rigth i have 4096 digital in and outputs in the robot. If i go view-> digital inputs, i see only 1026 inputs. Why?

Thanks in advance!

$IN[1008] is the end of INW 62, not the start of INW63. $IN and $OUT "blocks" always start with an odd number, and end with an even number which is also a multiple of 8.

Your proposed range crosses over the special system $INs 1025 and 1026. Standard practice is to avoid that byte entirely, just to keep things as clean as possible.

Your robot may not support more than 1024 I/O -- $IN[1025] and $IN[1026] are special inputs from back when KRCs did not support anything above 1024. Once the I/O ranges were expanded on later KSS versions, $IN 1025 and 1026 were kept as-is, which makes those bits unusable for I/O.

Check the system variable $SET_IO_SIZE.

Firstly, appreciate your quick answer!:)

Quote from SkyeFire

Check the system variable $SET_IO_SIZE.

INT $SET_IO_SIZE=1 ;SETZEN EA-BEREICH (1=1024, 2=2048, 4=4096)

I Found it, i will change it to 4096. Thanks!:)

i would like to clarify why i ask it.

First integration mapping in iosys.ini was:

INW0=7,0,x16 ; $IN[1]-$IN[256]

OUTW0=7,0,x16 ; $IN[1]-$IN[256]

After that every thing worked like it had to(almost).

I changed a SYS IO (i think it is sys io), which name is $MOVE_ENABLE. From $IN[1015]( Im not sure right now) to $IN[255], because my mapping area was that, what i wrote upper.

In EXT everything worked correctly, the PLC sand move enable etc... but when i changed mode to T1, then i could not move the robot, because robot wait for move enable.
What can you recommend for me?

How should do it normally(the communication and mapping))?

Quote

$IN[1008] is the end of INW 62, not the start of INW63. $IN and $OUT "blocks" always start with an odd number, and end with an even number which is also a multiple of 8.

Ohh your right! Then can you tell me please what should be the range of this?

I had a bit which was the 0.bit of 10.byte and when i changed the mapping to this(what i wrote earlier):

INW63=7, 0, x16
OUTW63=7, 0, x16

Then the 585. bit turned to TRUE

If we make a quick calculation, then the 0.bit of 0.byte is $IN[505]?

How is it possible? :O

Appreciate your help! Thank you in advance!

Quote from Mate_271

In EXT everything worked correctly, the PLC sand move enable etc... but when i changed mode to T1, then i could not move the robot, because robot wait for move enable.

$MOVE_ENABLE does not change addresses when you switch between EXT and T1. Therefore, whatever device you have sending the KRC $MOVE_ENABLE needs to be adjusted to send $MOVE_ENABLE when the KRC is in T1.

Quote from Mate_271

Then the 585. bit turned to TRUE

If we make a quick calculation, then the 0.bit of 0.byte is $IN[505]?

$IN[585] should be in the middle of INB73, or INW36, if my math is correct.

I used to have a spreadsheet for this, but it seems to have gone missing. I attached a quick&dirty remake that should be correct, or at least pretty close.

Quote from SkyeFire

$MOVE_ENABLE does not change addresses when you switch between EXT and T1. Therefore, whatever device you have sending the KRC $MOVE_ENABLE needs to be adjusted to send $MOVE_ENABLE when the KRC is in T1.

I thought i made a mistake, cause changing a sys io is not allowed.(if move enable is sys io😅)

When i wrote back the move enable input value to 1015 and press ack, the robot start moving. Thats why i would like to change the mapping: wrote back every sys variable to factory value and cover those IOs with my 256bit.(which i have)

Quote from SkyeFire

$IN[585] should be in the middle of INB73, or INW36, if my math is correct.

Yes..:( Thats what i calculated too. Thats why i dont understand what is happening and why is it happening (with INW63…)😓

Thanks for your spreadsheet. I will try to figure out what can be the problem😊

INW63=7, 0, x16
OUTW63=7, 0, x16

After this the first bit should $IN[1009].

Sadly, what I wrote upper, my first bit in the robot was $IN[505], which is almost the half of it.

(In the picture $IN[585] is the 0.bit of 10.byte)

Maybe some function can do this?

I attach some photos, which can help.

Quote from Mate_271

Code

INW63=7, 0, x16
OUTW63=7, 0, x16

After this the first bit should $IN[1009].

Nope, it's kind of inconsistent what kuka does here.

The number direct behind INB / OUTB / INW / OUTW / INDW / OUTDW always are counted as bytes.

The reason would be, that if it was depending on kind of IN / OUT you can't map it bytewise.

Calculate 63 * 8 + 1, and you have the beginning I/O number on the robot.

Read the complete thread!

Quote from hermann

Nope, it's kind of inconsistent what kuka does here.

The number direct behind INB / OUTB / INW / OUTW / INDW / OUTDW always are counted as bytes.

The reason would be, that if it was depending on kind of IN / OUT you can't map it bytewise.

In kuka i changed the mapping what you see upper, but in my turck hmi the 0.bit of 0.byte start from 0.
I think i have to change the mapping in PLC. Should start from 127.byte. The 0.bit 0.byte should be 1009(Which should be the 0.bit of 127.byte).

The robot will take an intermediate value between 0 and 1009. I think that could happen here.

Is it possible?

No clue about what you really mean. Haven't looked into you zip file. You can post pictures here as attachment, not as zip,so we can see them direct without wasting time downloading and unzipping.

I can attach only 2 pictures. I didn't want to spam the post, therefore i made a zip. Sorry!:/

In this picture show one of my variable bits. This variable(INT) first bit is my 0.bit of 10.byte.($IN[585]) Which means my first bit of 0.byte is $IN[505]. Which is the intermediate value of 0 and 1009. If mapping values didn't match(i mean in robot side and plc side), maybe the system "puts" the ios in an intermediate position. Is it possible?

Okay, let's back up a bit here. Try just using a single byte mapping first, and see what happens. Like INB63=7,0. Just that, nothing else.

If that works, try adding INB64=7,1 and so on. Using INWs and x-multipliers is convenient but not necessary (and in fact, IIRC there were some versions of KSS where using Ws and x-multipliers could cause problems).

With multi-byte mappings, KUKA uses Big-Endian, and some other brands (like Siemens) use Little-Endian. Which would mean the bytes are swapped. Your photo makes it look like this is not the problem

Quote from hermann

The number direct behind INB / OUTB / INW / OUTW / INDW / OUTDW always are counted as bytes.

I can't believe I managed to forget that. I guess it really has been too long since I used a KRC2....

no worries... been there more than once... it is an easy thing to forget

that is why i choose to always do all mapping in bytes... and there was no more issues.

Quote from SkyeFire

Okay, let's back up a bit here. Try just using a single byte mapping first, and see what happens. Like INB63=7,0. Just that, nothing else.

If that works, try adding INB64=7,1 and so on. Using INWs and x-multipliers is convenient but not necessary (and in fact, IIRC there were some versions of KSS where using Ws and x-multipliers could cause problems).

Thank you very much for your help guys!( hermann, SkyeFire ) I will try it as fast as i can!:)

Thanks to your help guys, it looks like things are slowly working out.

The picture show, if i comment out: INB128=7, 3 every single byte can be used.(expect that obviously)

The log says 31 input and 32 output is useable.

BUT:

if I leave it in, the picture show what's wront. At this time the iosys.log says only 3 inputs and 0 output is useable. I tried to search what can be the problem, but i find nothing.

Why doesn't the system allow me to map to that zone?

Quote from SkyeFire

.. Your robot may not support more than 1024 I/O -- $IN[1025] and $IN[1026] are special inputs from back when KRCs did not support anything above 1024. Once the I/O ranges were expanded on later KSS versions, $IN 1025 and 1026 were kept as-is, which makes those bits unusable for I/O...

128×8+1=1025

Mapping into those two special bits (1025, 1026) is not allowed.