Guidelines and compatibility

Backward compatibility is always considered in the development of the Plastic Base Application. On the other hand, changes that involve the removal of old items are only handled as an addition. This means that items that are renamed, changed, or redesigned are always added to the project, and the old version remains in the project with the "Obsolete" label. However, updates with new features and items can conflict with the existing end application. It is recommended that you follow the following guidelines to ensure compatibility:

Prefixes

In the Plastic Base Application, internal variables of a class are given a data type-dependent prefix. This allows a distinction to be made between variables and properties. A list of the usual prefixes can be found in the TE1000 XAE PLC documentation. The following prefixes are used differently to this definition:

Type	Prefix	Instead of	Description	Declaration example(s)
`INTERFACE`	`i`	`ip`	Instance of a safely assigned interface. An interface for `Cyclic()` methods is safe if a check is performed by the `Init()` method.	`iCylinder: I_Cylinder;`
`INTERFACE`	`iq`	`I`	Instance of an optionally assigned interface. This must be checked for <> 0 before each access in a `Cyclic()` method.	`iqOption: I_Option;`
`WORD`	`w`	`n`	Instance of a bitwise coded integer	`wStatus: WORD;`
`GVL`	`-` (none)	`GVL_`	Global variable list as declaration space for global instances (e.g.:)	`Carriage.` `Temperature.` `HmiCommunication.`

Use of a property

Properties in object-oriented PLC programming consist of a Get and a Set method. In principle, this means that each property could also be programmed using two methods. For this reason, the Plastic base application defines some scenarios for selecting the action object to be used:

Scenario	Sample	Note
Access to an actual state	`fbObject.ActValue` (Get)	Actual values can only be read
Access to a setting value	`fbObject.Parameter` (Get, Set)	Parameters can be read and (possibly conditionally) written
Access to a sub-object	`fbObject.SubObject` (Get) `fbObject.SubObject.Property`	Access to sub-objects is controlled via `INTERFACE`. It must be guaranteed that the returned `INTERFACE` is set (`fbObject.SubObject <> 0`).
Interface to the HMI	`fbObjectHmi.Value` (Get) `fbObjectHmi.Parameter` (Get, Set) `fbObjectHmi.Cmd` (Get, Set)	Properties offer the option of calculating values for the HMI according to requirements. This eliminates the need to copy values, especially for use in the HMI.

The following guidelines should be considered in all scenarios:

The basic rule for Plastic Base Application properties is that they represent passive access to an object. This means that a Set or Get should not result in any immediate action.
If a property is to be used to access a structured sub-object, the property must allow reference access. It must be ensured that a valid instance is always returned for this reference access.
Since no prefix is used when naming a property, the data type of the property can be specified by using a specific name. Samples:

Has, Is or Enable indicates a Boolean property.
Number, Idx, ID indicates an integer property.
Value indicates a floating point property.
Name indicates a string property.
_Property indicates a property reserved for internal purposes.

Adding the attribute {attribute „monitoring“ := „call“} to the declaration of a property allows the current value of the property to be displayed live in the PLC's online view. This attribute is also a prerequisite for accessing a property from the HMI.
As obsolete variables are converted to properties, address accesses to the variables of a class should be avoided. In this case, an address access would cause a compilation error and a necessary change.

	Deviations from the guidelines possible Different usage scenarios may occur in the Plastic Base Application for practical and/or historical reasons. The following cases, for example, were selected for simplification (practicability): FB_Motion`.Motion` and FB_Axis`.Axis`, which can return access to any unset `INTERFACE`s. FB_Monitoring`.Input` and FB_Setpoint`.Output`, which expect optional I/O elements as properties.

Use of a method

In contrast to the properties of the Plastic Base Application, methods are fundamentally used for triggering active functions. Accordingly, a list of scenarios can also be compiled for methods:

Scenario	Sample	Note
Executing a command	`fbObject.DoSomething(bCmd)`	A command can be actively enabled and disabled by passing a `bCmd` flag.
Call for a one-time action	`fbObject.Clear() fbObject.Init()`	This type of method is designed for an event-based (one-time) call.
Index-based access to a sub-object	`fbObject.SubObjects(i) fbObject.SubObjects(i).Property`	Access to sub-objects is controlled via `INTERFACE`. It must be guaranteed that the returned `INTERFACE` is set (`fbObject.SubObjects(i) <> 0`). In addition, a method can be used to prevent the index limits from being exceeded.
Cyclic processing	`fbObject.Cyclic()`	Cyclic program code whose cyclic call can also be carried out via a `INTERFACE`.
Cyclic subroutines	`fbObject._SubRoutine()`	Division of the cyclic program code into individual routines. These methods can only be called within the class and inheriting classes using the access modifier `PROTECTED`.
Help Functions	`fbObject._DetermSmth()`	Class-internal auxiliary functions avoid multiple occurrences of identical code. A method with the access modifier `PROTECTED`, which can only be called within the class and inheriting classes, is used for this purpose.
Initializing a reference	`fbObject.SetRef(iObj)`	Enables a successful reference initialization to be checked.