KUKA KRC4 - ProfiBus issue

    Hello all,


    I'm comissioning a KUKA KR16 robot at the moment, with a KR C4 controller to replace an old KR C2 controlled robot. The line uses a SIEMENS 315-2 DP PLC.
    The client wants us to prepare the new robot to be fitted into the line when the old one fails. Bit of a hassle if you ask me, but that's the client.


    The problem is that I've never configured the PROFIBUS for a KUKA before - or any KUKA - so I'm a bit lost.
    I have set everything as far as the manual would cover it, downloaded the project into the controller, connected the PLC to the robot...but the PLC is not seeing the connection to this new robot. The robot is set as slave, has the correct address set in - to replace the old robot - and...that's as far as I've gotten with the thing.
    We're trying not to disturb anything else on the line since the robot won't go into production now but I don't know if I'm missng something or if I've misset something.


    I'm using Work Visual 4.0.
    The software version on the robot is 8.3.32.
    There is no fault led on the Beckhoff device in the controller as it only shows RUN.


    Does anyone have an idea on how to proceed on this? Or what information I should offer to help diagnose?

    You will not be successfull with this project without changig configuration on PLC. Krc4 has a complete different PB slave than KRC2. So you have to include the GSD description into PLC and change the slave in PLC.

    Damn GSE files.


    Managed to get to the heart of it and we were using the wrong GSE file after all. Read through most of the topics on PROFIBUS problems here on the forum before I figured it out. I'm feeling a bit foolish now really...

    "Output from the PLC comes back to the PLC"? What? That makes no sense.


    Going by your screenshot, you have $IN[1]-[8] and $OUT[1]-[8] mapped to the first Output and Input byte on the PLC, respectively. So if the PLC sets outbyte0.0, you should see $IN[1] on the robot. Likewise, setting $OUT[1] on the robot should result in the PLC seeing inbyte0.0 (obviously, you'll have to adjust for your PLC's internal addressing).

    "This makes no sense" is about half of the dialogue around the robot today....
    Whatever we set on the PLC as an output towards the robot comes instantly back on the corresponding input on the PLC. On the robot I get absolutely nothing when checking the inputs. And similarly, when I set an output on the robot the PLC doesn't see it. And we're stumped.

    That is not the way to do it. It does not even connect to robot IO.....
    Left pane should not be a Fieldbus (you haave that on the right side already)
    Left pane need to be the robot I/Os. Then do IO mapping and deploy

    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 think I may delete my account on this forum, just out of sheer shame. I was not aware it worked that way - first time using all of this, so eh...-
    Something did seem fantastically odd to me about all of this, but it didn't say anything in the manuals I read.


    Thanks man. Now it makes a lot of sense and explains the behavior.

    [size=2]
    so far so good...
    now make sure that you select signals in bottom two panes and connect them. This is described in WoV help and manual. whatever you select on one size, must be same size and selection on the other side. for example in lower left you selected just one output (first one). that is one bit. to connect it to something on the right side, you must also select signal that is one bit. pay attention to gray arrows. both left and right arrow must be in same direction. good luck.... [/size]

    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

    Edited once, last by panic mode ().

    Thanks man. The way I understood things was a bit...off. I understood connecting the signals as making them available for the PLC. Didn't actually give much thought to HOW they went to the PLC. Assumed it was something closer to FANUC.


    Anyway, with this out of the way Dobby will be freeeee tomorrow. Thanks again.

    Well, don't be too embarrassed -- my face is :icon_redface: too. I completely missed the error in the first screenshot.


    Apparently, in that first screenshot, you actually had the incoming signals "looped" straight back out to the PLC -- I wasn't even aware that was possible. :icon_eek: But once Panic pointed it out, it was fairly obvious. That's why you were seeing the test results you were getting.


    Hm... now I wonder if it's possible to directly map signals through the robot from one device to another, or even between busses, this way, without using the "classic" method of adding pass-through code in the SPS. The next time I have a KRC4 to play with, I'll have to remember to experiment with that a bit.

    Never imagined something like this though. In ABB and FANUC you need to jump through a few hoops to get this result...here I got it by stupid chance.
    Once that got sorted out, we mapped everything nicely this morning, tested and were on our merry way. Incredibly simple once you know what it is you're actually doing.

Advertising from our partners