KRC2 EIP Config

  • KSS: 5.6.11

    Arm: KR180PA-2

    Cabinet: KRC2 ed05

    EtherNet/IP: 2.1.2


    Doing some modifications on a couple KRC2 robots and struggling on the fieldbus config.


    Robot 1:

    1. Replacing a DeviceNet IO block with an EIP IOL master
    2. Adding an AB PLC (EIP comms)

    Robot 2:

    1. Replacing a DeviceNet IO block with a different DeviceNet block
    2. Adding an AB PLC (EIP comms, but this one will speak through a DeviceNet -> EIP gateway as it does not have an EIP comm card)

    I've managed to:

    • Understand how the iosys.ini & applicom software work (through a Win XP VM, no less)
    • Understand how to share robot folders over the network
    • Semi-configure the applicom stuff, download to the robot, and then reconfigure the IO driver on the pendant

    Unfortunately, I have no idea how the existing configuration was set up. Apparently there's no functionality built in to let you read from the comm card... It should have been fairly simple, though, as it was just talking to one EA7 HMI panel. I was able to pull the EDS before breaking the config so I think it should work, but I keep getting comm errors (device not ready: status 65 & error on read/write of EthIPDRV). It's just using a generic EDS that I added 50 bytes of IO to.


    iosys.ini:

    My additions are just the "IOBK" and "PLC" lines underneath [ETHERNETIP].


    Pics of the EIP Console / Applicom software:

    tG0mTJI.png


    Pic of errors:

    tn9zvNP.jpg


    Manual says to check the connection settings for status 65, so:

    LCHGjso.png


    I know they're super old robots, but anyone remember setting this stuff up? I can probably get the new stuff sorted after fixing the HMI I broke...

  • Place your Ad here!
  • Nation

    Approved the thread.
  • We scrapped the EIP idea, figuring dnet would be easier. It's almost good, but I can't get a connection to this gateway (A-DNTR/B).


    Updated iosys:


    Updated devnet:


    devnet.log:


    Pic of dnShow:

    TvrV6jD.jpg


    Pic of the gateway's status:

    458JCeh.png



    I don't know what else I can do to debug. The telnet & devnet.log results don't really give me anything to go off of. We verified that the wiring is okay by swapping with another block and it did seem good.

  • the telnet screenshot shows that node 4 is offline and all values are zeroes.


    is the gateway itself configured?


    does the configuration match your robot settings?


    i only see that it is a node 4 and baud rate is 125kbps but not the role (master or slave) or size of IO blocks.

    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

  • Quote

    Unfortunately, I have no idea how the existing configuration was set up. Apparently there's no functionality built in to let you read from the comm card... It should have been fairly simple, though, as it was just talking to one EA7 HMI panel. I was able to pull the EDS before breaking the config so I think it should work, but I keep getting comm errors (device not ready: status 65 & error on read/write of EthIPDRV). It's just using a generic EDS that I added 50 bytes of IO to.


    iosys.ini:


    My additions are just the "IOBK" and "PLC" lines underneath [ETHERNETIP].


    I do not understand what you mean there.

    why are you adding two connections at once on a system you are not very familiar with or where information is lacking?

    there are plenty of settings that need to be made and all need to be correct so keep it simple and only add ONE node... when this one is ok, then add the next one etc.


    when working with EIP on KRC2 i always used my own Ethernet switch (separate from the plant network) and only connect things i really need (and gradually add more things if needed).

    for example if making connection to PLC i would connect 4 cables to the ethernet switch (and nothing else):

    1. PLC (or whatever product need to be setup to talk to KRC via EIP)

    2. Laptop (required for setup and diagnostics, not used in operation)

    3. KRC onboard ethernet (required to configure and transfer settings to EIP card, not used in operation)

    4. KRC EIP card (required to communicate to PLC)


    next i would choose network settings for each node and IO size to be exchanged.

    then i would choose roles (Which side is master, which is slave) since setup is a bit different when roles are reversed.

    and then, configuration can begin...

    once the setup is complete and working, next node would be added (IOBK for example) and process would be repeated etc.

    once everything is setup and working on local network, then laptop and KRC onboard Ethernet port would be disconnected.

    remaining Ethernet cables would be connected to the regular Ethernet switch (plant network).


    Don't have access to robot so following document was created using my recollection and some screenshots that i had. Therefore correctness or completeness cannot be guaranteed but for the most part it should be correct and point out things to pay attention to:

  • oh and yeah, this should be obvious but just in case:

    IO size of the instance must match on both ends even if expressed in different units.

    On KRC side allocation is done in bytes.

    On AB PLC there is no byte but SINT is a same size (also 8 bit).


    Although not necessary, it is a good idea to keep the same units.

    for example if one side is set to 16 BYTEs, the other node could use either 16 BYTEs, or 16 SINTs or 8 WORDs or 4 DWORDs or etc.


    Personally I prefer to use bytes for fieldbus. This is the because recalculation is not needed and diagnostics tend to be simpler (the raw values are same on both ends even when they use different endianness).

    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

  • is the gateway itself configured?

    Ah sorry, yeah it is afaik. It let me choose the node ID & the data size so far, which I set to 4 and 64 bytes in/out, respectively. It's also set as a dnet target, so it should be a slave to the robot.


    Is there anything else I'm missing for the dnet config? I think I hit everything that Kuka's document specified?

    there are plenty of settings that need to be made and all need to be correct so keep it simple and only add ONE node... when this one is ok, then add the next one etc.

    Right, I didn't realize that some of the errors I was getting come up just when a device is missing. I can try deleting the config and try to get just the HMI working again on Monday. Thanks for the document!


    Now that I think about it, the generic EDS I thought I pulled from the original program had assembly instances of 0. Might actually make sense why it couldn't communicate if EIP requires a non-zero instance.

    oh and yeah, this should be obvious but just in case:

    IO size of the instance must match on both ends even if expressed in different units.

    Yep, see people run into this here and there in various devices often enough 😅

    Edited once, last by jyimg ().

  • Alright, so nothing I've done seems to have any effect. We brought in a KUKA tech and he was just as stumped. He was considering calling the EIP card bad, but not sure downloading to it would've killed it?


    We tried:


    EIP to the HMI (robot as master)

    EIP directly to the PLC (robot as slave)

    DevNet to the gateway (robot as master)


    and nothing ever seems to get connected. The PLC attempt gave us "invalid parameter" regardless of data size (we tried 1 byte, 8 bytes, and 256 bytes).


    Anything else I can try?

    Edited once, last by jyimg ().

  • Hmmm... bummer...


    I would say start from scratch and keep it simple. Do not mix things up, focus on ONE thing:

    If you want to pursue DeviceNet - good. Make a thread JUST about DeviceNet.

    If you want to pursue EIP- also good. Make a thread JUST about EIP setup.


    When everything is piled up in one thread, nothing will get done even if it takes very long.


    And make a connection diagram, with configuration of each side.

    Make sure that everything you try is detailed to a point that others could replicate it.

    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

  • Yeah sorry, been a little hectic. I'll try to put together a diagram tomorrow or Monday.


    I think the DeviceNet issue is a conflict between the MFC and the gateway's functionality (not sure it supports a master on both sides?), but we'll do some more digging and see what happens.

  • I think the DeviceNet issue is a conflict between the MFC and the gateway's functionality (not sure it supports a master on both sides?), but we'll do some more digging and see what happens.

    DN is a bus that has strict rules -- one Master, up to 255 Slaves on a single bus.


    Since the KRC2 MFC-card DN driver can only act as a Master, the Gateway would have to be configured to act as a Slave on its DN side. IIRC, the Gateway can be configured to act as either M or S.

  • Since the KRC2 MFC-card DN driver can only act as a Master, the Gateway would have to be configured to act as a Slave on its DN side. IIRC, the Gateway can be configured to act as either M or S.

    Yeah, made sure it was acting as a slave. Doesn't seem to matter what I set either side as, so maybe it's just not functional for this application. Waiting on their tech support to see if I'm doing something wrong.


    Here's a pic of the network, in any case:

    NCa2c0T.png


    The pink blocks are our additions. "DNet Tee 1" used to go to an empty IO block with Node ID of 4.


    Probably going to scrap any new comms on this thing and just write a dumb palletizer in the robot. We can hardwire a discrete style select and reprogram the HMI, I guess.

  • your DeviceNet topology is not a bus. this would be the first thing to look at. note cable lengths, cable types (trunk/drop) and location of terminators.


    next check DNet hgateway configuration. DNet side must be configured as DNet slave, have unique macid and operate at same baud rate as rest of the DNet.

    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

  • Here's a pic of the network, in any case:

    Where are your DeviceNet terminating resistors on that diagram? They should be located at the ends of the longest cable distance between any two nodes. (and remember, two -- no more, no less). Looking at your diagram, I would guess Nodes 2 and 5 (or Node 2 and the Gateway, depends on cable length of each branch). Remember, DN has a total cable length limit, a trunk cable length limit (defined by the distance between the terminators), and a limit for each branch (anything from a T that doesn't end in a terminator).

    Pic of dnShow:

    Have you tried a dnWho? That should query the bus and show a report of every node that reports back, with enough details to set their entries in the DEVNET.INI file. Any node set to the correct baud rate should respond to the dnWho command.

  • Where are your DeviceNet terminating resistors on that diagram?

    Honestly, I didn't see anything resembling the resistors but I didn't really look for them. I would guess they might be plugged into two of the field blocks...? The existing nodes still seem to work fine, so I would assume the resistors are okay?



    Also we didn't change any cable lengths, just used an existing cable for the gateway.


    Have you tried a dnWho? That should query the bus and show a report of every node that reports back, with enough details to set their entries in the DEVNET.INI file. Any node set to the correct baud rate should respond to the dnWho command.

    Ah, I guess I never took a picture of my dnWho results. All the existing nodes come up and the gateway comes up as "UCCM."

  • in my experience most of the problems are due to bad wiring.

    if wiring is correct, it is possible to make fieldbus work - even rookie will be able to get there just by playing with parameters.

    but...

    but when wiring is not correct, it is impossible to make the bus work regardless what settings you try.


    also, i would add that you are not serious about getting this to work or you would be reading applicable documentation and considering advices of those trying to help you.


    terminating resistors are not optional. they are REQUIRED and NEED to be placed at the ends of the BUS.


    what you have described is NOT a bus.


    so you want this to work, you really need go ahead and check it out:

    1. find WHERE the terminating resistors are placed

    2. MEASURE length of each cable section

    3. draw an EXACT topology of the whole thing INCLUDING lengths of cable sections.

    4. check connections at the node that is not working (DNet has 4 conductors + shield. is this really connected correctly?)

    5. check node settings of the non-working node and compare with master.


    about wiring... there are two DNet cable types - thick and thin.


    thick cable is really thick (like a thumb). this is preferred (superior performance) type of cable but it is not cheap or easy to work with.

    thin cable is thin (like a pencil). this is cheaper, more flexible and usually easier to work with but this degrades performance which means bus length and bus speed are to limited.


    the long cable section between the terminators is called a TRUNK (like a tree trunk). normally this is the place for thick cable.

    the branches are short cables that connect node to the TRUNK. Branch segment is called DROP. Sometimes drop may be split into further branches. However this is not preferred. ANY non-zero length of the drop or branch is ruining bus performance and at some point part of the bus. Failure to observe lengths means that part of the bus or even complete bus may be UNUSABLE.


    If the part of bus is communicating, this does not mean that things are perfect. It simply means that nodes are able to overcome distortions - presently. But that may be a very delicate balance, close to the point of instability. Adding another cable to such bus may tip the balance and some or all of the nodes may not be able to communicate.


    The thing is that each DROP should be really as short as possible (zero meters) to call this a bus. In practice drop length may be non-zero. Depending on size of network, bus speed etc. it may be ok to use drops that are up to certain length. Specification may tolerate something like 3m or even 6m or so (whatever the specification states).


    Consider following examples:

    top case is a true bus - just one cable and properly terminated. Any nodes would be connected directly to the trunk.

    next is less than ideal bus but - much more practical. drop lengths are present but they are short.


    the last case is unacceptable configuration since it contains drops with excessive cable lengths.

    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

  • I'll admit I didn't have the chance to do any research on devicenet, sorry. I've been split across a few different projects. Looked into a bit + read your message, thanks for the detailed explanation!


    I'll be there Monday and will document the network accordingly.

  • Honestly, I didn't see anything resembling the resistors but I didn't really look for them. I would guess they might be plugged into two of the field blocks...? The existing nodes still seem to work fine, so I would assume the resistors are okay?

    If the existing nodes and dnWho work, your resistors are probably ok, but it can't hurt to check. Termination comes in 3 different types on DN:


    1. some modules have internal termination resistors that can be connected or disconnected using the same DIP switches used for setting the MAD ID.


    2. On the circular 5-pin connectors (your Ts probably look like this), there can be big thumb-sized terminators that look like a 5-pin circular connector that's caped off


    3. On the 5-pin Phoenix connectors (like the X801 on the KRC's MFC card), you'll usually find a regular old resistor like you might buy at Radio Shack back in the day, stuck into the screw terminals for the CAN+ and CAN- lines.


    Each Terminator should be 121 ohms, with 4% tolerance or better. If you power down the DN bus and use an ohm meter at any point on any branch of the bus, you should see 60 ohms between CAN+ and CAN-, plus or minus 2, maybe 3 ohms. The failure I see most often is someone leaving one or both terminators off, or adding more than two.

  • Okay, so we managed to get another kuka tech in this morning and we spent some more time digging into it. Prior to, I was checking the lengths & double checked the actual layout (I have a partial updated layout but am not there presently to complete it). It definitely doesn't look like a proper "bus" as shown in the typical devicenet layouts. I did see ~61 ohms between the CAN lines, however.


    In the meantime, we actually figured out why the direct Ethernet/IP comms to the PLC wouldn't work.


    Apparently, the KRC2 adapter won't accept unicast packets. When he changed it to multicast (on the PLC side), it got "running" immediately and we verified some signals.


    I think we can table the DeviceNet discussion (as I don't have a need editing that portion of it now, and we can source another EIP card for the older robot), but I really appreciate the detailed support you guys have given!

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

Advertising from our partners