Free Guide
Download our Modbus for Field Technician for free, or purchase this guide for $20 on amazon.com.
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.
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.
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.
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).
24V AC (+/-10%) or 12-30V DC @ 12W
Configuration/Diagnostic utilities
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
Memory upgrade for additional data points
Custom Configuration Service
Drivers available for a wide range of Ethernet and social protocols
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.
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 |
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 has various advantages and disadvantages. The advantages include:
The disadvantages of Lonworks are presented in the following list:
Amongst the extensive range of LonWorks technology applications the vital nine are listed below:
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.
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 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.
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:
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.
Download NodeUtil:
More Nodeutil Downloads available: HERE
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 – 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.
How to Commission and Bind using Lonmaker. CAS can configure Lonworks gateways so Commissioning and Binding can be avoided. Call our Tech Sipport for more info.
https://www.youtube.com/watch?v=u_mzAdszviI
https://www.youtube.com/watch?v=w3QeimYx94I
https://www.youtube.com/watch?v=H76n1-lcrhI
https://www.youtube.com/watch?v=SEcAx6xy3is
https://www.youtube.com/watch?v=dFyyKNmGVB4
https://www.youtube.com/watch?v=B_Cs1clgNzM
https://www.youtube.com/watch?v=29cuWwVKNdA
https://www.youtube.com/watch?v=vm2Ss72C5bg
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:
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 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.
Free Guide
Download our Modbus for Field Technician for free, or purchase this guide for $20 on amazon.com.
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.
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.
Most functions can be configured to occur on a configurable period or on update of the data source.
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
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)
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