Data Poll on unreliable OPC server

Hi; my first post to the forum after purchasing and starting to use FSQL.

I’ve got most of what I want to do running.

For one set of data, it is coming from a rather unreliable OPC server. When I say unreliable it is a PLC on a poor quality radio link. The data is always there, sometimes you need to wait for it to come through. As a result, the table data gets 0 and 8 data quality codes, as well as plenty of 192 (Good).

I want to poll the PLC infrequently (i.e. every 30 mintes), but when I do poll, I want to keep going until I get a good quality data result (i.e. 192).

If there a way to configure FSQL to keep trying until 192? Or perhaps some advanced triggering?

Hi, and welcome to the forum.

This does sound like a bit of a tricky problem. There’s probably a number of things you could do to get close. One quick thing you could try would be to use “polled reads” for the group instead of the default subscription behavior. HOWEVER, how successful this will be will depend a lot on the OPC server’s behavior. But, I’d say it’s worth a shot.

To turn it on for the group:

  1. Go to Settings->Frontend Settings, and enable “Show advanced group options”.
  2. On the “Advanced” tab that’s now available for the group, turn on “use polled reads”.
  3. Set your group rate to 30min, and start it. (For testing, you’ll probably want to set it to like 1 min or so, if it works at that level it should probably work at 30min).

Note: I would only do this for groups with this problem, not for all of your groups. The default subscription model is better for most monitoring purposes.

As I said, there’s a good chance this might not work at all and you always get bad data, depending on the server. So, if that’s the case, post back and we can try something different.

Regards,

Hi neville,

If I could ask, what type of PLC (or protocol) are you using? And what OPC server?
The ‘poll-till-I’m-good’ logic should really be handled by the OPC server communicating with the device, rather than OPC client-to-server.
An OPC server designed to be used in telemetry environments should have additional configurations for retries, timeouts, scheduled poll times, etc. Since it is expected that sometimes data will be unavailable due to communication problems, a Telemetry Class OPC Server will exhaust all retry/repoll options, before updating the OPC cache with a Bad Quality.

If Colby’s suggestion doesn’t work out for you, you might find a server that meets you needs here:
matrikonopc.com/opc-drivers/ … scada.aspx

Good luck.

Thanks for the replies.

Eric, yes I know that adressing this at the PLC Comms / OPC server end is the ultimate way to deal with it. That is outside my contorl for this project.

Colby, I will try your suggestion… I presume that this causes the OPC to try for new values in a different way to the standard method…what exactly is the difference?

Thanks
again…

Well, the difference is really going to be internal to the OPC server, so I can’t give a specific answer. However, I can explain the difference between the two modes, so you have an idea of what might occur.

Default - Subscription based updates: FactorySQL creates “groups” on the server that contain a list of items that it’s interested in, and how often it wants to be notified if anything changes. The OPC server will do what it can to accommodate this, and provide notifications in the given time frame. If nothing changes, nothing is sent. So, for example, if FactorySQL subscribes to a point at a rate of 5 seconds, but the actual data changes every second, it will only be notified of every 5th value. If the value doesn’t change for 5 minutes, FactorySQL won’t receive any notifications for that time.

Polled reads: FactorySQL doesn’t notify the opc server of anything in advance. Each time it wants a value, it sends the tag’s address to the opc server in a read command.

There are a few advantages to the subscription model. First, by knowing of all the tags to update, the OPC server is able to optimize the way it reads. For example, if one group wants n7:1 and a different group wants n7:2, it can just read those together. Secondly, it minimizes the amount of work the applications have to do- instead of transferring the same unchanged value for each read request, it only sends updates as they occur. This point is relatively minor, since you’re just using COM on the local machine between FSQL and the OPC server (I assume, as opposed to DCOM if the programs were on separate machines). Still, it’s more work.

So basically, subscriptions are generally more efficient. HOWEVER, my thought process when I made my suggestion was that subscriptions are also generally a bit “looser”- the server is expected to send back a value as soon as possible after subscription, so it will send back a bad quality until it has better. With an explicit read, it may be more likely to take the time it needs to get a good value, up to some (hopefully settable) timeout. Unfortunately, this is completely up to the OPC server, so it’s just a thought/hope.

Hope this helps a bit,

Eric’s spot on here!

Colby, back to his “hacky” approach - can he reference the quality code as an OPC path/item to use as the basis of the group trigger condition? This would definitely be a “trial and error” situation. I’m assuming that the the read isn’t guaranteed to occur any faster than the group “update rate”. Is that right? In that case the data would be correct but updates could be intermittent.

Well, you could certainly trigger on the quality in order to only record good values, but I think the solution needs to go a bit deeper than that, either on the opc server side or the FSQL side, if you want to get good values when you need them. Also, his request on the timing came into play in my thought process- only wants values every 30 min. Sure, it should be possible to simply set the group to 30 min in subscription mode, but if the quality is bad, you’re going to have to wait another 30 min for another sample. A different option would be to set the group to run every 30 seconds, and then use a more complicated trigger that used action items to track time, quality, etc.- but this means the opc server would be communicating with the plc at least every 30 seconds.

Ultimately it’s good to put all these ideas out there.

neville,

If figured as much, but thought I’d throw it out there anyway.

If I understand your problem, you currently are subscribed to an item. Usually it comes back Good, but occassionally you get Uncertain or Bad values which are probably due to slow/unreliable response between the Server and PLC. Correct?

If the subcription is returning non-good qualities, that means the server has already updated it’s cache. Really the OPC client needs to force the Server to update it’s cache with a new value, outside the scheduled update rate. The way to do that would be perform a DEVICE read.(Either a Synch Read or Refresh). Of course, even this won’t guarantee a ‘Good’ result, it just means the server will poll the PLC right then.

Colby: Is the FactorySQL ‘poll read’ a Synch Read from Cache, Synch Read from Device, or a ‘Create Group, Add Item, Perform Read’? If it is option 3, I can see where you are going with your thinking, in that the server might perform an demand refresh before returning the first update when the Group is activated. Of course it is equally valid for the server to return its default cache value of ‘Waiting For Inital Data’ for the first update. But I agree, it’s worth a shot.

If that doesn’t work, the only thing I could think of (other than replacing the Server) is even more ‘hacky’ :slight_smile:
If having ‘only Good’ values is the most important criteria, then you could consider the following. Instead of reading directly from the OPC Item in the PLC, read from a ‘holding register’ OPC item that some other OPC client is only updating with ‘Good’ values.
For example, MatrikonOPC has a double-headed client call ‘OPC Data Manager (ODM)’ which reads from one OPC server and update tags in another. It has an option to ‘only transfer Good Values’. ODM would poll the OPC server connected to the PLC, and only update a ‘holding register’ OPC item with Good Values. FactorySQL OPC Client would read it’s values from here. (ODM also allows you to copy the ‘Quality’ of an item into a string tag, so you can track whenever non-good values were not transferred across.)
Depending on how critical a solution is to you, adding more components may not be worth the effort, but it’s food for thought if you are running short on options :slight_smile:

Cheers
Eric

Hey Eric-

I was trying to skirt around a bit of complexity by saying that “it depended on the server”. What I primarily meant by that was whether the OPC server was DA2 or DA3 compliant. If it’s a OPC-DA 2 server, FactorySQL will have to do the “group-item-read” sequence, if it’s 3 compliant, FactorySQL just does a device read (technically speaking, IOPCItemIO::Read with max age of 0, thus “equivalent to OPC_DS_DEVICE” according to the spec’… but we know how that kind of logic often works out :slight_smile: )

I think I am having a similar problem right now. Although mine might be more of a timing issue. What I would like to know is more information about the two FSQL settings: NUMBER OF THREADS and PERCENT OF OPC. Is there a set of guideline on how these affect performance?

The problem I am getting is I have the data written to a compact flash on the PLC, there is also about a 50mS timer to help make sure the data has stabalized. I can pull the CSV files and see all the data is correct. There is primary key settings on the database on the items Machine, Start and Stop. So if there are duplicates it will throw a PRIMARY KEY fault and will not write the record. We looked thru our first database before we put the keys in place and it appeared that when writing some of the records not all the data had updated before the trigger fired. The start and stop fields are sent over as string, since that is what the PLC supports and the machine is sent as INT. My guess is it takes longer for these strings to come across hence the reason they dont update fast enough. So we are looking further into all areas to make this better. Hence the question about the number of threads and percent opc. If the data is writing to the compact flash ok and correctly then it has to be some kind of timing between the PLC and the database. The only 2 items there are Kepserver and FSQL. The setting is standard not polled and the start and stop are stored in consecutive locations on the plc, actually all the data is consecutive and blocked, all DINT together, all INTs together and all STRINGS together. I originally did an OPC test way back when and it was taking on average if I recall 30mS to read all the data from the PLC but that was when we had 8 online, now we have 70 online so maybe it takes longer I dont know. When I had talked to KepServer they said that the way I had it setup was in a parallel format so that all things would read same time or something like that statement. But now that we are comming to close with this project we are now working to stabilize all annomalies.

Thanks and have a great day.

[quote=“Colby.Clegg”]Hey Eric-

I was trying to skirt around a bit of complexity by saying that “it depended on the server”. What I primarily meant by that was whether the OPC server was DA2 or DA3 compliant. If it’s a OPC-DA 2 server, FactorySQL will have to do the “group-item-read” sequence, if it’s 3 compliant, FactorySQL just does a device read (technically speaking, IOPCItemIO::Read with max age of 0, thus “equivalent to OPC_DS_DEVICE” according to the spec’… but we know how that kind of logic often works out :slight_smile: )[/quote]