2023.1.1571.2 Logic Component
Overview
A Logic Component enables the user to connect a Standard Component to an external PLC using a Logic Simulator.
A Logic Component consists of both component specific settings and general settings. For details of component specific settings (Properties & PLC outputs), look at the documentation of that specific Logic Component.
General Settings
This is the overview of the defined signals grouped by signal type (input, output and variable)
Here you see the defined name whenever you are in edit mode. In playmode you can send(write) inputs from the inspector if you enable allow manual input signals from inspector
The input field for a ulong is not supported by unity and is therefore (unfortunately) limited to the max value of long from the inspector
Signal Naming Settings |
|
---|---|
Signal Naming Rule Overrides | Allows you to customize the names of your Input/Output signals based on component instance settings |
Size | The number of different communication channels you wish to use for this component |
$ALL |
|
Rule Target | Describes the subset of signals this rule applies to. $ALL $INPUT $OUTPUT $VARIABLE [CUSTOM] |
Plc Address Path Format | The formatting for the PLC address path. Variables wrapped in double curly brackets are replaced on component instantiation |
Plc Path Separator | The separator character used in the hierarchical path for PLC addressing |
Instance Name Rule | The pattern used to replace |
Defining Prelogic Components
A simulator is used for the connection to the server. The components for connection the inputs and outputs.
The terms ‘INPUT’ and ‘OUTPUT’ are from the external source’s perspective.
From prespective’s perspective, it will write to the external’s INPUT and read from externals’s the OUTPUT.
Custom component
Create a new script that inherits from the PreLogicComponent (add the using u040.prespective.prelogic.component) :
Select implement missing members:
The most important part of making a custom component is to define the inputs and outputs. These are defined in the list of signal definitions.
Create a new list of signaldefinitions:
In this list we will define the individual IO’s .
A signal definition should consist of four base parts:
Name
The name to identify the IO
In our case ‘ModuleOK’
Direction
Wheter it is an input or an output
SignalType
Type of the signal
in our case BOOL as can be seen in the datatype in UA Expert
Base Value
Value on initialization. Not settings this might show unexpected null refs
which is an optional parameter called _onValueChanged:
Reading a Value
This is called whenever a value changed. Making a callback per IO is the most convenient.
You can do whatever you like with the value coming in. For example set an object’s field value. As you can see the callback type is an object. To use it, cast it to the correct type.
Writing a value
Writing values does not happen automatically. You need to connect this to an event or update it every frameupdate.
For example a UI element can run a void when clicked (set this on the UI element) or do this every simulation update.
You can do whatever you like with the value coming in. For example set an object’s field value. As you can see the callback type is an object. To use it, cast it to the correct type.
The WriteValue command takes an address and a value parameter. The IO_Name is stored in a variable to make sure that whenever a name changes, it is also changed in other functions like writing.
Code Overview
For reference, here is the complete script:
Prespective Documentation