Issue with Beckhoff and KRC4 safety integration

    Hello, I am back I have finally received the Beckhoff parts and gotten them installed in a panel along with the EL6695-1001 into the KRC4 cabinet. I am having some issues with setting up the Beckhoff EL6910 safety to interface with the KUKA robot and am wondering if i can get some feedback on whether the physical configuration is correct, the software setup is correct, or if I'm making some blatant mistakes in interfacing between these two systems.

    So far the setup we have is as follows: KRC4 > EK1100 > EL6695-1001 on the primary.

    On the secondary we have as follows: EL6695-1001 > EK1110 > CX8190 > EL1008 > EL6910 > EL2008 > EL1918(EL1904) > EL2904 > EL6070 > (This is where the EK1110 is actually but for flow I put it at the front)

    does this seems correct? we are going to have DI/O in the form of a colour sensor and force torque sensor and i don't think it matters if the EL1008 and EL2008 cards are connected to the robot slave ethercat network versus the Beckhoff and being passed along Ethercat to the robot.

    I have the ethernet cable connected between the secondary side of the EL6695-1001 to the EK1110. as far as i am aware in Work visual I only need to put the EK1100 and the EL6695-1001 Primary devices in under the SYS-X44 bus and ensure that FSoE is activated in the safety control page and then map inputs ( as well as the robot programs). (I then pushed this configuration to the robot successfully)

    As for the Twincat3 side of things is where i am a little more confused, The documentation for setting up FSoE from KUKA is dated and doesn't really explain it to well so i am having issues with the implementation here. (some tabs are different, some things are missing and its hard to follow, I will be contacting Beckhoff for some help on the twincat implementation but i would like other eyes to help as well.

    I have scanned the devices into the I/O section, it had issues with the EL6695-1001 so i followed the KUKA guide and imported the secondary .esi file and it still has issues. The EL6695 is stuck in ERR_PREOP and is not moving into the OP state. (I can reset it and it goes into INIT state) and its not allowing me to map the inputs to the safety or even view the inputs in the I/O section of the solution explorer. Any clarification on how to achieve communication correctly would be greatly appreciated as I am lost currently.

    Here are some photos for diagnosticsrjStJzY


    Thank you for your time and sorry if i am missing something blatantly obvious :frowning_face:

    Colton

  • Go to Best Answer

  • HawkME June 10, 2023 at 12:42 AM

    Approved the thread.

    hmmm... just glanced it and it seem to be correct.

    and keep in mind that not everyone will bother following link to external sites.

    btw check the process data to ensure that PDO blocks to be transferred are actually selected.

    standard PDO need to be mapped to robot IO, but this has nothing to do with safety interface


    target system must be defined. in this case it is one of EL1918 instead of EL6910

    and of course one need IO mapping and TwinSafe program

    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

    • Best Answer

    Hello Again,

    I have fixed it WOOHOOOOOOO. I now have working safety via FSoE. For anyone curious as to how i accomplished this. Other than following the KUKA document on beckhoff FSoE integration, i called beckhoff support and also just banged my head against a wall for 40 hours.

    • Setup WoV correctly in my case i only needed to add the EK1100 and EL6695-1001Primary to the X-44 bus. (make sure to have SION-CIB in X48 because i didnt and that took a full day to figure out)
    • Set the data size and map the inputs and outputs between EL6695-1001 primary and the KRC4.
    • In TwinCAT3, once connected to your controller, scan the devices in and it should recognize them all. Change the standard data size from 8 to match whatever you set in WoV.
    • create a plc program, global variable list and 2 safety controller programs with Error Acknowledgement. 1 is for the Beckhoff side and the other the FSoE passthrough
    • make sure your safety controller device is connected (EL6910 in my case)
    • add 2 global variables called ErrAck and RunStop, and in your PLC program set them to TRUE.
    • Add your alias devices to your beckhoff safety network (EL1904, EL2904, ETC.) and link them to the physical device
    • Add your EL6695-1001 to the KUKA safety network and link it to the physical device
    • link your ErrAck to the ErrorAcknowledgement.sds file.
    • create your safety function blocks.
    • the tricky part is mapping the variables and ensuring all device settings are correct. If any of them are not fully mapped or you change a device settings you will get an error and want to cry.
    • make sure to also map the errack and runstop for both of your safety networks.
    • to pass variables between networks you need to have a decoupler on each one and then the output of one can be mapped to the input of the other. (its really ugly and i hate it)

    Theres probably a simpler way to set this all up but i have safety working now :smiling_face:

    Hello all, I am back again with an issue.


    As per my last post I was able to get safety working over FSoE with a Beckhoff EL6910 and the EL6695-1001 from KUKA. Almost everything seems to be working and its nice being able to run programs now :). As to why im posting here i am having an issue where the EL6695-1001 loses communication to the beckhoff safety controller for some odd reason sometimes when I reset or cancel a program on the KUKA teaching pendant. The issue is very intermittent (might happen 4/10 resets programs and 5/10 cancel programs) and the only error i recieve is the EL6695-1001 has a communication error from the pendant. In the KUKA safety interfaces page, the X44 interface seems to still be able to communicate with the EL6695-1001 and From the Beckhoff side, i have one error and my safety configuration is put into a reset state that cannot be left until I reboot the Beckhoff system or redownload my safety program to the safety controller.


    I am writing this to see if anyone else has had this issue or can help pinpoint the issue. I have a sneaking suspicion the issue is caused by my handling or lack thereof of the Comm Err, which is causing the reset, however in the live safety view, my safety networks doesnt give a diagnostic Comm error and instead says "ethercat master has reached a failsafe value"

    I dont have any photos of the errors at this moment but if need be i can get some. I am posting here because the configuration is already detailed in my previous replies which will hopefully make it easier to diagnose.

    we can only go by what you shared. so far issue seem to be on the PLC side with some undescribed error. Also downloading PLC code does a temporary fix that allows everything else to function again. this means KRC is ok and ready the whole time, just waiting for PLC. my guess is that your configuration, code or both are faulty so PLC stops due to bug or for safety reasons.

    Quote

    From the Beckhoff side, i have one error and my safety configuration is put into a reset state that cannot be left until I reboot the Beckhoff system or redownload my safety program to the safety controller.

    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

    Solved this issue and figured i would post it here, I never handled ErrAck and ComErr properly and it was causing issues. When i redeployed the KUKA configuration from WorkVisual it was tripping the safety and the CommErr LED would light up, so i just needed to acknowledge it properly and now it is working as intended.

Advertising from our partners