Issues after upgrading to 4.2.10

I upgraded to 4.2.10 over the weekend. This morning I went to check to make sure things are working correctly, and they’re not. I figured the differences I was seeing over the weekend were due to using polled reads on certain groups, which according to you guys, didn’t work correctly for me until this version because I’m using OPC server v2.

I think I may have the issue narrowed down. It doesn’t make any sense, but I think I finally figured out what’s going on.

If a tag is in a group using “polled reads instead of subscriptions”, we’ll call this Group A, the value of that tag doesn’t update anywhere else in FactorySQL until Group A updates.

I’ve verified this by turning off all the “polled reads” groups. Suddenly tags started updating again in other groups.

This is really messing with my system right now. Please help.

I’ve also noticed that some tags show up as “Not connected” almost randomly.

But again, as soon as I turn off “Use Polled Reads” on all groups, everything works ok.

I’m currently using RsLinx. Would switching to Kepware OPC server fix these problems?

Hi-

I’ll have to look into that a bit more. Are all of the groups (at least the ones having problems) set to the same update rate? FactorySQL breaks up subscriptions by item path and update rate, and it’s possible that there could be some problem with the subscribed/polled items interacting with each other.

If they are set to the same rate, you can try setting them to different rates and see if that helps.

Regards,

The two groups that I had set to “use polled reads” are refreshing every 1 second because I want them to trigger as soon as the group trigger tag goes high. The reason I turned on “use polled reads” is because refreshing all those tags every second is bogging down the PLC with traffic. After turning on “use polled reads”, these two groups act the way I want them to; that is, only monitoring the trigger tag every second and if it goes high collects the values of the other tags and sends them to the database. But it causes problems anywhere else any of the tags are used.

The other groups have differing refresh rates. My “machine status” group is set to 30 seconds. It doesn’t have a trigger, it just sends all the tags from the machine to a table every 30 seconds. Any tag not in the “use polled reads” group(s) works OK. The tags that are included in the “use polled reads” group(s) say “Not connected” until the “use polled reads” group(s) is triggered.

So for now I turned off “use polled reads”, but that means I’m right back to where I started with bogging down the PLC with unnecessary reads.

Ok, I confirmed there’s a problem: if the polled read tag is registered first, subsequent subscriptions to the path will be tied to that polled tag.

Changing the rate won’t help- it seems that the only solution would be to not used polled reads, or make sure the subscription group gets started first.

However, we should have a fix for you in just a little bit.

Regards,

For everyone following along at home, Colby sent me a file that fixed this problem.

And the fix will be included in 4.2.11.

For those using polled reads, the problem comes when ALSO using a tag in a normally subscribed group (NOTE: sqltags aren’t affected). If you’re not using the tag in multiple places, there shouldn’t be a problem.

Regards,

Hi Colby,

When do you expect 4.2.11 to be release. I have a deployment this comming up this week I would not mind trying again the poll reads I disabled it on my last job because I have issues. or if you feel okay with me using the fix that you have I will be filling to try it, you can email it to me or point me to a location were I can download it.

Thanks

Julio D

[quote=“Colby.Clegg”]And the fix will be included in 4.2.11.

For those using polled reads, the problem comes when ALSO using a tag in a normally subscribed group (NOTE: sqltags aren’t affected). If you’re not using the tag in multiple places, there shouldn’t be a problem.

Regards,[/quote]