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.
Signal Type | Description |
---|---|
PLCInputBool | A PLC Input which is a boolean value (true/false) |
PLCInputInt | A PLC Input which is an integer value (can be also a Byte, UInt, SInt … on the PLC-Side) |
PLCInputFloat | A PLC Input which is a float value (can be also double, single on the PLC-Side) |
PLCOutputBool | A PLC Output which is a boolean value (true/false) |
PLCOutputInt | A PLC Output which is an integer value (can be also a Byte, UInt, SInt … on the PLC-Side) |
PLCOutputFloat | A PLC Output which is an integer value (can be also a Byte, UInt, SInt … on the PLC-Side) |
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:
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.
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.
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 | [ ] |
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:
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 | public void SignalChangedEditor(Signal signal) |
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 | void Start() |