Automation Interfaces

Overview

Automation Interfaces handle the communication between real or virtual automation controllers. For each type of communication, a special interface is required. The interfaces currently available are for Siemens S7 (S7-300,400,1200,1500,Sinumerik, Simotion), Simit, PLCSim-Advanced (the virtual Siemens S7 1500 PLC) and OPC-UA.

All interfaces are using standard PLCInput and PLCOutput objects (like PLCInputFloat or PLCOutputBool) for storing signal values. The Interface itself handles the real-time values of the signals. Some interfaces provide the ability to import all signals automatically and to create the suitable PLCInput or PLCOutput objects in the realvirtual.io hierarchy automatically. Sometimes the signals can be imported by communication with the controller itself, or sometimes a signal list used for programming the automation controller can be exported and used. Imported signals can be automatically connected to realvirtual.io signal objects by the (SignalManager).

The Signals are connected to the input and output properties of the Behavior Models.

This tutorial explains the relation between Signals and Behavior Models:

The following Signal types are supported by all Interfaces. In most cases the PLC itself can support more data types. For example Signed Int and Unsigned Int, are all transfered to the corresponding base type in realvirtual.io.

Check Signal status and connections to Behavior models

You can check all signals in the Hierarchy view of your model:

PLCInputs are shown in red and PLCOutputs are shown in green. All signals which have not been connected to realvirtual.io behavior models (this means all signals, which are currently not controlling the model or are not getting any information from the model) are shown in brackets.

It is possible to check on the Signal component itself the connected Behavior models in the section Signal Connection Info:

Forcing (overriding) signals

Signals can be forced to a certain value. By doing this, all connected components receive the forced value and not the value of the current input or output. Signals can be forced by setting Settings>Override in the Signal to true. The value is now defined by the Value you define in Value Override. Forced signals are always displayed in italic letters.

Connecting Signals

To connect two signals you can use Connect Signals. The two signals must be of same datatype but it does not matters if they are input or output.

In this example an InputFloat is connected to an Output Float. The signal value of the connected signal is transfered to the current signal.

Signal Events

Signals in Behaviour Models

Usually Signals should be used by Behavior Models which are defined by a script.
In the Behaviour model references are used to identify the signals which are attached to the Behavior Model. Here is a simple example of a Behavior Model which can be attached to a Sensor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

[RequireComponent(typeof(Sensor))]
  //! The Sensor_Standard component is providing the Sensor behavior and connection to the PLC inputs and outputs.
  public class Sensor_Standard : BehaviorInterface
  {
     
      [Header("Settings")] public bool NormallyClosed = false;  //!< Defines if sensor signal is *true* if occupied (*NormallyClosed=false*) of if signal is *false* if occupied (*NormallyClosed=true*)
      [Header("Interface Connection")] public PLCInputBool Occupied; //! Boolean PLC input for the Sensor signal.

      private Sensor Sensor;
      
      // Use this for initialization
      void Start()
      {
          Sensor = GetComponent<Sensor>();
      }

      // Update is called once per frame
      void Update()
      {
          bool occupied = false;
      
          // Set Behavior Outputs
          if (NormallyClosed)
          {
              occupied = !Sensor.Occupied;
          }
          else
          {
              occupied = Sensor.Occupied;
          }

          // Set external PLC Outputs
          if (Occupied != null)
              Occupied.Value = occupied;

      }
  }

The public variable public PLCInputBool Occupied acts as referene to the Input Signal. Because the Sensor Behavior Model is attached to a GameObject with the Sensor base model also attached to it can get a reference to the sensor. In the Update cycle the Behavior Model is transferring the status between the Signals and the Sensor base object itself. Behavior Models give you the flexibility to program different behaviors and to still use the same base objects.

You can see the relations in this picture:

Unity Events and Signals

You can receive Unity Events as soon as a signal is changed. To do so you can select in the Unity Editor a method on each signal which should be called once the signal is changing it’s status:

The method which is called receives as a parameter the Signal. The method must be defined like this:

1
2
3
4

public void SignalChangedEditor(Signal signal)
     {
         Debug.Log("Signal Changed Editor " + signal.ToString());
     }

Subscribing for Signal changed events in a method

Another alternative is to subscribe to the Signal changed events in a method. You want see anything in the Unity Editor if you do so. The subscription is done each time Unity is starting the simulation. Here is an example:

1
2
3
4
5
6
7
8
9
10
11
12

void Start()
    {
        // Register Event During Runtime
        var com = GetComponent<PLCInputBool>();
        com.SignalChanged += SignalChangedRuntime;
    }

 
    public void SignalChangedRuntime(Signal signal)
    {
        Debug.Log("Signal Changed Runtime " + signal.ToString());
    }