Each Modbus client device has a “Modbus Config” container slot with 5 properties—you can access them on the device’s property sheet, as well as the New or Edit dialog for a device object when in the device manager view (of its parent network). Figure 24 shows the properties in the New dialog for a device.

Figure 24. Modbus Config properties in New/Edit dialog when working in network’s device manager view

These properties allow you to “override” the network-level (global) Modbus Config equivalent settings for handling Modbus data from and to this device, and are described as follows:

In many cases you might leave these properties at defaults, particularly if different devices used the same settings—in which case you could adjust them (globally) at the network level.

Each Modbus client device has a “Ping Address” container slot with 3 properties—you can access them on the device’s property sheet, as well as the New or Edit dialog for a device object when in the device manager view (of its parent network). Figure 25 shows ping properties in the New dialog for a device.

Figure 25. Ping Address properties in New/Edit dialog when working in network’s device manager view

These properties specify a particular data address (either input register or holding register) to use as the device status test (meaning “Monitor” ping requests). Ping requests are generated at the network-level by the configurable network monitor. See “About Monitor” in the Drivers Guide for more details.

When enabled, a network’s monitor periodically pings (queries) this address. While receiving any response from the device, including an exception response, this is considered proof of communication, and the Modbus client device is no longer considered “down” if it had been previously marked “down”.

The device ping address properties are:

Default device ping address values (first holding register) typically “work,” as even an exception response from the device is considered OK for device status. While this is considered proof of communications, it is recommended to configure the ping address to a known data address and type according to the device’s documentation, to ensure device status monitoring without an exception response.

Each Modbus client device has four container slots for setting a “base address” on each of the four data item types (coils, inputs, holding registers, input registers), as follows:

Access these slots on the property sheet of the client Modbus device, as shown in Figure 26.

Figure 26. Base Address slots of client Modbus device

These properties specify an “address offset” that is added to any child proxy point using a data address for that data item type. Base addressing of coils and holding registers also affects addressing of “Preset” components (see Modbus preset components).

Each base address container slot has two properties:

For example, if a device’s Holding Register Base Address is set to “Decimal, 100”, any child Modbus proxy point using a holding register “Data Address” of “Decimal, 13” is effectively addressed as “Decimal, 113” (Absolute Address). See Modbus client point ProxyExt properties for related details.

Typically, all Base Address properties of a device are left at default (hex: 0). However, you can use them as an engineering method (along with multiple device objects) if a Modbus device has data partitioned into multiple areas with repeating address patterns. This way, the same device (and child proxy points) can be replicated, and the only address changes made in the “Base Address” offsets.

If entering Base Addresses in a device, Modbus formatted data addresses cannot be used (select Hex or Decimal)—and this also applies to Data Address properties of child proxy points.

Each Modbus client device has a frozen container slot “Device Poll Config,” which you can see under the device when expanded in the Nav tree, as well as in the device’s property sheet, as shown in Figure 27.

Figure 27. Device Poll Config container of client Modbus device

By default (initially) the Device Poll Config container is empty, but it can hold one or more “Device Poll Config Entry” children, which configure and enable device polling. A device poll permits a single NiagaraAX Modbus query message to retrieve a number of consecutive data values. Device-level polling may help overall polling efficiency by reducing the number of polls necessary at the point-level.

In a few cases, a device-level poll has actually proven counterproductive, at least for improving polling efficiency. It was determined that the target Modbus device was taking more time to assemble a long data response than it did to handle a number of separate responses (no device poll—point-level polling only) for the equivalent data. While not typical, you should be aware that Modbus devices vary in performance.

Configuring Device Poll Config

Based upon the existing child Modbus proxy points, you can configure “device-level” polls (Device Poll Config) using either of these two methods:

• Automatically, using the right-click “Learn Optimum Device Poll Config” action on the Device Poll Config container (Figure 28). This creates one or more Device Poll Config Entry components, already configured to produce the needed device polls to query consecutively addressed data items.

  The station must be running to use this method (offline station usage not supported).

• Manually, by editing properties in any existing Device Poll Config Entry, and duplicating/re-editing it (or by coping entries from the modbusAsync or modbusTcp palette and editing as necessary).

Figure 28. Action “Learn Optimum Device Poll Config” dynamically adds/configures child components

Typically, you choose the automatic (action) method—note it lets you replace existing device poll entries (start over), or append to the existing device polls. The Device Poll Config container also has a separate “Clear” action you can use to remove all existing Device Poll Config Entry children.

For best results, it is recommended that you first create all needed proxy points under a device, before configuring for device polling.When executing the learn action, its algorithm looks for any consecutively addressed Modbus proxy points, and creates a DevicePollConfigEntry if it finds two or more consecutively addressed points. If you have small gaps between consecutively addressed Modbus proxy points, you may want to manually adjust the created DevicePollConfigEntries to poll over the small gaps. Remember you can always create, configure, and remove DevicePollConfigEntries until you find the most efficient device-polling scheme.

Device Poll Config Entry

Figure 29 shows a Device Poll Config Entry child expanded, and its properties that were populated from the learn action on the device’s Device Poll Config slot.

Figure 29. Expanded Device Poll Config Entry, representing one device poll message

Properties of a Device Poll Config Entry child are described as follows:

• Enabled — By default, is true. If set to false, associated proxy points use individual point polls instead.

• Start Address — First data item address, including format and numerical address.

• Data Type — Modbus data type: Holding Register, Input Register, Discrete Coil, or Discrete Input

• Consecutive Points to Poll — Number of data items to poll starting from start address

• Read Group Size — 1 or 2, Usually 1 unless all data items are 2-register types (float or long values), although a 1 works the same, providing “consecutive points to poll” is really consecutive registers.

• Read Status — A numerical error code 0—2, and a corresponding text description.