Communicating with KNX Networks

Plant SCADA KNX driver supports communicating with KNX IP devices via KNXnet/IP routers configured for Unicast or Multicast mode.

The routers need to be properly configured to route messages on to the IP network.

Note: The KNX driver should be capable of communicating with any KNXnet/IP-based KNX-to-IP router that has the routing specification implemented. However, you should perform specific testing to confirm the driver's ability to communicate effectively with a particular device.

When communicating with large and complex configurations it is important to configure the I/O devices appropriately. For example, when multiple floors of a building have identical installation of routers, devices and so on, you need to configure one or more I/O devices for each floor.

Multicast Mode

In Multicast mode, the driver connects to the router using the Multicast address and multicast port configured for KNX/IP routing. A single device in Plant SCADA can communicate with KNX devices on multiple routers. The routers must be configured for Multicast mode communication.

The following diagram illustrates a general layout of the KNX communication in multicast mode.

Unicast Mode

An entire group of KNX devices is configured as a single device in Plant SCADA. This requires all the devices to be on a single router which is configured for Unicast mode communication.

The following diagram illustrates a general layout of the KNX communication in unicast mode.

Connection sequence in Unicast mode:

1. Driver sends a CONNECT_REQUEST to the router.

2. After sending connect request, driver waits for TunnelConnectionTimeout to receive a response [CONNECT_RESPONSE] from the router.
   Once the connect response time is ended, any response for the previous connect request will be ignored by the driver and it will request another connection [CONNECT_REQUEST] if there is any pending retries (configured through TunnelConnectionRetries), else it makes the device offline.

3. Driver starts sending TUNNELLING_REQUEST packets to the router requesting data for respective group addresses configured in the Plant SCADA project to populate the cache.

4. After the InitTimeout time, if at least one tag is good or when all the tags become good whichever occurs first the driver makes the device online and displays the tag values.

5. Driver continuously polls the router status with a CONNECTSTATE_REQUEST to check the connection status with the router. The polling interval can be configured in TunnelConnectionActive INI parameter. The router will reply with a CONNECTSTATE_RESPONSE message to confirm the status.

6. The Driver/Router sends the DISCONNECT_REQUEST packet to close the connection if:

   • The device stops

   • The I/O server is stopped

   • The router receives any malformed packet

   • The connection is broken.

See Also

Communications Settings

Tag Addressing