DNP 3.0 Serial to Modbus RTU Multiport Gateway

A FieldServer protocol gateway that provides data exchange between DNP 3.0 Serial and Modbus RTU.
The Multiport Gateway provides a wealth of features to enable data transfer between different devices and networks.
The DNP3.0 Serial driver allows the FieldServer to transfer data to and from devices over RS-232 or RS-485 using DNP3.0 protocol.
Modbus Serial over RS232 or RS485. We have all variants of this protocol.
SKU:
FS-B3510-0769
01-12-01-14_B3510 Angled scaled down and sqrd WT BG.png - /2017/aug/01-12-01-14_B3510 Angled scaled down and sqrd WT BG.png

Multiport Gateway (Serial-Ethernet-LonWorks)

This protocol translator/gateway provides a wealth of features to enable data transfer between different devices and networks utilizing serial, Ethernet or LonWorks ports. The extensive library of FieldServer drivers provides easy interoperability with devices and networks used in building automation, HVAC, fire and process control industries.

The FS-B3510 is one of the FS-X30 Series FieldServers designed to meet the needs of system integrators in designing a complete interoperable system. The FS-B30 Series brings together the powerful FieldServer driver library with state-of-the-art gateway design. This FieldServer includes four serial connections (two RS-232, two RS-485), two Ethernet ports, and a LonWorks port. The multiport design allows for serial-to-serial interfaces or interface from mulitple serial products to an Ethernet or LonWorks network. The two Ethernet ports enable the integrator to connect a PC to download configuration changes without disturbing the system connections and without the additional cost of an external hub.

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. 


DNP3.0 Serial

The DNP3.0 Serial driver allows the FieldServer to transfer data to and from devices over RS-232 or RS485 using DNP3.0 protocol. The FieldServer can emulate either a Server or Client. When the FieldServer is a Server (slave), only one Client (master) can communicate to it. The DNP3.0 Serial Driver adheres to and supports the framework specified by the IEEE 1815-2012 Standard for electrical power system communications.

The following information was copied from the DNP3 User Group Internet site

The development of DNP3 was a comprehensive effort to achieve open, standards-based Interoperability between substation computers, RTUs, IEDs (Intelligent Electronic Devices) and master stations (except inter-master station communications) for the electric utility industry. Also important was the time frame; the need for a solution to meet today's requirements. As ambitious an undertaking as this was, we reached this objective. And since the inception of DNP, the protocol has also become widely utilized in adjacent industries such as water / waste water, transportation and the oil and gas industry.

DNP3.0 is based on the standards of the International Electrotechnical Commission (IEC) Technical Committee 57, Working Group 03 who have been working on an OSI 3 layer "Enhanced Performance Architecture" (EPA) protocol standard for telecontrol applications. DNP3.0 has been designed to be as close to compliant as possible to the standards as they existed at time of development with the addition of functionality not identified in Europe but needed for current and future North American applications (e.g. limited transport layer functions to support 2K block transfers for IEDs, RF and fiber support). DNP3.0 has been selected as a Recommended Practice by the IEEE C.2 Task Force; RTU to IED Communications Protocol.

DNP3.0 is an open and public protocol. In order to ensure interoperability, longevity and upgradeability of, protocol the DNP3.0 Users Group has taken ownership of the protocol and assumes responsibility for its evolution. The DNP3.0 Users Group Technical Committee evaluates suggested modifications or additions to the protocol and then amends the protocol description as directed by the Users Group members.

DNP3 Features:

DNP3 offers flexibility and functionality that go far beyond conventional communications protocols. Among its robust and flexible features DNP3 includes:

  • Output options
  • Secure configuration/file transfers
  • Addressing for over 65,000 devices on a single link
  • Time synchronization and time-stamped events
  • Broadcast messages
  • Data link and application layer confirmation

DNP3 was originally designed based on three layers of the OSI seven-layer model: application layer, data link layer and physical layer. The application layer is object-based with objects provided for most generic data formats. The data link layer provides for several methods of retrieving data such as polling for classes and object variations. The physical layer defines most commonly a simple RS-232 or RS-485 interface. DNP3 is very efficient for a layered protocol while ensuring high data integrity.

DNP3 Benefits:

Because DNP3 is based on the IEC 870-5 requirements, DNP3 is suitable for application in the entire SCADA environment. This includes RTU to IED communications, master to remote communications, and even peer-to-peer instances and network applications. It permits multiple masters and encourages distributed intelligence.

Users can expect many benefits from using DNP3. In the short term:

  • Interoperability between multi-vendor devices
  • Fewer protocols to support in the field
  • Reduced software costs
  • No protocol translators needed
  • Shorter delivery schedules
  • Less testing, maintenance and training
  • Improved documentation
  • Independent conformance testing
  • Support by independent users group and third-party sources (e.g. test sets, source code)
I'd like to inquire about the DNP 3.0 Serial to Modbus RTU Multiport Gateway FS-B3510-0769. Please provide me with a quote for this product.

Specifications

Multiport Gateway (Serial-Ethernet-LonWorks)

Field Connections
  • Ethernet Ports – 2: 100 BaseT RJ45 connector (auto MDIX and sensing) with ESD protection
  • Serial Ports – 5: 2 x RJ45 RS-232 galvanically isolated with ESD protection. 2 x RS-485 galvanically isolated with ESD protection. 1 x RJ45 RS-232 system port.
  • LonWorks – 1: FTT-10 twisted pair. 1000 Network variable capability. LonWorks service pin
  • Auxiliary ports – 2: 2 x USB ports. Expansion: Fieldbus connectors available for selected protocol
Environment
  • Operating Temperature: 0-60°C  (32-140°F)
  • Relative Humidity: 10-90% non-condensing
Power Requirements

24V AC (+/-10%) or 12-30V DC @ 12W

Physical Dimensions
  • Dimensions (WxDxH): 6.3x5.4x2.0 in.(16.0x13.7x5.0cm)
  • Weight: 2.5 lbs (1.5 Kg)
  • Input voltage: 24 V DC nominal: 10-30V DC
Other

Configuration/Diagnostic utilities

  • Capacity: Base system has 1000 point capability (upgradeable to 10,000 points)
  • Mounting Options: Desktop, Wall, Panel Optional: DIN rail
LED Indicators

Power, Run, System Error, Configuration Error, and Node Offline

Ethernet connection– Link OK, Tx/Rx communication activity

RS-232/RS-485 – Tx/Rx communication activity

LonWorks - Activity

Communication, Option, Drivers

Memory upgrade for additional data points

Custom Configuration Service

Drivers available for a wide range of Ethernet and social protocols

Approvals
  • CE Marked
  • CSA Certified: UL916 Standard and CSA @ 22.2
  • DNP 3.0 Tested
  • RoHS Compliant
  • GOST-R Certified
  • FCC: Part 15
  • LonMark Certified
  • Modbus Tested
  • BTL Certified

Block Diagrams

imports/blockDiagrams/LP DNP3.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

Logos

imports/logos/Logo DNP3.jpg
imports/logos/Logo DNP3-2.jpg
imports/logos/Logo Modbus.jpg

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
*Required Field
I'd like to receive the newsletter. *Check email for confirmation.
*Required Field
8:00am - 12:00pm 12:00pm - 5:00pm