Profinet and Profisafe communication between KRC4 and S7-1200 1214FC

    Hello, this is my first post here, I’ll try to give the information as accurate and complete as possible and try to explain my question the best I can.

    I have a KR210 and a KRC4 (8.3.37) that I want to control via PROFINET (also using the PROFIsafe interface) with a S7-1200 1214 FC DC/DC/DC. I use WorkVisual 6.0 and TIA Portal V17 for configuration and programming.

    I’ve been able to establish PROFINET communication with the PLC. Meaning: IP’s and Device names have been correctly stablished, mapping has been configured, and I’ve been able to read and write values from the non-safe PROFINET I/Os and see how they were also having an effect on the Teach Pendant I/O Visualization window.

    In the KRC4 side, I’ve used PROFINET 3.3 and activated PROFIsafe (2.4). The procedure in WorkVisual was: set the parameters in the PROFINET tab, set the parameters in the Safety Control tab, map the PROFINET I/Os (PROFIsafe I/Os are hard-mapped) and keep in mind the security ID Address for the configuration in TIA Portal.

    In the PLC side, I’ve added the GSDML file for the KRC4-PROFINET-3.3, connected it to the PLC in the device and networks tab, and stablished the corresponding names and IP addresses. I’ve also set the F_Dest_Add parameter (inside the properties of the 64 safe digital i/os in the KRC4 controller) to 7 as in the Profinet Safety ID in WorkVisual.


    What I’m trying now is to get the robot into the AUT EXT mode and be able to control both the Safe outputs and the mapped (not safe) outputs with the inputs given from the PLC.

    For example, from the KUKA System Software 8 Robot Programming 1 Anex 14, there is a collection of signals used for the protocol to link the PLC and the robot in the AUT EXT mode.


    In the manual KUKA Profinet 3.3 for KUKA System Software 8.3 and 8.4 section 5.8 Safety Interface via PROFIsafe, the input and output safe bytes description is given.


    Some of them, for example, Byte 0 Bit 2: Operator safety, resembles the one $USER_SAF from the document previously mentioned.

    Here are some of the questions I have:

    Are the AUT EXT predefined signals ($USER_SAF, $STOP_MESS,…) always required for the AUTO EXT communication and operation?

    Which is the purpose of the safe signals then? Can I get to the AUT EXT with them?

    Can I get the AUTO EXT to work, without physical safety components installed (I know it’s not recommendable and dangerous), but forcing both safe and non-safe outputs from the PLC (inputs in the KRC, like USER_SAF or Byte0_bit2_BS)?

    If the SafeOperation package is installed, is it mandatory to set all the reserved bits to 1? Are there any bits that, if not used, should be set to 1?

    I have seen different errors in the Teach Pendant, but my main focus now is to understand better these concepts and what more I may be missing in terms of configuration and pre-defined values settings. Once that is addressed, I’ll may post more info related to specific errors.

    Please, feel free to ask anything regarding unclear or misleading information, any help is well appreciated. Thanks in advance.

  • Go to Best Answer
    Quote from Bender_the_robot

    What I’m trying now is to get the robot into the AUT EXT mode and be able to control both the Safe outputs and the mapped (not safe) outputs with the inputs given from the PLC.

    that is correct but it will be different programs. safety signals must be programmed in the safety task. none-safe (standard) logic goes into standard task

    Quote from Bender_the_robot

    Are the AUT EXT predefined signals ($USER_SAF, $STOP_MESS,…) always required for the AUTO EXT communication and operation?

    They are not specific to AUTO EXT, they are ALWAYS required (any operating mode). It is just that configuration/mapping of those signals happen to be in screen pages incorrectly named "Auto External". SOME of the signals there are used for Auto External. but there are many more there that have nothing to do with AutoExternal.

    Quote from Bender_the_robot

    Can I get the AUTO EXT to work, without physical safety components installed (I know it’s not recommendable and dangerous), but forcing both safe and non-safe outputs from the PLC (inputs in the KRC, like USER_SAF or Byte0_bit2_BS)?

    yes...

    Quote from Bender_the_robot

    If the SafeOperation package is installed, is it mandatory to set all the reserved bits to 1? Are there any bits that, if not used, should be set to 1?

    Safe operation manual tells what need to be set.

    Safe (deenergized) state is default... with all values 0.

    but to move the robot, they all need to be 1, including some of reserved ones.

    But this need to be done in the safety task.

    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 Bender_the_robot

    Do the safe inputs for the KRC have any control over the regular outputs of the KRC?

    nope.

    regular outputs are just regular outputs that user or programs can set and reset any time and without any restrictions. ANY TIME!!! yes, you have a robot arm crashed into the wall, flaming oil comming out of it, Emergency stop pressed and still the outputs (grippers, lights etc) could be moving and flickering any way you - like Christmas tree decorations.

    the only restrictions are skin deep - from the HMI (things you see on the smartPad). so the HMI may not let you toggle outputs if the robot program is running or if drives are not on. but... that is just the HMI and even so - if you know your way around it, everything is possible. for example you don't need to use HMI to access IOs. Or you can use HMI but let Submit do things for you - even the robot program is running or when drives are off.

    Out of box robot system and controller (in this case KRC/KSS) do not care about state of the standard IO. making outputs work only when some safe function is active is YOUR job. and the outputs are not tied into safety of the robot in any way because nobody knows what your application and needs are. you need to choose which outputs need to be affected by safety circuit and how. normally this means providing power to the outputs through suitable safety logic. so when the safety logic says "no power for you", the outputs are dead regardless if the robot logic has them turned on or off.

    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
    Quote

    Are the AUT EXT predefined signals ($USER_SAF, $STOP_MESS,…) always required for the AUTO EXT communication and operation?

    To move the robot in AUT EXT mode the AUT EXT signals need to be correctly configured and run (meaning timed correctly etc.) To move the robot arm at all outside of Startup Mode the Profisafe Inputs need to be correctly configured and run (meaning safety needs to be sent to robot, for example SHS1 signal needs to be 1 because 0 means safety stop).

    Quote

    Which is the purpose of the safe signals then? Can I get to the AUT EXT with them?

    Safe signals are for safety purposes. As per above, to move the robot in AUT EXT both the safety needs to be correct (or faked) (because the arm will not move otherwise) and AUT EXT signals need to be correct (otherwise no AUT EXT mode).

    Quote

    Can I get the AUTO EXT to work, without physical safety components installed (I know it’s not recommendable and dangerous), but forcing both safe and non-safe outputs from the PLC (inputs in the KRC, like USER_SAF or Byte0_bit2_BS)?

    Of course! How would the robot controller know that there is no estop button if you sent it that ESTOP button is pressed using the PLC? It wouldn't and it doesn't. You can force all safety outputs on the PLC.

    Quote

    If the SafeOperation package is installed, is it mandatory to set all the reserved bits to 1? Are there any bits that, if not used, should be set to 1?

    SafeOperation has nothing to do with those signals, it is ProfiNet option package which configures that. SafeOperation configures other things, like brake testing, mastering test, safety zones, safety tools etc. In ProfiNet manual you will find that it says that it is best to set reserved signals to 1, that is in case of upgrades in the future, but also best practice.

    If the safety interface for the robot is ProfiSafe, you MUST set reserved bits to true in the safety PLC.

    When it comes to SafeOperation, larger block of safety data is exchanged.

    Without it, only the first 2bytes are really used (bytes 0 and 1, they are containing same signals one normally finds on X11).

    With SafeOperation, additional 6 bytes are used (they contain signals normally found on X13, plus few more).

    In case of ProfiSafe, all 8 bytes are exchanged with safety PLC regardless if you have SafeOperation or not. In other words the 6 bytes used for SafeOperation are transmitted even if not used.

    in case of CipSafety (via EthernetIP), one can choose if exchanged data will transmit only the first two bytes or all eight bytes.

    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

    Thank you all for the answers, great pieces of information there that I was missing.

    Quote from aknezevi.proton

    for example SHS1 signal needs to be 1 because 0 means safety stop).

    I missunderstood the usage of this kind of signals, I'll set all of them to one for the testing purpose and connect them to physical components in next stages.

    Quote from panic mode

    In case of ProfiSafe, all 8 bytes are exchanged with safety PLC regardless if you have SafeOperation or not. In other words the 6 bytes used for SafeOperation are transmitted even if not used.

    This is another great thing for me, I was not setting the reserved bytes from the SafeOperation part, nor the other ones, and I've read that for example you need at least one tool always active in the dedicated bytes, so I was missing that too.

    Thank you all for the support, I'll apply the changes and see If I can now configure the AUT EXT correctly

    Quote

    I missunderstood the usage of this kind of signals

    I am assuming you meant that you thought 1 means safety stop?
    That is not how industrial automation works. What if PLC suddenly loses power, and since it is a profisafe device it runs all safety. If 1 meant that safety was breached (for example 1 meaning safety stop), then if PLC controller (which runs ALL safety!) lost power there would be no way for robot controller to know that there has been a safety hazard, it would not be told that.

    And, yes, KRC would know that communication broke, but imagine it was just one wire breaking. That is why mostly in all industrial automation 1 means good to go, and 0 means something is broken. Because if there is no power, by default you send that something is broken, which is just good practice.

    But, you can always fake signal and just see what controller tells you, to make sure what is 1 and what is 0.

    Quote from aknezevi.proton

    I am assuming you meant that you thought 1 means safety stop?
    That is not how industrial automation works. What if PLC suddenly loses power, and since it is a profisafe device it runs all safety. If 1 meant that safety was breached (for example 1 meaning safety stop), then if PLC controller (which runs ALL safety!) lost power……

    Yes, I understood that, 1 means safety stop, and didn’t give it a second thought. What you explained makes perfect sense, and now, I will remember it and apply it.

    Thanks for the explanation!

    the data is expected to be "1" since it is fail safe. in this state each bit acts as permissive or enable signal.

    each safety node (master and slave) checks for correct data of course but it also checks for other things including state of local IO and the communication timeouts. this way, regardless of type of failure, each safety node (master or slave) will automatically clear all data, along with all outputs that it has control over, thus resulting in a safe state.

    some bits are reserved, meaning they may not have assigned function yet, but this may change in the future. this is why all the bits are still checked - for future compatibility.

    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

    Hi again, I have a question regarding the set up for the input bytes in the profisafe reserved bytes. Particularly the SPA bit, which is the 7th bit in the input byte 1. From the description given in the Profiner 3.3 Manual, I don’t know if it should be defaulted to 0 or to 1, given that is an acknowledgement signal. I’m thinking of a 0, but I may be missunderstanding something. The manual description is copied bellow:

    System Powerdown (controller will be shut down)

    One second after the SP signal has been set, the PSA output is reset by the robot controller, without confirmation from the PLC, and the controller is shut down.

    0 = controller on safety interface is active.

    1 = controller will be shut down

    Thanks in advance!!

    Quote from panic mode

    the data is expected to be "1" since it is fail safe. in this state each bit acts as permissive or enable signal.

    hey Panic mode, I posted a comment about one specific signal, could you help me with that?? Thanks!!

    and you are correct - power down signal is an apparent exception.

    frankly - not sure why is this even part of the safety interface.

    manual tells that this need to be 0 and if this is set to 1, it WILL shut the robot controller down. so, nothing unexpected about that.

    i never used it nor plan on doing so. can't think of scenario where i would want safety PLC to shut down KRC. it is normal that safety PLC enables/disables peripherals but this is something that happens in milliseconds upon conditions being met. but powering down device that takes forever to reboot (like robot controller) is something that happens on a very different time scale and i have never seen any other device that would support this.

    if i use something to power things down, i expect to use the SAME mechanism to revert the state and power up. which is not there in this case...

    perhaps it was debugging feature used by developers to get past some frustrating issues that they could not program around. or it may have been just conceived during Oktoberfest...? :clinking_beer_mugs: :clinking_beer_mugs: :clinking_beer_mugs: :clinking_beer_mugs: :clinking_beer_mugs:

    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

Advertising from our partners