ModScan32 Polling: Count Documents, Not Windows, When Isolating Traffic

A ModScan32 workspace with several visible windows does not
necessarily contain the same number of independent pollers. Conversely,
the foreground window may account for only part of the requests the
application is generating. Establish the polling documents behind the
interface before using its counters to explain a busy Modbus
connection.

The scope is WinTECH’s legacy ModScan32 documentation inspected on 19
October 2026, including ScanGuide.txt in its official distribution. No
executable was run, and no scheduling precision or throughput was
measured. Check the installed build when applying this diagnostic
method.

Separate the polling
object from its views

The WinTECH
guide in the official distribution, sections 1.1, 2.1 and 2.5,
distinguishes documents from windows. A document defines a device, point
type, address and length, together with periodic scanning. File New
creates another document; Window New Window creates another view of the
same document.

This matters when reproducing a communication fault. Two views are
useful for observing one definition, but counting them as two separate
workloads produces a misleading test description. Record document
identities and scan definitions rather than taking the number of tiled
windows as the number of independent request sources.

Imagine an original document reading one diagnostic range. A second
view of that document changes how the workspace is observed. A
separately created document reading an adjacent range introduces another
scan definition. Those two actions should not be treated as equivalent
load changes in a test log.

Read the counters at the
right scope

Guide section 4.2 describes per-document request and correct-response
counters. The status bar aggregates counters from active documents,
including documents used by OLE Automation clients. Section 4.5 adds an
important exclusion: user-defined messages are not included in the
message counters.

Therefore, neither one document’s count nor the status-bar total is a
complete packet capture. Record which counters were read, which
documents were active and whether a custom-command or automation path
participated. A difference between a trace and the screen can reflect
their observation scopes before it says anything about lost traffic.

Do not infer undocumented details of exception classification from
the word “correct.” Preserve the actual response and status indication
when that distinction matters. Nor should a reset of local display
counters be described as clearing a remote device’s protocol diagnostic
counters; these are different instruments.

Construct a controlled
comparison

WinTECH’s application
description confirms that multiple documents can actively scan and
that a document’s cycle is user-configured. Begin a proposed bench
comparison with one known read-only definition and no automation
clients. Preserve the document configuration and observe requests over a
recorded interval.

Next add a second view, keeping the underlying definition unchanged.
Then compare that with a separately created polling document. Observe
request identities and timing in an independent capture at the relevant
transport boundary. The intended question is which operation added a
poller, not whether the interface feels busier.

Run custom-command checks as a separately identified phase only if
their contents are documented and safe for the test device. Do not
include uncounted custom traffic in a denominator derived from ordinary
poll counters. Avoid changing the polling rate, number of documents and
requested span simultaneously, because the resulting traffic difference
would have several explanations.

Report the
workload rather than a screen layout

A reproducible record includes each document’s device identity,
function-table selection, start address, length and configured timing,
plus any automation or custom-message activity. Record the capture
interval and the counter-reset boundary without inventing an exact
relationship between configured delay and observed request rate.

WinTECH now separates legacy
ModScan32 from its newer products. Keep the actual product and build
in the record rather than assuming a result transfers unchanged to
ModScan64.

The useful outcome is a request-source inventory that explains the
trace. It prevents duplicate views from being counted as extra load and
prevents background documents or excluded command paths from
disappearing from a communication diagnosis.