BACnet MSTP on a Delta DFM-200 Field Module
The Delta DFM-200 Field Module supports two communication protocols: BACnet MS/TP and LinkNet, Delta Controls’ proprietary protocol. This dual-protocol capability allows the same hardware platform to be used in different system architectures, depending on how the device is configured.
When shipped from the factory, the DFM-200 is typically configured for LinkNet operation using an internal protocol-selection jumper. Despite this default setting, BACnet MS/TP communication is still active on the device. As a result, BACnet MS/TP clients can communicate with the device under certain conditions even when the jumper has not been changed.
This behavior is important for engineers integrating Delta field modules into BACnet systems or troubleshooting mixed-protocol environments. For more information on BACnet integration options, see our BACnet Integration Gateways and Routers page.
BACnet MS/TP Behavior with the Default Jumper Setting
With the protocol-selection jumper set to LinkNet, the DFM-200 will still respond to direct BACnet MS/TP read and write requests. This means that if an MS/TP client already knows the device’s MAC address and device instance, it can read object values and write properties as expected.
However, BACnet device discovery behaves differently in this configuration. The DFM-200 will not respond to standard BACnet Who-Is broadcast messages while the jumper remains set to LinkNet. As a result, the device will not appear during normal BACnet network discovery scans.
Role of the Protocol-Selection Jumper
The primary function of the internal jumper on the DFM-200 is to control whether the device responds to BACnet discovery requests. When the jumper is set for BACnet MS/TP operation, the device will reply to Who-Is messages with an I-Am response, allowing standard discovery tools to locate it automatically.
When the jumper remains in the LinkNet position, BACnet MS/TP communication is still possible, but only for clients that already have the necessary addressing information. This distinction can be confusing during commissioning if discovery behavior is assumed to reflect overall protocol availability.
Using Manual Device Entry with CAS BACnet Explorer
Even when a BACnet device does not respond to discovery broadcasts, it may still be possible to interact with it by manually defining the device in a BACnet client tool. This is particularly useful for devices like the DFM-200 when the protocol-selection jumper has not yet been changed.
CAS BACnet Explorer supports manual device entry, allowing users to specify device instance, MAC address, and network parameters directly. Once added manually, the Explorer can poll the device, retrieve its object list, and read or write object properties.
Practical Integration Considerations
This capability is especially helpful during commissioning and troubleshooting. It allows engineers to verify BACnet communication and object behavior before physically accessing the device to change jumper settings. In retrofit or live-system scenarios, this can reduce downtime and simplify validation.
Understanding how discovery behavior differs from basic read/write communication helps avoid incorrect assumptions about device compatibility. A device that does not appear in a discovery scan may still be fully functional on the BACnet MS/TP network when addressed directly.
FAQ
Can the DFM-200 communicate over BACnet MS/TP when set to LinkNet?
Yes. BACnet MS/TP read and write operations are still supported, but discovery responses are disabled.
Why doesn’t the device appear during BACnet discovery?
The protocol-selection jumper controls whether the device responds to Who-Is messages.
How can I access the device without changing the jumper?
By manually adding the device in a BACnet client such as CAS BACnet Explorer.