Archive for the 'Andover Continuum' Category

FieldServer Modbus TCP – Device / Station Address (ID) 0 (Zero)

Many Modbus TCP clients send polls with the Station / Device address (ID) set to zero.

Fieldserver’s cannot be configured as station zero so they cannot respond. There is a work around. Set the FieldServer Node_ID parameter to a value of 239. When Modbus TCP messages are received, the FieldServer looks at the one byte station number. If it is zero it changes the byte to 239 and then passes the message for processing by the driver. Thus if the server node is configured as 239 the FieldServer can respond correctly.

One example of a Modbus Client that sends requests to station zero is the EZ Touch Panel HMI from EZAutomation.net

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

TAC ACX Series Controllers

acx.jpgTAC has produced a superior, compact, and competitively priced access controller for the security concerns of today’s world in their new ACX Series Controllers. These controllers are among the most powerful and complete devices in the building automation industry.

The ACX Series Controllers contains the most recent Andover Continuum software and TAC’s Net Controller II, which is a network-managed controller. The ACX Series will offer a building administrator control of up to 8 access points (i.e. interior or exterior doors, dock entrances, etc.) and supports almost 500,000 personnel records. This series of controllers can be web-enabled for simple installation and control through a single workstation or automatically with program control.

The ACX Series Controllers offers other features as well. For example, the ACX Series will allow the user to adjust access rights during variable threat levels. Another feature will provide a total lockdown of a building from disabling card readers to physically sealing off access points. The ACX Series will additionally provide the user with complex encryption. Including 192-bit Internet Protocol Security (IPsec) and Internet Key Exchange Protocol (IKE) to ensure effective and safe communication between the access controllers and user workstations.

These access controllers were developed by TAC primarily in response to the U.S. government standards relating to security needs. This includes the Homeland Security Presidential Directive 12 and the Federal Information Processing Standards (FIPS) 201 project. The FIPS 201 project is a uniform standard for identification badges concerning building access and terminal login. Homeland Security Presidential Directive 12 was drafted by the White House, and a policy for a common identification standard for federal employees and contractors. TAC was also influenced by private sector customers who required more extensive security needs for their buildings.

TAC is a leader in building automation, security systems and energy solutions for both public and private sector clients. TAC’s products are based on standard non-proprietary technology such as TCP/IP, LonWorks, BacNet, and Ethernet. Besides security products, TAC produces systems that integrate such functions as environmental (i.e. heating, cooling, and ventilation), fire control, and lighting as well. Similar to the ACX Series Controllers, these other automation products can enable total control at a single workstation for a single or multiple buildings. TAC products have an advantage over others in that their products are compatible with a majority of other systems in the industry. This advantage gives the customer more options and prevents them from being restricted to another’s technology.

TAC has offices in the United States, Asia, and in several countries in Europe.

For more information on TAC and ACX series controllers

Written by:

Scott Cosby is an Engineering Technician and experienced writer at a state agency in Oklahoma for over 10 years. Mr. Cosby holds a B.S. degree in Geography from Oklahoma State University (OSU), studies in Engineering and Electronic Technology at the OSU campus in Oklahoma City.

© Chipkin Automation Systems 2007

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

Andover Continuum 1.73

BACnet clients must respect the servers report of supported services

In BACnet when a client connects to a server it has the responsibility of enquiring what services the server supports and then only using the supported services. In BACnet a server should be driven to a failed state if it receives a message requesing a service that isnt supported.

There are always grey areas in specs. Despite the plugfests, despite the testing … there will always be little gotcha’s. Isnt that why there are plugfests in the 1st place.

We recently supported a site where the server device reported that it did not support COV. Despite this ,the Andover Continuum software sent COV subscription requests. This caused a failure on the server device which was not able to handle them correctly.Normally the Andover Continuum respects the service capability of the server device but in this case additional programming had been configured in a program block which used subscriptions. These program blocks appear in this configuration not to have checked the supported services list before using one. Normally the server device responds to requests for unsuported services correctly – with an rejection message.

The problem was hard to diagnose for the following reasons;1. The problem manifested itself by allowing one server device to be recognized and its points were seen but when an identical (except for device instance id) was added then both servers failed.2. An attempt was made to emulate the problem offsite. The same controller and software version were used. The offsite test did not use the same configuration. Offsite , we were able to bring in the service devices and see the points. However, there were no program blocks and thus the problem did not show up.3. We obtained communication logs from site. The logs did show problems but these were a manifestation of the failure in the service devices caused by the COV subscription. Thus these errors were red herrings.4. The subscription message is sent early after the system is reset. Thus the subscription message was not captured in the logs.

Conclusions;

  1. It is probable that this same problem exists in all versions since 1.73 since we have not seen a correction notice.
  2. There is no substitute for capturing full logs from a site. Logs should be captured using external devices to avoid placing any additional load on the devices already installed on the network. Using an external device can be as simple as using a USB-485 converter. Chipkin Automation System has software tools for capturing BACNet MSTP logs. They are available free of charge. Call or email us for a free copy.

 

© Chipkin Automation Systems 2007

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