Profisafe Connection Errors

    Hello. I have just added a Profinet option package (Profinet KRC-Nexxt V3.3.5.19) to my controller. I have achieved successful communication between PLC and robot for standard (non-safe) I/O but I am struggling to get Profisafe working properly. I am hoping for some advice from the community. I have read similar posts, gone through all the relevant documentation I can find, and gone to the Focus Center - all to no avail.


    My systems are:

    Software: KSS 8.3.43, WorkVisual 6.0

    Controller: KR C4

    Robot: KR 6

    PLC: S7-1500, TIA 15.1 Update 8


    Link for pictures: https://imgur.com/a/kwxGLyb (also at bottom of post)


    What I have done:

    I started by creating a backup image and then I installed the option package according to the directions in the Kuka Profinet 3.3 documentation. The name of the option package in the Additional software page is "Profinet KRC-Nexxt" V3.3.5. This seemed to all go well. I then tried to switch to running safety over Profisafe instead of the X11 interface. I made what I believe to be the required hardware changes (disconnected the Ethercat connection from the SIB, unplugged power from the SIB, installed the X311 jumper on the CCU). I then made configuration changes in WorkVisual. I removed the SIB (SCION-SIB-STD) from the project and added Profinet to the bus structure. I still have the SCION-CIB in the X48 bus which I believe should remain. I then went through the Profinet settings (device name, # of I/Os, compatibility mode) and Safety control settings (Profinet Safety ID) and changed the relevant ones (see screenshots). I then mapped standard I/O from KRC I/Os to Profinet I/Os. I believe Profisafe I/O does not need to be mapped in this way - rather it is preconfigured. Let me know if I am mistaken here).

    I then made configuration changes on the PLC side in TIA portal. I added the device to my network along with the relevant GSDML file (gsdml-v2.32-kuka-krc4-profinet_3.3-20170131.xml). I updated the IP, device name, and the F_Dest_Add and F_Source_Add parameters in the PLC project. I configured PLC tags for safe and non-safe I/O. I then copied and pasted the Profisafe function call from a different and fully functional robot in the same cell. The second robot is a KR 210 with a KR C4 controller running KSS 8.6.9 HF2, KUKA.PROFINET MS V5.0.4, and SafeOperation V3.5.2. The Profisafe function call is a function block to set the Profisafe inputs and link the ACK_GL function from the PLC to the acknowledgement of operator safety bit on the Kuka profisafe inputs. Screenshots of this function block and it's call in the main safety block are included. I did change all the output addresses to set bits for the KR 6 (newly added robot) rather than the KR 210 (existing robot in the cell). I also removed the networks that were setting bits needed for SafeOperation but not used in Profisafe. I then downloaded the new project to the PLC and did a cold restart of the robot controllers with the "reload files" option checked.


    Where I am at:

    This all results in two errors on the robot. "Safe device communication error ProfiNet Device" and "Safety stop." Photo of errors is included. I do have proper communication of standard (non-safe) I/O over Profinet. So I think the issue is something specific to the safety side of the configuration. What is confusing to me is I have a working robot to reference so I could set everything up in pretty much the same way. But still one works and one does not. The relevant differences are the Profinet option package version (and the fact that I installed this myself) and the presence of SafeOperation on the working robot (KR 210).

    When looking at the Profinet Devicestack (PNIO-DEV), I noticed that none of the safety related F-parameters are being set on my KR 6 (picture included). Whereas on the KR 210 (picture also included) the proper F_DEST_ADD, F_SOURCE_ADD, etc. are shown. This surely indicates a problem but I am not sure where this problem lies, as I set the F_Dest_Add and F_Source_Add for the KR 6 in the TIA project. This is the only place I am aware of to set these parameters but they are not being properly inherited by the Kuka. And this parameter does match the safety ID on the Kuka.

    Something else I noticed on the PNIO-DEV page is that the two robots share the same AR ID. Is this expected? Could it cause issues? The input/output byte lengths also differ between the KR 6 and the KR 210. Is this normal?


    Potential culprits:

    Our KR 210 came installed with Profinet but I added to our KR 6 recently. So it is possible I did this installation wrong. Since Profinet is working but not Profisafe, I think it would point towards the safety hardware changes that need to be made. But I have checked over the process, which seems pretty straightforward, and I believe I have done it correctly. There could also be something wrong with the configuration changes I made in WorkVisual.

    I think another potential issue could be the safety program in the PLC . I copied a working one from the KR 210 and changed the PLC outputs to the proper addresses for the KR 6. I also referenced the Profisafe input byte addresses and how they must be set, which all looks correct. I thought this might be wrong because the same two errors show up on the KR 210 until the acknowledge button on our PLC cabinet is pushed. So I thought maybe the KR 6 was not receiving the acknowledgement. But I did a test where I checked the PNIO-DEV page on the KR 210 before acknowledging anything and it still had the correct F-addresses. So it seems an acknowledgement handshake is not required for the PNIO-DEV page to show the correct F-addresses. This makes me think there is something else causing the incorrect F-addresses on the PNIO-DEV page.

    Apologies for the long post but I wanted to include all the details. I have done lots of troubleshooting but I am unsure of what to try next. Please let me know if you have any ideas or if I can provide further details. Any help would be greatly appreciated!

    Also, I couldn't figure out how to attach an image other than via URL so I added all my images under an Imgur link: https://imgur.com/a/kwxGLyb. Let me know if there is a preferred method for this.

    kwxGLyb

  • massula December 18, 2024 at 1:25 AM

    Approved the thread.

    Hi


    I passed through a situation like this:

    Now my robots with ProfiSafe is working good. You must to pay attention with:

    • Did you made the reintegration routine in your PLC program?
    • Can you send a photo of your network configuration by PLC side?
    • Did you make assign device name for your robots?

    • Here is my ProfiSafe configuration...


    Hi Emanuel. Thanks for the reply.

    Quote

    Did you made the reintegration routine in your PLC program?

    I am not sure what you mean by the reintegration routine in the PLC program. I added the KR 6 to the project, set the parameters, added a safety function block, and downloaded the project to the PLC as described in my post and shown in the images. Is there another step I might be missing?

    Quote

    Can you send a photo of your network configuration by PLC side?

    I'm not exactly sure what you mean by network configuration. Below is an image of the devices and networks tree in my PLC project as well as one of the device view for the KR 6 when I go online with the PLC (the same view that you showed in your image). This shows the standard I/Os are connected but there is an error with the safe I/Os.

    Quote

    Did you make assign device name for your robots?

    Yes. That is shown on the Kuka side in the Imgur link in my original post (https://imgur.com/a/profisafe-images-kwxGLyb). The name matches on the PLC. I imagine that the 2032 standard I/O would not be working if there was an issue with the device name and/or IP address.

    Hi

    According your photos the Profisafe is fine. When the ID is not OK, just an "x" appears in your device. When is red or green means that the communication is OK.

    Maybe you are missing some safe bits required from robot.

    This bits are used to do the reintegration. When the ProfiSafe stops (PLC goes to STOP, the system is turned OFF, for example), you must to do reintegration. In my case I used a FirstScan bit in parallel with a reset button.


    Now, about the safe bits: In my case is working good. Maybe later you can separate the bits when robot is in T1, for can move with the doors open. But in my application this is not important.

    I have a similar safety program (can be seen in my images). I use ACK_GL instead of ACK_REI, but from Siemens documentation this should be suitable for reintegration. I do not set all 16 bits to one but I did reference the Profisafe documentation and believe I have set the necessary bits.

    That is helpful to know that the communication is working but I am still at a loss as to what could be causing the error. Do you (or anyone else) have other ideas? I am hoping to avoid having to switch back to the X11 for safety and adding a bunch of safety relays to my PLC cabinet.

    Edited once, last by g.weight (January 7, 2025 at 6:48 PM).

    I am replying to this thread mostly for posterity. I seem to have solved my issue and the solution is a bit obscure so it may be helpful to someone. Someone at Kuka said, "There is an internal note I found but it doesn’t make sense and sometimes the internal notes are incomplete. It states the a PROFIsafe connection isn’t possible with older GSDML files but obviously that hasn’t been the case with older KSS versions. I’m wondering if newer TIA and Step 7 projects could be an issue but again it looks like I’m missing some information." And he sent me the following image:

    I did as he recommended and tried the GSDML for ProfiNet 4.1 which cleared all my previous errors. I am not sure why this worked and it seems odd to use a mismatched GSDML version. I hope there are not other consequences to this and hopefully Kuka will provide some clarity in that regard. I'd be curious if anyone in the community has thoughts on this.

Advertising from our partners