User Manual

4/18/2011 Page 2 of 8
SignalFire Telemetry - Rev 5.0
Operating Modes
The Modbus-in-a-Stick supports two modes of operation, a preconfigured register set,
and an automatic scanning “transparent” mode. The Modbus stick can be used in either
mode or a combination depending on the system requirements.
Pre-Configured Register set mode
This mode of operation is most useful for large data sets, and frequent polling of a set
register map. This mode requires that the Modbus stick be configured with the register
map with the configuration utility at time of installation.
In this mode the pre-configured set of registers is automatically read from the modbus
sensor device and forwarded to the Modbus gateway on a pre-defined schedule (1 minute
to 5 minutes is typical). The register data is then buffered in the gateway and is available
to be read by the RTU at any time.
Transparent Modbus Mode (version Modbus_r38 and Gateway version 7.37 and later
only)
This mode requires no Modbus setup, and can be used for smaller number of registers
that only need to be read infrequently.
Upon initial power-up the Modbus stick will automatically poll all slave ID’s (1-240) to
discover attached devices. Any devices found will be reported to the gateway so that a
wireless link will exist to the Modbus device. This scan is automatically repeated every
24 hours in the event that an additional device is added to the bus. The scan may also be
initiated from the Modbus Stick’s debug port, or remotely from the Modbus Gateway.
See the Modbus Gateway manual for register details.
When the RTU polls the gateway for a Modbus register, if the register is buffered
(meaning it was pre-configured) the buffered value is returned. If the register value is not
buffered, but the Modbus slave ID is known, the request is forwarded over the Signalfire
wireless network to the Modbus sensor, the response is forwarded back to the gateway
and delivered to the RTU. Due to the multi-hop wireless network, latency will be
introduced. It is required that the RTU’s timeout be on the order of 10 seconds to allow
for maximum possible network delays. This limits the effective amount of data that can
be pulled.