MODBUS RTU SNIFFER

Overview 

The Modbus RTU sniffer driver enables fully non-intrusive insight into any existing Modbus RTU network consisting of a master and at leats one slave. The driver can be configured to “sniff” the requests of the master and the log the responses fo the slaves into the database some notes of interest are:

– The Modbus sniffer driver never transmits on the Mosbus network being sniffed

– Supported Modbus functions are indicated in the table

Supported Modbus RTU sniffer functions

-Both Holding and Input Registers are independently supported in device Srevice Objects.

-The Modbus sniffer Service Objects are similar to those of the Modbus Master Service Objects with the exception that insted of the driver itself generating request, it must rely on the existing Modbusmaster to inititate request on its behalf. Therefore if the master never reads or writes a certain register thats is configured in a sniffer service object the value of that register will never be updated in the internal database.

Sniffer Settings

Baud rate

Selects the baud rate of the network

Parity

Selects the parity and number of stop bits

Service Object Settings

The Modbus RTU Sniffer driver is passive (listen only), ans uses service objects to define what a registers to log values for from the network traffic. Each Input registeror holding register in a service object is mapped to 2 bytes in the database (the data type is fixed at 16-bit Unsigned)

Separate services objects exist for targeting holding register accesses and input register accesses. Because these service objects are largely identical, however, their settings will be adressed together. In general, the only difference is taht input register service object always sniff reads, whereas holding register service object csan selectively sniff only reads, only write or both reads and writes.

Description

This 32-character (max) field is strictly for user reference: its not used at any time by the driver.

Destination Address

Indicates the destination address (0…247 for holding register service objects and 1…247for input register service objects).

Note that address 0 is defined by Modbus as the broadcast address: if this address is used in a holding register service object, the “Read Function” must be set to “Disabled”, as slaves cannot respond to broadcast messages. Also that using a destination address of 0 will configure the service object to only log broadcast messages and requests targeted specifically at the defined destination address will be logged.

Start Register

Defines the starting register number (1…65535) for a range of registers associated with this service object.

Number of Registers

Defines de number of registers (1…123) to be targeted by this service object.

Database Address

Defines the database address where the first register of this service object will be mapped. The configuration studio will not allow entry of starting database address that will cause the service object to run past the end of the database. The highest valid database address, therefore, will depend on the number of items to be accessed.

Multiplier

The amount thats associated network values are scaled by prior to being stored unto de database. Network values (logged from the device) are divided by the mutliplier stored into the database.

Data Type

Fixed at 16-bit Unsigned

Read Function

Fixed at “4 (read input registers) ” for input register service objects. Select whether or not to log the reponses to read requests from the master to the slave: Note that the Read Function and  Write Function cannot be set to “Disabled”

Write Function

Not available for input register service objects. Select whether or not to log writes from the master to the slave. When enabled, writes using both function codes 6 and 16 are logged, so that write values will be captured regardless of the function code used by the master. Note that the Read Function and Write Function cannot both be set to “Disabled”.

Diagnostic Object

Each service object can optionally include a diagnostics object for debugging and diagnostics. Note that the diagnostics object for Modbus sniffer driver is slightly different than that of the Modbus RTU master driver, because the sniffer driver deas not actually transmit any requests itself. The diagnostics information should be interpreted from the prespective of the network master (as if the master were updating the diagnostics information) for example, when the master transmits a request to read a register, the TX Counter is incremented, and when the slave responds, RX Cpunter is incremented.

Diagnostics Database Address

Enter the database address at wich to store the status information.