BACnet32

BACnet32

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

The BACnet driver is used for communication between one or more devices supporting BACnet (BACnet automation stations) and the zenon Runtime. This requires that the connected BACnet devices run as servers. Only client functionality is implemented in the driver.


BACNET32 - Data sheet

BACnet32 -> BACNET32 - Data sheet

General: |
Driver file name | BACNET32.exe
Driver description | Bacnet and DDC4000 driver
PLC types | All Bacnet "BACnet/IP, Annex J" compliant PLCs; Kieback + Peter DDC4000 PLCs
PLC manufacturer | Kieback + Peter; BACnet;

Driver supports: |
Protocol | BACnet/IP;
Addressing: address based | -
Addressing: name based | x
Spontaneous communication | x
Polling communication | x
Online browsing | x
Offline browsing | -
Real-time capable | x
Blockwrite | -
Modem capable | -
Serial logging | -
RDA numerical | -
RDA String | -

Prerequisites: |
Hardware PC | Standard network card
Software PC | WinPcap.dll
Hardware PLC | -
Software PLC | -
Requires v-dll | -

Platforms: |
Operating systems | Windows XP, Vista, 7, Server 2003, Server 2008/R2;
CE platforms | -;


Driver history

BACnet32 -> Driver history

Date | Driver version | Change
07.07.08 | 3600 | Re-created driver documentation
27.10.08 | 3800 | New functionality: configurable priority and read delay
17.11.08 | 4000 | Corrected errors in documentation links


Requirements

BACnet32 -> Requirements

This chapter contains information on the requirements that are necessary for use of this driver.


PC

BACnet32 -> Requirements -> PC

Driver files: Copy BACnet32.exe, PTP.dll, nb_link_settings.dll to the program directory, if they are not already there.

WPcap.dll; installation set available for free in the Internet, e.g. at http://www.winpcap.org/install/default.htm

Copy the file WPcap.dll to the directory system32.

We recommend version 3.0 or higher.


Configuration

BACnet32 -> Configuration

In this chapter you will learn how to use the driver in a project and which settings you can change.

info Info

Find out more about further settings for zenon variables in the chapter Variables of the online manual.


Creating a driver

BACnet32 -> Configuration -> Creating a driver

In order to create a new driver:

  • Right-click on Driver in the Project Manage and select Driver new in the context menu.
  • In the following dialog the control system offers a list of all available drivers.

  • Select the desired driver and give it a name:
    • The driver name has to be unique, i.e. if one and the same driver is to be used several times in one project, every time a new name has to be given each time.
    • The driver name is part of the file name. Therefore it may only contain characters which are supported by the operating system. Invalid characters are replaced by an underscore (_).
    • Attention: This name cannot be changed later on.
  • Confirm the dialog with OK. In the following dialog the single configurations of the drivers are defined.
  • Only the respective required drivers need to be loaded for a project. Later loading of an additional driver is possible without problems.

info Info

For new projects and for existing projects which are converted to version 6.21 or higher, the following drivers are created automatically:

  • Internal
  • MathDr32
  • SysDrv.


Settings in the driver dialog

BACnet32 -> Configuration -> Settings in the driver dialog

You can change the following settings of the driver:


General

BACnet32 -> Configuration -> Settings in the driver dialog -> General

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Parameters

Description

Mode

Allows to switch between hardware mode and simulation mode

  • Hardware:

    A connection to the control is established.

  • Simulation static

    No communication between to the control is established, the values are simulated by the driver. In this modus the values remain constant or the variables keep the values which were set by zenon Logic. Each variable has its own memory area, e.g. two variables of the type marker with offset 79 can have different values in the Runtime and do not influence each other. Exception: The simulator driver.

  • Simulation - counting

    No communication between to the control is established, the values are simulated by the driver. In this modus the driver increments the values within a value range automatically.

  • Simulation - programmed

    N communication is established to the PLC. The values are calculated by a freely programmable simulation project. The simulation project is created with the help of the zenon Logic Workbench and runs in a zenon Logic Runtime which is integrated in the driver. For details see chapter Driver simulation.

Keep update list in the memory

Variables which were requested once are still requested from the control even if they are currently not needed.
This has the advantage that e.g. multiple screen switches after the screen was opened for the first time are executed faster because the variables need not be requested again. The disadvantage is a higher load for the communication to the control.

Output can be written

Active: Outputs can be written.

Inactive: Writing of outputs is prevented.

Note: Not available for every driver.

Variable image remanent

This option saves and restores the current value, time stamp and the states of a data point.

Fundamental requirement: The variable must have a valid value and time stamp.

The variable image is saved in mode hardware if:

  • one of the states S_MERKER_1(0) up to S_MERKER8(7), REVISION(9), AUS(20) or ERSATZWERT(27) is active

The variable image is always saved if:

  • the variable is of the object type Driver variable
  • the driver runs in simulation mode. (not programmed simulation)

The following states are not restored at the start of the Runtime:

  • SELECT(8)
  • WR-ACK(40)
  • WR-SUC(41)

The mode Simulation - programmed at the driver start is not a criterion in order to restore the remanent variable image.

Stop at the Standby Server

Setting for redundancy at drivers which allow only on communication connection. For this the driver is stopped at the Standby Server and only started at the upgrade.

Attention: If this option is active, the gapless archiving is no longer guaranteed.

Active: Sets the driver at the not-process-leading Server automatically in a stop-like state. In contrast to stopping via driver command, the variable does not receive status switched off but an empty value. This prevents that at the upgrade to the Server irrelevant values are created in the AML, CEL and Historian.

Global Update time

Active: The set Global update time in ms is used for all variables in the project. The priority set at the variables is not used.
Inactive: The set priorities are used for the individual variables.

Priority

Here you set the polling times for the individual priorities. All variables with the according priority are polled in the set time. The allocation is taken place for each variable separately in the settings of the variable properties.
The communication of the individual variables are graduated in respect of importance or necessary topicality using the priorities. Thus the communication load is distributed better.

Update time for cyclical driver

The following applies for cyclical drivers:

For Set value, Advising of variables and Requests, a read cycle is immediately triggered for all drivers - regardless of the set update time. This ensures that the value is immediately available for visualization after writing. Update times can therefore be shorter than pre-set for cyclical drivers.


Driver dialog BACnet settings

BACnet32 -> Configuration -> Settings in the driver dialog -> Driver dialog BACnet settings

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Parameters | Description
Who-Is cycle [s] | Cycle time for sending the “Who-Is” service
Time synchronization cycle [min] | Cycle time for time synchronization [min], default=0 (no synchronization)
Command output time [ms] | Command output time for sending strategy 1 (single command) [ms]
Number of retries | max. number for sending out the “Who-Has” service per object
Port | Configuration of the UDP port in the decimal format. (Default for BACNet: 47808)
Separator for property names |
Number of simulatenous queries | Maximum number of simultaneous COV subscription packets. Used for BACNet devices that can only buffer and process a certain number of packets.
COV lifetime [sec] | After this time, registered COV subscriptions will become invalid and will then be requested from the driver again (see BACnet standard).
Write priority | Defines the write priority for variables. (see BACnet standard). The lower the value, the higher the priority ATTENTION: Values under "8" are often used by the PLC itself and should therefore be used with caution.
Read delay [ms] | Configurable delay between 2 polling queries. This is required for devices with performance problems.


Driver dialog diagnosis settings

BACnet32 -> Configuration -> Settings in the driver dialog -> Driver dialog diagnosis settings

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Parameters | Description
Plain text | Logging of the BACnet telegram in plain text
Hex format | Logging of the BACnet telegram in hexadecimal format
Max file size [kByte] | Max. size of the log file
Shortening [kByte] | Shortening of the log file, if max. file length is reached

Data is stored in the file <runtimepath>\RT\FILES\zenon\custom\drivers\BACnet.log

For Editor communication (browsing), the following file is used: <SQLpath>\<ProjektGUID>\FILES\zenon\custom\drivers\BACnet.log.


Driver dialog IP addresses

BACnet32 -> Configuration -> Settings in the driver dialog -> Driver dialog IP addresses

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Parameters

Description

No broadcast for 'WhoIs'

If this option is active, 'WhoIs' messages will only be sent to the BACNet stations in the list below.

ATTENTION: This function is not a part of the BACNet standard. We cannot guarantee that it works with all BACNet PLCs.

New...

Create a new station:

Device: Specify the device name (e.g. device name in BACNet)

IP address: IP address of the target device

Edit...

Edits the selected address

Delete...

Deletes the selected address

Dialog for creating and modifying connections

Device | Freely definable name of the connection
IP address | IP address of the BACnet device


Creating variables

BACnet32 -> Creating variables

This is how you can create variables in the zenon Editor:


Creating variables in the Editor

BACnet32 -> Creating variables -> Creating variables in the Editor

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Variables can be created:

  • as simple variables
  • in arrays
  • as structure variables

Variable dialog

To create a new variable, regardless of which type:

  1. Select the New variable command in the Variables node in the context menu

  2. The dialog for configuring variables is opened
  3. configure the variable
  4. The settings that are possible depends on the type of variables

Property

Description

Name

Distinct name of the variable. If a variable with the same name already exists in the project, no additional variable can be created with this name.

Attention: The # character is not permitted in variable names. If non-permitted characters are used, creation of variables cannot be completed and the Finish button remains inactive.

Drivers

Select the desired driver from the drop-down list.

Note: If no driver has been opened in the project, the driver for internal variables (Intern.exe) is automatically loaded.

Driver object type

Select the appropriate driver object type from the drop-down list.

Data type

Select the desired data type. Click on the ... button to open the selection dialog.

Array settings

Expanded settings for array variables. You can find details in the Arrays chapter.

Addressing options

Expanded settings for arrays and structure variables. You can find details in the respective section.

Automatic element activation

Expanded settings for arrays and structure variables. You can find details in the respective section.

Inheritance from data type

Measuring range, Signal range and Set value are always:

  • derived from the datatype
  • Automatically adapted if the data type is changed

Note for signal range: If a change is made to a data type that does not support the set signal range, the signal range is amended automatically. For example, for a change from INT to SINT, the signal range is changed to 127. The amendment is also carried out if the signal range was not inherited from the data type. In this case, the measuring range must be adapted manually.


Addressing

BACnet32 -> Creating variables -> Addressing

Addressing the variables of the BACnet driver is done with the unique names of the variables. The datapoints of the BACnet driver are uniquely referenced by the object names. The object name of the device object is placed before the object name of the BACnet object; the names are separated by a dot (e.g. BPS10.d10a002); for schedule objects, the name of the property is attached, again separated by a dot. The virtual datapoints of the type BACnet component status represent the status of the connection. They are uniquely identified by the object name of the device object.

Settings for the unique addressing of variables

Property | Description
Name | Used for the uniqe addressing. Format: device-name.object-name[.property]
Identification | Any text can be entered here, e.g. for resource labels, comments ...
Net address | Bus address or net address of the variable. This address refers to the bus address in the connection configuration of the driver. This defines the PLC, on which the variable resides.
Data block | not used for this driver
Offset | not used for this driver
Alignment | not used for this driver
Bit number | not used for this driver
String length | Only available for String variables: Maximum number of characters that the variable can take.
Driver object type | Depending on the employed driver, an object type is selected during the creation of the variable; the type can be changed here later.
Data type | Data type of the variable, which is selected during the creation of the variable; the type can be changed here later. ATTENTION: If you change the data type later, all other properties of the variable must be checked and adjusted, if necessary.


Driver objects and datatypes

BACnet32 -> Creating variables -> Driver objects and datatypes

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Driver objects are areas available in the PLC, such as markers, data blocks etc. Here you can find out which driver objects are provided by the driver and which IEC data types can be assigned to the respective driver objects.


Driver objects

BACnet32 -> Creating variables -> Driver objects and datatypes -> Driver objects

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

The following object types are available in this driver:

Driver object type | Channel type | Read / Write | Supported data types | Comment
Output | 11 | R / W | BOOL, REAL, SINT, USINT |
Input | 10 | R / W | BOOL, REAL, SINT, USINT |
PLC marker | 8 | R / W | BOOL, REAL, SINT, USINT |
Driver variable | 35 | R / W | BOOL, SINT, USINT, INT, UINT, DINT, UDINT, REAL, STRING | Variables for the statistical analysis of communication. Find out more in the chapter about the Driver variables

Driver object types and supported IEC data types for process variables in zenon

Driver object types | Supported datatypes | Read | Write | BACnet Object Type
Input | BOOL | Y | N | Binary Input
 | REAL | Y | N | Analog Input
 | SINT, USINT | Y | N | Multistate Input
Output | BOOL | N | Y | Binary Output
 | REAL | N | Y | Analog Output
 | SINT, USINT | N | Y | Multistate Output
PLC marker | BOOL | Y | Y | Binary Value
 | REAL | Y | Y | Analog Value Schedule - Present Value
 | USINT | Y | Y | Component status
 | STRING * | Y | Y | Schedule - Effective Period Schedule - Weekly Schedule Schedule - Exception Schedule

* The individual properties of schedule objects have a complex and variable structure (See BACnet standard). That is why you can only hand them over as Strings to zenon. Depending on the property, these Strings have different formats (you can leave out spaces when setting values):

Effective Period

Effective Period: | { <Start date> - <End date> }
Date: | <Year – 1900>.<Month (1..12)>.<Day (1..31)>.<Weekday (1..7, 1 = Monday)>

Weekly Schedule

Weekly Schedule: | { Array [1..7] of <Daily Schedule> }
Daily Schedule: | { List of <Time Value> }
Time Value: | { <Time>, [<Type>] <Value> }
Time: | <Hour>:<Minute>:<Second>:<1/100 sec.>
Type: | 1 2 3 4 5 6 7 8 9 10 11 12 | BOOLEAN UNSIGNED SIGNED REAL DOUBLE OCTET_STRING CHARACTER_STRING BIT_STRING ENUMERATED DATE TIME OBJECT_IDENTIFIER

Exception Schedule

Exception Schedule: | { Array [1..n] of <Special Event> }
Special Event: | { <Period> { List of <Time Value>* } <Event Priority> }
Period: | { [0] <Calendar Entry> } or { [1] <Calendar Reference> }
Calendar Reference: | Instance no. of the referenced calendar object
Calendar Entry: | [0] <Date>** or [1] <Start date>** - <End date>** or [2] <WeekNDay>
WeekNDay: | <Month (1..12)>.<Week of month (1..6)>.<Weekday (1..7)>
Event Priority: | 1..16, 1 = highest priority, 16 = lowest priority

* see Weekly Schedule, ** see Effective Period


Mapping of the data types

BACnet32 -> Creating variables -> Driver objects and datatypes -> Mapping of the data types

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

All variables in zenon are derived from IEC data types. The following table compares the IEC datatypes with the datatypes of the PLC.

Examples for all possible IEC data types

PLC | zenon | Range of values
8 Bit signed | SINT | -128 to 127
8 Bit unsigned | USINT | 0 to 255
32 bit floating point | REAL | ± 3.4E ± 38
Boolean | BOOL | 0, 1

Data type: The property Data type is the internal numerical name of the data type. It is also used for the extended DBF import/export of the variables.


Creating variables by importing

BACnet32 -> Creating variables -> Creating variables by importing

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Variables can also be imported by importing them. The XML and DBF import is available for every driver.


XML import of variables from another zenon project

BACnet32 -> Creating variables -> Creating variables by importing -> XML import of variables from another zenon project

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

For the import/export of variables the following is true:

  • The import/export must not be started from the global project.
  • The start takes place via:
    • Context menu of variables or data typ in the project tree
    • or context menu of a variable or a data type
    • or symbol in the symbol bar variables

attention Attention

When importing/overwriting an existing data type, all variables based on the existing data type are changed.

Example:

There is a data type XYZ derived from the type INTwith variables based on this data type. The XML file to be imported also contains a data type with the name XYZ but derived from type STRING. If this data type is imported, the existing data type is overwritten and the type of all variables based on it is adjusted. I.e. the variables are now no longer INT variables, but STRING variables.


DBF Import/Export

BACnet32 -> Creating variables -> Creating variables by importing -> DBF Import/Export

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Data can be exported to and imported from dBase.

Import DBF file

To start the import:

  1. right-click on the variable list
  2. in the drop-down menu of Extended export/import... select the Import dBase command
  3. follow the import assistant

The format of the file is described in the chapter File structure.

info Info

Note:

  • Driver object type and data type must be amended to the target driver in the DBF file in order for variables to be imported.
  • dBase does not support structures or arrays (complex variables) at import.

Export DBF file

To start the export:

  1. right-click on the variable list
  2. in the drop-down menu of Extended export/import... select the Export dBase command
  3. follow the export assistant

attention Attention

DBF files:

  • must correspond to the 8.3 DOS format for filenames (8 alphanumeric characters for name, 3 character suffix, no spaces)
  • must not have dots (.) in the path name.
    e.g. the path C:\users\John.Smith\test.dbf is invalid.
    Valid: C:\users\JohnSmith\test.dbf
  • must be stored close to the root directory in order to fulfill the limit for file name length including path: maximum 255 characters

The format of the file is described in the chapter File structure.

info Info

dBase does not support structures or arrays (complex variables) at export.

File structure of the dBase export file

The dBaseIV file must have the following structure and contents for variable import and export:

attention Attention

dBase does not support structures or arrays (complex variables) when exporting.

DBF files must:

  • correspond to the 8.3 DOS format for filenames (8 alphanumeric characters for name, 3 character suffix, no spaces)
  • Be stored close to the root directory (Root)

Design

Description | Type | Field size | Comment
KANALNAME | Char | 128 | Variable name. The length can be limited using the MAX_LAENGE entry in project.ini .
KANAL_R | C | 128 | The original name of a variable that is to be replaced by the new name entered under "KANALNAME" (field/column must be entered manually). The length can be limited using the MAX_LAENGE entry in project.ini .
KANAL_D | Log | 1 | The variable is deleted with the 1 entry (field/column has to be created by hand).
TAGNR | C | 128 | Identification. The length can be limited using the MAX_LAENGE entry in project.ini .
EINHEIT | C | 11 | Technical unit
DATENART | C | 3 | Data type (e.g. bit, byte, word, ...) corresponds to the data type.
KANALTYP | C | 3 | Memory area in the PLC (e.g. marker area, data area, ...) corresponds to the driver object type.
HWKANAL | Num | 3 | Bus address
BAUSTEIN | N | 3 | Datablock address (only for variables from the data area of the PLC)
ADRESSE | N | 5 | Offset
BITADR | N | 2 | For bit variables: bit address For byte variables: 0=lower, 8=higher byte For string variables: Length of string (max. 63 characters)
ARRAYSIZE | N | 16 | Number of variables in the array for index variables ATTENTION: Only the first variable is fully available. All others are only available for VBA or the Recipe Group Manager
LES_SCHR | R | 1 | Write-Read-Authorization 0: Not allowed to set value. 1: Allowed to set value.
MIT_ZEIT | R | 1 | time stamp in zenon (only if supported by the driver)
OBJEKT | N | 2 | Driver-specific ID number of the primitive object comprises KANALTYP and DATENART
SIGMIN | Float | 16 | Non-linearized signal - minimum (signal resolution)
SIGMAX | F | 16 | Non-linearized signal - maximum (signal resolution)
ANZMIN | F | 16 | Technical value - minimum (measuring range)
ANZMAX | F | 16 | Technical value - maximum (measuring range)
ANZKOMMA | N | 1 | Number of decimal places for the display of the values (measuring range)
UPDATERATE | F | 19 | Update rate for mathematics variables (in sec, one decimal possible) not used for all other variables
MEMTIEFE | N | 7 | Only for compatibility reasons
HDRATE | F | 19 | HD update rate for historical values (in sec, one decimal possible)
HDTIEFE | N | 7 | HD entry depth for historical values (number)
NACHSORT | R | 1 | HD data as postsorted values
DRRATE | F | 19 | Updating to the output (for zenon DDE server, in [s], one decimal possible)
HYST_PLUS | F | 16 | Positive hysteresis, from measuring range
HYST_MINUS | F | 16 | Negative hysteresis, from measuring range
PRIOR | N | 16 | Priority of the variable
REAMATRIZE | C | 32 | Allocated reaction matrix
ERSATZWERT | F | 16 | Substitute value, from measuring range
SOLLMIN | F | 16 | Minimum for set value actions, from measuring range
SOLLMAX | F | 16 | Maximum for set value actions, from measuring range
VOMSTANDBY | R | 1 | Get value from standby server; the value of the variable is not requested from the server but from the standby-server in redundant networks
RESOURCE | C | 128 | Resource label. Free string for export and display in lists. The length can be limited using the MAX_LAENGE entry in project.ini .
ADJWVBA | R | 1 | Non-linear value adaption: 0: Non-linear value adaption is used 1: non linear value adaption is not used
ADJZENON | C | 128 | Linked VBA macro for reading the variable value for non-linear value adjustment.
ADJWVBA | C | 128 | Linked VBA macro for writing the variable value for non-linear value adjustment.
ZWREMA | N | 16 | Linked counter REMA.
MAXGRAD | N | 16 | Gradient overflow for counter REMA.

attention Attention.

When importing, the driver object type and data type must be amended to the target driver in the DBF file in order for variables to be imported.

Limit definition

Limit definition for limit values 1 to 4, and status 1 to 4:

Description | Type | Field size | Comment
AKTIV1 | R | 1 | Limit value active (per limit value available)
GRENZWERT1 | F | 20 | Technical value or ID number of a linked variable for a dynamic limit (see VARIABLEx) (if VARIABLEx is 1 and here it is -1, the existing variable linkage is not overwritten)
SCHWWERT1 | F | 16 | Threshold value for limit
HYSTERESE1 | F | 14 | Hysteresis in %
BLINKEN1 | R | 1 | Set blink attribute
BTB1 | R | 1 | Logging in CEL
ALARM1 | R | 1 | Alarm
DRUCKEN1 | R | 1 | Printer output (for CEL or Alarm)
QUITTIER1 | R | 1 | Must be acknowledged
LOESCHE1 | R | 1 | Must be deleted
VARIABLE1 | R | 1 | Dyn. limit value linking the limit is defined by an absolute value (see field GRENZWERTx).
FUNC1 | R | 1 | Function linking
ASK_FUNC1 | R | 1 | With interrogation before execution
FUNC_NR1 | N | 10 | ID number of the linked function (if “-1” is entered here, the existing function is not overwritten during import)
A_GRUPPE1 | N | 10 | Alarm/event group
A_KLASSE1 | N | 10 | Alarm/event class
MIN_MAX1 | C | 3 | Minimum, Maximum
FARBE1 | N | 10 | Color as Windows coding
GRENZTXT1 | C | 66 | Limit value text
A_DELAY1 | N | 10 | Time delay
INVISIBLE1 | R | 1 | Invisible

Expressions in the column "Comment" refer to the expressions used in the dialog boxes for the definition of variables. For more information, see chapter Variable definition.


Online import

BACnet32 -> Creating variables -> Creating variables by importing -> Online import

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com

Variables are created with the driver online import. You will find the command in the context menu of the driver in the driver list.

Parameters | Description
Device | Select the device to be browsed
Button "Browse" | Reads out the variables of the device
Button "Add" | Adds the selected variable to the selection
Button "Remove" | Removes the selected variable from the selection
Button "OK" | Adds the selected variables to the variable list
Button "Cancel" | Cancel the import


Driver variables

BACnet32 -> Creating variables -> Driver variables

The driver kit implements a number of driver variables. These are divided into:

  • Information
  • Configuration
  • Statistics and
  • Error messages

The definitions of the variables defined in the driver kit are available in the import file drvvar.dbf (on the CD in the directory: CD_Drive:/Predefined/Variables) and can be imported from there.

Hint: Variable names must be unique in zenon. If driver variables are to be imported from drvvar.dbf again, the variables that were imported beforehand must be renamed.

info Info

Not every driver supports all driver variants.

For example:

  • Variables for modem information are only supported by modem-compatible drivers
  • Driver variables for the polling cycle only for pure polling drivers
  • Connection-related information such as ErrorMSG only for drivers that only edit one connection at a a time

Information

Name from import | Type | Offset | Description
MainVersion | UINT | 0 | Main version number of the driver.
SubVersion | UINT | 1 | Sub version number of the driver.
BuildVersion | UINT | 29 | Build version number of the driver.
RTMajor | UINT | 49 | zenon main version number
RTMinor | UINT | 50 | zenon sub version number
RTSp | UINT | 51 | zenon service pack number
RTBuild | UINT | 52 | zenon build number
LineStateIdle | BOOL | 24.0 | TRUE, if the modem connection is idle
LineStateOffering | BOOL | 24.1 | TRUE, if a call is received
LineStateAccepted | BOOL | 24.2 | The call is accepted
LineStateDialtone | BOOL | 24.3 | Dialtone recognized
LineStateDialing | BOOL | 24.4 | Dialing active
LineStateRingBack | BOOL | 24.5 | While establishing the connection
LineStateBusy | BOOL | 24.6 | Target station is busy
LineStateSpecialInfo | BOOL | 24.7 | Special status information received
LineStateConnected | BOOL | 24.8 | Connection established
LineStateProceeding | BOOL | 24.9 | Dialing completed
LineStateOnHold | BOOL | 24.10 | Connection in hold
LineStateConferenced | BOOL | 24.11 | Connection in conference mode.
LineStateOnHoldPendConf | BOOL | 24.12 | Connection in hold for conference
LineStateOnHoldPendTransfer | BOOL | 24.13 | Connection in hold for transfer
LineStateDisconnected | BOOL | 24.14 | Connection stopped
LineStateUnknow | BOOL | 24.15 | Connection status unknown
ModemStatus | UDINT | 24 | Current modem status
TreiberStop | BOOL | 28 | Driver stopped For driver stop, the variable has the value TRUE and an OFF bit. After the driver has started, the variable has the value FALSE and no OFF bit.
SimulRTState | UDINT | 60 | Informs the status of Runtime for driver simulation.

Configuration

Name from import | Type | Offset | Description
ReconnectInRead | BOOL | 27 | If TRUE, the modem is automatically reconnected for reading
ApplyCom | BOOL | 36 | Apply changes in the settings of the serial interface. Writing to this variable immediately results in the method SrvDrvVarApplyCom being called (which currently has no further function).
ApplyModem | BOOL | 37 | Apply changes in the settings of the modem. Writing this variable immediately calls the method SrvDrvVarApplyModem. This closes the current connection and opens a new one according to the settings PhoneNumberSet and ModemHwAdrSet.
PhoneNumberSet | STRING | 38 | Telephone number, that should be used
ModemHwAdrSet | DINT | 39 | Hardware address for the telephone number
GlobalUpdate | UDINT | 3 | Update time in milliseconds (ms).
BGlobalUpdaten | BOOL | 4 | TRUE, if update time is global
TreiberSimul | BOOL | 5 | TRUE, if driver in sin simulation mode
TreiberProzab | BOOL | 6 | TRUE, if the variables update list should be kept in the memory
ModemActive | BOOL | 7 | TRUE, if the modem is active for the driver
Device | STRING | 8 | Name of the serial interface or name of the modem
ComPort | UINT | 9 | Number of the serial interface.
Baud rate | UDINT | 10 | Baud rate of the serial interface.
Parity | SINT | 11 | Parity of the serial interface
ByteSize | SINT | 14 | Number of bits per character of the serial interface Value = 0 if the driver cannot establish any serial connection.
StopBit | SINT | 13 | Number of stop bits of the serial interface.
Autoconnect | BOOL | 16 | TRUE, if the modem connection should be established automatically for reading/writing
PhoneNumber | STRING | 17 | Current telephone number
ModemHwAdr | DINT | 21 | Hardware address of current telephone number
RxIdleTime | UINT | 18 | Modem is disconnected, if no data transfer occurs for this time in seconds (s)
WriteTimeout | UDINT | 19 | Maximum write duration for a modem connection in milliseconds (ms).
RingCountSet | UDINT | 20 | Number of ringing tones before a call is accepted
ReCallIdleTime | UINT | 53 | Waiting time between calls in seconds (s).
ConnectTimeout | UDINT | 54 | Time in seconds (s) to establish a connection.

Statistics

Name from import | Type | Offset | Description
MaxWriteTime | UDINT | 31 | The longest time in milliseconds (ms) that is required for writing.
MinWriteTime | UDINT | 32 | The shortest time in milliseconds (ms) that is required for writing.
MaxBlkReadTime | UDINT | 40 | Longest time in milliseconds (ms) that is required to read a data block.
MinBlkReadTime | UDINT | 41 | Shortest time in milliseconds (ms) that is required to read a data block.
WriteErrorCount | UDINT | 33 | Number of writing errors
ReadSucceedCount | UDINT | 35 | Number of successful reading attempts
MaxCycleTime | UDINT | 22 | Longest time in milliseconds (ms) required to read all requested data.
MinCycleTime | UDINT | 23 | Shortest time in milliseconds (ms) required to read all requested data.
WriteCount | UDINT | 26 | Number of writing attempts
ReadErrorCount | UDINT | 34 | Number of reading errors
MaxUpdateTimeNormal | UDINT | 56 | Time since the last update of the priority group Normal in milliseconds (ms).
MaxUpdateTimeHigher | UDINT | 57 | Time since the last update of the priority group Higher in milliseconds (ms).
MaxUpdateTimeHigh | UDINT | 58 | Time since the last update of the priority group High in milliseconds (ms).
MaxUpdateTimeHighest | UDINT | 59 | Time since the last update of the priority group Highest in milliseconds (ms).
PokeFinish | BOOL | 55 | Goes to 1 for a query, if all current pokes were executed

Error messages

Name from import | Type | Offset | Description
ErrorTimeDW | UDINT | 2 | Time (in seconds since 1.1.1970), when the last error occurred.
ErrorTimeS | STRING | 2 | Time (in seconds since 1.1.1970), when the last error occurred.
RdErrPrimObj | UDINT | 42 | Number of the PrimObject, when the last reading error occurred.
RdErrStationsName | STRING | 43 | Name of the station, when the last reading error occurred.
RdErrBlockCount | UINT | 44 | Number of blocks to read when the last reading error occurred.
RdErrHwAdresse | UDINT | 45 | Hardware address when the last reading error occurred.
RdErrDatablockNo | UDINT | 46 | Block number when the last reading error occurred.
RdErrMarkerNo | UDINT | 47 | Marker number when the last reading error occurred.
RdErrSize | UDINT | 48 | Block size when the last reading error occurred.
DrvError | SINT | 25 | Error message as number
DrvErrorMsg | STRING | 30 | Error message as text
ErrorFile | STRING | 15 | Name of error log file


Driver-specific functions

BACnet32 -> Driver-specific functions

This driver supports the following functions:

Protocol

The protocol was defined by the ASHRAE (American Society of Heating, Refrigeration and Air-Conditioning Engineers, Inc.) and is described extensively in the ASHRAE standard 135-2001 + Appendix A – L „A Data Communication Protocol for Building Automation and Control Networks”.

Connection

The BACnet standard offers five options on the data link and physical layers of the OSI layer model (which is reduced to four layers). The driver only supports the option ISO 8802-3, known as “Ethernet”. This option (together with the other layers of the BACnet protocol) is also called “BACnet/IP, Annex J”.

BACnet Layers |  |  |  |  | OSI Layers
BACnet Application Layer |  |  |  |  | Application
BACnet Network Layer |  |  |  |  | Network
ISO 8802-2 Type1 |  | MS/TP | PTP | LonTalk | Data Link
ISO 8802-3 | ARCNET | EIA-485 (RS485) | EIA-232 (RS232) |  | Physical

The communication of this option is based on ISO 8802-2 Type1 (Ethernet) in the data link layer. This means that the PC requires an Ethernet card with connection to a TCP/IP network.

Definition

Term | Description
BAS | BACnet automation station
BAZ | Command output time
COV | Change of Value
DA | Data type
DCS | Double Command State for TK 46
KT | Channel type
OB | Object
RPM | ReadPropertyMultiple

General function description

The BACnet automation station (BAS) is represented as a Device-Object in the BACnet driver. The BAS behaves as a server. For the peer-to-peer data exchange the BACnet driver connects as a client. Each datapoint of the BAS is modeled as a BACnet object. For the data update the COV Subscription as well as the ReadPropertyMultiple (RPM) service can be used. The cycle time for the resubscription as well as the polling interval for the RPM service can be defined in four priority groups (see Configuration of the BACnet driver).

A time synchronization from the BACnet driver in the direction of BAS can be defined.

Establishing connection and exchanging data

As a client the BACnet driver sends the “Who-Is” service to the subnet mask as a broadcast. The existing BAS answers with an “I-Am”. The driver variable of the type “Component status” resembling the name of the device object is set to 0 (OK).

With the service “Who-Has(object_name)” the client gets the BACnet objects of the according server. With the service “I-Have” the server sends the objects (incl. the properties “object_instance” and “object_type”) to the client. Unanswered “Who-Has” services are repeated according to the defined number of retries. If there are BACnet objects that still do not answer with the “I-Have” service, the component status of the according BAS is set to 1 (initializing error). The corresponding object names are written into the log file.

The client then starts the COV subscriptions or RPM services for the existing objects. If the value (present_value) or the status (status_flags) of a COV object changes, the client is informed with a COV notification. Then it requests the time stamp (event_time_stamps) for the according object from the server with the ReadProperty service. With the RPM services the properties Present_Value, Status_Flags and Event_Time_Stamps are cyclically requested from the server.

Send data (Present_Value, Status_Flags, Event_Time_Stamps) are sent to the server with the WritePropertyMultiple service. If one of these properties cannot be written on the server, the server acknowledges this with an error message („Rec_error: WritePropertyMultiple").

Saving value and status

Values, stati and time stamps of the output variables are saved spontaneously. So a data loss in the case of a computer breakdown is avoided. The saved information is read on a restart.

Breakdown monitoring

In order to check the presence of the server the client cyclically sends “Who-Is” telegrams. The cycle time is defined in the driver configuration dialog under BACnet settings.

If the server does not answer with an “I-Am” within a certain time, the interface will be considered as not operative. The corresponding virtual datapoint of the type BACnet component status is set to 64 (NOK). All process datapoints of this BAS are set to disturbed (invalid).

The server announces the reestablishment of the connection with an “I-Am”. The further procedure is the same as the one with the connection establishment.

Access methods

The values of the variables can be read spontaneous or by polling. The type of polling can be selected via the property "priority" of the individual variables
If the hardware allows the reading of time stamps, the variables get these time stamps, otherwise the variables get the time stamps from the driver.

Polling

If the variable property "Priority" is set to "Higher”, "High" or "Highest", the variable values will be polled in the interval defined for the according priority in the driver configuration (page "General"). For this, the BACnet service ReadPropertyMulti (reads the object properties "present_value", "status_flags" and "event_time_stamps") is used.

Spontaneous

If the variable property "Priority" is set to "Normal", the variable values will be read with the BACnet service COV ("change of value"). After the first request of the variable value, a so-called "COV subscription" will be executed, i.e. the according object will be asked to send a COV notification telegram each time the value changes.

The COV subscription is valid for the time defined for the priority "Normal" in the driver configuration. After that time the device will stop sending value changes. If in this case the variable value is still needed, the driver will execute another COV subscription.

After receiving the COV notification of BACnet objects, the properties "present_value" and "status_flags" (FAULT <=> IBit) are read and "event_time_stamps" is requested with the service ReadProperty. If the received time is invalid (0 or 255), the BACnet driver will use the current computer time.

Taking back values from the priority array:

For some object types, you can remove values set by zenon from the BACnet priority array of the variable on the PLC. However, this cannot be achieved directly via the driver; you will need a VBA script for this.

Example for a VBA script:

Sub ResetPrioArray()

Dim Var As Variable

Set Var = Variables.Item("TestVar 0")

Var.SetValueWithStatus 0, 262144, 0, 0 '262144 = Hex 40000, corresponds to the set INVALID bit

End Sub

Limitations

If you launch the driver several times, you will need different UDP ports for every driver. These ports also have to be configurable on the PLCs (BACNet Server).

Priority: The driver sends set values with priority 8


Driver commands

BACnet32 -> Driver commands

This chapter describes standard functions that are valid for most zenon drivers. Not all functions described here are available for every driver. For example, a driver that does not, according to the data sheet, support a modem connection also does not have any modem functions.

Driver commands are used to influence drivers using zenon; start and stop for example.
The engineering is implemented with the help of function Driver commands. To do this:

  • create a new function
  • select Variables -> Driver commands
  • The dialog for configuration is opened

Parameters

Description

Drivers

Drop-down list with all drivers which are loaded in the project.

Current state

Fixed entry which has no function in the current version.

Driver commands

Drop-down list for the selection of the command.
  • Start driver (online mode)

Driver is reinitialized and started.
  • Stop driver (offline mode)

Driver is stopped. No new data is accepted.

Note: If the driver is in offline mode, all variables that were created for this driver receive the status switched off (OFF; Bit 20).

  • Driver in simulation mode

Driver is set into simulation mode.
The values of all variables of the driver are simulated by the driver. No values from the connected hardware (e.g. PLC, bus system, ...) are displayed.
  • Driver in hardware mode

Driver is set into hardware mode.
For the variables of the driver the values from the connected hardware (e.g. PLC, bus system, ...) are displayed.
  • Driver-specific command

Enter driver-specific commands. Opens input field in order to enter a command.
  • Activate driver write set value

Write set value to a driver is allowed.
  • Deactivate driver write set value

Write set value to a driver is prohibited.
  • Establish connection with modem

Establish connection (for modem drivers) Opens the input fields for the hardware address and for the telephone number.
  • Disconnect from modem

Terminate connection (for modem drivers)

Show this dialog in the Runtime

The dialog is shown in Runtime so that changes can be made.

Driver commands in the network

If the computer, on which the driver command function is executed, is part of the zenon network, additional actions are carried out. A special network command is sent from the computer to the project server, which then executes the desired action on its driver. In addition, the Server sends the same driver command to the project standby. The standby also carries out the action on its driver.

This makes sure that Server and Standby are synchronized. This only works if the Server and the Standby both have a working and independent connection to the hardware.


Error analysis

BACnet32 -> Error analysis

Should there be communication problems, this chapter will assist you in finding out the error.


Error analysis

BACnet32 -> Error analysis -> Error analysis

Logging

You can choose to log the entire telegram traffic between the BACnet driver and the BAS (see BACnet32_DiagnosticSetting).

Data is stored in the file <runtimepath>\RT\FILES\zenon\custom\drivers\BACnet.log

For Editor communication (browsing), the following file is used: <SQLpath>\<ProjektGUID>\FILES\zenon\custom\drivers\BACnet.log.


Analysis tool

BACnet32 -> Error analysis -> Analysis tool

All zenon modules such as Editor, Runtime, drivers, etc. write messages to a joint log file. To display them correctly and clearly, use the Diagnosis Viewer program that was also installed with zenon. You can find it under Start/All programs/zenon/Tools 7.00 -> Diagviewer.

zenon driver log all errors in the log files. The default folder for the log files is subfolder LOG in directory ProgramData, example: C:\ProgramData\zenon \zenon700\LOG for zenon version 7.00 SP0. Log files are text files with a special structure.

Attention: With the default settings, a driver only logs error information. With the Diagnosis Viewer you can enhance the diagnosis level for most of the drivers to "Debug" and "Deep Debug". With this the driver also logs all other important tasks and events.

In the Diagnosis Viewer you can also:

  • follow currently created entries live
  • customize the logging settings
  • change the folder in which the log files are saved

Hints:

  1. In Windows CE even errors are not logged per default due to performance reasons.
  2. The Diagnosis Viewer displays all entries in UTC (coordinated world time) and not in local time.
  3. The Diagnosis Viewer does not display all columns of a log file per default. To display more columns activate property Add all columns with entry in the context menu of the column header.
  4. If you only use Error logging, the problem description is in column Error text. For other diagnosis level the description is in column General text.
  5. For communication problems many drivers also log error numbers which the PLC assigns to them. They are displayed in Error text and/or Error code and/or Driver error parameter(1 and 2). Hints on the meaning of error codes can be found in the driver documentation and the protocol/PLC description.
  6. At the end of your test set back the diagnosis level from Debug or Deep Debug. At Debug and Deep Debug there are a great deal of data for logging which are saved to the hard drive and which can influence your system performance. They are still logged even after you close the Diagnosis Viewer.

info Info

You can find further information on the Diagnosis Viewer in the Diagnose Viewer chapter.


Check list

BACnet32 -> Error analysis -> Check list

Is the PLC connected to the power supply

Are the participants available in the TCP/IP network

Can the PLC be reached via the PING command

Can the PLC be reached via TELNET

Are the PLC and the PLC connected with the right cable

Did you select the right COM port

Do the communication parameters match (Baud rate, parity, start/stop bits,...)

Is the COM port blocked by another application

Did you configure the net address correctly, both in the driver dialog and in the address properties of the variable

Did you use the right object type for the variable

Does the offset addressing of the variable match the one in the PLC

Use the DiagViewer for further analysis -> Which messages does it show


PICS (Protocol Implementation Conformance Statement)

BACnet32 -> PICS (Protocol Implementation Conformance Statement)

Previous chapter Next chapter Show all Show all Hide all Hide all
© Ing. Punzenberger COPA-DATA GmbH. For any questions regarding the documentation please contact: documentation@copadata.com
Date | September 21, 2005
Vendor Name | COPA-DATA GmbH
Product Name | BACnet-driver for process control system (HMI/SCADA)
Product Model Number: | Version 6.20 SP1
Applications Software Version | 6.20.1
BACnet protocol Revision | 2

Product Description

The BACnet driver allows communication and data exchange between one or more BACnet-capable devices and the SCADA-Runtime. Therefore it’s required that the connected BACnet devices are operating as servers. In the BACnet driver only the Client functionality is implemented.

BACnet Standardized Device Profile (Annex L):

X | BACnet Operator Workstation (B-OWS)
 | BACnet Building Controller (B-BC)
 | BACnet Advanced Application Controller (B-AAC)
 | BACnet Application Specific Controller (B-ASC)
 | BACnet Smart Sensor (B-SS)
 | BACnet Smart Actuator (B-SA)

Additional BACnet Interoperability Building Blocks Supported (Annex K):

DS-RP-A, DS-RPM-A, DS-WP-A, DS-WPM-A, DS-COV-A, DM-DDB-A, DM-DOB-A, DM-TS-A, DM-UTC-A, SCHED-A

Segmentation Capability:

Segmented requests supported Window Size _____________

Segmented responses supported Window Size _____________

Standard Object Types Supported:

Analog-Input, Analog-Output, Binary-Input, Binary-Output, Multi-State-Input, Multi-State-Output, Schedule, Device

Object definitions

1. Analog Input

Property | Client uses
Present_Value | R
Status_Flags | R
Event_Time_Stamps | R

2. Analog Output

Property | Client uses
Present_Value | W
Status_Flags | W
Event_Time_Stamps | W

3. Analog Value

Property | Client uses
Present_Value | R / W
Status_Flags | R / W
Event_Time_Stamps | R / W

4. Binary Input

Property | Client uses
Present_Value | R
Status_Flags | R
Event_Time_Stamps | R

5. Binary Output

Property | Client uses
Present_Value | W
Status_Flags | W
Event_Time_Stamps | W

6. Binary Value

Property | Client uses
Present_Value | R / W
Status_Flags | R / W
Event_Time_Stamps | R / W

7. Multi State Input

Property | Client uses
Present_Value | R
Status_Flags | R
Event_Time_Stamps | R

8. Multi State Output

Property | Client uses
Present_Value | R
Status_Flags | R
Event_Time_Stamps | R

9. Multi State Value

Property | Client uses
Present_Value | R / W
Status_Flags | R / W
Event_Time_Stamps | R / W

10. Schedule

Property | Client uses
Effective_Period | R / W (as String)
Weekly_Schedule | R / W (as String)
Exception_Schedule | R / W (as String)

11. Device

Property | Client uses
Local_Date | W
Local_Time | W

Data Link Layer

X | BACnet/IP, (Annex J)
 | BACnet/IP, (Annex J), Foreign Device
 | ISO 8802-2, Ethernet (Clause 7)
 | ASTM 878.1, 2.5Mb. ARCNET (Clause 8)
 | ASTM 878.1, RS485 ARCNET (Clause 8), baud rate(s): _______
 | MS/TP master (Clause 9), baud rate(s): _______
 | MS/TP slave (Clause 9), baud rate(s): _______
 | Point-To-Point, EIA 232 (Clause 10), baud rate(s): _______
 | Point-To-Point, modem (Clause 10), baud rate(s): _______
 | LonTalk, (Clause 11), medium: _______
 | Other

Networking Options

Router, Clause 6 - Routing configurations: ___________

Annex H, BACnet Tunneling Router over IP

BACnet/IP Broadcast Management Device (BBMD)

Character Sets supported

X | ANSI X3.4
 | IBM /Microsoft DBCS
 | ISO 8859-1
 | ISO 10646 (ICS-4)
 | ISO 10646 (UCS2)
 | JIS C 6226

Optional Service-Parameters Supported

ReadProperty, ReadPropertyMultiple, WriteProperty, WritePropertyMultiple, SubscribeCOV, COVNotification, Who-Is, I-Am, Who-Has, I-Have, TimeSynchronization, TimeUTCSynchronization