Posts by jyimg

    There's a bit of tracing back to figure out the usage. From what I can tell:

    • SG_MOVE eventually calls SGW_GetSpotValues
    • This calls SG_PrepareComm_IWT
    • This calls GetTimerImpl, which calls various SG_PrepareCommImpl# or lastly SG_PrepareCommCustom
    • If all of the above fail, it reverts to SG_PrepareCommStd - which is exactly the same as the initial CustomComm:
    GLOBAL DEFFCT INT SG_PrepareCommStd(Point_DATA:IN,NewStart:OUT)
       DECL BOOL NewStart
       RETURN -1

    So now getting back to both of your concerns -

    the opposite meaning could be that writing value failed because the targeted outputs are out of range

    I suppose this is actually possible, as we do know how many bits are actually mapped out to the timer. Otherwise, there isn't any feedback (as far as I know) that the program is "valid" on the WTC's side.

    This actually is already checked by SG_SetNumberToOutput -

    If you guys would like the entire ..\TP\ServoGun folder to review, I could supply it?

    I know this is a really old thread, but I wanted to note down a solution we had found out a couple robots ago.

    It seems like this remains an issue even on KSS 8.7.5 / 8.7.6 with ServoGunBasic 3.2.2.

    I narrowed down the issue to the following routine located in ..\TP\ServoGun\WeldTimer\SG_TimerImplCustom.src

    GLOBAL DEFFCT INT SG_PrepareCommCustom(Point_DATA:IN,NewStart:OUT)
       DECL BOOL NewStart
        RETURN -1

    It seems like it will forever return -1 if you are not using a supported timer (of which WTC is not). So from a different integrator's robot, I found this modification:

    GLOBAL DEFFCT INT SG_PrepareCommCustom(Point_DATA:IN,NewStart:OUT)
       DECL BOOL NewStart
       RETURN 1

    Seems to have gotten a few of my robots going so far.

    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!

    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.

    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."

    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:


    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.

    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.

    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?

    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 😅

    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:


    Pic of dnShow:


    Pic of the gateway's status:


    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.

    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.


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

    Pics of the EIP Console / Applicom software:


    Pic of errors:


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


    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...

    The one downside that I have experienced to having many modules with few routines is that to view other routines I have to go back to module view, then select view routines for the other selected modules. Kind of adds that extra step when trying to follow/examine the code.

    Ahh, ran the flex pendant sim and I see what you mean. Suppose I can make my groups more loose. Thanks!

    Then my Part modules is separately loaded as required from the HDD and inside them is all data required for the use in that Module.

    Is loading/unloading modules like this common practice or is it just used when you've hit your memory limit? Seems a little extra for small-ish programs?


    Getting a few ABB robots (IRC5 controllers) so I'm trying to figure out how it all works. Reading through the RAPID manuals, it sorta makes sense, but wondering if I'm approaching this properly. The only internal example projects I have access to display some ~50 procedures inside one main.

    Here's a pic of some sample modules I created:


    Basically I've separated global procedures in "grouped" modules. Does this make sense for ABB or does it fall flat on a real teach pendant? If this seems okay, should some of these be system modules (namely the handshakes/EOAT stuff)?

Advertising from our partners