Modbus TCP uncontrolled polling

Problem: Modbus TCP device is getting polled every second, despite Tag Group settings
Device: Modbus TCP connection to Rotronic room temperature monitor
S/W: 8.0.7 / Modbus Driver 6.0.7
I am capturing two serial numbers, temp, and humidity from a Rotronic device. They feed standard OPC tags with hardcoded paths (e.g. ns=1;s=[Rotronic]Reading1). The tags are assigned to a custom Tag Group (Direct mode, Polled, Rate= 15,000). When the moon aligns and I create the device / addresses / tags from scratch, the tags follow the polling rate of the group and the device gets two Modbus requests every 15 seconds.
The problem is that on a whim the tags will start refreshing every second. This has happened when I’ve renamed the device, created the tags via drag-n-drop from the tag browser, and has even happened after 12 hours of stable functionality when I restarted a tag in the OPC browser.
Once the fast polling starts, all the tags go to that rate and it’s irreversible. To the point that it is currently hammering out Modbus requests even though I just recreated the device, added the addresses, but have NO TAGS CREATED.
This polling rate causes periodic tag health issues from overquerying the device - and this data is supposed to be used for audit trail on a temp controlled room.
Anyone else seen anything like this? I’ve been experimenting for days and can’t find how to precisely reproduce (or avoid) the problem.

Address Configuration:
|Reading|1|4|TRUE|0|InputRegisterFloat|31001|
|Serial|1|4|TRUE|0|InputRegisterUInt32|30001|
Radix 16

This sounds like a bug that should be fixed in one of the upcoming nightly releases.

The changelog note on it right now is:

OPC tags in Direct tag groups can occasionally get subscribed at a default “leased” rate, depending on references to the tags.

Is that [bug-14313] from August? Looks like you nailed the problem.
I changed my Modbus tag group from Direct to Driven mode triggered by 2=2. Forcing the Driven group on, I can specify a 20,000 polling rate and it seems solid. It may have taken a tag restart to take effect.
One interesting behavior - I have two blocks of Modbus addresses defined (the two sequential floats for readings and the two sequential longs for readings). These two “blocks” always generate their own Modbus request (e.g. 1E 3E 00 00 00 06 00 04 75 30 00 04 and 1E 41 00 00 00 06 00 04 79 18 00 04). When the direct groups were working I could poll these two groups at independent frequencies (thus Modbus Slow for Serial nums and Modbus Fast for readings).
While running the tags as “Driven”, both Modbus requests seem to synchronize to the faster of the polling rates.
Bottom line is, I am relieved to have a workaround - and really appreciated your assistance.

The fix was merged this morning, so if the nightly build succeeds tonight you should be able to grab an 8.0.9 nightly release tomorrow and verify.

Rock and roll. Thank you!

I confirmed yesterday that the 8.0.9 nightly build has (so far) resolved the Direct / Leased polling rate issue. I was able to create stable UDT instance Modbus Tags (with parameterized paths). It is also allowing one address range (readings) to have a faster rate than another range (serial numbers). All is right in the world at the moment. :+1:

2 Likes

Does the 8.0.9 Stable release still have the fix for direct Tag Groups polling at Leased rates? Looking to do the upgrade off the nightly build I’ve been running.

Yes, although if you wait a few more days you can probably go to 8.0.10 and get a few more fixes.

1 Like

Cool beans, I’ll do just that.