DeviceNet Master to Modbus, BACnet, or any other protocol Multiport Gateway

A FieldServer protocol gateway that provides data exchange between DeviceNet Master and Modbus, BACnet, or any other protocol.
The FieldServer DeviceNet Master gateway makes it easy for integrators to interface devices utilizing various building or industrial protocols to DeviceNet Master networks.
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 allows the FieldServer to transfer data to and from devices over Ethernet using the Modbus TCP Protocol.
The BACnet Master-Slave/Token-Passing (MSTP) driver implements a data link protocol that uses the services of the RS-485 physical layer.
The LonWorks driver allows the FieldServer to transfer data to and from devices using LonWorks protocol.
The Ethernet IP driver allows the FieldServer to transfer data to and from devices over Ethernet using the EtherNet/IP protocol.
The DeviceNet Master Adapter driver can be used to emulate a single Master Scanner station on a DeviceNet network.
SKU:
FS-B3521-XXXX
B3510 Angled scaled down and sqrd WT BG png - B3510 Angled scaled down and sqrd WT BG png
This product converts form DeviceNet Master to any number of protocols from the FieldServer Library. 

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.

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.

DeviceNet Master Hardware

TThe FieldServer DeviceNet Master gateway makes it easy for integrators to interface devices utilizing various building or industrial protocols to DeviceNet networks. As the leading manufacturer of protocol gateways in the building automation industry, MSA Safety has developed the largest driver library in the industry and the widest range of gateways available, designed to meet the needs of system integrators.

The FS-B3521-05 provides a wealth of features to enable data transfer between different devices and networks utilizing serial (RS-232 or RS-485), Ethernet, LonWorks and DeviceNet Master. The multiport design allows for serial-toserial, serial-to-Ethernet, LonWorks and DeviceNet Master interfaces. With a larger point count than any similar gateway, the FieldServer FS-B35 series provides a single device solution for your networking needs. The FieldServer is designed to meet a wide range of interface needs and it is easily configured as a master or a slave.

The FieldServer Toolkit with the updated browser-based interface makes it easy to find specific FieldServers on the network and provides a user-friendly method to determine status, network settings, node information, map descriptors and more. The interface also makes it easy to transfer files to update FieldServer in the field.

Configuration is easy, but if needed, configuration services are available from the MSA Safety support team. The proven FieldServer support team is recognized around the world for its knowledge of the many different protocols involved in building automation.

MSA Safety continuously strives to enhance our gateways and the latest FS-B35 series includes a major software upgrade, resulting in significant enhancements in performance, including:

  • 40% higher point count capability – some protocols are major memory hogs, and the result is that they can slow down performance of any gateway. With the greater memory enhancement, the FS-B35 Series can easily handle all of the drivers extremely well.
  • Memory utilization monitoring – the user is provided with application memory statistics (in both kB and as a percentage of the available memory) enabling optimal matching of device models and configurations to specific applications.
  • Improved stability and performance under high loads – the new software enhances the operation making it more forgiving to configuration problems with fewer crashes when capacity limits are reached.
  • USB firmware update – this allows the firmware or configuration of the FieldServer to be updated from a USB flash drive whenever it is inserted, enabling users to easily update firmware in the field. This is a great time saver if you have multiple FieldServers in the field.

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. 


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.

EtherNet/IP

The Ethernet IP driver allows the FieldServer totransfer data to and from devices over Ethernet usingthe EtherNet/IP protocol. The FieldServer canemulate either a Server or Client.

EtherNet/IP uses CIP (Control and InformationProtocol), the common network, transport andapplication layers also shared by ControlNet andDeviceNet. EtherNet/IP then makes use of standardEthernet and TCP/IP technology to transport CIPcommunications packets. The result is a common,open application layer on top of open and highlypopular Ethernet and TCP/IP protocols.

The Driver is able to read/write using the Data Tablestructure employed by all Logix Series PLC’s.

PCCC support is also provided for legacy devicesthat do not fully support CIP encapsulation. EIPPCCC Encapsulation was tested at the FST factoryusing a PLC5 I785 ENET card. The following datatypes were tested:

  • N
  • F
  • S

The Driver also supports PCCC communication onSLC and MicroLogix (Tested on MicroLogix 1400Device)

Fragmented Services (0x52) is supported fordata_table read and write operations. 

LonWorks

The LonWorks driver allows the FieldServer to transfer data to and from devices using LonWorks protocol over the TP-FT/10 channel amongst others. The LonWorks FieldServers can emulate either a Server or Client.

The FS-B30, QuickServer, and SlotServer Series FieldServers have a built-in LonWorks Interface and a Fieldbus connection is available on the FieldServer.

The FS-B30 and the SlotServer can handle up to 4096 Network Variables which can be of the Standard Network Variable Types (SNVT) and/or User-defined Network Variable Types (UNVT), and the QuickServer can handle 250 Network Variables (or a limit of 500 for the enhanced model).  

Devicenet Master

The DeviceNet Master Adapter driver can be used to emulate a single Master Scanner station on a DeviceNet network. The FieldServer DeviceNet adapter is implemented as an ODVA profile 12 communications adapter. Standard DeviceNet Baudrates of 125k, 250k and 500kbit/s are supported. The DeviceNet Master Scanner can open IO connections of up to a total of 1536 Bytes in each direction to DeviceNet Slaves. 

I'd like to inquire about the DeviceNet Master to Modbus, BACnet, or any other protocol Multiport Gateway FS-B3521-XXXX. Please provide me with a quote for this product.

Specifications

DeviceNet Master Hardware

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.
  • DeviceNet – 1: DDeviceNet Master Serial Terminal Port. Baud rates: 125K, 250K, 500kbit/s. Up to 512 Bytes in each direction.
  • 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

Approvals

FST - Lonworks Approvals
LonMark International

The following FieldServer Platforms are LonMark Certified:

http://www.chipkin.com/files/web30_prepImages/FST_lonmark_approval.jpg

The FieldServer provides the capability of defining multiple functional blocks, but only a single LonMark object. The user can create multiple functional blocks or a LonMark object by filling out the Node SelfDocumentation String and the respective Network Variable Self-documentation String fields in the FieldServer configuration file.

Standards & Certification

LonWorks became and ANSI standard in 1999, and subsequently became a widely adopted global standard. The standard is supported and maintained by LonMark International. Standards include:

ANSI-CEA-709.1-B
ISO-IEC 14908-1
ISO-IEC 14908-2
ISO-IEC 14908-3
ISO-IEC 14908-4

LonMark International is responsible for certification, education, and promotion of interoperability standards for the benefit of manufacturers, integrators, and end users. LonMark International has developed extensive product certification standards and tests to provide the integrator and user with confidence that products from multiple manufacturers can work together. 

 

Sierra Monitors FieldServer has more LonMark Certified gateways for integrators and OEMs that carry the LonMark logo than any other gateway manufacturer. For more information about our LonMark Certified products, visit the LonMark International Product Certification Directory.

http://www.chipkin.com/files/web30_prepImages/FST_lonmark_approval_3510.jpg

http://www.chipkin.com/files/web30_prepImages/FST_lonmark_approval_QS.jpg

 

Certified Products are listed here:

https://www.lonmark.org/products/search  check for updates

FS-B2011 Serial/Ethernet/LonWorks® Gateway Sierra Monitor Corporation 3.4 TP/FT-10
FS-B3510 Serial/Ethernet/LonWorks® Multiport Gateway Sierra Monitor Corporation 3.4 TP/FT-10
FS-B4011 Serial/Ethernet/LonWorks® 10-port Gateway Sierra Monitor Corporation 3.4 TP/FT-10
ProtoCarrier/ProtoCessor FPC-CD2 Daughter Card Gateway for OEMs Sierra Monitor Corporation 3.4 TP/FT-10
ProtoCessor FPC-F04 Embedded Gateway Module for OEMs Sierra Monitor Corporation 3.4 TP/FT-10
ProtoNode LER External Protocol Gateway for OEMs Sierra Monitor Corporation 3.4 TP/FT-10
QuickServer FS-QS-1XY1 Gateway for LonWorks® Sierra Monitor Corporation 3.4 TP/FT-10
HVAC Gateways Manufacturer Version Transceiver
Liebert SiteLink-12 LonWorks® Adapter Sierra Monitor Corporation 3.3 TP/FT-10
Industrial Gateways Manufacturer Version Transceiver
SlotServer LonWorks® Open Interface Sierra Monitor Corporation 3.3 TP/FT-10
FS-B2011-01 Water Temp Sensor Sierra Monitor Corporation 3.2 TP/FT-10
HVAC
Boiler Controller Manufacturer Version Transceiver
Cleaver Brooks Adapter for LonWorks® Sierra Monitor Corporation 3.3 TP/FT-10
Discharge Air Controller Manufacturer Version Transceiver
FieldServer Data Aire DAP Adapter for LonWorks® Sierra Monitor Corporation 3.3 TP/FT-10
Industrial
Generator Set Manufacturer Version Transceiver
FieldServer Caterpillar EMCP II Adapter Sierra Monitor Corporation 3.3 TP/FT-10
FieldServer Kohler 550 Adapter Sierra Monitor Corporation 3.3 TP/FT-10

Block Diagrams

BACnet Combined Block Diagramimports/blockDiagrams/LP Modbus.jpgimports/blockDiagrams/LP Lonworks.jpgimports/blockDiagrams/LP Rockwell.jpgimports/blockDiagrams/LP DeviceNet.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.

Modbus for Field Technician - 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

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.

Lonworks - LonWorks Protocol

A set of services is offered by the LonWorks Protocol that enables all devices in the network to transmit and receive messages to and from other devices via their application program— requiring no acquaintances with network topology or the other devices’ names, addresses, or functions. Besides, LonWorks Protocol can be made to deliver authentic, high priority messages within delimited transaction times. Moreover Network management services allow remote network management tool’s interaction with devices over the network; making them capable to reconfigure network addresses and parameters, download application programs, report network problems and Start/stop/reset device application programs. Consequently it’s relatively easy to employ LonWorks network over any medium, including power line, twisted pair, radio frequency (RF), infrared (IR), coaxial cable, and fiber optics.

Lonworks is another communications protocol useful in building automation applications. The protocol was developed by the Echelon Corporation in the late 1990s. Lonworks originally transformed from Echelon’s earlier “Lontalk”, and was submitted to the American National Standards Institute (ANSI) for acceptance. Lonworks was designed on a low bandwidth platform for networking devices through powerlines, fiber optics, and other media.

The entire Lonworks package consists of the following components by the Echelon Corporation:

  • Lonworks – communications protocol (ANSI/EIA 709.1, and others).
  • Echelon’s “Neuron” chip (Three 8-bit inline processor). Two are used by Lonworks, and one as a general application processor.
  • Twisted-pair and/or powerline transceivers to transmit Lonworks protocol.
  • LNS Network Operating System is the required software.
  • Internet connectivity through Standard Network Variable Types (SNVTs) or with LonMark profiles.
  • LonMaker allows interoperability among devices.

Lonworks has various advantages and disadvantages. The advantages include:

  • Less architecture at the device level.
  • Numerous developers of Lonworks products in the market.
  • Lonworks devices are close to “plug & play” ability, but still far from achieving interconnectivity in today’s computers using Microsoft Windows.

The disadvantages of Lonworks are presented in the following list:

  • Less architecture causes controlled devices and variables to be connected to a separate control device. Most designers do not recommend this type of architecture because network interruptions could eventually produce system failures.
  • The protocol is proprietary, and not truly open to the public. Only actual members, mostly manufacturers are included in standard development(s).
  • Extensions within Lonworks are allowable only through the LonMark Consortium.
  • Hardware specific, and requires the Neuron chip for network movement of the protocol.
Lonworks - LonWorks Applications

Amongst the extensive range of LonWorks technology applications the vital nine are listed below:

  • Semiconductor manufacturing
  • Lighting control systems
  • Energy management systems
  • Heating/ventilation/air-conditioning systems
  • Security systems
  • Home automation
  • Consumer appliance controls
  • Public street lighting, monitoring, and control
  • Gas station control
Lonworks - Building Control Networks

A P2P (peer to peer) architecture is undoubtedly the preeminent way to build control networks. Being exclusive of a single master control, P2P-based control network confers high reliability and high performance to its users. Unlike other control networks, in P2P architectures, there is absolutely free and open communication between network devices which automatically puts a stop to the system collapses that could occur whenever the master stops working.

Lonworks P2P networks

Lonworks - Neuron

A processor identified as Neuron chip embracing three 8- bit inline processors designed by Echelon is well optimized for control network devices. Out of three processors: two are committed for the communications protocol and one is a general-purpose applications processor. Standardization of the variables used to illustrate physical things to LonWorks is maintained by LonMark International and each standard is known as Standard Network Variable Types (SNVTs). LNS Network Operating System is a mandatory software component of open control systems which ensures an open environment for extending, maintaining, and managing LonWorks based system

Lonworks - Introduction

LonWorks is not just a protocol or physical layer for communication but an exclusively designed networking technology platform to install, maintain, monitor and sense various automation and control applications. Essentially LonWorks was established for a range of automation functions within buildings such as lighting and HVAC. Invented by Echelon Corporation, the fundamental communications platform, twisted pair signaling technology, power line signaling technology, and IP tunneling method constitutes a global standard documented ISO/IEC 14908.

Lonworks - Software - NodeUtil

What happens if you need to learn about a Lonworks network and it devices but you haven’t been provided with the database or if you don’t have LonMaker?

NodeUtil is a Lonworks utility that can be used to explore Lonworks networks and devices without having LonMaker. All you need is a device such as an Echelon U10/U20 USB Network Interface.

 

Using NodeUtil you can discover devices , learn about the Domains, SubNets, NodeID’s. You can also upload the XIF file from specific nodes.

 

 

http://i160.photobucket.com/albums/t188/adamrich33/NodeUtil.jpg

 

Download NodeUtil:

Nodeutil v3.23

Nodeutil v1.82

More Nodeutil Downloads available: HERE

Lonworks - Software - Lonmaker

LonMaker is a Windows GUI based network/device management tool for Echelon LonWorks. It can be used for initial network setup and functioning as a management console on a completed network.

Purchase from Echelon.

LonMaker image

Lonworks - Why are Lonworks communications so good

The communications between all Lonworks devices is done by means of a proprietry chip (The Neuron chip) made according to one design by one company according to one standard which it wrote on its own. It’s obvious that there are so many less aspects of the data communications process that can go wrong when there is a single entity involved. When a device vendor implements a Lonworks System Interface he simply has to implement the application layer of the data communication process. For almost all other protocols the device vendor must implement the physical layer, data link layer, the Network Layer, The transport Layer, The Session Layer, the Presentation Layer and the Application Layer. You can see how many more areas of risk there are.

When Echelon released the standard, their license terms required anyone who implements it to implement the full standard. The fact that other vendors can’t cherry pick features and services means that even when implemented by other vendors you still have the same strong chance of success.

Lonworks - Jargon Watch

Lonworks – a wide ranging term generally applied to describe the whole technology developed by Echelon. It is used frequently and ambiguously.
LonTalk – A registred trademark belonging to Echelon. They use it as the name of the protocol used for data communications in a Lonworks system. Ie. It is the brandname protocol. Echelon released this protocol so it could be adopted as a standard – ANSI-approved standard EIA/CEA-709.1-A-1999 – SO/IEC Standard 14908 or European standard EN14908.

Lonworks - How to - Commissioning and Binding
Lonworks - Software - XIFdump

Another useful utility is XIFDUMP. It is a report generator (DOS), and it allows you to generate reports (text file) from a XIF files.

Download XIFDUMP:

XIFDUMP

Articles

Case Study - BACnet IP to DNP3 Serial Integration
BACnetIP - What is the BACnet IP to Xively data logger
Modbus - Convert between Modbus Flavors
Modbus - C#
Modbus - Modhopper for Modbus Wireless Communication
Modbus - 32 bit numbers
Modbus - Multiple Masters of one slave
How Real (Floating Point) and 32-bit Data is Encoded in Modbus RTU Messages
Table 2 Modbus Registers
Case Study - Modbus RTU and Veeder Root to Ethernet IP
Case Study - Modbus RTU (RS485) - BACnet MSTP Integration
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 do you have that can help me convert my Modbus TCP data
ModbusTCP - We want to check the communication between our device and personal computer, so we need the 232 communication software
Simplified Configuration for Modbus-to-Modbus Integration with Fieldserver Devices
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
How to Make the CAS Modbus Scanner Read A Modbus 6 Digit Address (JBUS)
USING PUTTY OR REALTERM FOR SERIAL COM CONNECTIONS (HyperTerminal replacement)
Testing Modbus communication
Low Power Wireless Modbus
Modbus Frequently Asked Questions (FAQ) and Answers
FS-8704-03 – Modbus TCP
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
Discover a LonWorks Device, Find the Neuron ID, and obtain XIF files
Simple Steps to Install FieldServer EDS files on a Rockwell PLC

Logos

imports/logos/Logo BTL Bacnet Test Lab
Logo bacnet1
Logo Modbus
Logo lonmark_logo.png
Logo Echelon.png
Logo Lonworks Lonmark
Logo Lonworks
Logo Lonworks Echelon
Logo Rockwel
Logo DeviceNet

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