Chipkin Automation Systems GE-TLC Driver Manual

Driver Manual
(Supplement to the FieldServer Instruction Manual)
FS-8700-108
GE-TLC
(GE Total Lighting Control)
Driver

Driver Version:
Document Revision:

1. GE-TLC Driver Description
This serial driver allows connectivity to a GE-TLC network by providing data transfer to the RLINK device. The RLINK device is provided by GE Lighting Controls as a gateway between its proprietary network and building automation networks. Thus to provide data transfer between a 3rd party protocol such as BACNet, it is necessary to connect the BACnet network to the RLINK by means of a FieldServer.
The driver may be configured as a client or server. The Client functionality is fully documented and supported. The FieldServer cannot be used as a substitute for the RLINK device – for this
reason the server side functionality is not documented. If you are interested using the server side please contact the sales group.

As a client the driver is capable of :
• polling for status data,
• sending commands to operate the relays,
• sending commands as if a PSS switch had been operated,
• receiving unsolicited status messages from the TLC network.

The driver can be configured as an adapter – a device which reads a predefined data set and automatically make its available as a set of BACnet data objects. More information is provided in Appendix A.1

The driver can support a simultaneous connection for a PC running TLC configuration software. More information is provided in Appendix C

2. Driver Scope of Supply

2.1  Supplied by FieldServer Technologies for this driver

2.2 Provided by the Supplier of 3rd Party Equipment

2.2.1 Required 3rd Party Hardware

2.2.2 Required 3rd Party Software

None required to enable this driver/

2.2.3 Required 3rd Party Configuration

None required to enable this driver/

2.2.4 Optional Items

3. Hardware Connections

The FieldServer is connected to the R-Link Device as shown in connection drawing.

Configure the R-Link according to manufacturer’s instructions

3.1  Block Diagram

3.2 Connection Photo – FS20 shown as typical

3.3  Cable Diagram – Using A Serial Cable

Note: On FS30 series only P2 can be used for connection to the Rlink.

3.4  Cable Diagram – RJ12 direct to RJ45

3.5 Hardware Connection Tips / Hints

3.5.1 Two or more Rlink’s on the same network ?

If there are two or more RLINK’s on the same network this could present a problem if the driver is not configured correctly. The reason is as follows. Normally the FieldServer is configured as a client. It polls for data and expects responses and can also process unsolicited status updates sent when something changes. If there is another RLINK on the network and it is being used by other client software such as the GE Software or Wincontrol then the FieldServer will receive a copy of the polls sent by that software as all network messages are sent to the each RLINK. When a copy of the poll is received the FieldServer will not know how to respond and this will cause problems. The problem is easily resolved by setting the connection parameter called ‘TLC_Server_Enabled’ to ‘No’. See section 4.2

4. Configuring the FieldServer as a GE-TLC Driver Client

For a detailed discussion on FieldServer configuration, please refer to the FieldServer Configuration Manual. The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer (See “.csv” sample files provided with the FieldServer).

This section documents and describes the parameters necessary for configuring the FieldServer to communicate with a GE-TLC Driver Server.

4.1 Data Arrays/Descriptors

The configuration file tells the FieldServer about its interfaces, and the routing of data required. In order to enable the FieldServer for GE-TLC Driver communications, the driver independent FieldServer buffers need to be declared in the “Data Arrays” section, the destination device addresses need to be declared in the “Client Side Nodes” section, and the data required from the servers needs to be mapped in the “Client Side Map Descriptors” section. Details on how to do this can be found below.

Note that in the tables, * indicates an optional parameter, with the bold legal value being the default.

Example

4.2 Client Side Connection Descriptions

1Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available on specific hardware.

2Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available on specific hardware.

Example

Example – Configured as Tunnel for PC doing configuration.

4.3 Client Side Node Descriptors

Example

3Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available on specific hardware.

4.4 Client Side Map Descriptors

4.4.1  FieldServer Related Map Descriptor Parameters

4.4.2 Driver Related Map Descriptor Parameters

4.4.3 Timing Parameters

4.5 Map Descriptor (MD) Example 1 – Read Relay Status.

This Map Descriptor (MD) reads the status of the relays on a LCP and stores the result. The length of 48 allows the driver to read andstore data for 48 relays. The address parameter is not used because the driver will read the data for all relays and will start storingrelay #1’s status information at offset 0 in the Data Array (DA) called DA_N22_Status. Relays #2’s status will be stored in offset 1.This read task will be executed every 5 seconds. The TLC_Function parameter tells the driver what data to read.

If a relay status changes the LCP sends an unsolicited message reporting the change. When the driver receives the message it willlook for a place to store the data. If the message is from the LCP_22 then this MD will be used to store the data. Thus the data in theassociated DA may be updated more often than the scan interval.

4.6 Map Descriptor (MD) Example 2 – Read Relay Failures.

This example is almost the same as example 1 except that in this example we are not reading the relay status but the relay failurestate. If a relay has failed the driver stores a 1 and if the relay is in a non-failed state the driver stores a zero.

This Map Descriptor (MD) stores the failure state for relay #1 in offset 48 of the Data Array (DA) called DA_N22_Status. Relays #2’sfailure state will be stored in offset 49.

If a relay fails the LCP sends an unsolicited message reporting the change. When the driver receives the message it will look for aplace to store the data. If the message is from the LCP_22 then this MD will be used to store the data. Thus the data in the associatedDA may be updated more often than the scan interval.

4.7 Map Descriptor (MD) Example 3 – Read Module (LCP/LAP) Status.

In this MD the driver reads the status of the module – this is the LCP or LAP status and not the status of the relays on the module. Thedriver stores 8 consecutive bits. In this example the Data_Array_Offset is 96 and thus the driver stores the 1st of the 8 at offset 96.

Bit 1 : Clock set if=1

Bit 2: Program set if=l

Bit 3: Relay failure if=1 . (cleared by clear relay failure indicators or when last relay failure self-clears)

Bit 4: Reserved

Bit 5: =1 when driver 1 is in place (relay 1-12)

Bit 6: =1 when driver 1 is in place (relay 13-24)

Bit 7: =1 when driver 1 is in place (relay 25-36)

Bit 8: =1 when driver 1 is in place (relay 27-48)

If the module status changes the module sends an unsolicited message reporting the change. When the driver receives the message itwill look for a place to store the data. If the message is from the LCP_22 then this MD will be used to store the data. Thus the data inthe associated DA may be updated more often than the scan interval.

4.8 Map Descriptor (MD) Example 4 – Passively listening for Relay Status changes, Relay Failures Module Status changes.

This is achieved by using the same MD’s as in examples 1-3 but change the function to ‘passive’. This means the driver will not pollfor data but by providing the MD’s you define a place for the driver to store data from the unsolicited messages.

When status changes result in unsolicited messages sent from the panels then when they arrive at the driver, the driver looks for aplace to store data from the messages. First it makes sure that there is a matching node. If there is it looks at the type of message andfinds a matching Map Descriptor based on the TLC_Function parameter. If it finds a match it stores data. If none is found the data is ignored.

4.9 Map Descriptor (MD) Example 5 – Turning a relay on /off

The driver can write through a read. This means that if you are reading the relay status (example 1) then to change the state of anyone the relays all you have to do is have the upstream device change the data in the associated Data Array. This is usuallyaccomplished by having a server side MD for the upstream protocol. The upstream normally reads the relay state by reading andhaving the FieldServer serve the response. Now the upstream node writes instead of reads. The data is written to the Data Array. Ifthe DA name and offset correspond to those shown in the MD below then the driver build a message to turn the relay on or off.

4.10 Map Descriptor (MD) Example 6 – Turning a relay on /off

It is conceivable that you may which to turn relays on / off but not read their status. In such a scenario you cannot use the solutionprovided in example 5. Now you need an MD.

In this example a single MD waits for an upstream node to send data to DA_N22_status offset 5. When the DA location is updated(not necessarily changed) the driver sends a write command to the relay using the 1 or zero found in the DA location to command therelay specified by the ‘Address’ parameter. Note that the length is 1.

You need one of these MD’s for each relay you which to command this way.

4.11 Map Descriptor (MD) Example 7 – Set the Relay Schedule Action

You cannot use the strategy outlined in example 5 to write the Relay Schedule Action because it cannot be read.

In this example a single MD waits for an upstream node to send data to DA_N22_Sched offset 5. When the DA location is updated (notnecessarily changed) the driver sends a write command to the relay using the 1 or zero found in the DA location to command the relayspecified by the ‘Address’ parameter. Note that the length is 1.

You need one of these MD’s for each relay you which to command this way.

4.12 Map Descriptor (MD) Example 8 – Set the Relay Clean Action

Use the same method as in example 7 but change the MD name, DA name and TLC_Function as illustrated below.

4.13 Map Descriptor (MD) Example 9 – Set the Relay Shed Action

Use the same method as in example 7 but change the MD name, DA name and TLC_Function as illustrated below.

4.14 Map Descriptor (MD) Example 10 – Capturing a PSS Broadcast

PSS switches send broadcast messages when activated. This driver can capture these message and store data from them allowingupstream protocols to read the data and take appropriate actions. If a PSS switch sends a message and the driver cannot find a placeto store the data because there isn’t an MD corresponding to the PSS’s Node_ID then the message is ignored.

A PSS may have up to 12 switches (Typically there are three switches for each 12 relays on a panel. Thus a LCP48 has 12 switches.The driver stores 5 data values for each switch. . The position in the DA where PSS data is stored is dependent on the switch number.Multiply the switch number by 5 to get the base offset.. Ensure that the Data_Format of the DA is suitable to store integer values.

Base Offset       : Src Address Number

Base Offset + 1 : Switch Number

Base Offset + 2 : On/Off, switch state

Base offset + 3 : Initiator

Base offset + 4 : Data Word 0 (raw value extracted from message)

4.15 Map Descriptor (MD) Example 11 – Emulating a PSS

You can have this driver emulate one or more PSS’s. Why would you do this ? If you wanted an upstream device to send data whichhas the same effect as a PSS then this provides the solution.

This MD waits for the upstream node to send data which updates the Data Array. When this happens the driver sends a writecommand as if a PSS had been operated.

When the write is triggered the driver extracts 2 consecutive data values from the Data Array. This is despite the fact that the MDlength is 1. Thus you must take care to use the DA correctly and ensure there are no overlaps with other MD’s.

The driver extracts the value from offset 0 (in this example) and treats this as the switch number and extracts data from offset 1 andtreats this as the required state. Load the value 17 to have a required state of ON and zero to have the required state of off.

The write is triggers when you update the value (update doesn’t mean change) the value at offset zero. So take care to set the requiredstate 1st.

4.16 Map Descriptor (MD) Example 12 – Link Status

Y

If you don’t care about the status of the link then don’t include this Map Descriptor. Whenever the status of the link changes an unsolicited message is sent you can capture this data with the following Map Descriptor. You can also actively poll for the data bychanging the passive to RDBC. The following data is stored. Contact GE to interpret the data.

Offset 0 : indicates dataline is shorted

Offset 1 : indicates LINK has No Clock

Offset 2 : indicates at least one LAP Relay Failure

Offset 3 : indicates at least one LAP No Program

Offset 4 : indicates that the alarm contacts are closed

Offset 5 : indicates that the unit is a Slave LINK

Offset 6 : Not Used

Offset 7 : means acknowledge alarm button was used to acknowledge alarms (otherwise cleared by computer)

Offset 8 : DF1 & DF2

Offset 9 : DF3 & DF4

Offset 10: DF5 & DF6

Offset 11: DF7 & DF8

5. Configuring the FieldServer as a GE-TLC Driver Server

A full Server has been implemented. The server implementation allows you configure the FieldServer so that remote devices appear as PSS’s and LCP’s to the GE system. The server side is used to test the client side as part of an ongoing quality assurance program. If you are interested in using it please contact us.

Appendix A. Advanced Topics

Appendix A.1. Adapter Mode

You can configure the driver as an adapter. An adapter reads a predefined set of data from the GE LCP and PSS’s and auto creates a server side configuration to provide this data to remote clients using BACnet. The best part of the adapter is that it requires minimal configuration as the driver knows what data to read and what data to serve.

You can choose whether you want the adapter to be BACnet IP or Ethernet.

You can also choose between a number of predefined sets of data.

You can also choose whether the FS creates one BACnet node to server all the data or whether it creates one BACNet node to correspond to each TLC node. (We call these virtual BACNet nodes).

You can exclude a TLC node from auto configuration and configure the node manually by simply assigning a node name that begins with an underscore (‘_’).

A.1.1 TLC_Adapter

Controls the server protocol and how server nodes are created. The following are permitted settings for this parameter

A.1.2  TLC_Adapter_Mode

Controls the auto-creation of client side Map Descriptors. Depending on the setting the driver will create MD that read different subsets of data from the TLC device. You can use combinations of these subsets.

A.1.3 BACnet Node_Id’s

Non Virtual Node Servers (TLC_Adapter = 1 or 2 )

If you specify a System_Node_Id in your configuration file then the driver will use that to number the BACnet node created to serve the data. If the driver cannot find this setting then it uses a hard-coded number = 11221.

For limitations on the BACnet Node Id read one of FieldServers’s BACnet-IP manual.

Example of how to set the System_Node_Id

Virtual Node Servers (TLC_Adapter = 3 or 4 )

The driver attempts to number each BACnet node based on the TLC Node in the following way; The driver looks for the parameter called ‘Alias_Node_ID’ on the TLC node description. If it finds this parameter then it uses this value as the number of the corresponding BACnet node. If the parameter isn’t found then the driver number the BACnet node with the same Node_ID as the TLC node.

A.1.4 BACnet Object ID’s

The driver numbers the object sequentially starting at 1 for Virtual Node Servers.

For non-Virtual Node servers the objects are numbered to indicate the type of device and the they are numbered so object representing one node can easily be isolated from objects representing another node. For each new node the 1000 is added to the object ID. If the objects represent a PSS emulation they start at 250, if the objects represent a PSS message trap then they start at 260, if the objects link status they start at 350 and if the objects represent the relays and module they start at 1.

Appendix A.2. Example Adapter configuration file

Appendix A.3. BACnet Object List

A.3.1 Lighting Panel Objects

A.3.2 PSS Objects

PSS Traps

(A PSS Trap is a way of monitoring a remote PSS switch so that its activation can be monitored by an upstream front end)

PSS Emulation

(A PSS emulator is a way of emulating a PSS switch. When the upstream remote front end sends data to these objects, a message is sent on the TLC network as if a PSS had been activated)

A.3.3 Notes to the Object List

Appendix B. Troubleshooting tips

Appendix B.1. Connection Tips & Hints

Forcing a link reset.

Section Appendix B.3 provides information on how to expose driver stats. Once configured, you can poke values into the Data Array where the stats are reported to generate a reset of link by

Appendix B.2. Driver Error and Warning Messages

A number of corrective actions require that you edit the configuration file. When you have completed the edit, you must download the modified configuration file to the FieldServer and reset the FieldServer for the changes to take effect.*

Appendix B.3. Driver Stats – How an Upstream Device can Monitor Performance.

If this driver is appropriately configured , it can expose operation statistics in a Data Array which can be monitored by a remote device to check that the driver is performing without error.

The lines from the example below can be cut and pasted into a configuration file to expose these stats.

The driver maintains one set of stats for each communication port.

To determine the base offset use the following formula:

Base Offset = Port Number * 100 where Port Number is the port number printed in the error log by message #32.

Relative Offset : Calculate the offset of each stat by adding the relative offset to the base offset.

Appendix B.4. Node Offline

The driver follows the standard FieldServer procedures for offline node with one exception – If all the nodes on a connection are offline the driver will reset the link with the Rlink.

The notes below may be superseded by the Bridge Configuration manual as they describe the general functionality of the FieldServer.

Normally, the driver tries each node 3 times (Node parameter = Retries). It waits 10 seconds (Node parameter = Retry_Interval) between retries. Thereafter it puts the node status to offline and waits 30 seconds before retrying (Node parameter = Recovery_Interval) until it receives a good response. The normal polling interval is specified by the Map Descriptor parameter = Scan_Interval. Good polls must continue for a period of 2 seconds before the driver puts the node back online. This period is controlled by the Node Parameter = Probation_Delay

When a node is offline or when the data read by the client side of the driver has aged out the server side of the driver stops serving the data. You can control the data age aspect of behavior using the Bridge parameter = Cache_Age_Limit whose default value is 300 seconds. The offline behavior can be controlled by the node parameter = Srv_Offline_Method . The following are permitted values for this parameter.

Ignore_Clients =synonym= Always_Respond

Any_Offline

All_Offline,

Don’t forget that this parameter is applied to the Server Node Descriptors to give the following effect – When a remote client polls for data the FieldServer inspects the data status before responding. If the data is ‘offline’ then the response is based on the setting of the parameter. One server node may be serving data read from several lighting panels/ devices.

Appendix C. Configuration as a Tunnel

Appendix C.1. Simultaneous support for a Configuration PC

The driver can allow a computer running the GE TLC Configuration application to send messages to the TLC network using the same Rlink. The computer is connected to a secondary port. Every message the computer sends is copied to the Rlink port and every respond from the Rlink is copied back to the secondary port. When the secondary port is active receiving a message from the configuration PC, the driver suspends its own polling for a short period. The period can be configured.

This solution saves the requirement for a second Rlink device to be installed. The purpose of this functionality is to allow for occasional monitoring and configuration changes. It is not intended to provide support for a continuously polling remote device.

This configuration has been tested by GE TLC’s tech support group.

Appendix C.2. Limitations of the tunnel

The tunnel in the driver has been designed to allow upload/download of configuration without using PC software without requiring an extra Rlink. It is expected that this occurs infrequently and as a maintenance task. It was not designed to allow the tunnel to be used for continuous data configuration or status or command data transfer. It is expected that during the upload / download that remote operation of relays using the FieldServer will not occur. If they do occur it is possible that some of these commands will be lost. There are two parameters used to control the tunnel. These can be used to experiment to find the optimal setting for your site but performance is not guaranteed. If you require reliable remote control of the relays using the FieldServer do not leave the software using the tunnel to remain running and continuously polling the network and further, use the tunnel to transfer configurations only when this remote operation is not required. If these limitations are not acceptable to you then do not use the tunnel.

During testing it was found that a highly satisfactory performance could be achieved with the tunnel. Results may vary.

Appendix C.3. Block Diagram for Tunnel Configurations

Block Diagram of a FieldServer providing a tunnel to allow simultaneous configuration and monitoring using a PC running GE-TLC configuration software.

Appendix C.4. Cable for Secondary Port (Tunnel) Connection (FS20 and FS40)

Appendix C.5. Cable for Secondary Port (Tunnel) Connection (FS30 Series)

Appendix C.6. Tunnel Trouble Shooting

C.6.1 Baud Rate and connection settings:

The Baud rate of the tunnel connection is fixed by the baud rate of the primary connection. Thus if the baud rate of your primary connection is 9600 then the tunnel expects messages at the same baud rate. This applies to the other connection settings such as parity, stop_bits and data_bits.

Check that baud rate of the GE Software or WinControl is set at the same baud rate. If you are using Remote Serial Port devices such a Lantronics RSP then ensure that its baud rate is set the to the same value.

We have had one customer report, that once the Windows software had tried to connect at 19200, then the RSP device which auto sensed the baud rate, remained at 19200 despite changes to the windows software.

C.6.2 Do not keep the tunnel active all the time:

If the windows software is permanat3ently sending messages to check the status of the lighting panels then the tunnel will be active all the time and the FieldServer will not have time to do its work of polling for data. Read about ‘TLC_Tunnel_Delay’ in section 4.2

C.6.3 TLC_Tunnel_Delay Settings:

TLC_Tunnel_Delay=10msec Tunnel_Option=0(Default):

During testing, a value of 10 with Tunnel_Option=0(Default), was found to allow upstream devices to control relays with satisfactory but not perfect performance while WinControl continuously monitored the panel. Uploading / Downloading a configuration with Wincontrol and simultaneously controlling relays through the FieldServer was not tested.

TLC_Tunnel_Delay=500msec Tunnel_Option=1:

During testing, a value of 10 with Tunnel_Option=1, was found to allow upstream devices to control relays with highly satisfactory but not perfect performance while WinControl continuously monitored the panel. Uploading / Downloading a configuration with Wincontrol and simultaneously controlling relays through the FieldServer was not tested.

6. Revision History