BuR Library Design Guidelines

B&R Library
Design Guidelines
Version 2.00
B&R Library
Design Guidelines
V2.00
Copyright © B&R – Subject to change without notice March 5, 2015

BuR Library Design Guidelines.docx 0/29
B&R Library Design Guidelines
I Versions
Version Date Comment Edited by
1.20 Mar 14, 2014 Release
2.00 Mar 10, 2015 Second Edition
Table 1: Versions
Copyright © B&R - Subject to change without notice March 5, 2015

B&R Library Design Guidelines
II Table of Contents
1 Motivation.................................................................................................................... 3
2 Vision ........................................................................................................................... 3
3 Objectives ................................................................................................................... 3
4 PLCopen guidelines ................................................................................................... 4
5 Terminology ................................................................................................................ 4
6 Rules ............................................................................................................................ 5
6.1 Naming conventions ............................................................................................................................. 5
6.1.1 General information......................................................................................................................................... 5
6.1.2 Libraries, Function blocks, Functions, Variables, Type definitions .................................................................. 6
6.2 Function blocks ..................................................................................................................................... 8
6.3 Functions............................................................................................................................................. 13
6.4 Enable/Execute behavior and status information ............................................................................... 14
6.5 Parameter ........................................................................................................................................... 20
6.6 User specific commands ..................................................................................................................... 22
6.7 Error handling...................................................................................................................................... 24
6.8 Strings ................................................................................................................................................. 25
6.9 Cycle time violations and memory allocation ...................................................................................... 25
7 Compatibility ............................................................................................................. 26
8 Libraries for redundant systems ............................................................................. 27

8.1 Introduction ......................................................................................................................................... 27
8.2 Labels .................................................................................................................................................. 27
8.2.1 Examples ...................................................................................................................................................... 28
8.3 Data tracking ....................................................................................................................................... 28
8.3.1 Data not to be tracked ................................................................................................................................... 29
8.3.2 Context based redundancy capability ........................................................................................................... 29
8.4 Active changes .................................................................................................................................... 29
8.5 Not capable of redundancy ................................................................................................................. 29

B&R Library Design Guidelines Motivation
1 Motivation
Software technology in Automation Studio from the user's point of view is largely shaped by librar-
ies. As a result, the terms technology and libraries are significantly interrelated or even often used
synonymously.
How these libraries are designed will therefore influence the user's experience when interacting
with these products and ultimately justifies the need for shared guidelines.
Guidelines create standards and also help to maintain quality in time-

critical situations
2 Vision
These guidelines are intended to support the development of software technology so that it...
• is easy to understand
• can be configured and put into operation as intuitively as possible
• is of the highest possible quality
Complex technologies should be easy to understand and quick to use
3 Objectives
The objective of these guidelines is to optimize the quality of the user experience by ensuring...
• a uniform appearance in Automation Studio

• a common and user-friendly operating concept
• standardized interfaces
In addition, software quality should also be improved through the use of...
• a library template with testing environment in accordance with these guidelines

• defined function block behavior
• specifications that promote the reusability of code

B&R Library Design Guidelines PLCopen guidelines
4 PLCopen guidelines
These Guidelines are strongly related to existing

PLCopen guidelines.
Of course, if PLCopen guidelines already exist in cer-

tain areas, e.g. motion control, safety, OPC UA, they
must be preferably used.
5 Terminology
The following section will define some of the most important terms concerning libraries.
B&R Technology Libraries

IEC libraries in Automation Studio which are tailored to a specific area of technology. Their ver-
sions are managed independently.
B&R Automation Runtime Libraries

IEC libraries that are considered part of Automation Runtime. Their version is inherited from the
respective Automation Runtime version.

B&R Library Design Guidelines Rules
6 Rules
6.1 Naming conventions
6.1.1 General information
ID Rules
6.1.1 Upper camel case must be applied for names if not defined differently.
6.1.2 Clear names for libraries, function blocks and variables.
6.1.3 In general abbreviations should be avoided.
Allowed abbreviations are listed below:
absolute abs function fcn numerator num

acceleration acc group grp object obj
actual act identifier ident parameter par
additive add index idx password pw
address adr interface if powerlink plk
column col length len position pos
command cmd manager mgr Positive pos
6.1.4 configuration cfg maximum max reference ref
continuous cont memory mem relative rel
count cnt message msg source src
deceleration dec minimum min standard std
denominator den negative neg velocity vel
device dev number nr
To resolve ambiguities, e.g. pos, it must be clear from the context which word is meant.
Otherwise the full name must be used.
Keywords which are typically used in several programming languages are not allowed to
be used for any names. Even not with changed upper/lower case.
6.1.5
Examples:
• Access, bit, case, else, if, exit, goto, int, return, static, void, while.
6.1.6 The abbreviation for function block(s) is FB.

6.1.2 Libraries, Function blocks, Functions, Variables, Type definitions
ID Rules
If a library is designed only for SG4 targets

6.1.7 • 10 characters can be used for the library name and
• 32 characters for function block names.
If a library is designed for SG4, SG3 and SGC targets, then only one library name shall be
defined. Here,
6.1.8
• 8 characters can be used for the library name and
• 9 characters are significant for the function block names.
Library names start with a defined prefix, namely
Ar Automation Runtime Library which is part of the Automation Runtime.

MT Mechatronic Library with Mechatronic background, e.g. open
and closed loop control, signal processing, simu-
6.1.9 lation,…
Gmc Generic Motion Control Library with Motion/CNC/Robotics background.
Mp mapp Library which is part of mapp technology.
Examples:
• MTBasics, MTFilter, GmcAcp10Ax, MpRecipe, MpData
Function block names are composed of the full library name and the function name.
6.1.10
Examples:
• MTBasicsDelayTime, MTFilterLowPass, MpRecipeXml, MpDataRecorder
Constant names start with the library prefix in lower case. The following name is written
in capital letters, single words are separated with “_”. Constant names are limited to 32
characters.
Composition of constant names:
6.1.11 Constants valid for more libraries: prefix + descriptive variable name
Constants valid for one certain library: library name + descriptive variable name
Examples:
• mtBASICS_POSITIVE_DIRECTION, mpRECIPE_ERR_INVALID_FILENAME

Structure types are written in Upper Camel Casing style and end with the name Type.
Composition of data type names:
Data types valid for more libraries: prefix + name + Type
Data types valid for one certain library: library name + name + Type
6.1.12
Data types valid for one function block: function block name + name + Type
Function block internal structures: function block name + Internal + Type
Examples:
• MTFilterParameterType, MpRecipeXmlHeaderType
Enumeration types are written in the same style as we have defined for structure types
in (6.1.12). The word Type is replaced by Enum.
6.1.13
Examples:
• MTFilterTypeEnum, MTBasicsPWMModeEnum, MpRecipeXmlLoadEnum
The enumeration type elements are written in the same style as we have defined for con-
stants in (6.1.11). These elements are limited to 32 characters, too.
6.1.14
Examples:
• mtPULSE_MIDDLE, mpRECIPE_XML_LOAD_HEADER

6.2 Function blocks
Function blocks can be characterized in the following way:
Enable/Execute input
An enable or an execute input are used to set the function block busy. These commands work to-
gether with some defined status information outputs. The exact behavior of these variables and
how they are used on the most suitable is described in section 6.3.
Internal memory
Function blocks may have an internal memory, see (6.2.10).
More than one return value

Function blocks may have more than one return values.
ID Rules
Each function block has an enable or an execute input with the corresponding standard
6.2.1
status information outputs. The interaction of these variables is described in (6.4).
6.2.2 Input and output variables are written in Upper Camel Casing style.
General Interface Structure
Basic parameters which

are essential for the Standard status
FB functionality information
6.2.3
Process inputs Process outputs
Commands and
parameters these Additional
commands need information

The parameter inputs

are applied internally at
Enable or Execute. These outputs
change when the
With Update a set of FB status changes
new parameters can be
applied afterwards.
These inputs are These outputs are

processed cyclically calculated cyclically
These inputs are

These outputs may
checked cyclically
change cyclically or
but only processed
in case of an event
when they change
A FB is divided into three parts:
• Upper part (orange)

o Only the commands Enable, Execute and Update are allowed to be used here.
o The identifier, if necessary, is always above enable or execute.
o A parameter structure is always above the corresponding update command.
• Middle part (grey)

o This part shows the flow of information.
• Lower part (white)

o Contains additional commands accompanied by the value the command
needs. These values are directly placed above the command input.
o The output variables provide further useful information.
More examples
6.2.4


6.2.5 When the FB is disabled all output variables are set to zero.
Optional parameters can be defined.

6.2.6 • Even if these parameters are not set the function block should work without error.
• Optional input and output variables are written in italics.
It is preferred that structures are directly integrated into the function block interface. If nec-
6.2.7
essary, pointers to structures are also allowed.
6.2.8 Parameters should be combined to one structure if it improves usability.
When Enable or Execute is set all parameters in the orange area are taken into account.
Update only acts on the parameters directly above.
6.2.9
A command is accompanied by the values the command needs. The values are written
above the command input.
6.2.10
Every function block has an internal structure called “Internal”. It contains data needed
6.2.11
while the function block is active. The structure type is defined according to (6.1.12).

6.2.12 Variables of this internal structure are also written in Upper Camel Casing.

6.3 Functions
Functions can be characterized in the following way:
• No Enable/Execute input
Functions are executed every function call.
• No internal memory
If information must be stored for the next function call, then a function block must be used
instead.
• Only one return value

If more than one value must be returned, e.g. result and error code, then a function block
must be used instead.
ID Rules
6.3.1 Variables are written in Upper Camel Casing style.
If functions have no return value they should return StatusID indicating the status of the
6.3.2
operation.
If functions have a useful return value they do not provide any StatusID. An error is indi-
6.3.3
cated by a “safe” return value.
Graphical representation
6.3.4
• Functions only have one orange area.

• ReturnValue is the only output variable.

6.4 Enable/Execute behavior and status information
Behavior of Enable
• The Enable command is level sensitive.
• This functionality shall be used to switch on and off the function block like a power supply.
When it is switched on additional commands shall be used to perform some action.
• It should not be used to short term stop the FB execution, e.g. when you want to hold a
control loop. A Hold command shall be used instead.
• Status outputs like Active show that the FB is switched on, initialized and ready to perform.
Behavior of Execute
• The Execute command is edge sensitive.
• This functionality shall be used to trigger a specific function or process. The FB is only exe-
cuted as long as this process is active.
• For the user it is important to know when the process ends. Therefore, status outputs like
Done are installed to show this event.
Why this approach makes sense
The advantage is that applications get easier to program and it allows a precise management of
command sequences to control machine actions.

ID Rules
Standard status information
• These status outputs are always related to an enable or execute input. Therefore,
they are located in the upper part (orange) of the FB interface (see 6.2.3).
6.4.1
• They have a defined hierarchy and functionality.
• They are always present as BOOL output, respectively.
Depending on the configuration the following standard status outputs must be used:
Execute
Enable
Status output Description
Is set when the command action has been success-

Done
fully completed.
This output can be used instead of Done. InXxx

stands for InVelocity, InPosition, InTorque, InSync…
InXxx
It is mutually exclusive to Done (only one can be pre-
sent) but has a different behavior.
The FB is working. It remains high as long as the FB

Busy
6.4.2 is performing any action.
The initialization is done. The FB inputs are control-

Active
ling the process.
The FB action started with Enable or Execute is inter-

CommandAborted
rupted by another command.
An error has occurred and an error code is indicated

Error
at StatusID/ErrorID. The FB is in error state.
mandatory optional not allowed
It is important that this order from top to down must be maintained at the FB outputs.

The usage of Busy – Active
A Busy – Active combination makes sense when e.g. the FB works together with a hard-
ware where it needs time to initialize and to shut down this device. Another case is when
an asynchronous process is executed in the background for some initialization purpose.
6.4.3
1…Initialization
2…Exit
It is also possible to use Active without Busy. One such example would be a simple FB
running on the PLC only, e.g. MTFilterLowPass.
6.4.4
Here, no initialization or exit procedure is necessary.

Usage of Enable – Errors that can be automatically cleared
6.4.5
Case1: Error is cleared automatically

Case2: Disable procedure with active error
Case3: Disable procedure when there is no error
Usage of Enable – Errors that cannot be automatically cleared
6.4.6

Usage of Execute – Done
6.4.7
Case1: FB execution is aborted

Case2: An error occurs
Case3: The FB has finished successfully
1…If Execute is reset before these outputs are set, they remain high only for one cycle.
• The outputs Busy/Active – Done – Error – CommandAborted are mutually exclu-

sive. This means only one of them can be high.
• Done can also be used to reset Execute. This kind of handshake is frequently used
in many applications.

Usage of Execute – InXxx
6.4.8
Case1: FB execution is aborted

Case2: An error occurs
Case3: The FB is working without error
1…If Execute is reset before these outputs are set, they remain high only for one cycle.
• The outputs Busy/Active – InXxx – Error – CommandAborted are mutually exclu-

sive. This means only one of them can be high.

6.5 Parameter
Definition
• Parameters are used to identify a characteristic, a feature, a measurable factor that helps to
define a system.
• Parameters are constant values. They only change internally when confirmed by a certain
command like Enable, Update, SetOut.
ID Rules
Parameter check at Enable
An error during an update procedure together with the command Enable is treated like an
error that cannot be automatically cleared (see 6.4.6).
6.5.1
Case1: Parameter check fails directly when Enable is set

Case2: An error occurs during the parameter update procedure
Case3: Parameter check successful
1…Sometimes the update procedure takes more than one cycle. Especially, when hard-
ware or asynchronous functionalities are involved.

Parameter check at Update
6.5.2
Case1: Parameter check fails directly when Update is set

Case2: Parameter check successful – Update command is reset after update procedure has finished
Case3: Parameter check successful – Update command is reset immediately
1…If Update is reset before UpdateDone is set, it remains high only for one cycle.
• UpdateDone can also be used to reset Update. This kind of handshake is frequent-
ly used in many applications.

6.6 User specific commands
In the white part of a function block user specific commands may appear. To make sure that these com-
mands have the same functionality three command classes are defined below.
ID Rules
The following pool of command names which are associated with frequently used func-
tionalities should be used.
6.6.1
Power Hold
Home Reset
Stop QuickStop
Command class – edge sensitive
6.6.2
Typical applications:
• Action with fixed execution time.
• No feedback necessary that command execution has finished.
Examples:
• Set or reset of an output variable

Command class – level sensitive
6.6.3
Typical application:
• Action that is started and stopped with the same command.
Examples:
• Keep the output variable constant as long as command is set.
Command class – edge sensitive with handshake
6.6.4
1…If Command is reset before CmdDone is set, it remains high only for one cycle.
Typical applications:
• Action that is started with a certain command, maybe its duration is unknown and it
is important to know when its execution has finished successfully.
Examples:
• Start of a tuning procedure.

6.7 Error handling
ID Rules
6.7.1 An error is indicated by the output Error of type BOOL.
6.7.2 All FB of a library must have either StatusID or ErrorID.
6.7.3 It is not allowed to use StatusID and ErrorID for one FB.
The error identification is written to StatusID or ErrorID. This number is given as DINT
value. Its 32 bit format is as follows:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Sev C R Facility Code
Sev – Severity Code:

• 00 = Success
• 01 = Informational
6.7.4 • 10 = Warning
• 11 = Error
C – Customer: 0 = B&R, 1 = Customer

R – Reserve
Facility – indicates the area this error number belongs to
Code – error code
6.7.5 StatusID combines error, warning and any other information identification.
6.7.6 ErrorID only shows error identification.
Constants should be used to represent error or status numbers. Here, the notation is ac-
cording to (6.1.11). A constant name which represents an error number should contain the
abbreviation ERR, warnings the abbreviation WRN.
6.7.7
Examples:
• mpRECIPE_ERR_INVALID_FILENAME , mtERR_INVALID_PARAMETER,
mtBASICS_WRN_OUTPUT_IN_SATURATION.
6.7.8 When the FB is disabled StatusID or ErrorID show the value 0.

6.8 Strings
ID Rules
6.8.1 Each given string must be a null-terminated string.
If a string should be written into a given buffer and the buffer size is too small, an addition-
6.8.2
al output variable beside the ErrorID shall indicate the necessary buffer size.
6.9 Cycle time violations and memory allocation
ID Rules
To avoid cycle time violations function calls that may lock the system are not allowed.
Examples:
• Access to AR-registry
• Access to protected resources
6.9.1
• Usage of device open
• Usage of malloc
• Access to areas that are protected by semaphores
One way to avoid this problem is to use the Asynchronous function call manager (Asy-
fuma).
Allocation and deallocation of memory in the cyclic part of a function block is not allowed
because it causes memory fragmentation.
6.9.2 This problem can be avoided in the following ways:
• Memory allocation in the init-part of a library.

• Provide it as input buffer that is given by the user.
6.9.3 If memory is provided by the user, its size must also be given as an input value.

B&R Library Design Guidelines Compatibility
7 Compatibility
Interface of a function block
The interface of a function block is defined by its input and output variables as well as by the varia-
bles of the internal structure (see 6.2.11).
Changes to an existing library can be classified as follows:
Compatible changes
The interface and functionality of the function blocks are not affected by the change.
Examples:
• Adding functions and/or function blocks to the library
• Adding data types or constants
Incompatible changes
The interface or the functionality of the function blocks are affected by the change.
Incompatible changes may require the application to be modified, which in turn requires a new
Build. This may take a considerably longer amount of time.
Examples:
• Changes to the name
o of a function or function block
o of input or output parameters
o of data types or constants
• Changes to the value of a constant
• Any changes to the internal variables
ID Rules
7.0.1 Only compatible changes must be made to Automation Runtime specific libraries.
Incompatible changes can be made to B&R standard libraries. However, any such chang-
es must be clearly communicated to the user. One possible way to denote an incompatible
library change is by adjusting the version number accordingly.
V 0.xx.x Versions prior to first official release.

7.0.2 V x.xx.9 Test version, only for unofficial test purposes.
V x.xx.x Guaranteed compatible changes, small bug fixes.
V x.xx.x Guaranteed compatible changes, small bug fixes, functional extensions.
V x.xx.x Changes may be incompatible. Please, read release information.
V x.xx.x Changes may be incompatible. Please, read release information.

B&R Library Design Guidelines Libraries for redundant systems
8 Libraries for redundant systems

8.1 Introduction
There are three important things to consider for libraries that will be used in redundancy projects:
Labeling for cyclic tracking

This copies the contents of all labeled PVs from a task class on the active controller to the standby
controller each time processing is finished on the active controller. Because instances of function
blocks can be PVs, function blocks must be labeled for tracking.
Changes to the function blocks

Some function blocks require a definite change in order to be useful in the context of a redundant
system. This includes function blocks that can only be run on the active controller, i.e. they will re-
turn an error code when called on the standby controller.
Inappropriate for use

Some functions and function blocks are inappropriate for use in redundant systems. These must
be labeled as such and cause error messages.
8.2 Labels
The label indicating whether a PV should be synchronized or if a library or function block is capable
of redundancy is done using pragmas in the .fun file. The following pragmas are available:
Pragma Description
Labels the variables, structures or function blocks that will

REDUND_REPLICABLE
be synchronized.
Labels the variables, structures or function blocks that will

REDUND_UNREPLICABLE
not be synchronized.
Labels a function block or function for unrestricted use in

REDUND_OK
redundant configurations.
Labels a function block or function for restricted use in

REDUND_CONTEXT redundant areas. Behavior may differ on the active and
inactive controller depending on the operating phase.
Labels a function block or function that cannot be used in

REDUND_ERROR
a redundant configuration.
In essence, only variables that are not being synchronized must be labeled.

8.2.1 Examples
FUNCTION_BLOCK fun1
VAR_INPUT
var_in_01 : {REDUND_REPLICABLE} INT;
var_in_02 : {REDUND_UNREPLICABLE} USINT;
var_in_03 : USINT;
END_VAR
VAR_OUTPUT
var_out_01 : {REDUND_UNREPLICABLE} USINT;
var_out_02 : USINT;
END_VAR
VAR_IN_OUT
var_inout_01 : INT;
var_inout_02 : {REDUND_UNREPLICABLE} USINT;
var_inout_03 : USINT;
END_VAR
VAR
var_01 : {REDUND_UNREPLICABLE} USINT;
var_02 : USINT;
END_VAR
END_FUNCTION_BLOCK
{REDUND_OK} FUNCTION_BLOCK CfgGetIPAddr

VAR_INPUT
enable : BOOL;
pDevice : {REDUND_UNREPLICABLE} UDINT; (* pointer *)
pIPAddr : {REDUND_UNREPLICABLE} UDINT; (* pointer *)

Len : USINT;
END_VAR
VAR_OUTPUT
status : UINT;
END_VAR
VAR
i_state : UINT; (*internal variable*)
END_VAR
END_FUNCTION_BLOCK
8.3 Data tracking

In principle, data tracking is only necessary for function blocks. Functions have no memory and
can therefore be ignored in this regard.

8.3.1 Data not to be tracked
• PV elements that are only relevant locally (i.e. pointers, handles, idents, etc) are not permit-
ted to be tracked at all.
• These elements are not to be tracked in connection with function blocks that return data as
a result or as a temporary value that can or should be different on the two controllers. One
such example of this would be the amount of available memory.
8.3.2 Context based redundancy capability

Functions or function blocks that are not automatically capable of redundancy may still be capable
of redundancy based on context. In principle, this applies to functions that could provide different
results on the two controllers within a specific system tick. The user must ensure that hot redun-
dancy is maintained on the system when using these function blocks. They are labeled with the
pragma {REDUND_CONTEXT}.
8.4 Active changes

If it only makes sense to execute a function or function block in a redundant system on the active
controller, then a corresponding query must be added to the source code.
8.5 Not capable of redundancy

Any function or function block whose activation in the context of a redundant system leads to a loss
of synchronization between the controllers must be forbidden. This is done by labeling the function
or function block as not capable of redundancy using the pragma {REDUND_ERROR}. One such
example of this would be functions that change the system configuration.


BuR Library Design Guidelines

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BuR Library Design Guidelines

Încărcat de

Drepturi de autor:

Formate disponibile

B&R Library

Copyright © B&R – Subject to change without notice March 5, 2015

Copyright © B&R - Subject to change without notice March 5, 2015

4 PLCopen guidelines ................................................................................................... 4

8 Libraries for redundant systems ............................................................................. 27

Copyright © B&R - Subject to change without notice March 5, 2015

Guidelines create standards and also help to maintain quality in time-

Complex technologies should be easy to understand and quick to use

• a uniform appearance in Automation Studio

• a library template with testing environment in accordance with these guidelines

Copyright © B&R - Subject to change without notice March 5, 2015

These Guidelines are strongly related to existing

Of course, if PLCopen guidelines already exist in cer-

B&R Technology Libraries

B&R Automation Runtime Libraries

Copyright © B&R - Subject to change without notice March 5, 2015

6.1.1 General information

6.1.2 Clear names for libraries, function blocks and variables.

6.1.3 In general abbreviations should be avoided.

Allowed abbreviations are listed below:

absolute abs function fcn numerator num

6.1.6 The abbreviation for function block(s) is FB.

Copyright © B&R - Subject to change without notice March 5, 2015

6.1.2 Libraries, Function blocks, Functions, Variables, Type definitions

If a library is designed only for SG4 targets

Library names start with a defined prefix, namely

Ar Automation Runtime Library which is part of the Automation Runtime.

Composition of constant names:

Copyright © B&R - Subject to change without notice March 5, 2015

Composition of data type names:

Data types valid for more libraries: prefix + name + Type

Copyright © B&R - Subject to change without notice March 5, 2015

6.2 Function blocks

Function blocks can be characterized in the following way:

More than one return value

General Interface Structure

Basic parameters which

Process inputs Process outputs

Copyright © B&R - Subject to change without notice March 5, 2015

The parameter inputs

These inputs are These outputs are

These inputs are

A FB is divided into three parts:

• Upper part (orange)

• Middle part (grey)

• Lower part (white)

Copyright © B&R - Subject to change without notice March 5, 2015

Copyright © B&R - Subject to change without notice March 5, 2015

Optional parameters can be defined.

6.2.8 Parameters should be combined to one structure if it improves usability.

Copyright © B&R - Subject to change without notice March 5, 2015

Copyright © B&R - Subject to change without notice March 5, 2015

Functions can be characterized in the following way:

• Only one return value

6.3.1 Variables are written in Upper Camel Casing style.

• Functions only have one orange area.

Copyright © B&R - Subject to change without notice March 5, 2015

6.4 Enable/Execute behavior and status information

• The Enable command is level sensitive.

• The Execute command is edge sensitive.

Why this approach makes sense

Copyright © B&R - Subject to change without notice March 5, 2015

Standard status information

• They are always present as BOOL output, respectively.