Leased Tag - Need slower OPC UA Subscription Interval when lease is inactive

Ignition
1

Dear All,

In tag Group Editor, using OPC UA "Publishing Interval" default value of -1.0 for a Leased tag results in the interval being limited upwards to 1000ms, which is too fast for my needs.

Specifically what happens seems to be this:
Ignition generally chooses a (Requested) Publishing Interval that is 1/2 of the specified (Sample) Rate, which makes sense. What does not make immediate sense to me is that if the Rate is set higher than 2000ms, the chosen Publishing Interval remains at 1000ms, and does not increase beyond this seemingly arbitrary value.

Here are some values as they appear in Status - OPC Connections:
Name, Tag Group Rate, Requested Publishing Interval, Revised Publishing Interval, Tag Count:

tag-group-default_viewnorm_slow-leased
1000 500 500 33
tag-group-default_viewnorm_slow
30000 1000 1000 3846

Q1: Where does this 1000ms max value come from?

My OPC UA Server, a Siemens 1500 PLC, bravely accepts the requested interval - ie. it does not modify it - but then it struggles to publish on time. As a result, I see Good_Overload status being applied intermittantly in the Tag Browser. And I guess this means I have to worry that not all tags are being published successfully, and so they might go stale.

I would like to cut the server some slack by overriding the Publishing Interval, but this would mean setting one specific value for an Active Leased Tag, and another specific value for an Inactive Leased Tag.

However, there is only one entry for Publishing Interval in the Tag Group Editor. If I put a value here, it applies for both the Active case and the Inactive case.

So I have a Tag Group that, when Inactive, only needs to be sampled every 30 seconds, but Ignition still requests publication every 1 second.

Q2: Is there a way to override the OPC UA Subscription Interval for Leased Mode using specific values for Active and Inactive status of the tag?

Q3: Or, is there a way to change the 1000ms default max Subscription Interval ?

Q4: If neither are possible, can anyone suggest how I might get around this problem in a different way?

Hope someone can shed some light on this...

2

Good question. Sounds like a bug. Consider reporting to Support.

3

AFAIK, Good_Overload has nothing to do with publishing interval, only the sampling interval.

Publishing is cheap, especially when there are no changes to publish, which is certainly going to be the case when the sampling interval is slower than the publishing interval.

I don't think your problem has anything to do with publishing interval.

(tag group rate is used as sampling interval, unless explicitly set by changing the group's sampling interval property away from -1)

4

Yet according to the Siemens docs, unless I misread them, Good_Overload status is written to all tags in cases where some tags have not been checked for changes before a publication deadline.

The core question to me is how I can specify slower Publication Interval to the server for Inactive leased tags without affecting the (necessarily much quicker) Publication Interval of Active leased tags.

5

You can't.

6

And these docs suggest it's sampling, not publishing: https://support.industry.siemens.com/cs/document/109763090/what-is-the-meaning-of-the-opc-ua-status-code-goodoverload-?dti=0&lc=en-DE

Do you have a different source?

7

Hmm,

I guess I should make a feature request in that case.

To me, it would seem to make sense to have two fields for "Subscription Interval" for Leased Mode in the Tag Group Editor, so that this could be specified independently for Active and Inactive tags. Ignition already applies different Intervals, it just doesn't set any of them longer than 1000ms.

This is likely only a problem because the Siemens OPC server is not perfect, and in my case the server is not able to do on time what it thinks it can. I assume that is why it does not revise the requested rate. (See table in first post)

My other hope is to be able to somehow modify the 1000ms default value.
I'm guessing it's a long shot, but I'm hoping it's not just hard coded somewhere? Any thoughts on this?

8

1000ms is hardcoded as the max, there's a coercion step that happens to ensure the requested publishing interval is in the range [1, 1000].

Publishing interval is used as the basis for other subscription properties like the max keep alive count, lifetime count, all of which influence the expected rate at which we'd receive a "keep alive" publish response in the absence of any data changes. This further influences the subscription watchdog timer, which is looking for multiple missed keep alive responses (regular data change notifications also reset the timer) to decide if there's a serious issue with the subscription on the server.

It's kept at a max of 1000ms because it keeps these other settings in line and allows us to target a 10-12s expected keep alive.

Being able to change this isn't going to solve your problem with Good_Overload.

1 Like
9

You are correct, it does talk about sampling time in the PLC. I was looking at the same document.
But in the Siemens configuration you can only specify the minimum times for sampling and for publication, implying that the sampling is allowed to take longer as long as there aren't any publishing jobs waiting. Which is why I would like to allow more time between publication requests.

10

I think I see what you are saying, but I'm not sure if it's as clear cut...
If I specify a Subscription Interval of 5000 (replacing the -1.0 default value), the 5000ms value is accepted and appears in the Status - OPC connections, tags are updated every 5 seconds and I get no more Good_Overload messages.

Of course, this also does not solve my problem, as now tags are always updating slowly, but it illustrates that Ignition is able (safely or not) to request publication at longer intervals.

11

As noted above, Subscription Interval overrides tag group rate if specified. Only the tag group rate changes for leased vs. inactive tags.

I suspect you have more tags leased than you think, overloading the PLC at 1000ms.

12

I don't think it's the leases that overload the server, more that the Siemens server is overloaded in general. I was able to get rid of the Overload messages in with this configuration, but it remains to be seen what wil happen when more of the leases kick in.

For now I have just specified slow subscription rates whereever I can get away with it. The table below shows the breakdown of leased vs non-leased. Sorry I don't know how to post in a nicer table format :slight_smile:

Name, Tag Group Rate, Requested Publishing Interval, Revised Publishing Interval, Tag Count
tag-group-default_viewnorm_slow-leased 1000 2500 2500 600
tag-group-default_viewnorm_slow 30000 2500 2500 3279
tag-group-default_viewfast_slow-leased 500 250 500 44
tag-group-default_viewfast_slow 30000 1000 1000 16
tag-group-default_viewfast_norm-leased 500 250 500 2
tag-group-default_recipetoplc 30000 1000 1000 923
tag-group-default_recipefbfromplc 2500 2500 2500 1475
tag-group-default_default 1250 1250 1250 2497

13

I don't think the leases will have any effect when you specify a subscription interval. That was my point.

14

Ok, we'll see how it goes, might be upgrading the PLC yet.

Thanks both of you for the quick and invested response!
:slight_smile:

15

I agree

16

I misread the code, it's only coerced to [1, 1000] when applied to the tag group rate and the Publishing Interval is -1.

If you specify a custom Publishing Interval it is requested.

17

Interesting, this would suggest that the aforementioned feature request might not be out of the question?

18

I'm still not convinced it would solve anything for you. I'm going to do some experiments here and see.

1 Like
19

Sounds good, the longer Publishing Intervals definitely got rid of the Overload messages in my case. I look forward to hearing what you discover.

20

The other issue is I'm not sure what you're requesting is possible.

The OPC subscription system doesn't know anything about leasing or tags. It's given a rate that is decided by the tag system above it to be the leased or unleased one.

Similarly, the tag system doesn't know anything about these custom tag group properties added by the OPC UA module.