Archive for the 'FieldServer' Category

Node Offline Responses

Published by skapoor June 1st, 2009 in FieldServer and Uncategorized. 0 Comments

When a Client Node on the FieldServer goes offline the corresponding data objects on the FieldServer are also marked offline. If a client polls a virtual FieldServer node for this particular data, an offline response will be returned by the FieldServer. If the client then requests the FieldServer to identify itself, a valid response will be provided in spite of the data being offline. This results in status toggle, with the Server side Client receiving no replies to data requests and marking the Node offline and then again marking the node online after a successful identification poll, then again receiving no replies to data requests and marking the node offline and so on.

The Server Node must therefore be capable of deciding the nature of its response based on the status of relevant Client Nodes. This can be accomplished using responsible Map Descriptors (RDBC, WRBX, and WRBC). In case no acknowledgement of these functions is received, the device is identified as offline and a flag is placed at the data array offset. The virtual FieldServer can be configured using the Offline_Method option to respond to identification requests in one of the following ways:

  1. Ignore_Clients/No Setting (default) – The kernel ignores the status of Client side Nodes and uses only the online/offline status of relevant data objects to decide on the type of response.
  2. Any_Offline – If any relevant Client Node is offline the Server Node will respond with a node offline message as defined by the Server protocol. This option is available for selected drivers only.
  3. All_Offline – If all relevant Client Nodes are offline the Server Node will respond with a node offline message as defined by the Server protocol. This option is available for selected drivers only.
  4. Always_Respond – A response with data currently in the FieldServer is always sent, without considering the online/offline status of the relevant Client Nodes. This option is available for all drivers.

Offline Server Nodes are treated differently by different protocols. Some protocols will have an explicit offline response, while others will simply not respond.

If configured, the node offline response will take priority over the data offline response.<-->

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Timing Parameters

Published by skapoor June 1st, 2009 in FieldServer. 0 Comments

Normally a FieldServer sends a poll request to a Server device and that device gives a response back to the FieldServer.

Following are the timing parameters considered important in the fieldserver’s operation:

 

Scan_interval: It is the amount of time between successive poll requests. Its default value is 2 seconds and it belongs to Map descriptors, nodes and connections.

 

Poll_delay:  It is the time between receiving a response from a server device and the next poll request. Its default value is 0.05 seconds and it belongs to Connections only.

 

Timeout: If the FieldServer sends a poll request, and the Server device does not send a response, it is considered a timeout. The time for which the FieldServer waits before declaring a timeout can be adjusted by the timeout parameter. Its default value is 2 seconds and it belongs to Map descriptors, nodes and connections.

 

ic_timeout:  This parameter monitors the time between characters in a response. If the time exceeds the ic_timeout, the response is discarded and is considered a timeout. Its default value is 0.5 seconds and it belongs to Map descriptors, nodes and connections.

 

 

Retries: If a timeout occurs, then the FieldServer will retry the poll request a few more times. Number of times tried is specified by the retries parameter. Its default value is 3 times and belongs to nodes only.

 

Retry_interval: The interval between retries is specified by the retry_interval. The Fieldserver will send poll requests at the end of each retry_interval. Once the specified numbers of retries have been sent, the FieldServer will mark the node offline. Its default value is 10 seconds and belongs to nodes only.

 

Recovery_interval: Once a node has been marked offline, it will wait for a period specified by recovery_interval before sending another poll request. Its default value is 30 seconds and it belongs to nodes only.

 

Probation_delay: Once the communications have been re-established, the FieldServer will wait for a period called probation_delay, before marking the node as online. Its default value is 1 minute and it belongs to nodes only.

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

FieldServer’s Web Server

Published by xcosminel April 27th, 2009 in BACnet and FieldServer. 0 Comments

In a nutshell:

  • The FieldServer reads data from field devices.
  • This data can be used to animate web pages that can be served by the FieldServer.
  • Using a browser, a customer or user can monitor data from field devices and also control them.

july08art2pic1

A little more detail:

The FieldServer Web Server allows you to display and change data in a FieldServer. The FieldServer’s data is obtained by communication with remote devices such as gas Detectors, Lighting Controllers and many more.

The web server is a front end HMI (human machine interface) that can serve screens and data to any web browser such as Internet Explorer. Amongst other things, it allows your users to view and change values on your devices with out having to install any special software or be anywhere near the site.

Since the system is built in to a webpage, most of your users should already have the required skills to operate the system (click the link, push a button, flip a switch), a lower learning curve and less training. So simple that just about anyone can operate the system.

Your users can connect and change values on your devices from anywhere that has an internet connection and a web browser. Imagine sitting down in the comfort of your own home, and browsing to your site, viewing the status and making any changes that are needed, then rolling over and going back to sleep, with having to set one foot on the site.

The values on your device can be displayed in a number of ways from simple text and progress bars to animated images and sliders, its up to you how you want to display your data and the system is flexible to do just about anything you can think of, while remaining simple enough for anyone to use.

The system uses a simple template tag system to display and change the data on your devices; these tags can be inserted in to any html document and placed on the FieldServer. The server will then will run thou and strip out these tags and replace them with the data from your device. Its much simpler then it sounds, put this tag where you want to show your data. The template tags are built with web designers in mind, there simple to use and simple to debug.

 

How it all works:

This system works by creating a mini web server on our FieldServer that the users can browse to. When a user browses a webpage, the FieldServer searched the html document for special template tags, if the FieldServer finds these special template tags in the html document, it replaces them with data from your device. When you push a button on one of these web pages, the value is sent from your webpage to the FieldServer, to your device.

july08art2pic2

Step 1: FieldServer is configured to read data from field devices using RS232/ RS485/ Ethernet, Controlnet, DeviceNet, DH+, Modbus+ and any combination of drivers from the extensive protocol library. Over 100 protocols are available.

Step 2: A browser surfs the FieldServer. Pages served are just like any other html pages except that they can include animations based on the real time data obtained from the field devices. The pages can also contain elements to change the data in the FieldServer. These changes then get sent back down to the field devices, if this is what you require.

Step 3: Data read from the field devices can also be served to other field devices using another protocol. It depends on your requirements.

 

Examples

 
These are some of the examples you can produce with this system, the system is only limited by your imagination.
 

Simple Example

In this simple example we are only using the very basics of the template system, (display text and action buttons) but you can instantly see the power of this system, its easy to read, it’s easy to operate, it provides all the information that the user needs about the building.

july08art2pic3

Sleek and Pretty Example

In this example we put an information tag on an image of the factory; the loading doc has two tags associated with it, Lights and AC. You can see that the lights are on and the AC is off, the boarder is flashing red indicating a panic, the user then could click on this tag and get a screen similar to the one above where they can get more information and acknowledge the alarm.

july08art2pic4

Mirror example

In this example we copied the front display of the real device, anyone that has used the device before can quickly and easily navigate this interface.
july08art2pic5

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

FieldServer Gateway (Dual Serial)

Published by xcosminel April 27th, 2009 in BACnet, BACnet MSTP, Ethernet and FieldServer. 0 Comments
Dual Serial – Ethernet

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.
Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Four (4) Jumpers are required to connect a FS2510 to a 2-wire RS485 System

Published by xcosminel November 10th, 2008 in Cables, FieldServer, RS485 and Uncategorized. 0 Comments

In early versions of the FS2510 the serial LED does not flicker even when
there is normal RS485 activity.

Devices with firmware version 5.12k are known to require a firmware upgrade.
Contact Tech support for help.

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Multiple Clients of a Modbus slave

Published by xcosminel October 22nd, 2008 in FieldServer, Modbus and Uncategorized. 0 Comments

We are frequenty asked how you deal with a situation where you have more than one client for a slave(s). The Modbus spec does not support this but we have a solution.

The essence of the solution if to use a multi-port FieldServer. Connect each client to its own port and the slave(s) to thier own ports. Each client will see a single virtual slave(s) on its network. This not only solves the problem but is extremely efficient. Of course the FieldServer needs to be correctly configured.

In a situation like this we exploit the FieldServer technology known as ‘Port Expansion’

Figure 1: Normally it is not possible to connect two clients to the same slave. There are two primary reasons:
1) If you are using RS232 then there can only be two devices on the cable segment.
2) If you are using RS485 then the 2nd client will not know to proceess the poll from the 1st client. It will cause errors.



Click to enlarge

Figure 2: Using a FieldServer with an appropriate configuration solves this problem whether you are using RS232 otr RS485.



Click to enlarge

Figure 3: Each client is on its own port. Thus each client does not see poll messages from the other client. In this example client#1 sends a poll to the FieldServer. The is directed a specific slave address. When the poll arrives at the FieldServer, the FieldServer checks the address against its configuration. If there is no match then an exception response is sent. If there is a match the FieldServer determines the port that the matching slave is configured on. The poll message is then relayed to the slave port.



Click to enlarge

Figure 4: The slave responds. The FieldServer relays the response to client#1. The FieldServer also extracts the data from the response and stores in a temporary location (FieldServer calls that a cache block). The duration/expiry of the storage is configurable.



Click to enlarge

Figure 5: If any client requests the same data (client#1 or #2) and the data hasnt expired then the FieldServer responds with data from the temporary storage.



Click to enlarge

Figure 6: If any client requests different data or if the temporary data has expired then the match and relay process is repeated requesting the new data.



Click to enlarge

Figure 7: The slave responds, the response is relayed to the client doing the polling (Client#2 in this case) and the data is stored temporarily so that it is available to the other client.



Click to enlarge

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Scaling / Bit Packing

Published by xcosminel October 21st, 2008 in FieldServer, Modbus and Uncategorized. 0 Comments

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: Its 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.


Click for larger view

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Simplex 4100u FieldServer Configurations

Published by pchipkin March 28th, 2008 in FieldServer and Simplex 4100. 0 Comments

When simplex 4100U’s are networekd together the configuration of a FieldServer needs special considerations.

Follow these steps

1. Use the correct input doc. It must say ‘HW Ref’. This is the only report that can be used.

Sim4100 Input Report

2. Use the HW Ref column to work out which card-point-subPoints you need to capture in the configuration.

You will need one Map Descriptor for each card. 

3. Points from networked panels lose their original HW ref and get a new based on the network card.

For example if the network card is card 3 then all the points from the remote panels will come in as card=3.

The HW Ref will be 3-xxxxx

The trick is to convert the xxxxx to a point-SubPoint address so you can work out where the event will be stored in the data array.

4. Make a Map Descripto to cpature events from card 3.

Map_Descriptors
Map_Descriptor_Name ,Data_Array_Name ,Data_Array_Offset ,Function ,
Node_Name  ,sim4100_func ,sim4100_card ,sim4100_point ,sim4100_sub ,
protocol ,length ,Card_03_Points ,DA_CARD3 ,0 ,passive  ,Simplex_01 ,
xpoint ,3 ,0 ,256 ,sim4100 ,20000

There can only be one Map Desc for card 3.

Always set point to zero

Set SubPoint to 256 for networked points. (This means the driver expects 256 subpoints per point)

5.  Determine the Data Array Offset where a point’s event will be stored.

Convert the HW Ref to Point-SubPoint

For example:

Input Doc: 3-14126      3:M4-78-0        RIAM          RELAY           L2 BAK/CHE T2.035 CORR BY MEET RM B7.011

HW Ref=3-14126 so we know the card=3

temp=14126

temp2 = temp – 1

point = trunc(temp2/256)   trunc=truncated division. Rounds down.

subPoint = temp – point *256

Offset into Data Array = (point+1)*256+subPoint

Thus in this example: Offset=14381. When the point has an event, the data will be stored in DA_CARD3[14381].
 
 

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have