Part 1

The Building Automation Control Network (BACnet) protocol is not new to building management systems. Its development began in 1987, in 1995 it became the ANSI/ASHRAE standard and in 2003 it was standardized in ISO 16484-5. In process stations, however, it appears only gradually, especially for its not quite easy implementation. As with any communication protocol, the creators were looking for the optimum point between a quick and cost-effective implementation on a variety of hardware types and a simple, understandable application in practice. Thus, unlike relatively simple communication protocols such as Modbus, a number of services and objects are defined in BACnet that make it easier for application engineers to work in programming and commissioning technologies.

If we want to get acquainted with the BACnet protocol from the PLC programmer’s point of view, a complete description of the standard, which has more than 1300 pages in the 2016 edition, would probably discourage us. Norm makes more sense for a beginner as a reference book than a textbook. Let’s look at BACnet as a measurement and control technician, who is not so interested in the particular form of telegrams, but rather in the relationship of BACnet to the concepts we know from the PLC world.

BACnet uses the client-server model, so we must always distinguish whether certain hardware works as a BACnet client or a BACnet server. It is possible for one device to support both functions, but this is not common – except for programmable PLCs. To put it simply, the server contains objects, the client reads it and writes into it.

BACnet objects and properties

The BACnet server contains data in the form of objects. BACnet defines 60 standard object types, such as an analog value, a time program, a trend log, or a group of lifts. Some objects, as we can see, have a clear link to building management. A BACnet object is a structure that has several BACnet properties. A property is basically a variable that is of a defined type, has a name, and takes some value.

To distinguish objects of the same type within the device, each has a unique Instance Number. Thus, the unique identification of an object on a device consists of the object type and its instance number. Assuming a BACnet input module with 8 analog inputs, it will most likely contain Analog Input 1 to Analog Input 8 objects.

The objects are grouped in a “container”, a BACnet device. There can only be one object of this type in a hardware device, such as a PLC. The device also has some features. These define communication options in particular, and the BACnet client reads them first to know how to communicate optimally with the server.

Fig. Structure of BACnet objects and properties in hardware

An example of BACnet device properties is shown in the following figure:

Fig. Device object properties

The table is a screenshot of the BACnet client, the Yabe program, which is used as a BACnet device explorer. The program found the BACnet server on the network and read the BACnet device and its properties. Property names are in the left column, their values in the right column. One of the properties is Local Time, its value says that the real-time clock in the BACnet server shows 13:36:03. Later we will see that some features are required by standard, others are optional – even if the device does not, it still complies with the standard. Some properties may be required only under certain conditions: For example, the Local Time property is only required if the device contains a real-time clock.

An important property of the device is the Object List property. It is a list of all the objects that the device contains and which the client can then query. The table shows a part of the list of objects with their object types and instance numbers. For example, it is clear from indexes 4 and 5 that the device contains, among other things, two Binary Output objects with instance numbers 1 and 2. This is enough for the client to ask them in other queries and have their properties listed.

Even the properties are standardized. The norm specifies nearly 500 of them. Each property has its own text identifier, property identifier, as well as a number: for example, the most commonly used property of the object, present value, which, for example, bears the measured temperature at the temperature sensor, is 85. The table shows the standardized properties of the Analog Value object:

Fig. Properties of the Analog Value Object Type. Source: ISO 16484-5, (C) ISO 2016

The table shows the name of the property (eg Present Value), its type (here REAL) and whether it is a read-only (R), read-only and writable (W) or optional (O). The property numbers in the table are not listed, but it is good to know because many visualization programs allow you to set the used property by number to define the data points – it is probably easier than a long drop-down box with hundreds of properties (which would still lack of specific features that manufacturers can define arbitrarily, see below). Notes for optional variables – superscripts – specify the conditions under which, for example, optional properties become mandatory, limit their ranges, etc.

Variable types are either simple, such as Real, CharacterString, Boolean, Enumerated, etc., or BACnet-specific – for example, BACnetPriorityArray. Their detailed description would be found in the norm, we will not deal with it now.

Equipment designers can define their proprietary properties in addition to the object standard. These are used, for example, to define the location of an object in a hierarchical structure (tree) so that clients can display variables in a structured way by technology, and not just all of them clearly below each other.

Fig. Proprietary properties. Source: BACnet Browser Test Sequencer User’s Manual, (C) Siemens

According to the standard, Property ID numbers up to 511 are reserved for standard properties defined by the standard, numbers from 512 above can be used for specific, custom properties. In the figure above, we see properties with Property ID (first column) of 3000 and above. These are typical of Siemens implementation.

BACnet services

So we have a device containing objects. But how to read them? This is what BACnet thinks about and defines so-called services. They are actually standardized functions for working with data – they determine the format of queries and answers. Some services have somewhat bizarre names, such as Who-Is, I-Am, Who-Has, I-Have – these are used to detect and explore devices and objects. For others, the function is evident from the naming: Read-Property and Write-Property are obviously used to read and write individual properties in objects. Services are not so interesting to us, they are more important for driver programmers than for application engineers. However, their names appear in the Wireshark listing, so it is useful to know them as we will see later.

There are about 40 services and in addition to working with variables, it also solves functions such as alarm acknowledgment, time synchronization, dynamic creation and deletion of objects, as well as file transfer or data transfer using a terminal. File transfer can be used, for example, to play an application program.

In the next section, we will try using services to explore the objects that are contained in the device.

The post BACnet – a brief introduction to the basics appeared first on Domat International.

Exploring the BACnet server by the client

The most common task we are facing is to integrate data from a BACnet server (such as a heat pump) into some client software – either a visualization or a PLC that uses that data for a regulatory task. For other protocols, such as Modbus, we need a table from the server manufacturer with address and value descriptions – their formats, types, meanings, etc. BACnet server, due to its services, objects and their properties, can request this information to a certain extent to provide itself.

BACnet can use different buses for communication. Next, we focus on BACnet/IP. Suppose that a BACnet server is a device that has an Ethernet interface with a known IP address. In our case it will be PLC with IP address 192.168.1.17. The computer with the BACnet explorer client, in this case the Yabe program, has an IP address of 192.168.1.44 – the address is set to be in the same logical network. BACnet communicates on UDP protocol, the server listens on UDP port 47808 by default. This port number is reserved by IANA, and has been chosen to be remembered in hexadecimal form – BAC0.

Start Yabe and select Add device from the menu by right clicking on Devices.

Fig. Yabe – Add device

In the dialog, select the local network interface in the BACnet/IP over UDP field to be used by the program.

Fig. Yabe – Search

This is an important step. The IP address (Local Endpoint) is the outgoing address from which queries will be sent to the network. For example, if we selected the IP address of the Wi-Fi interface, the request packet would not reach the BACnet server at all. The BAC0 port is the destination port on the BACnet servers to which queries are directed. (The local port from which queries are sent is automatically assigned by the operating system from the list of free ports.) Click on Add button to confirm the selection.

Yabe sends several Who-Is search queries. The transmission channel (UDP port 47808) and the device found there appear in the tree.

Fig. BACnet devices in YABE

Wireshark is used for packet analysis. If everything works, we will not need it – the following figure is for illustration only. The “bacnet” parameter (green field at the top) was used as a filter, removing most of the other packets that occurred on the network interface from the list. In the blue field, BACnet packet listing, we see that the client with IP address 192.168.1.44 has sent a query using Who-Is as broadcast (broadcast is identified by the destination address being – in this IP network – 192.168.1.255). To this broadcast, more exactly to the question “is there a BACnet device?” addressed to all devices in the logical network, I-Am (“I am here”) answered the only device: PLC with IP address 192.168.1.17. (We see that the query was repeated three times with an interval of 1 second, and the same response came each time.)

The telegram of the query is further analyzed in the left window. More interesting is the answer in the box on the right. We can see there how the server revealed itself,

• that it contains a Device object with instance number 1;
• that the Maximum APDU Length Accepted parameter is 1476 (whatever it means);
• supports segmentation in both directions (dtto);
• that the device manufacturer is Domat Control System – it is identified by the (again standardized) Vendor ID, in this case 384.

Interestingly: Vendor ID is assigned free of charge by ASHRAE. By the end of 2019, almost 1,200 of them were allocated, of which 13 were companies from the Czech Republic. This number is used to identify the manufacturer of the equipment.

Fig. Question Who-Is and Answer I-Am

The client then usually initiates further communication and asks for other properties of the Device object, for a list of objects on the device, for properties of objects and their values, etc. Then the data can be viewed in a tree structure. If you leave Wireshark on, you will see the appropriate questions and answers in its window. We can also change the properties that are writable from the Yabe client.

Fig. View the contents of BACnet devices by the Yabe client

In the right Yabe window are the properties of the object and their values. Most likely we will be interested in the Present Value property, which in the case of Analog Input indicates the measured value, here 23.56. The Units property specifies that the value is in °C and therefore it menas temperature value, again using standardized numbering (62 means °C). The complete description and enumerations of engineering units can be found in the standard, but a “decent” client translates the unit number as here to a symbol or text (“Degrees Celsius”).

Another useful feature is Description. There we usually find what the object actually represents. Typical text in this property is “Outside Temperature”, “tNabehZapad”, “Otacky privod” (it means reverse lead), etc.

What if it doesn’t work?

I don’t know the IP address of the BACnet server

If it is in the same logical network as the client’s BACnet address, detection may still occur. However, we recommend that you check the address with your vendor or programmer to make sure that other network parameters (mask, gateway, UDP port) are set correctly.

The address is on the same network, but the client does not detect anything

Broadcasts can be blocked by a firewall on the computer running the client. Let’s temporarily disable firewall and virus protection. Broadcasts also do not have to pass through a router or VPN: it is better to use a switch for attempts. It can also help to disable or disconnect other – unused – network interfaces, such as wi-fi cards, VPNs, etc. Let’s check in Wireshark that the client is sending telegrams as broadcasts on the same network as the server: correct broadcast address 192.168.1.255.

Broadcasts leave correctly, but the client doesn’t detect anything

Some BACnet servers may (unreasonably for norm) require that port 47808 is used also on the client side as outbound. If the client allows it, try to set the port on it.

For other BACnet clients, the procedure is similar, some programs do not broadcast network broadcasts and require the specific IP address of the BACnet server to communicate with.

So we can already explore objects in a “hand-held” client. However, as we set up communication in a PLC development environment or visualization, we may encounter other parameters we haven’t encountered yet. We’ll look at them in the next section.

The post BACnet – a brief introduction to the basics pt. 2 appeared first on Domat International.

When deploying room units UI011, room controllers UC/FC…, as well as 3rd party devices talking Modbus, there appears a problem how to write into variables which are also controlled locally – over a knob, touch schreen, or other manual control.

We will take a UI011 room unit as an example – please, read the whole article here.

The post Coupling hardware I/O points appeared first on Domat International.

Basic settings in Merbon IDE

Just to be clear, let’s remind you that this part is about configuring the BACnet client, ie “reading” values from the BACnet server. (Of course, the client can also write to objects and properties that support writing.) It is important that the operation is initiated by the client. In order for the PLC as a client to be able to ask the server about specific objects and properties, we must enter these values as parameters of individual communication data points in the Merbon IDE when creating the application.

When defining variables, we proceed similarly to other communication protocols: first we create a communication channel in the PLC:

Fig. Establishment of a BACnet channel in the Merbon IDE

For the channel, fill in only the name, enable it (Enable = True), select the BACnet protocol and select (as the only option) the UDP transport protocol.

We insert the device into the channel.

Fig. Establishment of BACnet device in Merbon IDE

These settings apply to the Device object, it is the base object on the device with which we will communicate. In its parameters we specify the Device object instance in the BACnet server, usually 1, and the network address type – None. Other types of network addresses are ready for future expansion for other communication media.

The UDP parameters contain the IP address of the BACnet server and its UDP port. The local port is assigned automatically if 0 is entered. We change the local port number only if the server requires it, see above.

Gig. UDP ports for BACnet communication. The client is PLC Domat with Merbon Runtime.

The next step is to define a group of I/O points:

Fig. Establishment of the BACnet Group in the Merbon IDE

Practically nothing essential is set in the group except the type (here Read Only), it only serves as a “container” for I/O points. For other protocols, some common properties of the contained I/O points are usually defined in the group.

Next, you can define individual I/O points:

Fig. Creating an I/O point in the Merbon IDE

The basic parameters are Object Type and Object Instance. We will learn these values just by examining the server or they will be provided by the supplier in the form of a table. In most cases, the Property ID will be the Present Value. The value type is basically determined by the object type and by the property – for analog inputs, outputs and values, it will be Real type for the current value. For standard properties, the type is predefined, so it cannot be confused. The same type must be selected at the top in ST Type (marked in red).

In order to automatically create a global variable for the I/O point in the PLC, we check whether the Autogen function is enabled and whether the current project in the PLC is selected as the target project.

We will not deal with other parameters now, we can add other I/O points – or we will compile the project, upload it to the PLC and test how it communicates:

Fig. Successful communication with BACnet server

For study reasons, we can also look at communication through Wireshark. But it will only work if we use Merbon Runtime on Windows on the same PC as Wireshark instead of PLC. Why?

It is because the switch that optimizes communication on the network and always sends packets only to its ports (connectors), which are behind the destination addresses. If the switch is connected to a BACnet server device on one port, a BACnet client on the second PLC port, and a Wireshark notebook on the third port, BACnet communication takes place only between the first and second port. To scan packets, we would have to use either a hub – an older device that copies all traffic to all its other ports, or a configurable switch set to send all data from the other ports to one of the ports.

So successful communication looks like this:

Fig. Reading the analog value of BACnet in Wireshark

We can see that the client uses the Read Property Multiple service – to read more values (although only one has yet to be defined in the PLC). In the telegram of the response (from server to client) we can trace the Present Value, in the Real format (highlighted in blue at the bottom). The rising number after the service name (123…129) is the so-called Invoke ID, which the server copies into the response so that the client is able to match responses to the sent queries.

In the next section, we will write down the values.

The post BACnet – a brief introduction to the basics part 3 appeared first on Domat International.

Dear business partners,

we would like to invite you to our Merbon SCADA webinar, which will be taken in English language on our YouTube Channel.

LIVE STREAM HERE.

Date: 23th April 2020 from 09:00

Webinar will contain information about:

• Introduction to Merbon SCADA
• Deifferences between RcWare Vision and Merbon SCADA
• Installation
• Project editing and export
• Configuraion and user policy
• Compatibility with RcWare Vision
• Configuraion of Alarm server and Messaging services

The record of the online training will be published later on our YouTube channel and our web site.

The post Merbon SCADA webinar – in english appeared first on Domat International.

Writing values, priorities

In the previous section, we integrated an object of type Analog Input, ie an analog value. It is a good idea to start with a known quantity, such as the room temperature, because the real number is clearly visible at first glance, sometimes changes and can be easily checked, unlike, for example, binary values.

In the vast majority of cases, we will only need a few basic types of objects:

• Analog Input, Analog Value, Analog Output,
• Multistate Input, Multistate Value, Multistate Output,
• Binary Input, Binary Value, Binary Output,
• Schedule – a separate chapter will be devoted to this.

For Schedule objects, … Value and … Output objects, it is also possible to write to the Present Value property. It makes sense, the Analog Value can store the required temperature, for example, and the Binary Output is, for example, a relay output that can be remotely controlled.

This brings us to the issue of writing.

For other, simpler communication protocols, it is simply the case that if a variable is writable, the value changes when a write request is made. Write protection can be provided, for example, by some login using a username and password: once the client is logged in, it can set a variable. If there are several entries in a row (even from different clients), the value entered last applies. We are used to it and it is logical and understandable.

BACnet has these mechanisms addressed differently, through priorities. There are a total of 16 priorities and they are, as usual, standardized. (At least some.) The smaller the number, the higher the priority:

Tab. Priority BACnet

Blank priority names are freely usable, the device manufacturer can name them according to their needs. We can already see from the names that if the variable is controlled by a program with priority 15, ie quite low, and the operator would switch it over the control panel (ie priority 8), this control by the counter will take precedence. A step higher authority is, for example, the switch on the switchboard connected to the PLC input, which would have priority 7 – manual override by the operator “from the place”. However, even more important is, for example, the overheating of the exchanger reported by the emergency thermostat, which would probably have priority 5, ie a critical override of the technology automatically.

Each writable object has two mandatory properties: Priority_Array (priority field) and Relinquish_Default (default value when released). This can be seen, for example, in the Analog Output object:

Fig. Properties for priorities for an object of type Analog Output. Source: ISO 16484-5, (C) ISO 2016

The priority field has 16 positions for storing values of the same type as the Present_Value object (for Analog_Output it is type Real). This is because if a priority is included in the enrollment request, the new value is written to the appropriate position for that priority. (Writing can be done without specifying a priority, then it is automatically considered the lowest priority request.)

Fig. Examples of entries with and without priority

Figure a) shows the priority field of the object to which the value 23 with priority 8 has been written, Manual Operator Unit. This corresponds, for example, to a situation where the valve is set to 23 % from the control panel. The output, Present_Value, of this object is set to 23 because there is no entry on any of the higher priorities (1 to 7).

In the next step, a process, such as a control loop, writes a value of 19 to this object. This write is without a priority setting, so it is considered the lowest priority action (16). The value 19 is written to the appropriate item of the priority field, but this does not affect Present_Value, ie the output of this object – the value 23 % is stronger on priority 8. This situation is shown in Fig. b).

Now there will be an automatic write, let´s say from the procedure for emergency shutdown of the exchanger. With priority 5 (ie Critical Equipment Control, as we see in the table above), the value 0 is written. Because this is the record with the highest priority so far, the Present_Value of the object is set to 0 and the valve closes. (Fig. c).

What happens when the emergency situation disappears? The emergency procedure transfers control to normal regulation with lower priorities by releasing the priority: it writes a special “empty” value to the appropriate priority (here 5), symbolized by a dash in the figure. This gives up its reassignment and “it doesn’t care what comes out.” The situation in Fig. b) occurs again and the highest non-empty value from the top is at the output of the object, ie a manual intervention of 23 %. If the operator canceled the manual override from the counter, the output would be the value from the control loop that wrote with the lowest priority, ie 19 %.

If all 16 priorities have an “empty” value, the object output value will be Relinquish_Default.

In this way, BACnet elegantly aligns with the various priorities of write requests without the need for complex process logic in the program. For us, however, this means that if we are not entirely sure with what priority we can write, let’s choose write without priority (in Merbon IDE “Not specified”). Otherwise, we could significantly interfere with the function of the device. It is not possible to send the priority release from the PLC or visualization, resp. there is no way for the PLC to “self” determine when the priority should be released. It is an automatic write with predefined properties, only the written value changes.

It is similar with the BACnet client Promotic, which has the option of selecting the priority for writing directly in the definition dialog of the variable:

Fig. Variable definition in Promotic visualization

For visualization, we can set the priority ourselves, for the required values (temperatures, pressures, humidity, etc.) the notation without priority would probably be used. If the priorities are equal, the last value entered from any device applies.

Interesting fact: the settings from the local Siemens PXM20-E counter on the switchboard use priority 8 – manual override from the control panel. The data point is then displayed in the manual state (assembly key symbol). When released from the manual state, the counter writes NULL with priority 8, thus releasing the manual state.

In the last picture we see for illustration part of the answer to the question Read Property Multiple. An object (of the Multistate Value type, which is not visible in the viewport) has a current value (Present Value) of 1, because its only occupied priority is 16, just with a value of 1. Other, higher priorities are released, each has NULL value in the report.

Fig. Priorities in the Wireshark listing

All parts can be found HERE.

The post BACnet – a brief introduction to the basics part 4 appeared first on Domat International.

We store all webinars for you on our youtube channel HERE.

There you will now find a record of the online Merbon SCADA training (in English) from April 23, 2020.

You can find all planned webinars in our event calendar.

We look forward to the next online meeting.

Domat Control System team

The post Recorded Merbon SCADA webinar appeared first on Domat International.

COV – Change of Value

COV, or Change of Value, is a mechanism by which network traffic is optimized. In general, the client would like to have the most up-to-date data from the server. This would mean that he would have to query variables over and over again, and would most likely receive the same values as in previous queries, because the values of the variables usually do not change as often. At the same time, it would burden the network and the server with unnecessary queries.

Therefore, BACnet allows you to use the COV service. It is not a mandatory function, each manufacturer decides whether to support it or not. If the client wants to use the COV service, it sends a subscription request to the server to subscribe to reports that the value of a property of an object has changed. The server receives it, registers the client and sends a message to the client when the appropriate value changes. Therefore, the client does not have to inquire periodically, it is just waiting for information about the change, the so-called notification. This should reduce the frequency of queries while increasing the speed of transfer of changes from the server to the client. If the client is no longer interested in the update, he can cancel the registration – for example, if the user switched to another page in the visualization or left the menu on the control panel.

Upon registration, the client will also request whether the notification should be unconfirmed or confirmed. For an unconfirmed server, it sends data and does not determine if the client has received it. This means less load for both the server and the network, but the information may not reach the client. When the notification is acknowledged, the server expects the client to acknowledge receipt of the data. If this does not happen within a certain time (timeout), the notification is repeated. This means greater transmission reliability, but at the same time a greater burden on the network and both participants in the communication.

Fig. Successful application for COV registration

The figure above shows a communication listing in which in packet 45 the client requests a COV registration for the Analog Input 0 object. In packet 46, the server acknowledges this registration (Simple-ACK) and then sends the first notification in package 47 with the property values of this object. We see that this is an unconfirmed notification – another packet, 52 and beyond, is already dealing with the reading of another object, Analog Input 4.

If a confirmed notification is registered, the client, after receiving it, responds to the server with a confirmation message: in packet 14 the server sends the current values immediately after registration, in packet 15 the client confirms this notification:

Fig. Notification confirmation

On the contrary, the following figure shows a situation where the server does not support the COV service and rejected the registration request (Reject: Unrecognized Service). The client then no longer resolves the COV and periodically reads the current value of the Analog Input 4 object using the Read Property service.

Fig. Rejected application for COV registration

How does the server determine when to send a notification? For binary or multistate (integer) variables, it is clear when the change occurred: instead of True, False or vice versa, the integer is at least 1 larger or smaller. However, for variables of the real type, it must be determined how much change is to be considered significant enough to trigger a notification (sending a notification at the slightest change in analog value would probably burden the line even more than regular polling without COV). The COV Increment parameter is used for this.

This is a mandatory property for objects that support COV. Therefore, the notification is sent only if the value change since the last notification is greater than the COV Increment.

COV Increment has the server set as a reasonable default value, but it can also be specified by the client as an optional parameter in the registration request. For values such as temperature, a typical COV Increment is 0.1 ° C.

The application for registration contains, among other things, the identification of the object whose data the client is interested in and the time for which the registration is to last. After this time, it is assumed that the server deletes the registration so that it does not unnecessarily keep the old, no longer current in the registration memory. On the contrary, the client should renew the registration periodically, preferably in advance.

Examples of registration times and renewal periods for some clients:

Tab. Examples of COV timing

However, the BACnet standard does not specify what the longest required registration time can be for a client (it can also be “infinity”). If the server supports COV, it should accept a registration time of at least 8 hours. However, it is not prescribed that the server would have to maintain registrations even after a power failure. Although the server can store registrations in memory, which is not deleted when restarted, but then there is a risk that a large number of registrations for an infinitely long time will fill its memory over time – so it is necessary to define rules for periodic memory cleanup. Therefore, situations may occur when, for example:

• the client successfully requests registration, for example, for 12 hours, after a few minutes the server is restarted, while the registrations are deleted. The client lives in the belief that it would receive notifications, however, it does not receive information about new values,

• the client registers without confirmation a large number of values ​​for a long time, after which a situation occurs in the server when a large number of changes occur suddenly (short-term power failure, closing hundreds of fire dampers, etc.). The client is not able to process incoming changes and data may be lost,

• clients register a large number of values, but do not cancel the registration – the server must either allocate enough memory to store all requests or eventually begin to reject new requests.

• etc.

We must take these properties into account when designing networks and considering the reliability of communication. It always depends on how good the implementation of BACnet in a given device is.

All parts can be found HERE.

The post BACnet – Brief Introduction to the Basics Part 5 appeared first on Domat International.

We would like to inform you that we will be hosting a webinar on working in the Merbon IDE environment, which will take the form of a live stream on YouTube.

Term: April 30, 2020 from 9 am

Link to live stream HERE.

You do not need to be signed in to YouTube to watch the webinar. However, to ask questions and comment on chat, it is necessary to log in, without this function is not available.

During the webinar you will be introduced to the Merbon IDE and its differences from the SoftPLC IDE. The training will take place on the new regulators of the mark series.

The post Webinar – Merbon IDE Training for beginners appeared first on Domat International.

In systems with fan coils, heat exchangers are often used alternately for heating and cooling. In a classic two-pipe connection with change-over, the whole building (or at least a branch) has to work with one type of energy – it can either heat or cool. In modern buildings, however, the requirements for heating and cooling in rooms are often very different or contradictory, and it is in these cases that the use of a four-pipe system with one exchanger can help. It is very elegant in these cases the use of a six-way valve. However, this requires a special control signal: in one 0 … 10 V sequence, the part is reserved for heating and the part for cooling. There is a dead band between them. The sequence is therefore divided into three working parts:

• heating sequence (H 100% … H 0%)
• dead band (H 0% … C 0%)
• cooling sequence (C 0% … C 100%).

The positions of the start and end points of the individual parts are determined by four constants. Their values are adjustable so that the output can be connected to any type of six-way valve actuator. In the Modbus table FCR013 we can find it in registers 149 to 152, for each output AO1 and AO2 separately.

Heating and cooling sequence in the controller output signal

If we want the output AO1 or AO2 to work in the mode for the six-way valve, it must be set in the Modbus register 148. The default setting is 0.5 … 4.5 V for heating and 5.5 … 9.5 V for cooling. If neither the heating sequence nor the cooling sequence is active, the output is halfway between the zero values for heating and cooling, so by default it will be 5 V at the output. Each of the outputs has its own parameter settings. Details are given in the Modbus table FCR013. In the setting of the FCR013 controller, the voltage values are rounded to 0.1 V.

Different valve and actuator manufacturers have different actuator setting logics: sometimes the lower voltage range is for heating, other times for cooling, for some types of actuators the sequences can be reversed, usually by setting DIP switches. It is therefore a good idea to check the default settings of the drive before installation, and either adjust the parameters in FCR013 accordingly or describe the required settings on the drive in the implementation project.

For example, for the Siemens VWG41.20-1.6-2.5 (DN20) valve, the characteristic looks like this:

Fig .: Characteristics of the valve VWG41.20-1.6-2.5 (Source: Siemens)

Note that for heating (A-C) the valve has a different Kv value than for cooling (B-C). This is related to the heat output of the exchanger – during heating, the medium has a larger temperature drop and therefore a smaller flow rate is sufficient for the required output. The valve is used in conjunction with an actuator, eg GDB161.9E, whose dependence of the angle of rotation on the control voltage is linear. The valve has a 24 V supply, 0 … 10 V control, an ASK77.3 adapter must be used.

The individual points for setting FCR013 and the drive 0 … 10 V are then calculated as follows:

voltage [V] = angle [°] / 90 * 10

Similarly, the following relationship applies to the 2 … 10 V drive:

voltage [V] = angle [°] / 90 * 8 + 2

and thus for GDB161.9E:

Tab.: Setting points FCR013 for VWG41.20-1.6-2.5 with GDB161.9E actuator

Attention, the valve of the same series, but with DN10, has a different characteristic! (The points are at angles of 15°, 30°, 60° and 75°, see the valve data sheet.) When designing and commissioning, always check this with the valve and actuator supplier and set the appropriate constants in the controllers accordingly.

Belimo R30 … B2 valves have the recommended cooling sequence as the first sequence to change.

The table with parameters FCR013 then looks like this (suitable drive Belimo LR24A-SR is controlled by voltage 2 … 10 V):

Tab .: Points for setting FCR013 for R30 … B2 with LR24A-SR actuator

Another member of the six-way valve family is VBG6 from Honeywell. As in the previous cases, in the catalog sheet we find the angles of rotation that correspond to the individual points and calculate the relevant parameters. On the left is the cooling sequence, on the right the heating. Note that the direction of rotation of the valve is counterclockwise – the more we turn to the left, the larger the angle.

Fig. Characteristics of valve VBG6 (Source: Honeywell)

We must not forget to set the drive, if the drive allows it. The figure shows the default setting of the Honeywell MR6-024-010 actuator for the Honeywell VBG6 six-way valve.

Fig. Honeywell MR6-024-010 drive settings (Source: Honeywell, highlight: author)

The default parameters are marked in red and in this setting they suit us, except for the direction of rotation. See figure with positions above: from 0° to 90°, the valve rotates counterclockwise. We have two options: either switch the direction of rotation on the drive (DIP1 = OFF), or set the parameters in FCR013 so that 10 V corresponds to 0°.

Tab.: Points for setting FCR013 for VBG6 with drive MR6-024-010

From a practical point of view, it will be more appropriate to leave the default settings of the switches on the drive and adjust the parameters in FCR013. When replacing the drive, there is no need to reset anything to the initial state, while when replacing the controller, the entire set of parameters is played anyway – setpoints, input logic settings, etc.

Concluding remark: with the exact beginnings and ends of the sequences, this will not be so critical, because the drives still have a certain hysteresis. That’s why the deadband is so large, actually a third to a quarter of the working range of the drive. The main thing is that with zero energy demand, the drive is not in a position that represents a non-zero flow. This should fulfill the functions of transitioning to the center of the deadband. The precise control of the room temperature is finally ensured by the PI algorithm in FCR013, which, thanks to the feedback from the room temperature sensor, “tightens” the position so that the actual temperature corresponds exactly to the required one. Above all, we must make sure that the required direction of rotation is observed and verify during commissioning whether hot water actually flows into the register when heating is required and vice versa. We thus control the work not only of ourselves, but also of our suppliers of heating and cooling.

The post New function of fancoil controller FCR013 for control of six-way valves appeared first on Domat International.

Internships are nowadays an integral part of student life. In electrical engineering and IT, this is doubly true. Students will kill more birds with one stone: they will get to know the work environment and gain valuable experience that will be useful not only in their CV, they will establish contacts with people from the field, they will often solve compulsory practices, and they will earn some money.

In our company, many collaborations began in this way, during which the interns gradually became our internal employees, who, thanks to the acquired knowledge, more easily fit into the normal work process.

In order to show you a little about what such cooperation can look like, we interviewed our colleague Ondra, who started as an intern in the Development and Technical Support department. Now, he works in the same department as a software developer.

THE INTERVIEW COULD BE FOUND HERE.

The post From intern to employee: interview with our colleague Ondra S. appeared first on Domat International.

Due to the current crisis, it was not possible to organize Light + Building 2020, originally planned for March. Therefore, it was decided to postpone this leading world fair to a later date, at the turn of September and October 2020.

After reconsidering the current situation, the 11th Light + Building will finally take place in accordance with the usual sequence – from 13 to 18 March 2022.

Domat participates in the fair regularly, so we believe that in 2022 we will not be missing either.

In the meantime, we look forward to seeing you in March 2021 at the Amper trade fair in Brno and the ISH trade fair in Frankfurt.

Thank you for your understanding.

Domat Control System team

The post Light + Building 2022 appeared first on Domat International.

Although the Modbus standard was defined more than 40 years ago, the protocol still provides reliable and fast communication between programmable logic controllers, sensors, thermostats, frequency converters and other devices. Either the RS485, RS422, RS232 interface (Modbus RTU) or the TCP/IP Ethernet protocol (Modbus TCP) can be used for data transfer. The open Modbus communication protocol is based on a master/slave or client/server architecture. There are several advantages to this protocol – it is simple, fast, independent of the manufacturer/PLC and easy to implement. This is evidenced by the fact that after the advent of the Ethernet standard and the IP protocol, Modbus was implemented in the relational layer protocol.

We therefore have two main modes of data transfer:

• Modbus RTU – information transfer takes place via a serial line, usually an RS232 or RS485 interface
• Modbus TCP – information transfer takes place via TCP/IP in the Ethernet network

In practice, communication works in such a way that there is a “master” device (control element, eg PLC or industrial PC) on the bus, which sends queries. On the other hand, we have a “slave” device (monitored element, eg sensor, PLC, measuring device) that answers these questions. In the case of Modbus TCP, there may be more interrogating devices, at lower layers of the network the interrogations are serialized.

Both protocols, Modbus TCP and Modbus RTU, can be connected by a communication gateway.

Typical use of the Modbus protocol is for I/O modules, such as RCIO, RXIO or MLIO. One query can read or write a whole set of values – all inputs or outputs of the module, which optimizes communication on the line. Modbus is also one of the most used protocols for room controllers – radiators, fan coils or VAV systems (eg UC102, FCR010 or FCR015). Thanks to its extension and easy configuration, Modbus is also used as a protocol for the connection between specific buses and protocols and PLC or visualization. Converters are used as communication gateways, eg R091 for control of lights via the DALI bus, R065 for control of lights via the DMX standard, or R085 for integration of Landis & Gyr I/O modules on the P-Bus.

When designing and reviving serial buses communicating via the Modbus protocol, we sometimes come across situations where it would be advantageous to switch from a serial line to an Ethernet network and further transmit data over it. We have described it in more detail in our two-part routing series HERE.

For PLC and SCADA programmers, but also for others interested in integrated systems with Modbus RTU and TCP protocols, we regularly organize Modbus communication training. After completing it, participants are able to specify, design and enliven the communication between a foreign Modbus device and a PLC or visualization.

The post Modbus communication protocol appeared first on Domat International.

We already have all webinar records in their CZ and EN variants stored on our youtube channel.

You will find there:

• Merbon IDE for beginners 
• Merbon IDE for advanced
• Merbon SCADA

The post All online webinar in one place appeared first on Domat International.

Room and duct CO2 sensors for building control systems are based mostly on the NDIR (Nondispersive Infrared) measuring elements. They measure the diffusion of infrared light caused by the presence of CO2 molecules in the measuring chamber.

The whole article could be found HERE.

The post Autocalibration of CO2 sensors appeared first on Domat International.

A properly functioning technical support department is an essential part of any company that wants to offer any technology. Today’s products are not trivial, whether they are programmable substations or building materials such as sealants and adhesives. To deploy them, it is necessary to know a number of rules and procedures. We learn something from manuals, something from training, but sometimes it happens that we are stuck. Then it is support’s turn. In the following, we will look at how Domat Control System technical support works and how you should proceed to get the most out of it.

THE WHOLE ARTICLE COULD BE FOUND HERE.

The post How to communicate with technical support? appeared first on Domat International.

Dear Business Partners,

We would like to inform you about the new version of the software Merbon IDE 2.4.0.11 published on our website.

For more information and download links click HERE.

We ask all users who already have a version of Merbon IDE installed on their computer to use only the current version of Merbon IDE. The current version includes bug fixes for several bugs found and also fixes to improve program stability.

Records of Merbon IDE webinars for beginners and advanced can be found on our Youtube HERE.

The post New version of Merbon IDE 2.4.0.11 appeared first on Domat International.

Dear business friends,

We would like to inform you about the release of new firmware 2.4.0.11 for HT200.

More information could be found HERE.

Data sheet for HT200 could be found HERE.

The post New firmware 2.4.0.11 for HT200 appeared first on Domat International.

Dear business friends,

We would like to inform you about the webinar on Merbon SCADA, which will take place on our YouTube channel.

LIVE STREAM HERE.

Date: June 18, 2020 from 9 am

The training program will build on the previous training and will be an extension and additional information to the current Merbon SCADA training.

The webinar recording will later be published on the YouTube channel and on our website.

The post Merbon SCADA advanced appeared first on Domat International.

In our offer, you have definitely come across the M710 digital counter module. Another new product is its updated version – R710.

It is a microprocessor-controlled, communicative 4 binary input counter module. The module uses Modbus RTU on a RS485 bus for communication, and can be easily integrated in a variety of supervision and control systems. In addition to the overall redesign, it has added DIP switches for setting the address, which can be set physically directly on the module and the user no longer needs a computer for such settings.

You can download the data sheet HERE.

The post Product news: digital counter module R710 appeared first on Domat International.