Kuka KRC2 Devicenet Turck I/O Settings

    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.

    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.

    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 massula

    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

    While searching for examples I did come across some that had it and some that didn't. I followed the Kuka divicenet Manual on that one but I can try putting them in and see it helps.

    I don't think I fully understand what specific I/O this is setting in the Kuka either. I'd like to think this is setting the mapping for input 1-8 and output 1-8, I used the jumper to trigger input and started scrolling through l/O list to about 1000 and didn't see any triggered but there is upwards of 10,000 on the list and I did not scroll through all of them.


    Quote from massula

    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.

    We are trying to connect using the DeviceNet connector on the MFC Card. Does this make an impact on what the other things are that are connected to the NFC Port on the NFC Card? I Error on the side of caution when it comes to changing too much at a time.

    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.

    No error messages on pendant.

    Turck module shows established connection- solid green led

    Neither LED on the MFC card is lit.

    I will go out here in few and get a debug log!

    Reconfiguration after any change, every time.

    The Diagdrv and MFC settings are not understood as the connection is made on the MFC Card but found couple different threads on here that used both...

    Hello,

    I commented out MFC and Devnet.

    Modified file to the following

    [CONFIG]

    Version=2.00

    [DRIVERS}

    ;MFC=0,mfcEntry,mfcdrv.o

    DEVNET=2,dnInit,dn2drv.0

    ;DIAGDRV=22,cp_DiagInit,diagdrv.o

    [MFC]

    [DEVNET]

    OUTB0=22,1,x1

    INB0=22,1,x1

    [DIAGDRV]


    I can now trigger the i/o BUT:

    When I set output 1 to on output 9 turns on at the module and input 9 is showing =on, on the pendant.

    Applying 24v to the pins on the module it will turn on status LEDs on the module for pins 9-16 and triggers inputs on pendant of 1-8 but does nothing on pins 1-8.

    I changed it to what I just posted and also discovered that it slipped my mind to run AUX+ and AUX- to 1-8 on Module even though I did it for 9-14 and 15-16. Wired it up and set the settings as stated and it is working as intended.

    I would like to thank you all greatly for your help on this and would :beerchug: if we could.

    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.

Advertising from our partners