July 2009 Newsletter

Driver for Networked Robotics - NTMS4 Temperature Sensor Modules

The driver reports the temperature and a timestamp if the module could be read without problems. If the module reports an error, the driver reports a status number indicating the error type. In addition, the driver can set the temperature value to some configured value so that a remote HMI can see there is a problem with the sensor.

If the driver cannot reach the sensor ports or TCP/IP communications time out the driver can indicate this by setting a node on/offline indicator.

The driver has been tested on a site with 80 sensors and at our offices with 5 modules.

CAS is able to develop custom FieldServer drivers thus allowing new devices to connect to any device supported by some other FieldServer driver. Our development process ensures the drivers meet FieldServer’s QA requirements.

There are non electrical considerations to determine how many devices you put on an MSTP network.

The chart below illustrates (from one installation) how little of the bandwidth is used to transfer data. The APDU’s are application layer message that poll and respond with property values – they do work for us as data consumers. The rest is used to maintain the network – passing the token around and looking for new devices.

It’s not possible to provide a calculator to work out how many devices to install on a single network but the following list provides some help in assessing bandwidth considerations.

It takes approx 30 bytes to poll for a single property. It takes about 40 bytes to reply. A token is 8 bytes as is a Poll for master.

Assume that 50% of your bandwidth will be used by overhead (token, poll for master).

Divide the baud rate by 10 to get bytes per seconds.

Using a number like 30+40=70 as a best case and 100 as a worst case (obviously reading descriptions will take more) multiply by the number of objects and properties you are going to poll on a regular basis.

Here are some typical numbers assuming the device doesn’t support the ‘multiple’ services (see below).

What uses the MSTP bandwidth

• How many of the devices will be BACnet slaves?

Token passing and looking for new devices on the MSTP trunk consumes a fair amount of bandwidth.

A BACnet slave can be read/written but never gets the token. So it can’t initiate any messages because it never gets the token. The more slaves the fewer token passes. Typically you are not able to put a device in slave mode. Most vendors implement their devices as masters (ie token passing devices)

• How many Objects in each device are you interested in monitoring ?

The more you read and the greater the frequency the more bandwidth that will be consumed.

It takes approx 30 bytes to poll for a single property. It takes about 40 bytes to reply. A token is 8 bytes as is a Poll for master.

• How many properties from each of these objects ?

• What is the baud rate?

• What is Max Master Set to?

Every few cycles each (master) token passing device on the network must look to see if there are new devices. Max Master determines the biggest address that must be searched for. Each search involves sending a message and waiting for a response or a timeout (if the devices isn’t there). Timeouts cost time. The higher the number of Max Master (default is 127) the more potential devices must be searched for. If you use Max master to improve bandwidth then you must adjust it in each device.

• Do the devices support the “Read/Write Property Multiple” services or must each property be read in a separate message.

Find the answer to this question by reading the BIBs statement for each device or you could explore the device object of the device, find the property called BACnetServicesSupported and then look at the 14th item in the array to see if Read Property Multiple is supported and the 16th for Write Property Multiple. However, we have found that a large number of devices don’t display this information.

Obviously, if you can read a chunk of properties in one message you will be better off than if you can only read a single one.

• Can you use BACNet’s COV mechanism.

COV stands for Change of Value. When a device supports COV another device / application can subscribe to receive notifications when an object property changes. This means the data client doesn’t have to poll for data continuously but can wait passively to be notified of the change. This reduces the number of messages on a network dramatically.

• Some devices are slower than others.

BACnet allows up to 15 msec for a device to use the token. Since most messages on a MSTP network are token passes a device that uses the token in 5 msec will consume much less bandwidth than one that takes 15msec. (A number of vendors relax this requirement to allow for other vendors implementations. The more relaxed the more bandwidth is consumed doing nothing.)

Sheetal joined CAS in the first week of April. She will develop FieldServer skills and a significant portion of her work will be the development of FieldServer configurations and the provision of product support. As part of her training program, Sheetal, is documenting what she learns by writing content for automationwiki.com.

Sheetal begun her career with HMT Machine Tools Ltd which is the foremost manufacturer of Machine Tools, Heavy machineries and Tractors in India. She worked there on Manual tool Changer Project of a Vertical Machining Centre where she was largely indulged in the PLC Software development part for the machine. She has good quality knowledge of Siemens PLC systems & its programming, HMI and Profibus etc. Her latest assignment was with Moser Baer India Ltd which is a Second largest Optical Media Manufacturer in world. She single handedly took on a project of Online Screen life monitoring of Print Screens being used up in CD Printing Machines there as well which she successfully concluded Via Siemens Programming tools : Simatic Manager & Simatic Protool.