Member of: KNX Association | OPC Foundation
BACnet Interest Group Europe
Document Version: 1.0.1
Contents
1. Product description
1.1. Disambiguation . . . .
1.1.1. Block . . . . . .
1.1.2. Command . . .
1.1.3. Command flow .
1.1.4. Command logic
1.1.5. Connectors . . .
1.1.6. Inputs . . . . . .
1.1.7. Parameters . . .
1.1.8. Outputs . . . . .
1.1.9. Work sheet . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
6
6
6
6
6
6
6
6
6
2. System overview
2.1. Opening the XLogic Editor and creating a command . . . . . . . . . . . . .
2.2. Defining the command flow . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Defining the command logic . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. CMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2. IF THEN ELSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3. CMD BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4. GOTO and GOTO MARKER . . . . . . . . . . . . . . . . . . . . . .
2.3.5. COMMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. Compiling the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5. Executing an XLogic command . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1. Adding an XCommand definition within the NETx BMS Server Studio
2.5.2. Execution in BMS Studio . . . . . . . . . . . . . . . . . . . . . . . .
2.6. Transferring XCommands and creating backups . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
9
9
10
10
11
11
11
12
13
3. Examples
3.1. Lock object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1. Creating the command . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Command flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Verifying the lock object . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4. Writing the output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5. Saving the command and using the command within the NETx BMS Server
3.1.6. Improving the command by testing the quality of the lock object . . . . . . .
3.2. Limit Item Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Creating the command . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2. Command flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3. Check if input value is good . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4. Check the value range . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5. Check if output is set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.6. Writing the output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.7. Check if email address is set . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.8. Send email to configured address . . . . . . . . . . . . . . . . . . . . . . .
3.2.9. Saving the command and using the command within the NETx BMS Server
3.3. Delayed Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1. Creating the command . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. Command flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3. “Process input” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3.1. “Edge detection” . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3.2. “Is edge detected?’ . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3.3. “Set counter’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3.4. “Is output false?’ . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3.5. “Write true to output’ . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4. “Process output” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4.1. “Is counter 0?’ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
14
15
16
16
17
19
19
19
20
20
21
22
22
22
23
25
25
26
26
27
27
28
28
28
28
29
XLogic Editor 1.0.1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Page 2 of 36
3.3.4.2. “Is output true?’ . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4.3. “Write false to output’ . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4.4. “Decrement counter’ . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5. Saving the command and using the command within the NETx BMS Server
4. Predefined commands
4.1. ADD . . . . . . .
4.1.1. Summary .
4.1.2. Inputs . . .
4.1.3. Outputs . .
4.1.4. Parameters
4.2. AND . . . . . . .
4.2.1. Summary .
4.2.2. Inputs . . .
4.2.3. Outputs . .
4.2.4. Parameters
4.3. DELAYED OFF .
4.3.1. Summary .
4.3.2. Inputs . . .
4.3.3. Outputs . .
4.3.4. Parameters
4.4. DIV . . . . . . . .
4.4.1. Summary .
4.4.2. Inputs . . .
4.4.3. Outputs . .
4.4.4. Parameters
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
32
32
33
33
33
33
33
34
34
34
34
34
34
34
35
35
35
35
35
A. Appendix
36
A.1. Support and contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
XLogic Editor 1.0.1
Page 3 of 36
Copyright
This published handbook refers to the release of XLogic Editor 1.0. The
software is published by NETxAutomation Software GmbH, Maria–Theresia–
Straße 41, Top 10, 4600 Wels, Austria.
© Copyright by NETxAutomation Software GmbH, 2015. The correct and
usable documentation can only be guaranteed in connection with the regulations of the software agreement. Changes regarding the size of the function
volume of the mentioned software can be done and may not involve a change
of the documentation.
All rights are reserved. Copies, translations, micro filming and the storage
and processing in data processing systems are copyrighted. No part of this
publication may be reproduced without the prior permission of the publisher
NETxAutomation Software GmbH.
XLogic Editor 1.0.1
Page 4 of 36
1. Product description
XLogic Editor 1.0
The XLogic Editor is a graphical editor for implementing control functionality within the NETx BMS Server. The
defined logical functions are able to access and process the available data and functions of the NETx BMS Server.
For example, it is possible to read or write server items, send emails, access the current status of the server, or
invoke LUA functions. There are a range of predefined command blocks available for the user that cover a multitude
of applications.
XLogic Editor 1.0.1
Page 5 of 36
1.1. Disambiguation
1.1.1. Block
A block is a single component that is placed on the work sheet within the XLogic Editor. Blocks are used to define
the command logic and the command flow. Blocks have so called connectors that are used to connect blocks to
each other.
1.1.2. Command
A command or also called XCommand is a control logic that is used within the NETx BMS Server for extending
the existing control functionality of the building automation system. The XLogic Editor is a graphical editor for
implementing a command. The implementation itself consists of the command logic and the command flow.
1.1.3. Command flow
The command flow defines the sequence of executing the blocks within the command.
1.1.4. Command logic
The command logic specifies the control functionality that shall be implemented by a command. In addition to
perform mathematical operations and calculations, it is possible to access and process the available data and
functions of the NETx BMS Server. For example, a server item can be read or written, the current status of the
server status can be accessed or LUA functions can be invoked.
1.1.5. Connectors
In order to define the command flow, blocks have so called connectors that are used to connect blocks to each
other.
1.1.6. Inputs
Inputs provide the data point values that shall be processed within the control logic of the command.
1.1.7. Parameters
Parameters provide additional input values for commands. A parameter has a certain data type which has to be
specified by the user. A parameter can also be of type “ITEM ID”. However, the difference between an input and a
parameter of type “ITEM ID” is that a change of value of an input triggers the execution of command while a change
of value of a parameter does not trigger the command.
1.1.8. Outputs
Outputs are used to store the results of the command into data points.
1.1.9. Work sheet
The work sheet is the area within the main window of the XLogic Editor where the blocks are placed.
XLogic Editor 1.0.1
Page 6 of 36
2. System overview
2.1. Opening the XLogic Editor and creating a command
The XLogic Editor can get started by clicking on the “XLogic” icon in the toolbar of the NETx BMS Server Studio. To
create a new project within the XLogic Editor, the entry “new Command ...” of the “File” menu has to be selected.
The following parameters have to be set within the dialog:
Name The name of the new command. This name is later shown in the NETx BMS Server.
IN By clicking on the “+ INPUT Item” button, inputs can be added to the command. An input is always a server item
that has to be specified in the XCommand definition within the NETx BMS Server. The inputs provide the
data point values that shall be processed within the control logic of the command.
OUT By clicking on the “+ OUTPUT Item” button, outputs can be added to the command. An output is always a
server item that has to be specified in the XCommand definition within the NETx BMS Server. Outputs are
used to store the results of the command into data points.
PARAMS By clicking on the “+ PARAMETER” button, parameters can be added to the command. A parameter has
a certain data type1 that has to be specified by the user. Parameters have to be specified in the XCommand
definition within the NETx BMS Server.
After having confirmed the settings by pressing the “OK” button, the user can start with the development of the
command. At the left side of the window the “XLogic Catalog” appears. It lists all available functional blocks for the
actual context. The work sheet is visible in the main window of the program and can be used to place blocks and
connect them to each other. Below this window there is another panel available which shows general information
like system messages or help information.
2.2. Defining the command flow
The first step in the development of new command is to define its command flow. The command flow defines the
overall behavior of the command and can be defined in the work sheet that is opened after the command is created.
Starting from the “CMD HEADER” block located at the left of the work sheet a continuous flow to the “CMD END”
block has to be specified. This flow consists of the following blocks:
•
•
•
•
•
•
“CMD”
“IF THEN ELSE”
“CMD BLOCK”
“GOTO”
“GOTO MARKER”
“COMMENT”
Figure 2.1 shows an example for a command flow.
Figure 2.1.: Command flow
1
A parameter can also be of type “ITEM ID”. However, the difference between an input and a parameter of type “ITEM ID” is that a change of value
of an input triggers the execution of command while a change of value of a parameter does not trigger the command.
XLogic Editor 1.0.1
Page 7 of 36
2.3. Defining the command logic
The logic of a command is implemented by the different blocks. As mentioned in the previous section, six different
basic block types are available: “CMD”, “IF THEN ELSE”, “CMD BLOCK”, “GOTO”, “GOTO MARKER”, and
“COMMENT”.
2.3.1. CMD
“CMD” blocks are used to implement command logic that not only reads data and information but also processes it
and executes actions. Therefore, each “CMD” block has exactly one block that executes an action. An action can
be, for example, changing an output data point, sending an email, writing some logging information, changing an
internal variable, or executing a LUA function. Each “CMD” block has one incoming connector “PREV” which is
used to connect the previous block within the command flow and one outgoing connector “NEXT” which defines the
next block in the command flow.
To define the logic of the “CMD” block, the first field within the block has to be selected using a double click.
Afterwards, a new work sheet is opened where the logic can be implemented. Within the object catalog at the
left hand side of the work sheet, the different blocks that can be used to implement the control logic are listed.
These blocks are divided into four categories: “Values”, “Commands”, “Functions”, and “Tools”. Figure 2.2 shows
an example of a “CMD” block which is described in the following.
Figure 2.2.: “CMD” block
Blocks from the category “Values” are used to define constant values. Within the shown example, the block
“NUMBER” defines a constant number. To set the value of the constant, the first field within the block has to be
selected using a double click.
Blocks from the category “Commands” are used to execute the action within “CMD” block. There can only be one
such block within a “CMD” block2 . Within the shown example, the “WRITE OUTPUT ITEM” block within the sub
category “InOut/Output Item” is used to change the data point value of an output and to forward the value to the
fieldbus. To select the output that shall be changed, the first field within the block has to be selected using a double
click. The “VALUE” connector defines the new value of the output – the optional “DELAY” connector can be used to
specified a delay for writing the value. Blocks from the category “Commands” have no outgoing connector since
they result in an action that is executed by the NETx BMS Server.
Blocks listed in the sub tree “Functions” provide functionality with a result that is used as input for other blocks.
Therefore, these blocks always have at least one outgoing connector. Within the proposed example, two different
kind of blocks from the category “Functions” are shown. The “INPUT ITEM VALUE” block from the subcategory
“InOut/Input Item” reads the current value of an input. To select the input that shall be read, the first field within
the block has to be selected using a double click. In addition, it is possible to define a default value which is used
whenever the input is not available (e.g. if the quality of the server item is not “GOOD”). To specify a default value,
2
If a second block from the category “Commands” is placed on the work sheet, the already existing one is replaced.
XLogic Editor 1.0.1
Page 8 of 36
the “[DEFAULT]” connector has to be connected to a block that provides the value. The “ADD” block within the
proposed example performs a mathematical addition of two input values. The two input values can be defined using
the “Input 1” and “Input 2” connectors – the result is forwarded to the next block using the “Output” connector.
Within the category “Tools”, only the “COMMENT” block is available. A “COMMENT” block does not implement any
logic – comments are used for documentation purpose only. Therefore, “COMMENT” blocks do not have connectors
and thus they can be placed anywhere.
After having finished the definition of the command logic, the work sheet can be closed again. In addition, a
comment for the “CMD” block can be specified which provides the opportunity to add an additional description. To
add a comment, double click on the second field of the “CMD” block.
2.3.2. IF THEN ELSE
“IF THEN ELSE” blocks are used to change the command flow based on a condition. Each “IF THEN ELSE” has
one incoming connector “PREV” and two outgoing connectors “THEN NEXT” and “ELSE NEXT”. The “PREV”
connector is used to connect the previous block within the command flow. The “THEN NEXT” connector is used
for connecting the next block that shall be executed when the specified condition is evaluated to true – the “ELSE
NEXT” connector definies the next block if the condition is false.
To define the condition of the “IF THEN ELSE” block, the first field within the block has to be selected using a
double click. Afterwards, a new work sheet is opened where blocks from the object catalog can be placed. The final
result of the condition must also be connected to the “RESULT” connector of the predefined “END” block. Figure
2.3 shows an example of a condition. This condition evaluates to true if the specified input is greater than “100” –
otherwise false is returned.
Figure 2.3.: “IF THEN ELSE” condition
After having finished the definition of the condition, the work sheet can be closed again. Like all other block types, a
comment for a “IF THEN ELSE” block can be specified, too. To add a comment, double click on the second field of
the “IF THEN ELSE” block.
2.3.3. CMD BLOCK
A “CMD BLOCK” is a full command that in turn consists of a command flow and a command logic. “CMD BLOCK”s
are used to subdivide a command into sub commands and thus helps to organize the logic of complex commands.
A “CMD BLOCK” has one incoming connector “PREV” which is used to connect the previous block within the
command flow and one outgoing connector “NEXT” which defines the next block in the command flow.
To define the command flow and the command logic of the “CMD BLOCK”, the first field within the block has
to be selected using a double click. Afterwards, a new work sheet is opened where the command flow of the
sub command can be implemented. This command flow starts with the “START” connector of the predefined
XLogic Editor 1.0.1
Page 9 of 36
“BLOCK START” block and ends with the “FINISH” connector of the predefined “BLOCK END” block. The rest of the
implementation is done the same as for a normal command. Figure 2.4 shows an example of a “CMD BLOCK”.
Figure 2.4.: “CMD BLOCK”
After having finished the definition of the “CMD BLOCK”, the work sheet can be closed. Like all other block types, a
comment for a “CMD BLOCK” can be specified, too. To add a comment, double click on the second field of the
“CMD BLOCK”.
2.3.4. GOTO and GOTO MARKER
With the help of “GOTO MARKER” and “GOTO” blocks, it is possible to change the command flow by jumping to
defined positions. A “GOTO MARKER” block is used to specify a jump target – the block itself does not provide any
additional functionality. Each jump target has a unique name within the command flow. This name can be set by
selecting the first field within the “GOTO MARKER” block using a double click. Each “GOTO MARKER” block has
two connectors. The “PREV” connector links to the previous block in the command flow and the “NEXT” connector
to next one. A “GOTO” block is used to perform a jump. The jump target where the executing shall be continued
is defined by selecting the first field within the “GOTO” block using a double click. “GOTO” blocks only have one
incoming connector which connects the previous block in the command flow. There are no outgoing connector
since the execution is continued at the jump target.
Figure 2.5 shows an example, how these two blocks can be used. Within this example, the first “CMD” block shall
only be executed when the condition evaluates to “true” while the second “CMD” block shall always be invoked. This
is done by defining a “GOTO” block within the “else” branch of the condition that jumps to the “GOTO MARKER”
block between the two “CMD” blocks.
Figure 2.5.: “GOTO” and “GOTO MARKER”
Like all other block types, a comment for “GOTO MARKER” and “GOTO” blocks can be specified, too. To add a
comment, double click on the second field of the corresponding block.
2.3.5. COMMENT
“COMMENT” blocks do not implement any logic – they are used for documentation purpose only. Therefore,
“COMMENT” blocks do not have connectors and thus they can be placed anywhere in the command flow.
XLogic Editor 1.0.1
Page 10 of 36
For each “COMMENT” block, up to three lines of text can be defined. To change the text lines, double click on the
corresponding field of the “COMMENT” block.
Figure 2.6.: “COMMENT” block
2.4. Compiling the project
After having defined the functionality of the command, the command has to be compiled for using it in the NETx
BMS Server. This can be done by clicking the “Compile” or the “Save” icon within the toolbar – the “Compile” icon is
used to compile the command without saving it while the “Save” icon also saves the current project. If errors occur
during the compilation (e.g. blocks are not connected), the XLogic Editor prints corresponding error messages in
the messages window. By double clicking on an error message, the program redirects the user to the incorrect
block. In addition, it is possible to change several options of a command. To open the “Options” dialog, the entry
“Options ...” within the menu “File” has to be selected. Within this dialog, basic information about the command
can be specified. The flag “Add to Catalog” defines whether the command shall be visible within the catalog of the
XLogic Editor. If activated, the command can be reused in other commands. If the option “Auto-Compile” is set, the
command is automatically compiled whenever the project is saved.
2.5. Executing an XLogic command
There are two ways to execute the finished command within the NETx BMS Server. First, it is possible to add
XCommand definitions (cf. section 2.5.1). Second, a command can be executed manually during runtime using the
NETx BMS Server Studio (cf. section 2.5.2). In both cases the compiled version of the command has to be loaded
by the NETx BMS Server before it can be executed. Loading a new command or reloading a modified one is done
automatically during server startup. Alternatively, commands can also be loaded manually in the NETx BMS Server
Studio using the menu item “Tools / Load XCommand...” (cf. figure 2.7).
Figure 2.7.: Loading an XCommand in the NETx BMS Server Studio
2.5.1. Adding an XCommand definition within the NETx BMS Server Studio
XCommand definitions are used to create one or more instances of commands within the NETx BMS Server. These
command instances provide the control functionality that shall be added to the building automation system. To add
new XCommand definitions, the “XCommand event definitions” entry within the “Extensions” menu of the NETx
BMS Server Studio has to be selected.
Figure 2.8 shows an example of the the “XCommand event definitions” table.
The structure of the XCommand definition file is as follows:
XLogic Editor 1.0.1
Page 11 of 36
Figure 2.8.: XCommand event definitions
’ Name;VariableGroup;Type;Options;XCommand;Inputs;Outputs;Parameters
OR Example;;ON_INPUT;;Or;NETx\VAR\Boolean\Item1,NETx\VAR\Boolean\Item2,NETx\VAR\Boolean\Item3;NETx\VAR\Boolean\Item4;
Each line – except comment lines that start with ’ – defines a single task.
Column 1 – Name
This parameter defines the name of the XCommand instance. The name must be unique.
Column 2 – Variable group
This parameter defines the scope where the used internal variables of XCommand are valid. All XCommand
instances that are using the same variable group are accessing the same internal variables. This means that all
XCommand instances are sharing the same internal variables. If left empty, the instance name (column 1) is used
as variable group.
Column 3 – Type
This attribute defines when the XCommand shall be triggered. “ON_START” means that the XCommand is executed
once when the NETx BMS Server starts. “ON_TIMER” triggers the XCommand cyclically (the interval in seconds
can be specified in “Options” column). "‘ON_INPUT"’ executes the XCommand whenever one input item changes
its value. “ON_TIMER_AND_INPUT” is used for XCommands that shall be triggered cyclically and whenever one
input item changes. “ON_STOP” means that the XCommand is executed once when the NETx BMS Server stops.
Column 4 – Options
If “ON_TIMER” is selected, the time interval (in seconds) can be specified here.
Column 5 – XCommand
The parameter defines the XCommand that shall be executed. To assist in selecting the inputs, outputs, and
parameters, a dialog is available which can be openend via the “...” button.
Column 6 – Inputs
This parameter defines the inputs of the XCommand. If the XCommand is selected via the dialog, this parameter is
filled automatically.
Column 7 – Outputs
This parameter defines the outputs of the XCommand. If the XCommand is selected via the dialog, this parameter
is filled automatically.
Column 8 – Parameters
This parameter defines the parameters of the XCommand. If the XCommand is selected via the dialog, this
parameter is filled automatically.
2.5.2. Execution in BMS Studio
To execute a command within the NETx BMS Server Studio, use the menu item “Tools / Run XCommand” (cf. figure
2.9). This menu entry opens up a dialog that provides the possibility to choose the desired command. If the selected
command has inputs, outputs, or parameters, the dialog provides the possibility to select the corresponding values.
Figure 2.9.: Running an XCommand in NETx BMS Server Studio
XLogic Editor 1.0.1
Page 12 of 36
2.6. Transferring XCommands and creating backups
The XLogic Editor uses several directories and files to store the commands and their source code. All files and
directory are located within the following directory:
<Installation path NETx BMS Server>\NXA.XLOGIC\
This directory contains the following sub directories:
• DEFINITIONS: Here, the definitions of the available blocks within the object catalog of the XLogic Editor are
stored.
• MODULES: This directory contains the compiled versions of all available commands that can be executed by
the NETx BMS Server. Files that contain the compiled command code have the file extension “.xlogic”. If
commands shall be transferred from one NETx BMS Server to another NETx BMS Server, the content of this
directory has to be copied.
• PROJECTS: Here, the source code of all commands are stored. Files that contain source code have the file
extension “.xprj.xml”. If a command is transferred to another NETx BMS Server and if it is also desirable to
change the command, the corresponding “.xprj.xml” file has to be copied too. Note that in that case, it may
also be necessary to copy the content of the “DEFINITIONS” directory.
To sum it up, the following two cases can be distinguished:
• In order to use the commands only, the “MODULES” directory has to be transferred to the remote station.
• In order to use and change the commands, the “DEFINTIONS”, “MODULES”, and “PROJECTS” directories
have to be transferred.
XLogic Editor 1.0.1
Page 13 of 36
3. Examples
3.1. Lock object
This example shall implement the functionality of a lock object. This means that the value of an input data point
shall only be forwarded to an output data point if the value of another input item (called lock object) is not set to a
configured Boolean value.
This functionality is shown in the following truth table (suppose the configured value for the lock object is “true”):
Input data point
Lock object
Output data point
a
b
...
a
b
...
false
false
false
true
true
true
a
b
...
x
x
...
3.1.1. Creating the command
Within the NETx BMS Server Studio, start the XLogic Editor using the corresponding icon in the toolbar. Then
select the entry “New Command ...” from the menu “File”. A new dialog opens that is used to define the name of
the command as well as its inputs, outputs, and parameters. Within this dialog, set the name to “Lock” and define
the following inputs:
• Input data point: this is the item ID that specifies the input that shall be monitored.
Then, define following outputs:
• Output data point: this is the item ID that specifies the output where the result shall be written.
Finally, define the following parameters:
• Lock object: this parameter of type “ITEM ID” specifies the data point that is used as lock object1 .
• Lock value: this parameter of type “BOOL” specifies the value where the value is not forwarded. This
parameter is optional.
The dialog with all correct values is shown in Figure 3.1.
Figure 3.1.: Creating the command
3.1.2. Command flow
As next the command flow has to be defined. For the proposed command, an “IF THEN ELSE” condition and a
“CMD” block is needed. Drag and drop both blocks from the catalog on the left hand side onto the work sheet. For
documentation purpose, it is possible to set a comment to each block. Double click the “<comment>” field within
each block and enter a comment (e.g. “Verify lock object” for the condition and “Write output” for the command
block).
1
The lock object can also be defined as input. However, the difference between an input and a parameter of type “ITEM ID” is that a change of
value of an input triggers the execution of command while a change of value of a parameter does not trigger the command.
XLogic Editor 1.0.1
Page 14 of 36
To define the command flow, the blocks have to be connected to each other. The command flow is defined from left
to right – starting with the “CMD HEADER” block (begin of the command) and ending with the “CMD END” block
(end of command). First, connect the “CMD HEADER” block with “PREV” connector of the “IF THEN ELSE” block.
Then connect the “THEN NEXT” connector with the “FINISH” connector of the “CMD END” block and the “ELSE
NEXT” connector with the “PREV” connector of “CMD” block. Finally, connect the “NEXT” connector of the “CMD”
block with the “FINISH” connector of the “CMD END” block. The idea behind this command flow is as follows. After
command start, the lock object is verified with the “IF THEN ELSE” condition. If the condition verifies to true (the
object is locked), the command shall finish immediately. If the lock object is false, the output is written by calling the
“CMD” block. The final command flow is shown in figure 3.2.
Figure 3.2.: Defining the command flow
3.1.3. Verifying the lock object
As next the lock object has to be verified. By doing a double click on “IF THEN ELSE” condition, the work sheet of
the condition opens. Within this condition, the value of the lock object shall be compared with the lock value that is
provided as parameter. First, the value of lock object has to be retrieved. To do so, place a “PARAMETER VALUE”
block and an “ITEM VALUE” block on the work sheet and connect the “VALUE” connector of the “PARAMETER
VALUE” block with the “ITEM ID” connector of the “ITEM VALUE” block. Then, double click the “<empty>” field of
the “PARAMETER VALUE” block and select “Lock object” from the drop down list. In this way, the current value of
the data point behind the lock object is retrieved. The “PARAMETER VALUE” block provides the Item ID of the
lock object that the use has to be specified via the parameter “Lock object”. Using this Item ID as input, the “ITEM
VALUE” block gets the current value of lock object i.e. the item behind the lock object.
Figure 3.3.: Defining the condition
Afterwards, place another “PARAMETER VALUE” on the work sheet. Double click the “<empty>” field and select
“Lock value” as parameter. In this way, this “PARAMETER VALUE” block provides the user-defined lock value that
defines when the input shall be forwarded to the output. However, since the “Lock value” parameter is optional,
a default value has to set that is used whenever the user does not define a specific lock value. This is done by
XLogic Editor 1.0.1
Page 15 of 36
adding a “BOOL” block. Using a double click on the block, the value “TRUE” has to be selected. Then, the outgoing
connector of the “BOOL” block has to linked to incoming connector of the “PARAMETER VALUE” block.
Now place an “EQUALS” block on the workspace and connect the “VALUE” connector of the “ITEM VALUE” block
and the “VALUE” connector of the “PARAMETER VALUE(Lock Value)” block with the “INPUT” connectors of the
“EQUAL” block. Finally, connect the “Output” connector of the “EQUAL” block with the “RESULT” connector of the
“END” block. The final condition is shown in figure 3.3.
3.1.4. Writing the output
Close the condition and double click the “CMD” block within the command flow. Place an “INPUT ITEM VALUE”
block and a “WRITE OUTPUT ITEM” block on the work sheet. Connect the “VALUE” connectors of both blocks
with each other. Then double click the “<empty>” field of the “INPUT ITEM VALUE” block and select the “Input
data point” input. In addition, double click the “<empty>” field of the “WRITE OUTPUT ITEM” block and select the
“Output data point” output. In this way, the current value of the input data point is written to the output data point.
The final command definition is shown in figure 3.4.
Figure 3.4.: Writing the output
3.1.5. Saving the command and using the command within the NETx BMS Server
Figure 3.5.: Compiling the command
To provide the command to the NETx BMS Server, it has to be compiled. This can be done by clicking the “Save”
icon within the toolbar which saves and compiles the current command. In addition, it is possible to change several
options of a command. To open the “Options” dialog, the entry “Options ...” within the menu “File” has to be selected
(cf. figure 3.5). Within this dialog, basic information about the command can be specified. To make the command
visible within the catalog of the XLogic Editor and to reuse it in other commands, the flag “Add to Catalog” has to
be activated. If the option “Auto-Compile” is set, the command is automatically compiled whenever the project is
saved.
XLogic Editor 1.0.1
Page 16 of 36
After having compiled the command successfully, close the XLogic Editor and go back to the NETx BMS Server
Studio. Afterwards, the new command has to be loaded before it can be used. This can be done by restarting
the NETx BMS Server or by loading the command manually by selecting the entry “Load logic module” within the
“Tools” menu of the NETx BMS Server Studio (cf. section 2.5). Then, open the “XCommand event definitions” via
the menu “Extensions”. Add a new definition and enter a name for the command within the first column. The next
column can be left empty since all variables shall only be used locally. Within the third column, select “ON_INPUT”.
This indicates that the command shall be invoked whenever one of the inputs changes. Then, press the “...” button
within the “XCommand” column. A dialog appears where the command can be selected and configured. Select
the “Lock” command from the drop down list. Afterwards, specify the different inputs, outputs, and parameters. A
possible configuration is shown in figure 3.6.
Figure 3.6.: Defining the command within the NETx BMS Server Studio
After having saved the “XCommand event definition”, restart the NETx BMS Server and test the command2 .
3.1.6. Improving the command by testing the quality of the lock object
If the command is executed and the item behind the lock object has the quality “UNCERTAIN” or “BAD”, an error
will occur. The reason is that the “ITEM VALUE” block within the condition does not provide a correct value and thus
the “EQUALS” block gets a wrong input. To solve this, another condition has to be added to the command.
Figure 3.7.: Improving the command
Open the XLogic Editor and reopen the “Lock” command via the menu “File”. Place a new “IF THEN ELSE” block
on the workspace. Connect the “START” connector of the “CMD HEADER” block to the “PREV” connector of the
new “IF THEN ELSE” block. Then connect the “THEN NEXT” connector of the new block to the “PREV” connector
2
Note that the item behind the lock object has to be initialized. If the lock object has not the item quality “GOOD”, an error will be shown. A possible
solution to this problem is described in following section.
XLogic Editor 1.0.1
Page 17 of 36
of the “Verify lock object” block and the “ELSE NEXT” connector of the new block to the “FINISH” connector of the
“CMD END” block. The new command flow is shown in figure 3.7.
Then, open the “Verify quality” condition and place a “PARAMETER VALUE” and a “IS GOOD” block on the work
sheet. Select the parameter “Lock object” within the new “PARAMETER VALUE” block. Connect the “VALUE” of the
“PARAMETER VALUE” connector to the “Item ID” connector of the “IS GOOD” block and the “Output” connector of
the “IS GOOD” block to the “RESULT” connector of the “END” block. In this way, the item quality of the “Lock object”
is tested. If the quality is “GOOD”, the result of the condition is also true – otherwise it is false. The final condition is
shown in figure 3.8.
Figure 3.8.: Test the quality of the lock object
After having finished the new condition, save the project, compile it, restart the NETx BMS Server, and test the
improvement. Now, the command tests the quality of the lock object and does not invoke any function if the quality
is not “GOOD”.
XLogic Editor 1.0.1
Page 18 of 36
3.2. Limit Item Value
This example shows the functionality of an item value which is limited to a minimum and maximum boundary. The
minimum and maximum value can be defined by the user. Additionally it is possible to define an email address
where the user is notified when the input value is outside the upper or lower boundary. The value can also be
written to an output item, when the value is inside the defined value range.
The functionality of the example is based on the idea to limit the output for a specific server item. The user has to
specify the minimum and maximum value which defines the range in which the input values are accepted. The
definition of the example provides additionally two optional parameter. First an output item can be defined, where
correct values are forwarded too. Second it is possible to specify an email address, to inform the user about values
of the item which are outside the defined range. In the following section the example is solved in a step by step
tutorial and every single step is described in detail.
3.2.1. Creating the command
Within the NETx BMS Server Studio, start the XLogic Editor using the corresponding icon in the toolbar. Then
select the entry “New Command ...” from the menu “File”. A new dialog opens that is used to define the name of
the command as well as its inputs, outputs, and parameters.
Within this dialog, set the name to “LIMIT ITEM VALUE” and define the following inputs:
• Input data point: this is the item ID that specifies the input that shall be monitored.
Then, define following outputs:
• Output data point: this is the item ID that specifies the output where the result can be written on.
Finally, define the following parameters:
• Parameter_min: defines the minimum value of the range for the input item
• Parameter_max:defines the maximum value of the range for the input item
• Parameter_email:defines the eMail address where item values outside the boundaries are reported.
Figure 3.9.: Creating the command
3.2.2. Command flow
The next step to define the command is to add different blocks to define the command flow. In this example the
XLogic Editor 1.0.1
Page 19 of 36
structure can be grouped into three different steps that have to be taken to fulfill all the requirements of the task.
First the input value has to be validated, if the numeric input value is “GOOD”. This means that the input item was
assigned with a valid item value. The second step is to check, if the specified value is inside a defined value range.
The third and last step is the output of the item value. The value can be written on a specified output item or the
messages concerning non valid values outside the numeric range can be sent to a email address.
To validate the input three “IF THEN ELSE” blocks need to be added to the command window and connect them
as illustrated in figure 3.10. Three “IF THEN ELSE” blocks in combination three “CMD” blocks are finally used to
check and write the output to the defined server item or to write a message to an email address. Please connect
the individual blocks as illustrated in figure 3.10. In the following section the individual blocks and their purpose will
be described in detail. All remaining connectors that do not have a link to another block have to be connected to the
“CMD END” block. After the configuration the links of the connectors can be checked over the “Compile” button.
Figure 3.10.: Defining the command flow
3.2.3. Check if input value is good
In the first step it has to be checked if the input was assigned with a valid value. For this purpose the first “IF THEN
ELSE” block will be used. For documentation purposes it is possible to add a comment to the block. Via double
click on the field “<comment>” a message box opens, where a comment can be inserted (e.g. Input value good).
Via double click on the “<empty>” field of the “IF THEN ELSE” block, a new window for the definition of the condition
opens. A “Input Item ID” block and a “IS GOOD” block have to be inserted to this window. The “ID” connector of
the “Input Item ID” block has to be connected to the “Item ID” connector of the “IS GOOD” block. The “Output”
connector of the “IS GOOD” block has to be connected to the “Result” connector of the “End” block. Via double
click on the “Input Item ID” block the input “Input_Item_1” has to be chosen from the drop-down menu. The final
condition is illustrated in figure 3.11. The window can now be closed.
Figure 3.11.: Input value is good
3.2.4. Check the value range
The check for validating the value range is done in two steps. First the lower limit is checked and afterwards
the upper limit. Click on the “<comment>” field of the second “IF THEN ELSE” block and add a comment (e.g.
value greater min). Double click on the “<empty>” field of the “IF THEN ELSE” block. In the opened window a
“INPUT ITEM VALUE”, “PARAMETER VALUE” and a “GREATER OR EQUAL” block have to be added. The “Output”
XLogic Editor 1.0.1
Page 20 of 36
connector of the “INPUT ITEM VALUE” block has to be connected to the “Input 1” connector of the “GREATER
OR EQUAL” block. The “Output” connector of the “PARAMETER VALUE” block has to be connected to the “Input
2” connector of the “GREATER OR EQUAL” block. Double click on the “INPUT ITEM VALUE” block and select
“Input_Item_1”. Then double click on the “PARAMETER VALUE” block and select “Parameter_min”. Finally connect
the “Output” connector of the “GREATER OR EQUAL” block with the “Result” connector of the “End” block. Now the
input value is checked for the lower limit as illustrated in figure 3.12. The next step is to check the input value for the
upper limit. The window can now be closed.
Figure 3.12.: Value greater than minimum
In the second step the input value has to be checked if it is below the maximum value of the range. Click on the
“<comment>” field of the third “IF THEN ELSE” block and add a comment (e.g. value lower max). Double click on
the “<empty>” field of the “IF THEN ELSE” block. In the opened window a “INPUT ITEM VALUE”, a “PARAMETER
VALUE” and a “LESS OR EQUAL” block have to be added. The “Output” connector of the “INPUT ITEM VALUE”
block has to be connected to the “Input 1” connector of the “LESS OR EQUAL” block. The “Output” connector of
the “PARAMETER VALUE” block has to be connected to the “Input 2” connector of the “LESS OR EQUAL” block.
Double click on the “INPUT ITEM VALUE” block and select “Input_Item_1”. Then double click on the “PARAMETER
VALUE” block and select “Parameter_max”. Finally connect the “Output” connector of the “LESS OR EQUAL” block
with the “Result” connector of the “End” block. After this step the condition should look like in figure 3.13. The
window can now be closed.
Figure 3.13.: Value smaller than maximum
3.2.5. Check if output is set
To write the input item on a server item, it has to be checked if the output item parameter is not optional before the
value can be written on the item. For this purpose the fourth “IF THEN ELSE” block has to be used. Click on the
“<comment>” field of the “IF THEN ELSE” block and add a comment (e.g. Output item set). Via double click on the
“<empty>” field of the “IF THEN ELSE” block a window opens to define a new condition. Drag an “ARGUMENT
EXISTS” block into the new window and connect the “EXISTS” connector with the “Result” connector of the “End”
block. Double click on the “ARGUMENT EXISTS” block and select the “Output_Item_1” from the drop-down menu.
The window can now be closed.
Figure 3.14.: Output item exists
XLogic Editor 1.0.1
Page 21 of 36
3.2.6. Writing the output
After the parameter was checked if it is set and is not optional, the current value can be written to the defined
output item. For this purpose the “CMD” block after the fourth “IF THEN ELSE” block has to be used. Click on the
“<comment>” field of the “CMD” block and add a comment (e.g. Write input to output value). Double click on the
“<empty>” field of the “CMD” block to open the window to define the new condition. Drag a “INPUT ITEM VALUE”
and a “WRITE OUTPUT VALUE” block to the window and connect the “VALUE” connectors of both blocks with
each other. Double click on the “INPUT ITEM VALUE” block and select “Input_Item_1”. Additionally click on the
“WRITE OUTPUT VALUE” block and select “Output_Item_1”. Now the value can be written to the output if it is
inside the defined value range. The window can now be closed.
Figure 3.15.: Write to Output item
3.2.7. Check if email address is set
As next, it has to be checked whether an email address was set by the user. The two remaining “IF THEN ELSE”
blocks are used to define one for the upper and one for the lower limit. Click on the “<comment>” field of the “IF
THEN ELSE” block and add a comment (e.g. Email address set). Double click on the “<empty>” field of the “IF
THEN ELSE” block to open the windows to define new conditions. Add in both windows an “ARGUMENT EXISTS”
block and connect the “EXISTS” connector with the “Result” connector of the “End” block. Double click on the
“ARGUMENT EXISTS” block and select “Parameter_email” from the drop-down menu. The window can now be
closed.
Figure 3.16.: Email address exists
3.2.8. Send email to configured address
Figure 3.17.: Send to Email address
For this purpose the two remaining “CMD” blocks are used to send a message to the defined email address.
Click on the “<comment>” field of the “CMD” blocks and add a comment (“Value above max” and “Value under
min”). Double click on the “<empty>” fields of the “CMD” blocks and add a “PARAMETER VALUE” block, two
“STRING” blocks and a “SEND EMAIL TO” block to the upcoming window. Connect the “Value” connector of the
“PARAMETER VALUE” blocks with the “Address” connector of the “SEND EMAIL TO” blocks. Double click on the
“PARAMETER VALUE” block and select the “Parameter_email” from the drop-down menu. Connect now the two
XLogic Editor 1.0.1
Page 22 of 36
“STRING” blocks to the “Subject” and “Body” connectors or the “SEND EMAIL TO” block. Enter meaningful strings
to the two “STRING” blocks of each window (e.g “Value out of range”, “The input value is too high/low”) 3 .
3.2.9. Saving the command and using the command within the NETx BMS Server
Figure 3.18.: Compile the XLogic Editorcommand
To provide the command to the NETx BMS Server, it has to be compiled. This can be done by clicking the “Save”
icon within the toolbar which saves and compiles the current command. In addition, it is possible to change several
options of a command. To open the “Options” dialog, the entry “Options ...” within the menu “File” has to be selected
(cf. figure 3.18). Within this dialog, basic information about the command can be specified. The flag “Add to Catalog”
defines whether the command shall be visible within the catalog of the XLogic Editor. If activated, the command
can be reused in other commands. If the option “Auto-Compile” is set, the command is automatically compiled
whenever the project is saved.
Figure 3.19.: Defining the command within the NETx BMS Server Studio
After having compiled the command successfully, close the XLogic Editor and go back to the NETx BMS Server
Studio. Afterwards, the new command has to be loaded before it can be used. This can be done by restarting
3
To send emails the corresponding settings have to be added to the system configuration of the NETx BMS Server. The configuration of the email
system is also described in the documentation of the NETx BMS Server.
XLogic Editor 1.0.1
Page 23 of 36
the NETx BMS Server or by loading the command manually by selecting the entry “Load logic module” within the
“Tools” menu of the NETx BMS Server Studio(cf. section 2.5). Then, open the “XCommand event definitions” via
the menu “Extensions”. Add a new definition and enter a name for the command within the first column. The next
column can be left empty since all variables shall only be used locally. Within the third column, select “ON_INPUT”.
This indicates that the command shall be invoked whenever one of the inputs changes. Then, press the “...” button
within the “XCommand” column. A dialog appears where the command can be selected and configured. Select
the “LIMIT ITEM VALUE” command from the drop down list. Afterwards, specify the different inputs, outputs, and
parameters. A possible configuration is shown in figure 3.19.
After having saved the “XCommand definition”, restart the NETx BMS Server and test the command.
XLogic Editor 1.0.1
Page 24 of 36
3.3. Delayed Off
This example shall implement the following functionality: if a rising edge of a Boolean input is detected, the output
shall be set to true. After a defined delay, the output shall be set to false again. If the output is currently set to true
and another rising edge at the input is detected, the time delay for setting the output to false shall be reset.
Figure 3.20 shows the functionality mentioned above.
Figure 3.20.: Delayed off
3.3.1. Creating the command
Figure 3.21.: Creating the command
Within the NETx BMS Server Studio, start the XLogic Editor using the corresponding icon in the toolbar. Then
select the entry “New Command ...” from the menu “File”. A new dialog opens that is used to define the name of
the command as well as its inputs, outputs, and parameters.
Within this dialog, set the name to “Delayed Off” and define the following input:
• Input: this is the item ID that specifies the input that shall be monitored.
Then, define the following output:
XLogic Editor 1.0.1
Page 25 of 36
• Output: this is the item ID that specifies the output where the result shall be written.
Finally, define the following parameter:
• Delay: this parameter of type “NUMBER” specifies the delay in seconds.
The dialog with all correct values is shown in Figure 3.21.
3.3.2. Command flow
As next the command flow has to be defined. The proposed command shall be split into two different parts – one
part that processes the input and one part that process the output. To achieve this, insert two “CMD BLOCK”s and
set the comment of the first one to “Process input” and the comment of the second one to “Process output”. Figure
3.22 shows the final command flow.
Figure 3.22.: Defining the command flow
3.3.3. “Process input”
As next the “Process input” block shall be implemented. By doing a double click on the corresponding block, the
work sheet of the “CMD BLOCK” opens. Within this work sheet, define the command flow that is shown in figure
3.23.
Figure 3.23.: Process input
The command flow of the “Process input” block consists of the following blocks:
• “Edge detection”: this block of type “CMD BLOCK” performs the detection of the rising edge of the input.
• “Is edge detected?”: after having performed the edge detection, it has to be verified whether a edge currently
exists or not.
• ”Set counter”: if an edge was detected, the time delay is reset to the initial value (i.e. to the specified delay).
• “Is output false?”: this condition verifies whether the output is current set to “false”.
• “Write true to output”: if the output is currently “false”, it is set to “true”.
In the following, the above mentioned blocks are explained in more detail.
XLogic Editor 1.0.1
Page 26 of 36
3.3.3.1. “Edge detection”
The command flow of the “Edge detection” block is shown in figure 3.24.
Figure 3.24.: “Edge detection”
It consists of the following blocks:
“Is edge detected?”
This condition verifies whether a positve edge is detected at the input. The condition is shown in figure 3.25(a).
“Set edge”
Here, the variable “edge” is set which indicates that an edge has been detected. The implementation is shown in
figure 3.25(b).
“Reset edge”
This block is used to reset the variable “edge”. The implementation is shown in figure 3.25(c).
“Set last value edge”
Here, the current value of the input is stored in the variable “last input” which is used in the next command execution
to perform the edge detection. The implementation is shown in figure 3.25(d).
(a) Edge detection
(c) Reset variable “edge”
(b) Set variable “edge”
(d) Set variable “last input”
Figure 3.25.: “CMD BLOCK” for edge detection
3.3.3.2. “Is edge detected?’
This condition verifies whether an edge has been detected in the previous “CMD BLOCK”. Using an “EQUAL”
block, the current value of the variable “edge” (retrieved by the “VARIABLE VALUE” block in combination with a
XLogic Editor 1.0.1
Page 27 of 36
“VARIABLE NAME” block) is compared to the constant “TRUE” (provided by a “BOOL” block). The implementation
of the “Is edge detected” condition is shown in figure 3.26.
Figure 3.26.: “Is edge detected?” condition
3.3.3.3. “Set counter’
This block resets the counter to the value that is specified by the “Delay” parameter. The implementation of the “Set
counter” block is shown in figure 3.27.
Figure 3.27.: “Set counter” block
3.3.3.4. “Is output false?’
After having reset the counter, the output shall be set to true if it is not already true. To achieve this, the output has
to verified. Figure 3.28 shows the implementation of the required condition.
Figure 3.28.: “Is output false?” condition
3.3.3.5. “Write true to output’
Figure 3.29 shows how the output is set to true. Note that a “WRITE OUTPUT ITEM” block also forwards the value
to the bus if a physical data point is behind the server item.
3.3.4. “Process output”
After having finished the “Process input” block, the “Process output” block has to be implemented. By doing a
XLogic Editor 1.0.1
Page 28 of 36
Figure 3.29.: “Write true to output” block
double click on the corresponding block, the work sheet of the “CMD BLOCK” opens. Within this work sheet, define
the command flow that is shown in figure 3.30.
Figure 3.30.: Process output
The command flow of the “Process output” block consists of the following blocks:
• “Is counter 0?”: this condition verifies whether the current counter value is zero.
• “Is output true?”: if the counter is zero, the output shall be reset to false again. However, this shall only be
done if the output is currently set to true. The required test is done within this block.
• ”Write false to output”:Within this “CMD” block, the output is set to false.
• “Decrement counter”: if the counter is not yet zero, it is decremented by one within this block.
In the following, the above mentioned blocks are explained in more detail.
3.3.4.1. “Is counter 0?’
Using a “LESS OR EQUAL” block, the current counter value which is stored within the variable “counter” is
compared with zero. To get the value of the variable, a “VARIABLE VALUE” block is used. Since the variable may
be uninitialized after server startup, zero is specified as default value. The implementation of this condition is shown
in figure 3.31.
Figure 3.31.: “Is counter 0?”
3.3.4.2. “Is output true?’
If the current counter value is zero, the delay interval is elapsed and the output shall be reset to false again. However,
to avoid that multiple “false” telegrams are sent to the bus, the output shall only be set to false if the output is
currently true. The implementation of the required test is shown in figure 3.32.
XLogic Editor 1.0.1
Page 29 of 36
Figure 3.32.: “Is output true?”
3.3.4.3. “Write false to output’
Figure 3.33 shows how the output is set to false. To forward the value also to the bus if the output is a physical data
point, a “WRITE OUTPUT ITEM” is used4 .
Figure 3.33.: “Write false to output”
3.3.4.4. “Decrement counter’
If the current counter value is not zero, the delay interval has not been elapsed and thus the counter value has
to be decremented by one. Figure 3.34 shows the implementation of this functionality. Decrementing the value
is done using a “SUB” block. The incoming “Input 1” connector is connected to outgoing “VALUE” connector of
the “VARIABLE VALUE” block that provides the current counter value. The “Input 2” connector is connected to the
“NUMBER” block that provides the constant value 1. The result of the subtraction is stored in the “counter” variable
again using a “SET VARIABLE” block.
Figure 3.34.: “Decrement counter”
3.3.5. Saving the command and using the command within the NETx BMS Server
To provide the command to the NETx BMS Server, it has to be compiled. This can be done by clicking the “Save”
icon within the toolbar which saves and compiles the current command. In addition, it is possible to change several
options of a command. To open the “Options” dialog, the entry “Options ...” within the menu “File” has to be selected
(cf. figure 3.35). Within this dialog, basic information about the command can be specified. The flag “Add to Catalog”
defines whether the command shall be visible within the catalog of the XLogic Editor. If activated, the command
can be reused in other commands. If the option “Auto-Compile” is set, the command is automatically compiled
whenever the project is saved.
After having compiled the command successfully, close the XLogic Editor and go back to the NETx BMS Server
Studio. Afterwards, the new command has to be loaded before it can be used. This can be done by restarting
the NETx BMS Server or by loading the command manually by selecting the entry “Load logic module” within
4
If the value shall only be set internally and not forwarded to the bus, a “SET OUTPUT VALUE” block has to be used instead.
XLogic Editor 1.0.1
Page 30 of 36
Figure 3.35.: Compiling the command
the “Tools” menu of the NETx BMS Server Studio(cf. section 2.5). Then, open the “XCommand event definitions”
via the menu “Extensions”. Add a new definition and enter a name for the command within the first column.
The next column can be left empty since all variables shall only be used locally. Within the third column, select
“ON_TIMER_AND_INPUT”. This indicates that the command shall be invoked whenever one of the inputs changes
and/or after a predefined timer interval has elapsed. To specify the timer interval, enter “1” in the “Options” column.
This indicated that the command shall be executed every second in addition to a change of value of an input. Then,
press the “...” button within the “XCommand” column. A dialog appears where the command can be selected and
configured. Select the “Delayed Off” command from the drop down list. Afterwards, specify the different inputs,
outputs, and parameters. A possible configuration is shown in figure 3.36.
Figure 3.36.: Defining the command within the NETx BMS Server Studio
After having saved the “XCommand event definition”, restart the NETx BMS Server and test the command.
XLogic Editor 1.0.1
Page 31 of 36
4. Predefined commands
4.1. ADD
4.1.1. Summary
ADD sums up all passed parameters and returns the result.
4.1.2. Inputs
Input
Data type:
Mandatory:
Description:
1
numeric
Yes
First summand of the sum (aka. augend).
Input
Data type:
Mandatory:
Description:
1
numeric
Yes
Second summand of the sum (aka. addend).
Input
Data type:
Mandatory:
Description:
1
numeric
No
Third summand of the sum.
Input
Data type:
Mandatory:
Description:
1
numeric
No
Fourth summand of the sum.
Input
Data type:
Mandatory:
Description:
1
numeric
No
Fifth summand of the sum.
Input
Data type:
Mandatory:
Description:
1
numeric
No
Sixth summand of the sum.
Input
Data type:
Mandatory:
Description:
1
numeric
No
Seventh summand of the sum.
Input
Data type:
Mandatory:
Description:
1
numeric
No
Eighth summand of the sum.
Input
Data type:
Mandatory:
Description:
1
numeric
No
Ninth summand of the sum.
Input
Data type:
Mandatory:
Description:
1
numeric
No
Tenth summand of the sum.
XLogic Editor 1.0.1
Page 32 of 36
4.1.3. Outputs
Output
Data type:
Mandatory:
Description:
1
Numeric
Yes
Contains the result of the summation.
4.1.4. Parameters
None.
4.2. AND
4.2.1. Summary
AND conjuncts all passed parameters and returns the result.
4.2.2. Inputs
Input
Data type:
Mandatory:
Description:
1
Boolean
Yes
First Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
2
Boolean
Yes
Second Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
3
Boolean
No
Third Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
4
Boolean
No
Fourth Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
5
Boolean
No
Fifth Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
6
Boolean
No
Sixth Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
7
Boolean
No
Seventh Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
8
Boolean
No
Eighth Boolean item of the conjunction.
XLogic Editor 1.0.1
Page 33 of 36
Input
Data type:
Mandatory:
Description:
9
Boolean
No
Ninth Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
10
Boolean
No
Tenth Boolean item of the conjunction.
4.2.3. Outputs
Output
Data type:
Mandatory:
Description:
1
Boolean
Yes
Contains the result of the conjunction.
4.2.4. Parameters
Parameter:
Scope:
Default value:
Description:
WriteToBus
Boolean
true
Shall the value be written to the bus or just be set to the output item?
Parameter:
Scope:
Default value:
Description:
VerifyQuality
Boolean
false
If set, check the quality of the input items and abort the operation when one of them has
quality other than “GOOD”.
4.3. DELAYED OFF
4.3.1. Summary
DELAYED OFF turns off the output item after a specified time triggered by the input item.
4.3.2. Inputs
Input
Data type:
Mandatory:
Description:
1
Boolean
Yes
Input item, which triggers the start of the DELAYED OFF.
4.3.3. Outputs
Output
Data type:
Mandatory:
Description:
1
Boolean
Yes
This item will be turned off once the delay timer has expired.
4.3.4. Parameters
Parameter:
Scope:
Default value:
Description:
XLogic Editor 1.0.1
Delay
Numeric
0
Contains the delay in milliseconds for turning off the output item.
Page 34 of 36
4.4. DIV
4.4.1. Summary
DIV todo.
4.4.2. Inputs
Input
Data type:
Mandatory:
Description:
1
Boolean
Yes
First Boolean item of the conjunction.
Input
Data type:
Mandatory:
Description:
2
Boolean
Yes
Second Boolean item of the conjunction.
4.4.3. Outputs
Output
Data type:
Mandatory:
Description:
1
Boolean
Yes
Contains the result of the conjunction.
4.4.4. Parameters
Parameter:
Scope:
Default value:
Description:
WriteToBus
Boolean
true
Shall the value be written to the bus or just be set to the output item?
Parameter:
Scope:
Default value:
Description:
VerifyQuality
Boolean
false
If set, check the quality of the input items and abort the operation when one of them has
quality other than “GOOD”.
XLogic Editor 1.0.1
Page 35 of 36
A. Appendix
A.1. Support and contact
Please send all your support questions to:
[email protected]
If you have general questions regarding the product and service please send your email to:
[email protected]
XLogic Editor 1.0.1
Page 36 of 36