Why does zenon Process Gateway show?? for Update/Seconds?

What does ?? in Update/Seconds mean on a Modbus serial gateway?

On a zenon 6.20 SP1 system, the Process Gateway (zenprocgateway.exe) ran a Modbus serial module that had worked for some time. Its configuration form then began showing ?? instead of an Update/Seconds figure. The external Modbus master kept polling with no connection errors. A PC reboot cleared the fault, and it had not returned about a month later. No root cause was identified.

Because the master saw clean replies, the serial link and the request/response handling were working. The ?? points higher up, at the part of the module that produces the rate figure. Trace the request hop by hop:

1. The UART or USB-serial adapter and the Windows COM port driver pass the bytes to the application.
2. The Modbus serial module DLL inside the Process Gateway decodes the request and answers from its register image.
3. The gateway host keeps that register image fed with variable values from zenon Runtime.

Each Process Gateway protocol module is a separate DLL with its own window and its own statistics. The Update/Seconds value is computed inside that module. When the module cannot produce the number, the form shows ??.

The operational risk is stale data. A slave-side gateway that answers from a buffered image keeps answering the master even if its upstream feed from Runtime freezes. In that case the master logs no errors, but it is reading old values. Before you do anything else, find out whether the served values are still live.

Which hop stopped reporting?

Check the physical layer first, then work up the stack. The master's error counters already clear the lower hops, but confirm them in writing before you restart anything.

Restart the gateway, reboot the PC, or upgrade?

Several options clear or avoid the condition. They differ in downtime, in how much of the stack they reset, and in how much diagnostic state they destroy.

Recommendation:

1. Capture the state of the system first.
2. Run the stale-data test.
3. Restart only the gateway process.
4. Reboot the PC only if ?? survives the process restart.

This order tells you which layer held the fault. A reboot clears everything at once, so it fixes the symptom but tells you nothing about the cause.

How do you capture evidence and restart in the right order?

1. Take a screenshot of the Modbus serial module window showing ??. Record the PC boot time with systeminfo (System Boot Time) so you can tie the fault to uptime.
2. In Task Manager > Details, add the Handles, Threads and Commit size columns. Record the values for zenprocgateway.exe and for the zenon Runtime process.
3. Export the Windows Application and System event logs since the last boot. Look for application errors from the gateway, and for serial or USB driver warnings.
4. In Device Manager, note the COM port type. If it is a USB-serial adapter, check its power management tab. Selective suspend or re-enumeration can disturb long-running serial applications.
5. Run the stale-data test: force a known change on a mapped Runtime variable and confirm the master reads it. If the master does not see the change, schedule the restart immediately.
6. Warn the master-side operators. The restart causes a comms failure on every module the gateway hosts.
7. Close the Process Gateway. Confirm in Task Manager that zenprocgateway.exe has exited, then start it again with the same configuration.
8. Open the Modbus serial module window and check Update/Seconds. If ?? persists, reboot the PC.
9. Log the date, the action taken (process restart or reboot), and the captured figures. Recurrence intervals are the only way to separate an uptime-driven fault from an event-driven one.

Which conditions bring the ?? back?

• Trusting master error counters alone. Zero errors only proves the serial hop works. It does not prove the values are fresh. Repeat the stale-data test on a schedule.
• Uptime-dependent growth. If handles or commit size of zenprocgateway.exe climb steadily between reboots, the fault will return after a similar uptime. A planned periodic restart of the gateway is a valid workaround on a version that cannot be upgraded.
• USB-serial adapters. A Windows power-management event or a driver reload can briefly remove the COM port. The module may reconnect for traffic but leave its statistics in an undefined state. A native serial port or an adapter with power saving disabled removes this variable.
• Reading the wrong window. Each module keeps its own statistics. Confirm you are looking at the Modbus serial module and not another protocol DLL loaded in the same gateway.
• Rebooting before capturing state. The reboot fixed this installation but destroyed the process and driver state that would have identified the cause. Capture first, every time.
• Reproducibility for support. COPA-DATA support can only test the behaviour against a current version if the trigger can be reproduced. Record what changed before each occurrence: Windows updates, adapter replugs, Runtime restarts, and project reloads.

How do you confirm the Modbus master reads live values after the fix?

1. Confirm Update/Seconds on the Modbus serial module shows a numeric, non-zero value while the master polls.
2. Toggle a test bit and write a changing analog value in zenon Runtime. Confirm the master reads both changes within one poll cycle.
3. Check the master's counters over one full shift. Timeouts, CRC errors and exception responses should stay at zero.
4. Record handles, threads and commit size of zenprocgateway.exe right after the restart. Record them again daily for a week and compare against the baseline. A flat trend clears the leak hypothesis. A rising trend sets your periodic-restart interval.

FAQ