HGL ModBus Test Harness

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 incorrectly use 1-based relative register addresses and so map 40001 => 1, 40002 => 2 and so on. The test harness can handle this as there is an option to tick to support 1-based relative register addresses but this option is not ticked by default. Only tick this option if you suspect the target ModBus system does not support 0-based addressing.

To use the test harness you must specify an IP address and a port to which the alarm data will be sent using ModBus over Ethernet. If you specify the IP address as 127.0.0.1 (internal loop-back) then the test harness will create a subscriber object to receive the published alarms and simulate sending a suitable acknowledgement message in response. This allows the test harness to be run for test simulation purposes when a real target system is unavailable.

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. Our test harness by default expects this to be the case. 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 GUI. 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. In this test harness register addresses are computed consecutively starting at the specified start register so system status alarms followed by channel data quality alarms are in a contiguous block of registers. The test harness' user interface will indicate at what address system status alarms begin and at what address the first channel's alarm is, the other channels follow after the first channel's address.

It is possible and safe to change the number of devices and the start register address while publication is active. It just means that the next data published after these are changed will use the new settings. You do not have to stop, change the values, then start again. Although the target side may not like this depending on what it does with the received data. If in doubt stop publishing, change the values, then start again.

The test harness allows a user to specify the update rate in Hz. The default is 1Hz update rate, possible values are 1, 2, 5, 10 and 20Hz. It is also possible to simulate the same status being published repeatedly for several updates using the "Repeat status for N updates" spin edit, possible values are 1, 2, 3, ..., 10.

It is also possible to enable verbose debug logging. By default this is turned off. This can be safely be toggled at run-time while publishing data so you do not have to stop, tick it, then start again.

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.

The test harness cycles through devices periodically based on the update rate and repeat value and so initially device 1 will show in error, then device 2 and so on. Lastly all devices will be set to no error to simulate a working system and then we cycle back round again. When a device is in error the overall system error bit will also be set in bit 0 of the first register value.

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.

The test harness will cycle through all the possible alarm bit values repeatedly for each channel. It will do this periodically based on the update rate and repeat value. The alarm settings will be staggered across the channels so initially the following alarms are set: channel 1 stale data, channel 2 BB high warning, channel 3 BB high alarm, channel 4 BB low warning, channel 5 BB low alarm, channel 6 no alarm, channel 7 stale data, channel 8 BB high warning and so on.