S7-300 + kpserverEX : Issue with Boolean Tag Behavior on KEPServerEX

[AR_10646924]

Hello,

I’m facing a strange problem with KEPServerEX. We noticed that some alarms are not being logged in ThingWorx but are listed on the HMI. Upon investigation, we found that the scan rate on Kepware was set to 1000 ms, and the boolean tags were changing value too quickly (e.g., 0 -> 1 -> 0 within 200 ms), preventing them from being scanned.

We adjusted the device and Quick Client scan rate to 100 ms, and now we can see changes and the update count increment correctly.

However, this behavior doesn’t align with what’s happening on the PLC side. When the boolean changes from 0 to 1 on the PLC, Kepware shows the value changing from 0 to 1 and then immediately back to 0. The same behavior occurs for tags with value of 1.

Do you know why this could be happening?

We currently don’t have access to the PLC, but it shouldn’t be the issue because both Kepware and the HMI read from the same database.

Environment:

PLC: Siemens S7-300
KEPServerEX: v6.14.263.0, Siemens TCP/IP Ethernet driver
OS: Windows 10 IoT Enterprise (Edge)
Clients: ThingWorx (read-only), OPC Quick Client / ThingWorx
Configuration:

Device Scan Rate: 100 ms (Scan Mode = “Request All Data at Scan Rate”)
Quick Client Update Rate: 100 ms
Tags: ~550 total (~450 BOOLs, remaining WORD/INT in the same DB)
Access: All tags are Read-Only; no client writes; quality is always "Good."
Any guidance would be appreciated!

[MKhatri · Accepted solution]

Greetings,

Following our recent investigation into the issue with KEPServerEX where certain alarms are not being logged in ThingWorx but are visible on the HMI, I’d like to share a summary of our findings and some recommended actions.

Possible Causes Identified:

• Tag Value Fluctuation Due to PLC Logic
• Scan Rate vs. Tag Update Frequency
• Driver Behavior or Optimization Settings
• ThingWorx Subscription or Value Stream Configuration

Recommended Resolutions:

Use Latching Bits in PLC:
Modify the PLC logic to latch alarm bits until acknowledged or cleared, ensuring the bit remains active long enough to be reliably read.

Enable Tag Logging in Quick Client:
Use OPC Quick Client to log tag values over time to determine if transitions are being missed by Kepware or if the issue lies elsewhere.

Check Driver Diagnostics:
Enable diagnostics for the Siemens driver in Kepware to monitor polling behavior and response times.

Use Event-Driven Tags (if supported):
Consider using event-driven updates instead of polling to capture rapid transitions more effectively.

Increase Scan Rate Further (if feasible):
Reduce the scan rate below 100 ms (e.g., to 50 ms) if system performance and network conditions allow.

Review ThingWorx Logging Configuration:
Ensure ThingWorx is configured to log every tag change rather than periodic updates to avoid missing transient states.

Please let me know if you need assistance implementing any of these recommendations or if further investigation is required.

Regards,
Mohit