Trouble with exchanging variables of Festo PLC and KRC 4 controller via EL6695 EtherCAT bridge

    Hi!

    Trying to connect Festo CPC-E-CEC-C1 (programmed via CodeSys SP18 Patch 4) AND KRC4 robot controller with and EtcherCAT bridge(Beckhoff EL6695), the intent is to exchange regular data variables for coordination of two automatization systems.
    Safety over communication is unnecessary(X11 safety used on the robot). The Bekchoff EL6695 is the original one, NOT the EL6695-1001.
    Festo PLC is connected to the EK1100(EtherCAT Coupler slave) which has the bridge module on E-bus rail (Festo is on the Primary side of EL6695).
    The robot's controller is connected to the Secondary side of EL6695.(the RJ45 IN port of the bridge module).
    Both WoV and CodeSys see the respective side of device via EtherCAT device scan.

    I'm sure KRC4 version / robot serial is not relevant here, but if there is anything You could see that could help you help me then I would be happy to share. :smiling_face:

    On both sides the "communication is running all right ", but mapped variables do reflect change on other device no matter what. At most we managed to get one variable across in both directions, but adding 2nd or more resulted in the whole thing not reacting again.(as if both sides weren't configured the same and interpreted received as different types/sizes/mappings).

    I've collected photos and screenshots that I think might be relevant to see the existing settings, wiring, etc., as well as a CodeSys project archive.
    As I've read in READ FIRST there may be concern with data size, so I just uploaded all of aforementioned on Google Drive folder:
    https://drive.google.com/drive/folders/…b6M?usp=sharing
    I've searched KUKA Xpert Basic materials, and nothing useful came up. The Beckhoff documentation is helpful explaining the basic principle of the module function and communication, and shows examples of setting it up in TwinCAT programmed PLC, but it does not seem to contain much information compatible with Codesys and we're clearly lacking the expertise with this on our end.
    I've tried to connect to both sides of the EL6695 and configure it via TwinCAT as described in here: https://https//www.evergreen…ridge-terminal/
    To no avail.

    I've also searched for similar problem cases on this and other forums and nothing found seemed to help - it seems that we managed to make our own mistakes rather than the same mistakes others made. :smiling_face:

    Our company has used the regular EL6695(non -1001) secondary side on other robot projects in the past, and it worked, but we have never done it with a CodeSys IDE programmable controller, so our suspicion is that we might have made some mistake on CodeSys side but trying many different things, asking local experts and representatives of Festo, Beckhoff and CodeSys and KUKA don't seem to help shed some light on this. Was hoping maybe someone here has experience with this particular hardware combination and could give us assistance!

    Just about anything insightful would helpful at this point , as we really are trying to get our system in the testing phase and the deadline is looming.

  • Lemster68 February 1, 2024 at 5:06 PM

    Approved the thread.
    Quote

    At most we managed to get one variable across in both directions, but adding 2nd or more resulted in the whole thing not reacting again.(as if both sides weren't configured the same and interpreted received as different types/sizes/mappings).

    what does that mean? what variable? what size?

    the robot side is happy and 64 bits of inputs and outputs are mapped.

    so whatever you do outputs on the robot side, PLC should see it on its own inputs

    also if the PLC outputs are set correctly then Robot should see them. so .. .are you sure you are using directions correctly?

    for example i see in screenshot 11 that on the robot side two PDO are:

    if i understand correctly, PDO #1608 is an output (from the robot side) so the 64 bits you mapped as two words in WoV will end up in the bridge as #x1608. on the PLC side they should be mapped to PLC inputs...

    but your very first screenshot shows that PLC is also trying to use #1608 as an output, while #x1a08 is an input. to me that does not sound right... somewhere signals should be crossed. That would explain why both connections seem to be, both PLC and KRC can write without issue (but they write to same location). and they both can read without issue but you are reading nothing.


    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

    if i understand correctly, PDO #1608 is an output (from the robot side) so the 64 bits you mapped as two words in WoV will end up in the bridge as #x1608. on the PLC side they should be mapped to PLC inputs...

    Yes, you did understand correctly, and you described it exactly as I understood too. While messing around to try different things I had swapped these over just to see if maybe I was wrong, but forgot to change before taking the screenshot. Sorry for the confusion.

    When I had the PDO adresses swapped correcty I still had no comms running. I did realise that some input bits were blinking?(noticed this weird thing in some tries yesterday too)
    https://https//drive.google.…iew?usp=sharing
    What I kind of figured out, is that regardless if you tick or untick the SYNC input tickbox in WoV settings it seems to force add it anyway (and bug out the mapping?). You would get "Invalid Error-Byte Mapping" error on KUKA side. So I just deleted the EL6695 from the WoV project and added back manually(without device topology scan), then didn't touch the tickboxes at all and just typed in the amount of DWORD in bot directions.And mapped the 3 bool variables asociated with SYNC inputs to WoV digital inputs for good measure. And never touched it again from Wov aside from mapping the fieldbus entries.

    And then I still had problems from CodeSys side to get the primary side to go past PREOP, but if I unticked one of the boxes here and when downloaded project to PLC:
    https://drive.google.com/file/d/1lO-eXm…iew?usp=sharing
    I would then have succesful connection and everything was running.

    Note that after adding more variables(I need 31 DWORD going to robot as inputs and 11 DWORDS going from robot to PLC in my final version) on both Codesys and WoV, and then downloading the projects on both, the bridge module reports "config" or "input config" errors on both sides and would not go past PREOP.

    What then I had to do was connect the ETH cable straight to the EK1100(which the EL6695 primary is connected to) and configure the bridge from TwinCAT sofware to have same IO amount as in Codesys and WoV as described here:

    Quote from Davis_ME

    https://www.evergreeninnovations.co/el6695-ethercat-bridge-terminal/

    But yeah I got it running in the end and successfully exchanging 31+11 UDINTs between robot and PLC.

    Holy fuck that was unintuitive and for the most part completely undocumented. Sure as hell wish there was a forum post or guide or something of someone else describing this SOMEWHERE.

    But I got it to work, so then it works and I won't touch it again lest it stops working because I touched it. :smiling_face:

Advertising from our partners