TwinSAFE Input Linking to TwinCAT Idea / Question

[WScottHicks]

I think most people who've used TwinSAFE with Control Plus will admit that using a TwinSAFE IO in the TwinCAT PLC is a bit of a hassle, and requires some extra effort.

I was trying to find ways to make this less painful and found I can add DigitalInput Channels to an FSOE Module and link the Safety Inputs like normal Digital Inputs.  The Safety Inputs are then usable in Control Plus without mapping Inputs in TwinSAFE.  This doesn't work for outputs, but it feels easier and less convoluted to me.

It seems to work, but does anyone know of a reason why this would be a bad idea?

As an example the EL1904 FSOES Safety Module could get the following addition.  (I think having the Parameter allows it to be a compatible change with existing projects.)

  <Parameters>
    <ParameterValue name="Input Linking Type" hierarchy="" refId="CFF8565D-0626-48B3-9344-87FEA4E40905" varType="STRING" textDe="Linking Type" textEn="Linking Type" initialValue="SafetyPLC" variable="FALSE"  >
      <Values>
        <Value textDe="Safety PLC"                textEn="Safety PLC"                value="SafetyPLC"/>
        <Value textDe="Local (and/or Safety PLC)" textEn="Local (and/or Safety PLC)" value="Local"/>
      </Values>
    </ParameterValue>
  </Parameters>
  <Channels>
    <Channel name="Channel 1">
      <Types>
        <Type name="DigitalInput" />
      </Types>
      <Condition refLink="CFF8565D-0626-48B3-9344-87FEA4E40905" comparator="EqualTo" value="Local"/>
    </Channel>
    <Channel name="Channel 2">
      <Types>
        <Type name="DigitalInput" />
      </Types>
      <Condition refLink="CFF8565D-0626-48B3-9344-87FEA4E40905" comparator="EqualTo" value="Local"/>
    </Channel>
    <Channel name="Channel 3">
      <Types>
        <Type name="DigitalInput" />
      </Types>
      <Condition refLink="CFF8565D-0626-48B3-9344-87FEA4E40905" comparator="EqualTo" value="Local"/>
    </Channel>
    <Channel name="Channel 4">
      <Types>
        <Type name="DigitalInput" />
      </Types>
      <Condition refLink="CFF8565D-0626-48B3-9344-87FEA4E40905" comparator="EqualTo" value="Local"/>
    </Channel>
  </Channels>
  <IoLinks>
    <BinIoLink channelName="Channel 1" tcIoName="TxPDO^FSOE^InputChannel1"/>
    <BinIoLink channelName="Channel 2" tcIoName="TxPDO^FSOE^InputChannel2"/>
    <BinIoLink channelName="Channel 3" tcIoName="TxPDO^FSOE^InputChannel3"/>
    <BinIoLink channelName="Channel 4" tcIoName="TxPDO^FSOE^InputChannel4"/>
  </IoLinks>

[SteffenR-]

It is not recommended to link the FSoE variables of FSoE slaves into the PLC. These FSoE signals not always represent the physical input. The FSoE communication between the logic terminal (EL6910 etc.) and the input terminal (EL1908 etc.) also runs via these FSoE variables. Maybe the signal is correct in 99% of the time, but if the machine shows wrong errors or has a wrong behaviour in 1% of the time, it is hard to find the reason.

If you have a standardized TwinSAFE configuration, you could create your own EL6910 peripheral that includes the suitable IO links. But if you don't have a standardized TwinSAFE setup, the current TwinSAFE configuration in CpStudio is really not good (too much effort, too many possibilites doing something wrong, IOs of IO terminals are not part of the IO terminal but the logic terminal => AML import does not work, etc.).

There were already some conceptual meetings with the Nexeed development team in the past. It would be possible that all IOs are part of the safety IO terminals in CpStudio (i.e. AML import works and EtherCAT diagnostic represents physical architecture) and the CpStudio IO linking links the EL6910 signals with the BinIo variable in the PLC. But this new feature has not yet been priorised by our development team. If you (or anybody else) is using TwinSAFE or ctrlX Safety and need an improved handling in Control plus Studio, give feedback in the forum or via Helpdesk.