ModBus Configuration

All data is published using the ModBus "Write Multiple Registers" function code (value 0x10 in hex) and message structures for the published data and the expected success or error responses that should be returned from the subscriber are as per the ModBus standard.

The structure of a "Write Multiple Registers" message is as follows:
ModBus Header Fields (inc Unit ID and Function Code)  
Relative start register address 2 bytes unsigned integer
Num registers, N, to write 2 bytes unsigned integer
Num bytes of register values 1 byte
Register values N * 2 bytes unsigned integer
The start register address can be 40001 or greater. When transmitted in the above message it is converted to a relative address by subtracting 40001 fro the absolute address, e.g. 40001 => 0, 40002 => 1 and so.
Some implementations of ModBus use 1-based relative register addresses and so map 40001 => 1, 40002 => 2 and so on. 
ModBus targets should send a response to the "Write Multiple Registers" message. There is a success (ack) response and in case of a problem there is an error (nack) response. In case the ModBus target for some reason will not be issuing responses we can disable waiting for responses using the tick box on the Hawk GUI ModBus preferences. If the target system implements ModBus correctly and responses will be sent then leave this check box ticked.
If the ModBus target has a unit ID associated with it (a value from 0 to 254) then this can be specified so that the target accepts the message. If not required or if it is not known what the target's unit ID is set this to 255 (the default).
It is possible to specify how many Dragonfly devices you wish to simulate alarms for. The default is 1 but any amount up to and including 64 can be specified. Each device is assumed to have 8 channels for the purposes of this test harness.
It is possible to set the start register address. The default and lowest allowed value is 40001. 
The default update rate is 1Hz, possible values are 1, 2, 5, 10 and 20 Hz. 

System Status Alarms
The first type of data published represents system status alarms. This comprises a bit representing overall system health and a bit per device representing device health. A bit value of 0 = healthy and 1 = error.
If there are M devices to report then the first register value addressed at the specified starting register address contains the overall system status in bit 0 then bits 1 to 15 contain the status bit for devices 1 to 15, in increasing device start channel order. If M > 15 then further consecutive register addresses are used after the start register to encode the remaining devices. The next register value will contain status bits for devices 16 to 31 encoded in bits 0 to 15 respectively. The third register will encode statuses for devices 32 to 47 in bits 0 to 15 respectively and so on.

Channel Data Quality Alarms
The second type of data published is channel specific data quality alarms. Each channel will use a unique register address and will transmit the status in a single register value.
The register value will be used as a bit field where the bit positions are defined as follows:
Channel Alarm Bit Values
bit 0 Stale Data
bit 1 Broadband high warning
bit 2 Broadband high alarm
bit 3 Broadband low warning
bit 4 Broadband low alarm
If no bits are set then the channel data quality is good and there are no issues.