Replacing a (v)krc2 + KR210 to a KRC5 + KR120

    So it is finally happening. One of our old (v)krc2 is getting replaced:grinning_face_with_smiling_eyes:. the original plan was to go to a used KRC4, but kuka made us a nice offer for a brand new KRC5 that i could not refuse. But because i havent had any expiercence other then the VKRC2 en the KRC2 ed05. i have some questions. (Kuka is also helping with this, but i also know that there is a lot of knowledgeable people on this forum and i always like a second opinion)

    At the moment i am making a list of all the changes i need to make to our robot cell, most are straight forward but there are exceptions

    The current communication between the robot and the Cell is Devicenet. That is going to be upgraded to Ethercat. That part is not yet completely clear. I know that the KRC5 can only be Ethercat Master. Same goes for my PLC, so kuka will also supply an ehtercat bridge to connect both. What i can not find is if the bridge is configured true workvisual or if it is a separate thing. i have been poking around in workvisual, but in a empty configuration. So maybe this becomes clear after i download the actual configuration from the robot. :thinking_face:

    at the moment the cell and robot are turned on and off by cutting power with single switch. As far as i could find in the manuals this will still work with a krc5, What i can not find if this is best practice. KRC5 has a hibernate function and in the configuration i can see a "soft power button" listed. What i want to achieve is to turn on and off the cell and robot with a single button/switch like we do now with the KRC2.

    From what i have read, the rest should be no problem. All my programs are already written in straight KRL, so no problems with inline forms.i may have to change some of the INI's but that is about it. After installing the robot i have to measure only 6 bases and the homeposition and then everything should work again. I even don't have to write a new PLC program for the external control. i all ready have an KRC2 ed05 that is controlled by a PLC with ethercat and the start sequence is the same as far as i could tell. what could go wrong! :winking_face_with_tongue:

    if people have experiences with upgrading older cell's, i am all ears for suggestions for things i should not forget or what i should look at before removing the old robot.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    when migrating from KRC2 to KRC4 or KRC5 it is possible to bring in all DeviceNet slaves... it requires adding DeviceNet master to KRC (that is EK1100 + EL6752). just mentioning it as a possibility.

    if you are connecting to a PLC that is EtherCat master, you will need an EtherCat bridge such as EL6692 (and EK1100 unless you already have one).

    All configuration is done through WorkVisual. Note that naked WorkVisual is just that - bare bones. It can still collect project from KRC but deploying changes back to KRC may or may not work. to make sure it works you need to see what options are on the KRC (and installers are on the D:\).... then you may have to integrate KOP files of those option packages into WorkVisual. This allows WorkVisual to compile all things - including files that those options manage. Without this, WorkVisual would only compile things it already knows (basic KSS.... but not the options). And if such project is deployed and activated, one is usually facing hundreds of messages and every file icon has a big red X.

    If the deployed project contains any non-KUKA devices, you need to get device description files for each of them and load them into DTM Catalog. Then they can be taken from catalog and added into project... (and allow project to compile if those things are already there). That includes things from ANY other manufacturer, including mentioned devices (EL6692, EL6752, EK1100...).

    note that when it comes to EtherCat bridge, there are couple of versions such as

    EL6692 : simple bridge (non-safety IO only, could be from either KUKA or Beckhoff as it is the same thing - it was not modified so it uses Beckhoff device description files)


    EL6695 : newer advanced bridge (supports extended functions, this is from Beckhoff, so needs Beckhoff device description files)


    EL6695-1001 : KUKA variant of the above bridge (so it needs KUKA device description files). This one supports FSoE allowing both standard and safety messages.

    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 from panic mode

    when migrating from KRC2 to KRC4 or KRC5 it is possible to bring in all DeviceNet slaves... it requires adding DeviceNet master to KRC (that is EK1100 + EL6752). just mentioning it as a possibility.

    yeah, that was also my first thought. But because we are upgrading parts of the cell and our PLC does not have a devicenet option (in previous projects i used a Anybus Gateway). i figured it was better to change to ethercat.

    Quote from panic mode

    to make sure it works you need to see what options are on the KRC

    as far a i know there are no options installed, but i will check that when it arrives in a month time.

    Quote from panic mode

    note that when it comes to EtherCat bridge, there are couple of versions such as

    the kuka article number is 250244, but on the device page in my.kuka they don't list the article numbers. going from the pictures it should be EL6695-1001, but i am not a fan of trusting in pictures.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    New Robot has arrived! and a week early so that was a nice surprise.

    i can now confirm that is definitely is the EL6695-1001 that is installed. I have downloaded the current project from the controller (and made a back-up before i start messing with it :grinning_squinting_face:).

    I also got the robot to move in T1. Took me a little longer than i expected, but i got there eventually. There were 2 problems i got stuck on. the first is the XG11.1 connector for the emergency stops. The manual is quite clear on how everything is connected, only there are no numbers or any mark on the plug! so you have to go on how the connector is pictured in the manual. Personally i find this a little lacking, even if the picture is correct.

    second was resetting a dual channel fault in the emergency stops, when in plugged in the XG11.1 connector. i am accustomed to the ESC reset of the KRC2 so is was looking for something similar. Took me a while to figure out that it is in the software now. just have to find the right menu...

    in the next 2 weeks i am building a small test setup. so i can test communication between the PLC and KRC. i also will add all the hardware needed to the robot. Cables, valves, pressure regulators, that kind of stuff.

    When everything is working i am going to dismantle the old KRC2 and KR210, and hopefully switch everthing without to much problems. :thinking_face:

    Every problem has a solution, that isn't the problem. The problem is the solution.

    Did you make backup? If you do not have recovery stick, it is a good idea to order it asap (along with anything else you may want, mastering tool, software options. ). If done within short time of delivery, project pricing still applies. This means discounted pricing

    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

    Ran in to a small problem. When configuring the ethercat connection on the PLC side i have the problem that when i load the XML file (Kuka_EL6695sec.xml) i only have the options for a 4 bytes PDO. There should be options for 8,16,32,64 and 128 bytes.

    When i open the XML file in notepad i can see that these options are mentioned so i suspect it is going wrong in the software for the PLC (Unilogic for Unitronics PLC's). So i also asked Unitronics what could be going on here. As of now no response

    Has anybody else had a problem like this?

    As a last resort would it be possible to edit the XML file myself to only mention for example the 16 bytes PDO. Or am i then going down a rabbit hole where i never come out of again.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    not sure... sounds like import did not work...

    btw. if you are going to use Kuka_EL6695sec.xm on PLC side (That is secondary), then primary side will go to KRC. and that means your controller will be using FSoE interface. in other words, your PLC must be a safety PLC that supports FSoE.

    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 from panic mode

    not sure... sounds like import did not work...

    yeah under that assumption am i as well. i could not stop myself and i have been messing with the XML file myself and i did manage to get the 16 bytes option available. I just copied the code that was around the 4 bytes lines that marked it as default and put it in the same manner around the 16 bytes lines. so now i only see the 16 byte PDO. still have to test the connection to the KRC.

    Quote from panic mode

    that means your controller will be using FSoE interface.

    as far as i can see not. Advantage of reading through the XML files is that i noticed that there have been 2 revisions. in the last revision FSoE became an option. So it used to be that FSoE is required when using Kuka on the primary side apparently.

    With all the problems i have been having with the XML file that part works and i can disable it on the KRC and PLC without problems. that configurations is already active in the KRC and it has not given any issues yet.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    Again made some progress. connection is working, but somehow it is only one way. I can read data from the KRC, but can not write.

    I am a bit confused about that, i would expect that either it works completely or it doesn't work. But because this is my first time with workvisual and the EL6695 i am probably overlooking something.

    so in workvisual i configured the in/outputs in the signal editor:

    Then i linked the in and outputs to the KRC I/O in the I/O mapping screen

    KRC outputs work, but not the inputs.

    Am i missing something obvious?

    Every problem has a solution, that isn't the problem. The problem is the solution.

    Aren't only the top 3 sync inputs?

    The rest is configured under "Input Dword 0" which is addressed from 448 to 479. The second half of the first DWORD is a 16 bit integer (what i haven't linked to anything yet)

    Every problem has a solution, that isn't the problem. The problem is the solution.

    btw, i would not bother with signal editor and renaming of all I/Os. imho this is waste of time as nobody will see this at most i would just split signals if that is what you prefer to see.... i prefer to keep them grouped so there are as fewer mappings.

    what you want is enter I/O descriptions in symbol editor. this will bring the IO description to robot HMI.then just map thing en-masse... WoV will generate groups automatically... this is the quickest / most efficient way....

    you can enter IO comments in multiple languages so that when HMI language is changed, IO comments are also presented in correct language. if you value your time, you would appreciate ability to do this in Excel... Just export current IO list to a CSV file (File>Import/Export>....), manipulatee it, then import it back.



    as for mapping, select all inputs on the fieldbus side that are to be contiguous, then right click on first input in KRC side and and choose "Connect continuously".

    Do the same for outputs and you are done.

    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 changed all the I/O mapping and added the descriptions through the symbol editor. So at least that is sorted.

    Unfortunately still no luck in writing to the KRC. I also tried disabling the sync inputs (both in the PLC and KRC) but that did not have any effect. Reading still works fine.

    at the moment i am a bit struggling to find out where it is going wrong.

    • From the PLC to EK1100
    • From EL6695 to KRC
    • From ethercat bus to KRC I/O

    is there a way to check what data is going through the EL6695 directly? at least then i can figured out if the problem is on the PLC or on the KRC side.

    i found the option "connect with device" in workvisual, but after connecting i can't seem to much. From the help file the button "Monitor" is "currently without function" so that doesnt help.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    did you map them correctly? without correct mapping, it will not work.

    since you already messed with signal editor, i would say delete that node, then insert it again and ... pay attention:

    1. data is not packet tightly so boundaries of different areas are always on begin/end of a whole byte. different areas do not overlap or cross that boundary...

    2. you do not need to edit signals, just stick to Standard inputs and outputs,, stay away from anything that is SYNC or DIAG or similar (unless you KNOW what you are doing)

    3. if you are going to edit signal, make SURE to observe boundaries.

    just because some byte_0 happens to have 3 bits marked as some SYNC signals, remaining bits in that byte are still part of SYNC... it does not mean that remaining 5 bits are used for other area such as input or outputs.

    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

    Took a few days working on some other things. Hopefully a fresh mind helps

    Quote from panic mode

    just because some byte_0 happens to have 3 bits marked as some SYNC signals

    if this is the case how can use byte_0 then? Are they not a complete separate thing, not part of the normal inputs bytes. Or is the problem that i can not use the first 5 bits of DWord_0

    But following your advice i deleted the node and started over. without messing in the signal editor it now looks like this:

    Still the three Sync inputs at the top and then DWORD 0,1,2 and 3

    In the I/O mapping window i just grouped everything together like so:

    This time i also mapped the sync inputs, because that seems to be the only way that i can do some debugging.

    With everything changed i can still not write any data to the KRC. I can see the toggle bit of the sync inputs, so at least that is working.

    on the other side of the EL6695 i can receive data on the PLC, i only don't know if maybe for some reason i can not send data from the PLC to the secondary side of the EL6695.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    So i finally made some positive progress. the only other variable i messed with is the XML file for the secondary because i could not select the 16 byte PDO option. I changed that back to the original (and thus the 4 byte PDO) and now it works! :smiling_face: (i tried this before, but with old mapping so that might have helped as well)

    So i must have messed up something in the XML file, and only on the PLC output side (A.K.A KRC input). So now i only need to find what i messed up and i am good, how hard can that be? :thinking_face:

    I do really need at least 8 bytes so not out of the woods yet. Just good to know where i need to focus instead of randomly trying stuff.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    And the plot thickens...

    So went back to the XML file. was very careful to only change 2 "commands/lines" that defines the input and output PDO size as 4 Bytes to 16 bytes.

    F.Y.I that looks like this:

    Normally the command Default="1" s in front of #x200 (which is the 4 byte PDO) i moved that to #x202 for the 16 bytes PDO.

    This i have done twice. for the in and output PDO.

    In the PLC software (unilogic) i now have the 16 bytes PDO for in and output. Unfortunately i still can only read data from the KRC. PLC output still doesn't work constantly.

    I say constantly because today i noticed when i use the "recover Ethercat Network" option in the PLC. all the data is written where it should. that function as described by the Unilogic manual resets the Ethercat bus. Normally you would use this when you have unplugged a cable and a slave has disconnected or something similar. but it is only written once. After the reset is finished all data in the KRC stays the same.

    At this point i am for 99% certain that everything in the KRC is set correctly, and this is only between the PLC and the EL6695. still no closer to what exactly, but progress is progress.

    Every problem has a solution, that isn't the problem. The problem is the solution.

    So as an update. i gave up. i never got it to work. The unilogic software never read the XML file correctly whatever i tried. I am still not sure what exactly is the problem but it is definitely a problem with the unitronics materials. Unitronics weren't very helpful either.

    I switch to Ethernet/IP. got that to work but funnily enough not with again a weird issue. when loading in the KRC EDS file to configure the PLC as scanner. The software automatically used the max number of bytes defined for the in and outputs (505 and 509). which you can't change after. this is a problem because unilogic only support up to 505 bytes, so the program won't compile. in this case i could configure the scanner manually, but all together this hasn't been a great experience with the unitronics materials.

    Every problem has a solution, that isn't the problem. The problem is the solution.

Advertising from our partners