Advertising

Kuka KRC2 Devicenet with 16I/16O Phoenix contact - configuration error

  • Hello, I have a little trouble with device net configuration


    -KRC2 cabinet ed05

    -phoenix contact ILB DN 24 DI16 DO16

    https://www.phoenixcontact.com…862602&library=plpl&tab=1


    Steps:

    -wiring between Phoexnix - KUKA deviceNET card (terminating resistor at the end of line)

    -power supply 24V on devicenet line

    -DIP SWITCH on Phoenix contact (7=on - MACID 1) (8=on - baud rate 500)

    -Devnet.ini


    Code
    [krc]
    debug=1
    baudrate=500
    logfile=1
    [1]
    macid=1

    -Iosys.ini (delete ";" before DEVNET


    Code
    inw0=1,0,x1
    outw0=1,0,x1

    Now if I try to reconfig IO driver, I get a Configuration error I/O driver DNDRV and on module RED NT LED what mean:

    "Error that prevents communication with the network (e.g., bus offline or double device ID)."



    and


    in devnet.log

    ....


    dndrv version : 2.27.0.0

    ERROR receive error interrupt


    I have no idea what is wrong

  • AD
  • "I have a little trouble with device net configuration"

    so you won't need any support or replies?


    "-wiring between Phoexnix - KUKA deviceNET card"

    Which exact Kuka DeviceNet card? LPDN? Which port? Wired how? Using what cable? Shield connected how? Power applied how? terminated how? Voltages are what? Pukenix card is powered? How?


    "terminating resistor at the end of line"

    one resistor? 47kOhm or 2.2MOhm?

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • MFC card Phoenix

    1- Ground (black) Ground

    2-Can L (blue) Can L

    3-Shield

    4-Can H (white) Can H

    5-24V supply voltage (red) 24v


    Cable - shielded twisted pair fror DeviceNet

    Shield grounded and connected to center slot in MFC and Phoenix contact

    Termination resistor 121[ohm](Phoenix concoct datasheet) at the end of line (on phoenix contact slot)

    Phoenix card powered correctly like in datasheet (IO LED is OFF it means -

    No output is active, no error state is present.)




  • there should always be two resistors - one at each end of the bus - even if bus is short or low speed is used. without this there is a lot of signal reflections and need for retries.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Pretty sure MAC ID 1 is reserved for the bus master -- in this case, the MFC DeviceNet port. So your slave device should be set to something other than 1, and your IOSYS.INI and DEVNET.INI altered to match.

    • Helpful

    in case of MFC master is always 0... and i used I/O with macid 1 so this is ok.



    Btw. DNET is a very simple and straight forward network if one does each step correctly.


    1. wire it correctly (comms, power, termination, shielding)

    2. set up comms correctly (and make sure that all nodes are using same baud rate that is also supported by ALL involved nodes)

    3. map I/O correctly


    i don't see any of those steps rulled out as a possible problem so can't offer more tips or attention to this topic when feedback is still ambiguous and sparse.




    TIP (just to make sure we are on the same page):


    technical help is all about getting facts about actual (local) implementation and letting someone else "see" or recognize potential issues. it is wrong and not productive to share "info" that is based on your own subjective perspective. if you could see the problem, it would not be a problem, it would be taken care of already.




    for example:


    "i wired it like in manual" is a good example of pointless feedback. this is just like trying to help with programming someone who instead of showing their code tells "i used instructions like in manual but my program does not work". it tells nothing about ACTUAL cable length, routing etc and many other things.


    connector pinout without clarifying WHICH order is used (and relating it to shape). i have seen both ways (normal and reversed)- even from same company such as NI.COM as already reported in earlier DNET threads.


    number of resistor changed from total of one, to total of 4 (two per bus end). so which is it? why not just show circuit or photos or both?


    "yes shield is grounded" without explaining how exactly it is grounded. that is rather important, including how the cable ends are stripped, how much, workmanship in general, if insulation was nicked, strands are touching etc.


    "i turned on switches 1 and 8" does not tell what the other switches are at. and i have seen switches not fully on or off so i would prefer to see those switches myself rather than relying on words of some observer (specially one already looking for help). also is all this set BEFORE slave is powered on... or AFTER? in general, devices ONLY read configuration switches on powerup. so if this changed WHILE power is applied, slave will internally still use different settings and of course this will not work.

    "removed semicolon before DEVNET" can be interpreted in many ways. before could mean same line or same file or same file section. why not post ACTUAL files instead of some doctored "config" example? they are not big so slimming is not necessary.


    "i powered it like in manual"... also useless. what manual? does the slave unit get powered from SAME source as master or not? did you try INTERRUPTING that power or not? if this is powered from SEPARATE source, slave may not get restarted when controller is rebooted and it may STILL try to use incorrect settings (not what is set by switches for example).


    when asked to measure voltages on some cable, try MEASURING voltages on EACH wire and state what the measurements are with respect to. i don't belive that it is really 0V and 24V which tells me it was not measured. also there is no mention of voltages of CAN lines. this could be significant insight if they are not in expected range.


    and so on ...

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • You're complete right...I gave too little precise information. I will check everything and describe it exactly on Monday.


    The only thing I can add now is information that I checked the module by connecting it to another KRCcabinet - the same result

  • ah.. maybe something is wrong with the module itself... do you have another unit you can try?

    unfortunately MFC can only work as master so MFC to MFC connection cannot work

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • More precise information.


    -external power source for Devicenet net and Phoenix module DIN 24V 1A 24W Mean Well

    measured voltages:

    between (+) and(-) = 24.0[v]

    between CanL and CanH = 0.6[V]

    between shield and (+) = 12[V] and drop to 0[v] after 3 second of measurment

    -cable HELUKABEL Devicenet thin 1x2xAWG24 + 1X2XAWG22 PVC Fest length=1.5[m]

    -phoenix contact ILB DN 24 DI16 DO16

    https://www.phoenixcontact.com…862602&library=plpl&tab=1


    Wiring:

    " class="messageFloatObjectLeft">


    Connection MFC and module:

    " class="messageFloatObjectLeft">


    ">


    Module:

    " class="messageFloatObjectLeft">


    " class="messageFloatObjectLeft">


    Devnet.ini

    " class="messageFloatObjectLeft">


    Devnet.LOG

    ">


    IOSYS.INI


    IOSYS.LOG



    At this moment i have already photos of DEVNET.INI and IOSYS.ini (forgot a disk, I will send TXT file tomorrow)

  • you still have not mentioned how long this DNET bus really is. if using high baud rates, distances need to be shorter. if using thin cable, also shorter (this is why thick cable exists for DNET trunks). if forced to run near interference source, even shorter.


    cable color code and connections looks good aside from using duct tape instead of heatshrink tubing. but assuming this is ok without knicks, cuts etc. and the MFC side is the same, and shield is only grounded at one point, wiring should be good.


    all voltages should be measured from same reference point such as 0VDC of your power supply (using black lead of your DMM), then probing all five terminals on the DNET connector with your DMM red probe.


    then you should see approx:

    red = 24V

    white = 2.3 - 2.8V

    shield = 0V

    blue = 2.3 - 2.8V

    black = 0V


    if the voltages for CAN_H and CAN_L (white and blue) are supposed to be within 0..5V and.... close to center of that range. If they are close to 0V or 5V (or higher), then wiring or one of the nodes is toast. this is why cable and voltages should be checked before connecting devIces.


    setting dip switches 7 and 8 to ON and all other to OFF position will configure node to use 500kbps and macid 1. which matches your DEVNET.INI. this has to be set before powerup. it is still unclear what is your powerup sequence where is power to all those circuits coming from. as mentioned dipswitch settings are considered only on powerup. i have seen non-functional DIP switch before though this is rare. to rule that out change macid to a state that is complementary, such as 2, 4 or 8. this way dipswitch (if faulty) would stay low. also, same can happen with the baud rate config. if device is new or can be tested on another system, there is very little reason to suspect device as being the problem.


    usually all of the 24V circuits (bus and I/O modules) are powered from same source (KRC2 in this case) so that rebooting controller, also cycles power to all devices and they get powered all at once. note that KRC is using 27.1V instead of usual 24V but that is ok. i have yet to see device that complains about it. another option is use dedicated 24V power supply that is powered from KRC.


    you are getting message that I/O mapping is incorrect. usually this means that size and range used in IOSYS.INI is not matching actual I/O size that connected device is reporting. in case of modular devices, this usually means wrong number of I/O modules is connected or there is a connection problem ("backplane" or goldfingers) etc.


    i also don't see messages about writing error (if i recall these messages usually are in pairs). maybe you just need to try adjusting mapped I/O size for inputs.


    your last image shows DC source in upper left corner. polarity is wrong. long line is the positive, short thick line is negative.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • With the driver dndrv.o you have to use other syntax in the

    iosys.ini.

    Code
    [DEVNET]
    inw0=0,x1
    outw0=0,x1

    All IO are counted from first device until last device, no device address is used.

    The other syntax is only with driver dn2drv.o, with newer KSS.

  • Data bus is 5V.... Comms chips are powered by 5V and this is why CAN_H and CAN_L are measuring half of that -when using multimeter. On an oscilloscope you would see square wave 0-5V. Multimeter is just too slow to catch that and tou see average.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • You don't need to connect resistors on either side. Just connect 120 Ohms to one side. You should also connect 24V to the red end of the devicenet and 0V to the black end. Why are you making the address 1? Do 5.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now