CALL NOW CALL NOW CALL NOW GATEWAY SELECTOR CALL NOW GATEWAY SELECTOR LEARN MORE LEARN MORE PROCEED TO CHECK-OUT SUBSCRIBE TO OUR RSS FEED SEARCH GATEWAYS NOW SEND MESSAGE SUBMIT

Modbus to BACnet EZ Gateway (1,000 point)

The EZ Gateway Modbus and BACnet (FS-EZX-MOD-BAC) is an easy to use, high-performance building and industrial automation protocol gateway.
The BACnet Master-Slave/Token-Passing (MSTP) driver implements a data link protocol that uses the services of the RS-485 physical layer.
The BACnet/IP driver allows the FieldServer to transfer data to and from devices over Ethernet using BACnet/IP protocol.
Modbus Serial over RS232 or RS485. We have all variants of this protocol.
The Modbus TCP Driver allow the FieldServer to transfer data to and from devices over Ethernet using Modbus TCP Protocol.
SKU:
FS-EZ2-MOD-BAC
Max Points: 500, 1000
22-14-31-40_EZ_Gateway_mod_bac__56634.1456960708.1280.1280.png - /2017/jun/22-14-31-40_EZ_Gateway_mod_bac__56634.1456960708.1280.1280.png

EZ Gateway (Modbus to BACnet)

The EZ Gateway Modbus and BACnet (FS-EZX-MOD-BAC) is an easy to use, high-performance building and industrial automation protocol gateway for integrators to interface Modbus certified products to BACnet management systems in commercial buildings, campuses, and industrial facilities. Modbus-certified products encompass a wide range of applications such as energy, gas, heating, water, VFD drives, and PLCs. The EZ Gateway Modbus to BACnet integrates such Modbus-based devices and systems to BACnet-based management systems over BACnet MS/TP or BACnet/IP protocols.

The EZ Gateway Modbus and BACnet combines field-hardened Modbus and BACnet protocol drivers with an easy to use configuration interface. The EZ Gateway’s Modbus interface is compatible with all Modbus-certified products, while the EZ Gateway’s BACnet interface has been certified by BACnet Test Laboratory (BTL) at Version 12. The intuitive web-based interface allows configurations to be built in the field or in the office, thereby simplifying the commissioning and integration process.

Sierra Monitor’s unique FieldServer DeviceProxy™ feature allows each Modbus device to be presented as a corresponding virtual BACnet device within the EZ Gateway, thereby providing granular visibility and control over each Modbus device from within a BACnet management framework. For example, offline/online status is visible at the individual Modbus device level.

With the EZ Gateway Modbus to BACnet, the integrator or contractor does not need to be a protocol expert and can minimize configuration and commissioning time, while also reducing ongoing operating and maintenance costs.

BACnet MSTP

The BACnet Master-Slave/Token-Passing (MS/TP) driver implements a data link protocol that uses the services of the RS-485 physical layer. See the FieldServer BACnet PIC statement for the level of conformance that this driver implements.

All information in a BACnet system is represented in terms of objects. The Object_Identifier is a 32-bit code that identifies the type of Object (also identified by the Object_Type Property) and its "Instance" number, which together uniquely identify the Object within its BACnet device. Theoretically, a BACnet device could have over four million Objects of a particular type. The Object_Name is a text string, which has a unique capability. BACnet devices may broadcast queries for devices that contain Objects with a specific Object_Name. This can greatly simplify project setup.

BACnet requires one Device Object to be present in every BACnet device. The Device Object makes information about the device and its capabilities available to other devices on the networks. Before one BACnet device starts control-related communications with another, it needs to obtain some of the information presented by the other device's Device Object. Unlike other Objects, the Device Object's Instance number must be unique across the entire BACnet internetwork because it is used to uniquely identify the BACnet devices. It may be used to conveniently identify the BACnet device from other devices during installation.

Standard object types are used to hold real time data and other information. Each Object Type is referenced by a number, for example 0 represents an Analog Input.

Each Object consists of a number of prescribed properties, the main property being the Present_Value. Objects are monitored and controlled through their properties. The Analog Input Object is representative of the Objects involved directly with control elements and many of its Properties reflect this.

The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer.

BACnet IP

The BACnet/IP driver allows the FieldServer to transfer data to and from devices over Ethernet using BACnet/IP protocol. The FieldServer can emulate either a Server or Client.

All information in a BACnet system is represented in terms of objects. The Object_Identifier is a 32-bit code that identifies the type of Object (also identified by the Object_Type Property) and its "Instance" number, which together uniquely identify the Object within its BACnet device. Theoretically, a BACnet device could have over four million Objects of a particular type. The Object_Name is a text string, which has a unique capability.

BACnet devices may broadcast queries for devices that contain Objects with a specific Object_Name. This can greatly simplify project setup.

BACnet requires one Device Object to be present in every BACnet device. The Device Object makes information about the device and its capabilities available to other devices on the networks. Before one BACnet device starts control-related communications with another, it needs to obtain some of the information presented by the other device's Device Object. Unlike other Objects, the Device Object's Instance number must be unique across the entire BACnet internetwork because it is used to uniquely identify the BACnet devices. It may be used to conveniently identify the BACnet device from other devices during installation.

Standard object types are used to hold real time data and other information. Each Object Type is referenced by a number, for example 0 represents an Analog Input. See Appendix D.1 for abbreviation list.

Each Object consists of a number of prescribed properties, the main property being the Present_Value. Objects are monitored and controlled through their properties.

The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer.

Modbus TCP

The Modbus TCP Driver allows the FieldServer to transfer data to and from devices over Ethernet using Modbus TCP Protocol. The Modbus TCP driver uses port 502. This port is not configurable. The driver was developed for Modbus Application Protocol Specification V1.1a" from Modbus-IDA. The specification can be found at www.modbus.org. The FieldServer can emulate both a Client and a Server simultaneously on the same ethernet port.

The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer.

There are various register mapping models being followed by various vendors. To cover all these models FieldServer uses the following three Models

  • Modicon_5digit – Use this format where addresses are defined in 0xxxx, 1xxxx, 3xxxx or 4xxxx format. A maximum of 9999 registers can be mapped of each type. This is FieldServer driver’s default format.
  • ADU –Application Data Unit address. Use this format where addresses of each type are defined in the range 1-65536
  • PDU –Protocol Data unit address. Use this format where addresses of each type are defined in the range 0-65535.

The key difference between ADU and PDU is for example if Address_Type is ADU and address is 1, the driver will poll for register 0. If Address_Type is PDU, the driver will poll for address 1.

Note 1: If vendor document shows addresses in extended Modicon (i.e. 6 digit) format like 4xxxxx then consider these addresses as xxxxx (omit the first digit) and use either ADU or PDU

Note 2: The purpose of providing 3 different ways of addressing the Modbus registers is to allow the user to choose the addressing system most compatible with the address list being used. At the protocol level, the same protocol specification is used for all three with the exception of the limited address range for Modicon_5digit.

Modbus RTU

The Modbus RTU driver allows our FieldServer gateways to transfer data to and from devices over either RS-232 or RS-485 using Modbus RTU protocol. The Gateways are capable of being used as port expanders and can emulate either a Server or Client. The FieldServer is capable of supporting devices that use two Modbus Registers to transfer IEEE floating point format.


The information that follows describes how to expand upon the factory defaults provided in theconfiguration files included with the FieldServer.


There are various register mapping models being followed by various vendors.


  • To cover all these models FieldServer uses the following three Models
  • Modicon_5digit – Use this format where addresses are defined in 0xxxx, 1xxxx, 3xxxx or 4xxxxformat. A maximum of 9999 registers can be mapped of each type. This is FieldServer driver’sdefault format.
  • ADU –Application Data Unit address. Use this format where addresses of each type are definedin the range 1-65536
  • PDU –Protocol Data unit address. Use this format where addresses of each type are defined inthe range 0-65535.

The key difference between ADU and PDU is for example if Address_Type is ADU and address is 1, thedriver will poll for register 0. If Address_Type is PDU, the driver will poll for address 1. 


Specifications

EZ Gateway (Modbus to BACnet)

Environment
  • Operating Temperature: -40 to 75oC (-40 to 167oF)
  • Relative Humidity: 5-90% RH non-condensing
Power Requirements

9-30V DC or 12-24V AC
Current draw: @ 12V

  • FS-EZX-MOD-BAC: 240 mA
Physical Dimensions
  • Dimensions (WxDxH): 4.5x2.9x1.6 in. (11.5x7.4x4.1cm
  • Weight: 0.4 lbs (0.2 Kg)
  • Input voltage: 24 V DC nominal: 10-30V DC
Other

Configuration/Diagnostic utilities

  • Capacity: 500 points FS-EZ1-MOD-BAC. (1000 points FS-EZ2-MOD-BAC)
  • Table, Wall or DIN rail mount
Communication
  • Baud: 4800, 9600, 19200, 38400, 57600, 115200
  • Start Bit: 7, 8
  • Stop Bit: 1, 2
  • Parity: Even, Odd, None
  • Ethernet: 10/100 BaseT MDIX
Approvals
  • TUV Approved: to UL 916, EN 60950-1, EN 50491-3 and CSA C22.2 standards
  • BTL Mark:
  • RoHS Compliant
  • GOST-R Certified
  • CE and FCC
Dimensions

Block Diagrams

imports/blockDiagrams/LP Modbus.jpgimports/blockDiagrams/LP Modbus.jpg

Additional Information

Modbus - Protocol Specifications
Modbus - Reading Vendor Modbus Maps

Reading Vendor Modbus Maps

 

If you are reading the documentation for sensor blocks, valves, and other devices, you must keep in mind that some vendors may document their hardware in different ways.

According to the Modbus standard, addresses are simply integers from 0 to 65,535 with the different address ranges being referred to as coils, holding registers, etc. However, some vendors will document their hardware using numerical prefixes which are not actually part of the Modbus address. This originated from some models of PLCs which used the Modbus communications protocol, and which also used numerical prefixes in their internal data table. This is similar to using “I”, “Q”, “V”, etc. as address prefixes in IEC type PLCs.

However, it is important to remember that these numerical prefixes are documentation methods and are not part of what the Modbus protocol itself sends as part of the messages. A difference in documentation methods does not affect the compatibility of the protocol itself.

These prefixes are they mentioned anywhere in the Modbus standard, but the following shows how they are typically used in documentation based on this older convention:

  • 0xxxx – Coils.
  • 1xxxx – Discrete inputs.
  • 3xxxx – Input registers.
  • 4xxxx – Holding registers.

Note that there is no 2xxxx address prefix.

In addition to numerical prefixes, some documentation will refer to protocol addresses (addresses start at 0), while other documentation will refer to data model addresses (addresses start at 1). That is, the first holding register may be 0 or 1 (or 40000 versus 40001 using prefixes). However, this has no bearing on what gets sent over the wire as a Modbus message. For a Modbus protocol message, the lowest address is always “0”, not “1”.

Modbus - MK10 and 32 Bits Numbers

Scaling in Modbus

Modbus does not provide a method for transporting large or Floating Point numbers or a mechanism for scaling analog values. A 16 bit word can only contain values in the range 0-65535. Only whole numbers are permitted. To work around this many server device manufacturers use multipliers and document them in their manuals. For example, to report a temperature of 58.5 the device reports a value of 585, and makes a note in the manual that the master should scale by 10. This scaling is achieved by adopting a convention between the client and the server.
What about large numbers > 65535
Modbus does not provide a mechanism but 3 important schemes are widely used.

Long Integers – Two consecutive 16 bit words are interpreted as a 32 bit long integer.

MK10 values – Two consecutive words are used. The 1st reports the number of units and the 2nd reports the number of 10,000’s.

Floating Point Numbers – Two consecutive words are used and a scheme. These schemes are conventions and not all servers or clients support them.

The protocol does not identify these big numbers. Only the vendor docs do.
What we mean by this is – if you look at the byte stream in a Modbus message there is no way of telling whether you are looking at two consecutive 16 bit words, or two consecutive words that should be interpreted as floating point, long or MK10 formats. Because of this you always have to look to the vendor docs.

ModbusRTU - Free Booklet
ModbusRTU - ModbusTCP - Port Expansion

Port Expansion

FieldServer can easily be configured to allows a Modbus RTU client to talk to a ModbusTCP server and vice versa. You do not need to tell the FIeldServer which registers to map from one to the other. You simply configure the FieldServer telling it which port and protocol to use for each node.

 

In port expansion mode configuration can be moinimal. Tell the gateway which nodes are on which port and set the port settings.

ModbusRTU - Scaling and Bit Packing

Scaling / Bit Packing

FieldServers can scale data and manipulate values using some binary logic and arithmetic functions. Scaling can be applied to each block of Modbus Data read / served.

  • Move to change type : Convert from any FIeldServer Data Type to any other.
  • Move to pack/unpack bits and bytes: It’s possible to address each bit in a 8,16 or 32 bit data element by using the packed data types.
  • Move to change byte/word order: Handle the endianess of the remote system easily.
  • Convert to/from Float, MK10, IEE754, 32 bit, 16 bit, 8 bit numbers
  • Move conditionally:
  • Perform Arithmetic Operation: + – * div sqrt, sqr ,
  • Perform Binary Logic Operation: And, Or, Not, >, >= , <, <=

 

Most functions can be configured to occur on a configurable period or on update of the data source.

 

ModbusRTU - Supported Data Types

Supported Data Types

Bit

Byte

16 Bit Integer Signed

16 Bit Integer Unsigned

32 Bit Integer Signed

32 Bit Integer Unsugned

32 Bit Packed Bit

8 Bit Packed Bit

4 byte FLoating Point Numbers

ModbusRTU - Supported Functions

Supported Modbus Functions

01 Read Discrete Output Status (0xxxx)
02 Read Discrete Input Status (1xxxx)
03 Read Output Registers (4xxxx)
04 Read Input Registers (3xxxx)
05 Force Single Coil (0xxxx)
06 Preset Single Register (4xxxx)
15 Force Multiple Coils (0xxxx)
16 Preset Multiple Registers (4xxxx)

Modbus - Flavors of Modbus

Flavors of Modbus

RTU:

Common
Binary Protocol.
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers, CAS gateways

 

ASCII:

Similar to ModbusRTU but for each byte in an RTU message, there are 2 bytes in an ASCII message. The 2 bytes are the humand readable form of the single hex byte.
Eg RTU byte = 0x03 (Hex). ASCII bytes = ‘0’ and ‘3’ ie 0x30 and 0x33
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers

 

Jbus:

Modbus had the limitation of a max of 9999 items of each type. Ie only 9999 holding registers. However the protocol message allows 65k items to be addressed. JBUS allows all 65k items to be read/written. Other than that it is identical to RTU
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers, CAS gateways

 

TCP/IP:

Uses TCP/IP connection based Ethernet communications
Encapsulates RTU messages and adds a header.
A single slave can respond to multiple masters
Many slaves ignore the NodeID field in the message.
Supported by FieldServers, QuickServers, CAS gateways

 

MB Plus:

Proprietary coax networking layer
2 Mbits/sec
Supported by FieldServers, CAS gateways

Modbus - MK10 and 32 Bits Numbers

Scaling in Modbus

Modbus does not provide a method for transporting large or Floating Point numbers or a mechanism for scaling analog values. A 16 bit word can only contain values in the range 0-65535. Only whole numbers are permitted. To work around this many server device manufacturers use multipliers and document them in their manuals. For example, to report a temperature of 58.5 the device reports a value of 585, and makes a note in the manual that the master should scale by 10. This scaling is achieved by adopting a convention between the client and the server.
What about large numbers > 65535
Modbus does not provide a mechanism but 3 important schemes are widely used.

Long Integers – Two consecutive 16 bit words are interpreted as a 32 bit long integer.

MK10 values – Two consecutive words are used. The 1st reports the number of units and the 2nd reports the number of 10,000’s.

Floating Point Numbers – Two consecutive words are used and a scheme. These schemes are conventions and not all servers or clients support them.

The protocol does not identify these big numbers. Only the vendor docs do.
What we mean by this is – if you look at the byte stream in a Modbus message there is no way of telling whether you are looking at two consecutive 16 bit words, or two consecutive words that should be interpreted as floating point, long or MK10 formats. Because of this you always have to look to the vendor docs.

Modbus - Reading Vendor Modbus Maps

Reading Vendor Modbus Maps

 

If you are reading the documentation for sensor blocks, valves, and other devices, you must keep in mind that some vendors may document their hardware in different ways.

According to the Modbus standard, addresses are simply integers from 0 to 65,535 with the different address ranges being referred to as coils, holding registers, etc. However, some vendors will document their hardware using numerical prefixes which are not actually part of the Modbus address. This originated from some models of PLCs which used the Modbus communications protocol, and which also used numerical prefixes in their internal data table. This is similar to using “I”, “Q”, “V”, etc. as address prefixes in IEC type PLCs.

However, it is important to remember that these numerical prefixes are documentation methods and are not part of what the Modbus protocol itself sends as part of the messages. A difference in documentation methods does not affect the compatibility of the protocol itself.

These prefixes are they mentioned anywhere in the Modbus standard, but the following shows how they are typically used in documentation based on this older convention:

  • 0xxxx – Coils.
  • 1xxxx – Discrete inputs.
  • 3xxxx – Input registers.
  • 4xxxx – Holding registers.

Note that there is no 2xxxx address prefix.

In addition to numerical prefixes, some documentation will refer to protocol addresses (addresses start at 0), while other documentation will refer to data model addresses (addresses start at 1). That is, the first holding register may be 0 or 1 (or 40000 versus 40001 using prefixes). However, this has no bearing on what gets sent over the wire as a Modbus message. For a Modbus protocol message, the lowest address is always “0”, not “1”.

Modbus - Protocol Specifications
Modbus - Flavors of Modbus

Flavors of Modbus

RTU:

Common
Binary Protocol.
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers, CAS gateways

 

ASCII:

Similar to ModbusRTU but for each byte in an RTU message, there are 2 bytes in an ASCII message. The 2 bytes are the humand readable form of the single hex byte.
Eg RTU byte = 0x03 (Hex). ASCII bytes = ‘0’ and ‘3’ ie 0x30 and 0x33
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers

 

Jbus:

Modbus had the limitation of a max of 9999 items of each type. Ie only 9999 holding registers. However the protocol message allows 65k items to be addressed. JBUS allows all 65k items to be read/written. Other than that it is identical to RTU
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers, CAS gateways

 

TCP/IP:

Uses TCP/IP connection based Ethernet communications
Encapsulates RTU messages and adds a header.
A single slave can respond to multiple masters
Many slaves ignore the NodeID field in the message.
Supported by FieldServers, QuickServers, CAS gateways

 

MB Plus:

Proprietary coax networking layer
2 Mbits/sec
Supported by FieldServers, CAS gateways

BACnet MSTP to IP

A BACnet Router is used to connect MSTP trunks to BACNetIP systems. The router itself is a device on the IP and on the MSTP side. The router can also act as BBMD device allowing messages to cross from one subnet to another.

BACnet BBMD

BACnet messages cannot cross from one subnet to another except under special circumstances.

Most BACnet sequenc es of messages begin with a broadcast called 'who is'. All devices respond with 'I am'. That is how they are discovered. It is also how many system confirm the device is still there.

Broadcasts can't cross routers (they are blocked) and therefore devices on the other side of a router cannot e discovered.


BBMD is the name of the BACNet technology that resolves these issues. The BACNet ROuter sold by CAS provides BBMD services as do all FieldServer BACNet products when configured as clients.

Articles

Modbus - Minimum Function Implementation
Modbus - Convert between Modbus Flavors
Modbus - Digitrip 3000
Modbus - C#
Modbus - Modhopper
Modbus - 32 bit numbers
How Real (Floating Point) and 32-bit Data is Encoded in Modbus RTU Messages
Table 2 Modbus Registers
Table 2 Modbus Registers
Modbus - TCP
Modbus - Minimum Function Implementation
Modbus - Convert between Modbus Flavors
Modbus - Digitrip 3000
How Real (Floating Point) and 32-bit Data is Encoded in Modbus RTU Messages
Modbus - C#
Modbus - Modhopper
Modbus - 32 bit numbers
ModbusTCP - Modbus Transaction Identifier
Modbus - There are (were) a Max of 9999 points of each data type
ModbusTCP - What type of protocol is Modbus TCP
ModbusTCP - What functions can be performed by Modbus TCP to retrieve information from a device
ModbusTCP - What do you have that can help me convert my Modbus TCP data
ModbusTCP - What is the minimum subset of functions that a Modbus slave device should implement
ModbusTCP - We want to check the communication between our device and personal computer, so we need the 232 communication software
ModbusTCP - If I am converting from Modbus to Modbus, how difficult is it to Convert Serial (RTU) to TCP/IP and TCP/IP to Serial (RTU)
ModbusTCP - Can you give me an example of a Modbus/TCP to BACnet/IP configuration
ModbusTCP - How can I use Modbus Scanner to Write Registers of Digitrip 3000 (Protective Relays) Controls
Modbus - What is Modbus? (extended article)
Modbus - What is the Modbus Transaction Identifier
Modbus - Can you give me a list of Useful tools and applications for Modbus
Modbus - How do I Test Modbus communication
Modbus Scanner - What News Do You Have Regarding The CAS Modbus Scanner
Using PuTTY for serial COM connections (HyperTerminal replacement)
Modbus: Testing Modbus communication
Low Power Wireless Modbus
Modbus FAQ
FS-8704-03 – Modbus TCP
Modbus: Minimum Function Implementation
Modbus Protocol Specification
Modbus Specifications and Implementation Guides
MODBUS Exception Responses
RS485 Networks – Multiple Protocols
BACnet MSTP Installation, RS485 and Cables
BACnet MSTP Topology (RS485)
What can go wrong with 485 and BACnet MSTP ?
BACnet MSTP (RS485) – Bandwidth usage
Segmentation in BACnet

Logos

imports/logos/Logo Modbus.jpg
imports/logos/Logo Modbus.jpg
imports/logos/Logo bacnet1.jpg
imports/logos/Logo BTL Bacnet Test Lab.jpg
imports/logos/Logo bacnet1.jpg
imports/logos/Logo BTL Bacnet Test Lab.jpg

Gateway Selector

Select your combination of protocols.
Protocol 1
Protocol 2

Related Products

Contact Us

Contact us via phone (+1 866-383-1657) or leave a detailed message below for sales, support, or any other needs

*Required Field
I'd like to receive the newsletter. *Check email for confirmation.
*Required Field
Preferred Time To Be Contacted (PST)
8:00am - 12:00pm 12:00pm - 5:00pm