Understanding of numbers in IOSYS.INI

Read rest of the file.... there are comments at the bottom.

Krc arrays start with 1 so inputs are 1..1024 or 1..4096 for example.
SmalleSt block of data that can be mapped is byte (INB and OUTB) but you can also use larger units like words (INW or OUTW).
Bytes are groups of 8bit, words are groups of 16bits.

When you say INB0 that means first 8 inputs (1-8).
INB1 is next byte or inputs 9-16. Etc.
It works the same way for words but you are grouping io in blocks of 16.

Each field bus needs a driver. To use devicenet you need to activate device net driver (remove semicolon) and do IO mapping.
To make things simpler (less typing), each driver is also given index number. When mapping you need to use that index number.

INB2=2,0,x7

Above means we are mapping io to inputs;
Starting with byte 2 (means inputs 17 and up )
Driver which is updating those inputs us driver 2 ( devicenet).
We are starting to read from byte 0 from that driver.
We are transferring 7 units (bytes in this case) from data transferred by that driver (devicenet).

7 bytes is 7x8bit= 56 bit.
So inputs mapped in this case are inputs 17... 72

[size=1em]1. everything after semicolon is just a comment and can be ignored, it is added for clarity for humans (robot does not care about it).[/size]

[size=1em]2. yes, "2" is driver number in "DEVNET=2,dnInit,dn2drv.o"[/size]

[size=1em]Sorry, i did misspoke (it's been a while since i saw KRC2). another reason to use own judgement and read carefully... :-)[/size]

[size=1em]number after equal sign in mapping section is not a driver number (this is already known since mapping must be in correct SECTION such as [DEVNET]).[/size]
[size=1em]that number is a node address (macid) of device we are reading/writing to/from[/size]

[size=1em]3. A is ok, B is not (overlapping - you are mapping seven times something to same IO range: INW60). but this would be equivalent:[/size]

A)
INW60=1,0,x7

B)
INW60 = 1, 0, x1
INW61 = 1, 2, x1
INW62 = 1, 4, x1
INW63 = 1, 6, x1
INW64 = 1, 8, x1
INW65 = 1, 10, x1
INW66 = 1, 12, x1

Note, mapping in words is not popular because when mapping is fractional, some IO will be locked. and using larger chunks of data means locking more i/o.

for example, if you have IO card that has four inputs.
A)
INB0=1,0,x1 ; inputs 1-4 are used but inputs 5-8 are wasted and no longer usable

B)
INW0=1,0,x1; inputs 1-4 are used but inputs 5-16 are wasted and no longer usable

On KRC4 one gets larger I/O address space and much finer granularity (one can map bit by bit if needed).

Hi everyone,

I know it is an old post but I prefer reply here to stay in the same topic.
I read a lot the forum this past few days, and I think PanicMode has the answer and the best informations about are here.
Tell me if I am wrong and I will post somewhere else.

I am also trying to find out how the IOSYS.INI works...
We have 2 arms (KRC1 from Renault Plant) and they seem to work with Interbus for the API.
We do not have the possibility to work with.
So I am trying to remap with a LUTZE PLC (digital IN/OUT) we already have

Anyway, the wiring is almost ready, I do not want to make a mistake in the IOSYS.INI...
I found a wierd information on my IOSYS.INI:
//////////ORIGINAL /////////////////////////////////////////////////////////////
[INTERBUS]
;***********************
;MAITRE
;***********************
;******************************
; ESCLAVE
;******************************
;------------------------
;ENTREES
;------------------------
INW20=896 ; de 161-176 pour premier mot API
INW22=898 ; de 177-192 pour deuxieme mot API
INW24=900 ; de 193-208 pour le troisieme mot API
INW26=902 ; de 209-224 pour l quatrieme mot API
;------------------------
;Sorties
;------------------------
OUTW20=896 ; de 161-176 pour premier mot API
OUTW22=898 ; de 177-192 pour deuxieme mot API
OUTW24=900 ; de 193-208 pour le troisieme mot API
OUTW26=902 ; de 209-224 pour l quatrieme mot API
/////////////////////////////////////////////////////////////

First thing odd: how is it possible to "go" from 161 to 176 with the INW20 ?
if I do the maths, I found INW20 to go from 340 to 356
what is wrong with me?

assuming my maths are wrong
if I want to re-map those into a DEVNET, should I write?:
/////MY NEW IOSYS.INI /////////////////////////////////////////////////////////////
[DEVNET]
INW20=5,0,x1 ; de 161-176 pour premier mot API
INW22=5,1,x1 ; de 177-192 pour deuxieme mot API
INW24=5,2,x1 ; de 193-208 pour le troisieme mot API

and so on???
////////////////

thank you for your return
We are working (for hobby purpose as soon as we can) on those arms for almost 2 years now, I would really like to see them move

I am correcting myself...

I just find out something.
Either we have INB or INW, the address (the number) is always in bytes
so, when I saw INW20 .... from 161 to 176 it is OK in bytes!
it is the same address if you write INB20 or INW20, the starting point is the same.

Am I right guys?

also, I made a mistake in my maths, I finally make a spreadsheet

Please, could you still confirm the parameters after the "INW20" ?
/////MY NEW IOSYS.INI /////////////////////////////////////////////////////////////
[DEVNET]
INW20=5,0,x1 ; de 161-176 pour premier mot API
INW22=5,1,x1 ; de 177-192 pour deuxieme mot API
INW24=5,2,x1 ; de 193-208 pour le troisieme mot API

and so on???
////////////////

thank you for your return

B = byte (8-bits), therefore I/O are assigned in groups of 8INB0 corresponds to $IN[1..8]
INB1 corresponds to $IN[9..16]
INB2 corresponds to $IN[17..24]
etc.

W = word (16-bits), therefore I/O are assigned in groups of 16
INW0 corresponds to $IN[1..16]
INW1 corresponds to $IN[17..32]
INW2 corresponds to $IN[33..48]
etc.

D = double word (32-bit), I/O are assigned in groups of 32
IND0 corresponds to $IN[1..32]
IND1 corresponds to $IN[33..64]
IND2 corresponds to $IN[65..96]
etc.

So am I wrong again?

How do you explain the initial file saying:
"INW20=896 ; de 161-176 pour premier mot API "
?
If I follow "your rule":
INW means word
so INW20 means 321 - 336

but the original file, from the plant said: from 161 to 176...

please help!

...ask robot

[size=2]ok, i rarely get to see KRC2 and i don't see why anyone sane would use units larger than necessary (word, doubleword) and i explained why but... your persistence made me curious. as always, it does not matter what i think, ultimately, robot need to be ok with it.

but i just saw an old archive with IOSYS.INI inside so i read its content (sort of against my will, but curiosity is a dangerous thing   ). to be honest, i expected that my previous post would be correct because this is what i was told but, i never tried it... so it was worth taking another look...

... and it looks like numeric suffix following INB,INW,IND,OUTB etc is a byte offset (how many input bytes to skip in robot I/Os)so it would be something like:[/size]

[size=2]INB0 = inputs 1-8 (skip 0 bytes)[/size]
[size=2]INB1 = inputs 9-16 (skip 1 byte)[/size]
[size=2]INB2 = inputs 17-24 (skip 2 bytes)[/size]
[size=2]etc.[/size]

[size=2]so no surprised there, but... it looks like:

INW0 = inputs 1-16 (skip 0 bytes, map 16 inputs)[/size]
[size=2]INW1 = inputs 9-24 (skip 1 byte, map 16 inputs)[/size]
[size=2]INW2 = inputs 17-32 (skip 2 byte, map 16 inputs)[/size]
[size=2]INW3 = inputs 25-40[/size]
[size=2]INW4 = inputs 33-48[/size]

[size=2]and [/size]
[size=2]IND0 = inputs 1-32 (skip 0 bytes, map 32 inputs)[/size]
[size=2]IND1 = inputs 9-40 (skip 1 byte, map 32 inputs)[/size]
[size=2]IND2 = inputs 17-48 (skip 2 bytes...)[/size]
[size=2]etc.[/size]

Quote from ARAx2

So am I wrong again?

How do you explain the initial file saying:
"INW20=896 ; de 161-176 pour premier mot API "
?
If I follow "your rule":
INW means word
so INW20 means 321 - 336

but the original file, from the plant said: from 161 to 176...

please help!

Display More

Anything after a ";" is simply a comment, for the user. It has no effect on the actual configuration. So, whomever wrote those comments was incorrect.

Ok

I understand, it seems quite ok to keep INWx from the file. After the ";" the guys before should have made mistakes. I will just verify into the robot interface after starting.
I will test and keep you posted.
I should be able to do that this week-end...

Thanks a lot !

Quote from panic mode

B = byte (8-bits), therefore I/O are assigned in groups of 8INB0 corresponds to $IN[1..8]
INB1 corresponds to $IN[9..16]
INB2 corresponds to $IN[17..24]
etc.

W = word (16-bits), therefore I/O are assigned in groups of 16
INW0 corresponds to $IN[1..16]
INW1 corresponds to $IN[17..32]
INW2 corresponds to $IN[33..48]
etc.

D = double word (32-bit), I/O are assigned in groups of 32
IND0 corresponds to $IN[1..32]
IND1 corresponds to $IN[33..64]
IND2 corresponds to $IN[65..96]
etc.

Display More

Hi Panic,

it is IND for double word or INDW?

INDW.

Your IOSYS.INI file should have a very large comment section at the end that explains all the numerology in painful detail. But some earlier KSS versions didn't have it, so:

;==========================================================
;Valid entries have the following formats.
;Arguments in squared brackets are optional.
;If nothing else is mentioned, arguments are decimal.

;Digital Inputs and Outputs:
;
; Form 1:
; {token}{offset}={byte}[,{multip}]
;
; {token}   INB (byte), INW (word), INDW (double word)
;           OUTB, OUTW, OUTDW
; {offset}  byte offset of robot IO System (0..m)
; {byte}    byte offset over all peripheral devices (0..m)
;           Offset starts with 0 at the first device and
;           ends with m at the end of the last device.
; {multip}  creats n dataobjects of {token}
; Example:
; OUTW4=2,x3
; Three words of the periphery, starting at byte 2,
; are mapped to the outputs 33-80.
;
; Form 2:
; {token}{offset}={address},{byte}[,{multip}]
;
; {token}   INB, INW, INDW, OUTB, OUTW, OUTDW
; {offset}  byte offset of robot IO System
; {address} address of a peripheral device (0..m)
;           driver specific information, see descr. below
; {byte}    byte offset at this peripheral device (0..m)
;           Offset starts with 0 at the every device
;           driver specific information, see descr. below
; {multip}  creats n dataobjects of {token}
; Example:
; INW4=10,0,x2
; Two words of the peripheral device with address 10 and
; up from byte 0 are mapped to the inputs 33-80.


;Analog Inputs and Outputs:
;
; Form 1:
; {token}{num}={byte},{res},{type}[,CAL{factor}]
;
; {token}   ANIN or ANOUT
; {num}     number of the analog channel (1..i)
; {byte}    byte offset over all peripheral devices (0..m)
;           Offset starts with 0 at the first device and
;           ends with m at the end of the last device.
; {res}     resolution of the analog value (number of bits)
; {type}    type of analog value
;           0 : right justified without sign
;           1 : right justified with    sign
;           2 : left  justified without sign
;           3 : left  justified with    sign
; {factor}  maximum analog value, decimal without prefix, 
;           hexadec. with prefix 0x or octal with prefix 0
;           "CAL 0" or no entry sets factor to its maximum
; Example:
; ANIN1=10,12,3
; The analog input No.1 is used. The byte offset on 
; peripheral side is 10, the resolution is 12 bit and the
; type of analog value is 3 (left justified with sign).
; The maximum binary analog value is 2047.
;
; Form 2:
; {token}{num}={address},{byte},{res},{type}[,CAL{factor}]
;
; {token}   ANIN or ANOUT
; {num}     number of the analog channel (1..i)
; {address} address of a peripheral device (0..m)
;           driver specific information, see descr. below
; {byte}    byte offset at this peripheral device (0..m)
;           Offset starts with 0 at the every device
;           driver specific information, see descr. below
; {res}     resolution of the analog value (number of bits)
; {type}    type of analog value
;           0 : right justified without sign
;           1 : right justified with    sign
;           2 : left  justified without sign
;           3 : left  justified with    sign
; {factor}  maximum analog value, decimal without prefix, 
;           hexadec. with prefix 0x or octal with prefix 0
;           "CAL 0" or no entry sets factor to its maximum
; Example: 
; ANIN3=30,0,16,2,CAL 0x6C00
; The analog input No.3 is used. The device address is 30,
; the byte offset at this device is 0, the resolution is
; 16 bit and the type of analog value is 2 (left justified 
; without sign). The maximum binary analog value is 27648.
; The CAL-factor is especially required in case of using 
; Profibus analog modules.


;particularities:
;[MFC] MFC-IO with KRC1 / CAN-IO-Modul with KRC2
;     Entries in form 1
;
;[INTERBUS/INTERBUSPCI] Interbus Phoenix Mast./Slave Cu/LWL
;     Entries in form 1
;     $IN/OUT[n_1]=(n+1)*8-7
;     $IN/OUT[n_8]=(n+1)*8

;[DEVNET] DeviceNet on the KUKA MFC
;     Entries in form 2 for driver dn2drv.o
;     {address}=DeviceNet MACID

;[DNSC1] DeviceNet LPDN scanner channel 1
;     Entries in form 2
;     {address} = DeviceNet slave MACID
;     {address} = MACID of CH1 ==> Slave part of LPDN CH1
;
;[DNSC2] DeviceNet LPDN scanner channel 2
;     Entries in form 2
;     {address} = DeviceNet slave MACID
;     {address} = MACID of CH2 ==> Slave part of LPDN CH2
;
;[DNSC3] DeviceNet LPDN scanner channel 1
;     Entries in form 2
;     {address} = DeviceNet slave MACID
;     {address} = MACID of CH1 ==> Slave part of LPDN CH1
;
;[DNSC4] DeviceNet LPDN scanner channel 2
;     Entries in form 2
;     {address} = DeviceNet slave MACID
;     {address} = MACID of CH2 ==> Slave part of LPDN CH2
;
;[DNSC5] DeviceNet LPDN scanner channel 1
;     Entries in form 2
;     {address} = DeviceNet slave MACID
;     {address} = MACID of CH1 ==> Slave part of LPDN CH1
;
;[DNSC6] DeviceNet LPDN scanner channel 2
;     Entries in form 2
;     {address} = DeviceNet slave MACID
;     {address} = MACID of CH2 ==> Slave part of LPDN CH2
;
;[PBMASL] ProfiBus Siemens Master/Slave CP5614
;     Entries in form 2
;     {address} = Slave DP-address
;     {address} = 127 ==> Slave part of CP5614
;
;[DSEIO] Digital inputs/outputs for KR C3A
;     Entries in form 1
;
;[CNKE1] ControlNet 1784PCIC LP-Elektronik
;     Entries in form 2
;     {address} = ConNo
;     {byte}    = additional offset
;
;[CNKE2] ControlNet 1784PCIC LP-Elektronik
;     Entries in form 2
;     {address} = ConNo
;     {byte}    = additional offset
;
;[VIO] inputs/outputs for Virtual IO driver over TCP/IP
;     Entries in form 1
;
;VIO=30,vioInit,vio_drv.o
;
;[O2I] inputs/outputs for 'output to input for software developers'
;     Entries in form 1
;
;O2I=31,o2iInit,o2i_drv.o
;
;[IOLINKING] Outputs follow inputs
;     Special form:
;     $OUT[{bitoffset}]=$IN[{bitoffset}]
;
;     {bitoffset}    Bit(!)offset in the robot I/O-System,
;                    starting with 1 (1..MAXIO)
;
;     Example: $OUT[512]=$IN[401]
;     In this case output nr. 512 (bit 8 of byte 63)
;     is linked to input  nr. 401 (bit 1 of byte 50)
;
;     Notes:
;     IOLINKING means outputs follow inputs in the robot
;     I/O-system (within ipo-cycle), regardless if they
;     are mapped to drivers.
;     Port ranges cannot be specified, each bit must be
;     linked by itself.
;     Only a maximum of MAX_IOLINKS can be configured (set 
;     in progress.ini, if this value is increased, robot
;     functionality cannot be guaranteed!).
;----------------------------------------------------------
; 04/02/02  section [IOLINKING] added

Dear SkyeFire,

I am a beginner in profibus devices and i don't understand everything clear.

We have a system like this:

;[PBMASL] ProfiBus Siemens Master/Slave CP5614

; Entries in form 2

; {address} = Slave DP-address

; {address} = 127 ==> Slave part of CP5614

We will use our robot as a master with a HMI PLC slave whose address is 3. That's clear.

It's clear moreover i have to use form 2.

Form 2:

; {token}{offset}={address},{byte}[,{multip}]

;

; {token} INB, INW, INDW, OUTB, OUTW, OUTDW

; {offset} byte offset of robot IO System

; {address} address of a peripheral device (0..m)

; driver specific information, see descr. below

; {byte} byte offset at this peripheral device (0..m)

; Offset starts with 0 at the every device

; driver specific information, see descr. below

; {multip} creats n dataobjects of {token}

; Example:

; INW4=10,0,x2

; Two words of the peripheral device with address 10 and

; up from byte 0 are mapped to the inputs 33-80.

I don't know what should i choose of INB, INW or INDW.

It means how do i want to divide the bits on the PLC?Or what else?

Furthermore, how did you calculate that inputs 33-80 from INW4 = 10,0,x2 ?

I hope you can help me! Thanks in advance!

Cheers

Quote from Mate_271

I don't know what should i choose of INB, INW or INDW.

That's your choice. You can use wathever you want. As long as the resulting number of bytes on the interface matches the configured one.

You can even mix them. It has nothing to do with how you will access them on robot or plc.

Quote from Mate_271

Furthermore, how did you calculate that inputs 33-80 from INW4 = 10,0,x2 ?

Inw0 begins at input 1

Inw1 begins at input 9

So the formula is 4 * 8 + 1

Thanks for your help hermann !

I clearly understand the upper thing, but i have a problem with your lower comment

https://www.roboterforum.de/roboter-forum/…55065#post55065

In this topic the user calculate it differently:

"

INW(Word begin)=Modul adress,0, X(I/O Word Lenght)

Sample:

INW12=4,0,X6

Description:

The 4. Module I/O adress KRC2 $IN[72].....$IN[168]

INW12= 12*16(1 Word 16 Bit)= 72th Input (Beginning adress)

x6= 6*16=6 Words=96 bit=72 Beginning adress+96 bit Data lenght= In 72 to In 168

"

As you tell 4*8 + 1 = 33

But in this situation 12*8 + 1 = 97 and what he wrote the beggining value 72

97 not equal to 72.

Can you explain me why please?

The offsets at INB, INW, INDW are always bytes AFAIR, the calculation in above mentioned thread is wrong. Nobody corrected it.

But I must say: Last configuration of a KRC2 is long time ago, so may be I am wrong (don't think so, but I wouldn't bet on it ).

yup, this is old and i don't like to think much about it...

<removed since inaccurate, thanks to Hermann>

i don't see why would someone use anything but bytes. this gives you finest granularity and minimizes blocking.

for example you have two I/O nodes, each has some I/O modules of course. the most common type of I/O is digital and that means the I/O blocks are fractions of a byte... like 2 bit or 4 bit.

suppose first node has 12 inputs (three input modules with 4 inputs each).

if you map it using bytes, you need to use at least two (16 bits). that means that last 4 bits are unused. also they are blocked and cannot be assigned to anything else... including inputs of the next node so your Inputs list will have a gap of at least 4 bits because inputs of next node will have to start on byte boundary (input 17)

but if you map this using IND (32-bits), you would still have those 12 inputs functional but the next 20 inputs are blocked / reserved. so inputs from next node would have to start at 33... using large blocks means you are wasting a lot of I/O space and you are introducing larger gaps in I/Os. this means more scrolling when monitoring I/Os. not fun on a display with already very limited display space.

Now I'm confused.

in an earlier post:

Quote from panic mode

INW0 = inputs 1-16 (skip 0 bytes, map 16 inputs)[/size]
[size=2]INW1 = inputs 9-24 (skip 1 byte, map 16 inputs)[/size]
[size=2]INW2 = inputs 17-32 (skip 2 byte, map 16 inputs)[/size]
[size=2]INW3 = inputs 25-40[/size]
[size=2]INW4 = inputs 33-48[/size]

In last post:

Quote from panic mode

example in words

INW0 (inputs 1-16)

INW1 (inputs 17-32)

INW2 (inputs 33-48)

etc.

As already told. I remember the earlier version is correct. See comments in iosys.ini:

...
; Form 2:
; {token}{offset}={address},{byte}[,{multip}]
;
; {token}   INB, INW, INDW, OUTB, OUTW, OUTDW
; {offset}  byte offset of robot IO System
; {address} address of a peripheral device (0..m)
..

{offset} is the 'byte' offset.

But if someone has the KRC2 on hand, he can check it very easy.

I also always used bytes, so there is no confusion.