Kuka KRC2 Devicenet Turck I/O Settings

Have you double checked that the inputs and outputs are correctly mapped in the WoV project?

Quote from dexterv

Have you double checked that the inputs and outputs are correctly mapped in the WoV project?

I/O mapping on krc2 is set on different way. WorkVisual is just for KRC4.

Quote from Hancock Concrete

Hello, We are attempting to set up a Turck fdn20-16xsg via Divicenet and want to have 8 set as Digital outputs and 8 set as Digital inputs.

We have wired it and set the settings as good as we can understand following the Devicenet manual from Kuka and reading multiple topics here on Forums. We are not getting any errors on pendant and the Turck Module light is solid green stating it has an established connection. 121 Ohm resistor is installed on combicom plug on Turck module and also had one on the combicom plug that is plugged into MFC Card.

When using a jumper from 24V+ to try and simulate an input it does not show up in the I/O Monitor and when changing the output it does not switch a 24v+ reading with voltmeter.

Robot was a Decommissioned unit from Ballard International. We think it was in an Automotive Plant.

Robot is KR2210 2 us s c2 flr zh210

Kernel System KS V5.6.54 RTAcc

iosys.ini file is written as follows

[CONFIG]

Version=2.00

[DRIVERS}

MFC=0,mfcEntry,mfcdrv.o

DEVNET=2,dnInit,dn2drv.0

DIAGDRV=22,cp_DiagInit,diagdrv.o

[MFC]

[DEVNET]

OUTB1=22,1,1

INB0=22,1,1

[DIAGDRV]

devnet.ini file is written as follows

[krc]

debug=0

baudrate=500

[1]

Macid=22

I have worked on Fanuc systems before but this is my first KUKA and learning as we go.

Display More

I'm not 100% sure, but I think that the mapping is done in machine.dat.

Guys that know very well krc2 and could help you are massula and panic mode

Mapping is done on iosys.ini, and looks ok.

It was a long time since I touched a KRC2 with DeviceNet, but If I recall correctly, You should have DEVNET or MFC driver enabled at a time. You shouldn't have the both enabled at same time.

I think in this case, DEVNET should be enabled, and MFC, disabled.

Quote from ljuba

I/O mapping on krc2 is set on different way. WorkVisual is just for KRC4.

I am sorry, you are absolutely right, I completely phased out the KRC2 part even though there quite a few pointers. Please ignore my previous comment.

Quote from Hancock Concrete

[DEVNET]

iosys.ini file is written as follows

OUTB1=22,1,1

INB0=22,1,1

I don't remember if the multiplicator is obligatory or not, but on mapping section You can also try this:

OUTB1=22,1,x1

INB0=22,1,x1

Let's back up -- are there any error messages on the pendant? What do the status LEDs on the Turck module show? It's hard to be sure from your photo, but it looks like only the MOD LED is active, and not the DNET LED.

OUTB0 and INB0 correspond to $OUT[1]-[8] and $IN[1-8], respectively. For whatever reason, the I/O config files start all indices with 0, while at the program level, all indices start with 1.

Set DEBUG=1 in DEVNET.INI, and see what shows up in the DEVNET.LOG file.

Also, when you make changes to any of the I/O config files, are you performing an I/O Reconfig, or cold-booting the robot, after? The changes don't "take" until you do that.

If you're not using the DIAGDRV and MFC for anything (and it appears you're not), I would suggest commenting them out. I doubt they're getting in the way of the DN driver, but shutting off options you're not using is seldom a bad idea.

Ah... yes, the "22,1" setting should be "22,0". Again, the I/O indices start with 0. So MAC-ID 22, Byte 0, should be the first 8 Inputs or Outputs on the module.

Quote from Hancock Concrete

So should it be like this to set 1-8 as inputs and 9-16 as outputs?

[CONFIG]

Version=2.00

[DRIVERS}

;MFC=0,mfcEntry,mfcdrv.o

DEVNET=2,dnInit,dn2drv.0

;DIAGDRV=22,cp_DiagInit,diagdrv.o

[MFC]

[DEVNET]

INB0=22,0,x1

OUTB0=22,1,x1

[DIAGDRV]

Display More

This would connect $IN[1]-$IN[8] to the first 8 inputs on the module, and connect $OUT[1] - $OUT[8] to outputs 9-16 on the module.

Normally you don't need to do it this way -- the INB and OUTB have parallel addressing, not serial. So unless the module is unusual, you should be able to use OUTB0=22,0, which will connect $OUT[1]-[8] to the module's physical outputs 1-8.

Basically, there are two 22,0 addresses in the module -- one for input, the other for output. Using 22,0 for INB0 does not conflict or overlap with using OUTB0 on 22,0 as well. The divide between Input Addresses and Output Addresses is implicit -- if the line in DEVENET.INI is assigning OUTBx, then the driver switches to the module's output area before looking for the 22,0 address. If the next line is assigning INBx to 22,0, the driver switches to the module's input area before looking for 22,0.