When the product is shipped the internal jumper is set to LinkNet. Despite this BACnet MSTP is active and if you connect a MSTP client you can read and write the BACnet objects. What you cant do until you change the jumper is discover the device. It appears the only effect of the jumper is to enable the reply to a who-is.

Did you know that with the CAS BACnet Explorer you can add a device manually and then discover its objects and properties. Using this feature the DFM-200 was ‘discovered’ even with the protocol selection jumper in the wrong position.

1) Open the settings file with notepad. The settings file is stored in of two places

C:\Users\<username>\Documents\CAS BACnet Explorer\Settings.xml
C:\Users\<username>\Documents\CAS BACnet Explorer (beta)\Settings.xml

2) Find the iMSTPNmaxMaster value

<key name=”iMSTPNmaxMaster” value=”127“/>

3) Change the value to a number between 1-254. Note: 255 (OxFF) is reserved for broadcasts.

From the BACnet Spec:

This parameter represents the value of the Max_Master property of the node’s Device object. The value of Max_Master specifies the highest allowable address for master nodes. The value of Max_Master shall be less than or equal to 127. If Max_Master is not writable in a node, its value shall be 127.

Relationship between a connection, node and Map Descriptor for a client

The name of the connection/adapter is used to form the relationship between the connection and the node. Here the name ‘N1’ is used in common. This means that when messages are sent to the node called PLC_01 (Node Address=1) they will be sent using connection N1.

As the FieldServer processes each task (Map Descriptor) it needs to know which device or node to send the message to. The name of the Node is used to form the relationship. For example, the task to read address 40001 is defined for Node=’PLC_01’. Now the FieldServer looks for a node with the same name. When it finds it, it then known which connection to send the message on. In this example, it also finds the IP address of the node. So now it knows to send a read holding register message to the device with device address = 1 at IP Adrdess 192.168.1.82 using Network connection N1.

Relationship between a connection, node and Map Descriptor for a Server

For a server, it is not necessary to form a relationship between the connection and the node. What does it mean when a node is not related to a connection? Let’s say you define the same protocol on two connections (eg N1 and N2 – not all FieldServer’s have both) but you want to use the same server node to respond to messages that arrive on connection N1 or N2. By leaving the relationship between a connection and a node undefined (like this example), this becomes possible.

For a server, Map Descriptors may be thought of as server data object definitions. They must be related to a node. When a request for data from node 11 (like this example) is received, the driver must find a matching server node in the config. Once a matching node is found, the FieldServer must find a data object definition that matches the request. Thus, a relationship between the node and the Map Descriptor must be established. This is done by using a common Node_Name as illustrated by the green line.

What connects two protocols together?

The Data Arrays connect protocols. The client reads data and stores it in a data array. The server serves data, extracting it from the Data Array and serving the data using a different protocol. Some data scaling or rearrangement may be required. FieldServer provides tools to move, reorganize, do arithmetic and scale Data Array data. In this example the relationship is direct.

In this diagram the pink and purple lines show how client side data read using Modbus is served as BACnet Data.

The Client read 20 data items from register 30001 and stores the data in DA_Ana_Inputs starting at offset zero.

This means DA_Ana_Inputs[0] contains the value of register 30001.  DA_Ana_Inputs[1] contains the value of register 30002.  DA_Ana_Inputs[2] contains the value of register 30003.

The server Map Descriptor named ‘AnaInput01’ serves data extracted from the Data Array named ‘DA_Ana_Inputs’ offset 0. Thus the data it serves correlates to register 30001.

The server Map Descriptor named ‘AnaInput02’ serves data extracted from the Data Array named ‘DA_Ana_Inputs’ offset 1. Thus the data it serves correlates to register 30002.

The server Map Descriptor named ‘AnaInput03’ serves data extracted from the Data Array named ‘DA_Ana_Inputs’ offset 2. Thus the data it serves correlates to register 30003

A similar discussion applies to the other data.

If the client goes offline or the data cannot be read because of some error then the age of the data increases. At some point the data becomes too old to serve in which case the FieldServer marks the data as unreliable.

Data Arrays

Data Arrays are used to store data. Select Data_Formats that are suitable for the data. FieldServers can store 1,8,16 and 32 bit data, signed and unsigned as will as floating point data. A few other formats such as packed_bits and packed_bytes allow binary data to be easily packed/unpacked. In addition using special functions data can be moved from one location to another. During the move, data formats can be changed and arithmetic can be performed.

Data arrays use FieldServer memory but the length does not affect the point count.

Scaling

A value can be scaled before it is served. In this example, the value served will be 100 times smaller than the value found in the Data Array. Read the config as follows; When a value of 0-10,000 is extracted from the Data Array it will be served to the remote node as a value between 0-100.

Modbus Client

No more than once per second (Scan_Interval) read (Function=RDBC which means read continuously) 20 (Length) input registers starting at address 30001 (Address) and store the returned data in DA_Ana_Inputs[0..19]. For this protocol the Map_Descriptor_Name serves only a descriptive purpose – it is not used by the protocol.

There are three other similar tasks. Each reads a different data type and stores it in a different location.

BACnet Server

The BACnet device instance has been set to 11. (Node_ID).

12 Data objects have been defined. Each is defined by a single map descriptor. The unstated length of each map descriptor is 1 (default value for this protocol.). That means each map descriptor defines a single BACnet data object. The object type and instance numbers are defined by Data_Type and Object_ID. They do not have to be sequential.

The MapDescriptor name is used as the BACnet Object Name. When a remote client reads from this server it will find objects named ‘AnaInput01’, ‘AnaInput02’, etc…

The Virtual BACNet device will be allocated to the Local Network. (Network zero). There are methods to change this default allocation.

A parameter called ‘Relinqush_Default’ tells the driver what value to set the object to if it is not being commanded by a remote device and if it is not being read from a remote device. It is required for output types and the typical value is zero.

The function is set to server meaning that these map descriptors are capabilities as opposed to tasks. The FieldServer does no active work based on these Map Descriptors. The server side waits passively until it receives a message from a remote BACnet device. When a message is received, the Fieldserver matches it against a server side node and then against the server side map descriptors. If there is a match data can be extracted and served. If there is no match then an error response is sent.

Engineering Units are a property of a BACnet data object. You can set them to any supported unit using the ‘Units’ parameter. The manual provides a full list of units. You can see the analog data is scaled before it is served.

How to Write/Command Data

When you send a BACnet comamd to change the value of an object (typically an output object) then a message is sent to the FieldSever with the new value. If a matching device and object are found the Data Array is updated. Normally the data is read by the client side and shared with the server side. These two operations seem to contradict each other. Here is how it works:

1. Normally client side (Modbus) reads the data and server side serves that data.

2. BACnet Scada System sends a command to write a data object.

3. This causes the FieldServer to store the data in the Data Array location being used by the corresponding Server Map Descriptor.

4. This in turn triggers a once off operation. Instead of reading the data from the Modbus Device, a single write to the Modbus device is performed with the new data. FieldServers call this a ‘write-though-read’. That is why we get away with having no ‘write’ map descriptors to the Modbus device but we are still able to send commands to the Modbus Device.

Lets say a remote controller sends a new setpoint to Analog Output #2. In this case the new setpoint is stored in DA_Ana_Outputs[1] (offset 1).

You can deduce that DA_Ana_Outputs[1] corresponds to Modbus register 40002. ( Basis for deduction – follow the data array name from the server map descriptor – find which client Map Descrptor uses the same Data Array. In this case it is the one called ‘Read_Holding_Regs’. Now you can see that 40001 corresponds to DA_Ana_Outputs[0] and hence 40002 corresponds DA_Ana_Outputs[1].

Now the FieldServer knows where to send the new setpoint and hence a message to set 40002 in device #1 using Modbus/TCP is sent.

Modbus and Floating Point Numbers

Modbus does not naturally have a way of transporting floating point numbers. Commonly, two 16bit integers are used to store a representation of a floating point number. Commonly the representation method is IEEE754. FieldServer have a method of doing the conversion.

The following table shows the FieldServer function moves that copy two adjacent 16-bit registers to a 32-bit floating point value:

In these examples, 32 16-bit values are combined to form 16 floating point numbers.

In the 1st example DA_SYN_REG[502] and DA_SYN_REG[503] are combined and stored in DA_SYN_ FLOAT500[0]. This is repeated 15 more times. Eg DA_SYN_REG[504] and DA_SYN_REG[505] are combined and stored in DA_SYN_FLOAT500[1].

Complete Configuration File

FS-B2510

The FS-B2510 Dual Serial-Ethernet gateway provides a wealth of features to enable data transfer between different devices and networks utilizing serial and Ethernet protocols. 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-B2510 is particular cost effective in the integration of two devices/systems utilizing serial protocols such as a fire alarm control panel to BACnet MSTP. The FS-B2510 is one of the FS-X30 Series FieldServers designed to meet the needs of system integrators in designing a complete interoperable system. The FS-B25 Series brings together the powerful FieldServer driver library with state-of-the-art gateway design. This FieldServer includes twi serial connections (RS-232 or RS-485, software selectable) and one 10/100BaseT Ethernet ports. The multiport design allows for serial-to-serial interfaces or interface from mulitple serial products to an Ethernet or LonWorks network. The Ethernet port enables the integrator to connect a PC to download configuration changes without disturbing the system connections and without the additional cost of an external hub.

CAS sell, support, install, configure and develop custom drivers for FieldServers. With every FieldServer purchased from CAS that includes a BACnet protocol we provide a free license to the CAS BACnet Explorer which can be used to test / prove the BACnet interface is working. ]]> http://www.chipkin.com/articles/fieldserver-gateway-dual-serial/feed 0 http://www.chipkin.com/articles/segementation-in-bacnet http://www.chipkin.com/articles/segementation-in-bacnet#comments Thu, 23 Apr 2009 22:19:25 +0000 cpascu http://www.chipkin.com/articles/?p=270  

BACnet messages that don’t fit in a single packet use segmentation. Why would one message need more than one packet ? Well IP packets have a maximum length of 1500 bytes. So if you are sending a BACnet IP message that is longer than 1500 bytes then you need to send more than one Ethernet packet.

Example: Ask your fishing buddy if he wants another beer. The reply is short and fits in s single response packet. Yes. Now ask him to tell you about the one that got away. He will need multiple sentences to tell you the long storey. Your buddy needs you to support segmentation otherwise you will only hear the first sentence of his storey (lucky you.)

Be aware: 1500 is not a hard coded Maximum Transmission Unit (MTU) length in all Ethernet applications. Often the size is set smaller.

Most serial protocols like MS/TP choose a small number for the MTU because am error requires retransmission and the data is slow so it better to catch an error in smaller packet.

Practical / Field Issues

How does Segmentation affect you as a user ?If a device has a large number of objects and a message is sent to read the object list then it is possible that the response wont fit in a single packet. If both the device and the requestor support segmentation then there is no problem. If either side doesn’t support segmentation then 1) You are out of luck or 2) The requestor must use a different method to read the object list – for example, reading each object using its index until it reaches an index number with no object.The CAS BACNet explorer works like that – first it tries the most efficient method and then it slowly downgrades itself to try and ensure the response will fit in a single packet. How do you know if a device supports segmentation ? You can read the vendor’s PIC (Protocol Implementation and Conformance) Statement or you can look at the device object’s properties. segmentation in bacnet segmented-both (0) segmented-transmit (1) segmented-receive (2) no-segmentation (3) How can you work around the segmentation issue ? If you can configure the services your system uses to read data you have a fighting chance. Ensure you use read-property for a single property – avoiding read-property for all properties. If you have to use read-property-multiple then limit the list of properties to be read and avoid reading all using this service.

• Transfer size – More then x BYTES are collected or
• Latency timer – More then n Milliseconds (ms) expirer.

By default most ‘off the self’ USB to serial converters have a latency timer of 50ms and a transfer size of 4096 BYTES

The can be a major problem for PC utilities monitoring a serial network. The PC doesn’t get the BYTES fast enough to respond to the serial device before it times out.

For example:

On a network with a BACnet MSTP thermostat and a RS485 to USB converter connected to a PC. The BACnet MSTP thermostat will send a poll to the PC and will expect the PC to respond within 100ms. If the thermostat does not receive a response within this time the thermostat will assume that the device has gone offline. When the USB to 458 converter receives the message it will stay in its buffers for 50ms before being sent to the PC. Depending on the message it may take longer then 50 ms for the PC to respond to the poll and the thermostat will consider the PC offline.

Luckily we can set the Transfer size, and latency timer.

Most USB to 485 devices that I have used have the ability to set the transfer size and the latency timer.

1. Start menu–> Settings –> Control panel –> device manager –> Ports (COM & LPT) –>{Select your USB to RS485 converter}
2. Right click and select “Properties”
3. Select the “Port Settings” tab
4. Click the “Advanced” button 
5. Change the Latency Timer (mSec) to 1 or the lowest possible setting.
6. Change the USB Transfer sizes to 64 or the lowest possible settings
7. Save and close.

The question is: How do you match requirements of a project to the capabilities of the devices being installed ? The Answer – in BACnet – is BIBBS.

A BIBB is a Bacnet Interoperability Building Block.

Continuing with our example: Say your controller needs to read the set point on a thermostat to perform its control. Then the controller needs to support a BIBB called DS-RP-A. This isn’t enough. The thermostat must be able to respond so it needs to support a BIBB called DS-RP-B. DS stands for Data Sharing. RP stands for Read Property. The A and the B stand for Client (A) and Server (B).

The outdoor temperature on a HVAC controller could come from two places. A local sensor connected to the unit or a remote value sent via BACnet. In this case you would want to match the BAS controller and HVAC controller with BIBBS DS-WP-A and DS-WP-B (DataSharing-WriteProperty-A or B for Client and Server).

Thus, if you buy a great controller that supports Conditional and Range Reads you would want to buy field devices that support these services. DS-RPC-A/B for DataSharing-ReadPropertyConditional-Client/Server.

Abbreviation BIBB Category
DS        Data Sharing
AE        Alarm and Event Management
DM       Device Management
DM and NM are part of the same category.
NM       Network Management
T          Trend
SCHED Schedule

TIP : Device A and Device B. All the BIBBs end in ‘-A’ or ‘-B’. BACnet refers to the A device and the B device. The A device in this context is a device acting as a client. The B device means a device acting as a server. In BACnet devices can be both clients and servers since almost all devices can read data from each other.

A complete table of BIIB’s is available at: http://www.chipkin.com/articles/bacnet-bibbs-table-bacnet-interoperability-building-blocks

A: The reason for this is that the the standard 16C550 PC UART is too slow to keep up with the signals coming in and out. 76800 is not a standard multiple of the UART clock frequency.

Devices can be customized and therefore allow baud rates of 76800. If your PC has a customizable COM port card where you can program the bit clock then you would be able to set this value.

There is no fix for this, but if you find a converter that can change 76800 to a higher UART this could be a work around.

The standard frequencies are:

• 150
• 300
• 1200
• 2400
• 4800
• 9600
• 19200
• 38400
• 115000

“An MS/TP EIA-485 network shall use shielded, twisted-pair cable with characteristic impedance between 100 and 130 ohms. Distributed capacitance between conductors shall be less than 100 pF per meter (30 pF per foot). Distributed capacitance between conductors and shield shall be less that 200 pF per meter (60 pF per foot). Foil or braided shields are acceptable. The maximum recommended length of an MS/TP segment is 1200 meters (4000 feet) with AWG 18 (0.82 mm2 conductor area) cable. The use of greater distances and/or different wire gauges shall comply with the electrical specifications of EIA-485.”