KRC5, Interface XG11.1, XG58. How can I set or read the signals from these interfaces?

  • AD
  • read pinned topic READ FIRST... key manuals mention signals used to monitor various things including those... or check AutoExternal interface configuration...

    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

  • read pinned topic READ FIRST... key manuals mention signals used to monitor various things including those... or check AutoExternal interface configuration...

    But this is a Safety interface.

    Two Safety inputs and one Safety output.

    What are the names of these signals?


    And another question.

    The physical addresses on the XG12 interface are inputs and outputs numbered 1 to 16?
    $IN[1] - $IN[16], $OUT[1]-$OUT[16]

  • Quote

    But this is a Safety interface.

    Two Safety inputs and one Safety output.

    What are the names of these signals?

    i have just shown that... or... am i missing something?


    Quote


    The physical addresses on the XG12 interface are inputs and outputs numbered 1 to 16?

    could be if that is what you want. you can map them any way you like, they don't need to be consecutive either...

    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

  • You don't map them -- they are inherent to the KRC.


    So $USER_SAFE is a system output that always reflects the status of the Operator Safety inputs on the X11. That can't be altered.


    Now, if you want to send $USER_SAFE to another device, you simply need to change the $OUT number it's associate to, as Panic showed.

  • you are confusing safety signals with standard I/O. those are apples and oranges.


    with KRC:

    1. standard I/O is freely mapped. standard address space has 4096 inputs and 4096 outputs but this can be doubled if needed. For details refer to WoV manual.

    2. safety signals mapping is fixed. it id done internally by KSS and you cannot alter it... this is same for any Ethernet based safety (FSoE, CIP Safety or ProfiSafe). for details see key manuals mentioned in in pinned topic READ FIRST


    if using PLC (or safety PLC) connected to KRC:

    1. KRC standard I/O mapping need to be done (it has to match KRC signal order and size)

    2. KRC safety signals mapping need to be done (it has to match KRC signal order since KRC mapping cannot change)


    Monitoring on KRC:

    1. standard I/O can be monitored directly or using VARCOR (Single Variable Monitor)

    2. safety signals can be monitored by using system variable names. Some of them i highlighted in earlier post with blue rectangles. to learn more read key manuals mentioned in pinned topic READ FIRST (also link is in the signature footer below each of my posts)

    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

  • So $USER_SAFE is a system output that always reflects the status of the Operator Safety inputs on the X11. That can't be altered.

    So - $USER_SAFE is a Safety output.

    And what are the names for the 2 Safety inputs?

  • Thanks.
    I just couldn't find the signals in the interface, that's why I asked.

    I really need to know the names of the 2 safe inputs, as well as how to configure the addresses of the standard 16 inputs and 16 outputs on the XG12 interface.

  • Quote

    So - $USER_SAFE is a Safety output.

    no... read the manual.


    $USER_SAFE is a system variable that indicates value of the safety input called Operator Safety. In documentation you can see original name for it and abbreviation ("Bediener Sicherheit" - BS)


    $ALARM_STOP is system variable that indicated value if (all) EStop stops are ok or not ("Nothalt" - NH)

    $ALARM_STOP_INTERNAL is another variable that can tell if internal EStop is ok or not.


    etc.


    read the manual...

    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

  • So - $USER_SAFE is a Safety output.

    And what are the names for the 2 Safety inputs?

    No. "Safety Signal" is a very specific term, involving dual-channel, safety certification, and other complications.


    $USER_SAFE is a non-Safe signal that reflects the status of the Operator Safety inputs. This exists to make it possible to pass along status information in a non-Safe fashion to another controller.


    The actual Operator Safety inputs are not mappable or available to monitor -- they simply disable part of the robot's internal safety chain. $USER_SAFE is made available to let you know why the robot is throwing a safety fault.


    The historical reason behind this dates back to when safety circuits were all banks of relays in complex relationships, using hardware-level interlocks to enable/disable the robot motor power relay. Those relay banks were completely separate from the robot's "brain."


    But since opening the robot to look at the relays in order to determine which signals were active or not was counterproductive, many of the key relays in the chain had extra contacts that were wired to dedicated system inputs on the robot. These signals were not Safety Signals, but served to indicate to the robot controller which sections of the relay chain were closed or open. These signals could then be used, in a purely informational and non-Safe way, in programs, or to activate indicators. They also drove robot status messages more detailed than "Some part of the safety relay chain is open."


    These days, all Safety signals are dual-channel, but signals like $USER_SAFE are at a higher level of abstraction -- if $USER_SAFE is False, it could be that both of the Operator Safety inputs are open, or it could be a mismatch between the A and B channels of that input. Or it could indicate that there was a timing mismatch between the A and B channels which latched a single-channel condition and requires a reset.


    TLDR: the hardware-level signals on X11 are not accessible or mappable. Only their more abstracted non-Safe reflections like $USER_SAFE.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now