First off, I moved this from the FPMI forum to this one, since it belongs here. Hope you find it here…
Anyhow, ok: this is a fairly interesting scenario, and to be honest, I’m not sure exactly how to answer quite yet. However, let me start by commenting on your observations/explaining how it works:
FactorySQL uses OPC subscriptions exclusively to access the data. What this means is that FactorySQL says “I want point X, and I’d like to know about changes every Y seconds”. Now FSQL just sits back and waits. While the tag is active, the OPC server will handle monitoring the value, and send it to FSQL every Y seconds, if a change has occured. If there isn’t a change, nothing happens.
There is an active/inactive bit on the subscription and item level. For the most part, FactorySQL doesn’t play around with this too much: when the groups are running (or you want live values in the frontend), both the subscriptions and items are active. When values aren’t required (group is stopped), the subscription is removed. There is, however, a period of time where the subscription is made inactive before being removed. This is to avoid the overhead of removing/adding items in quick succession when a group is reloaded (happens at various time, such as right before the qroup starts logging).
Now, beyond that your observations are dead on. Triggers use OPC values, and affect logging to the db. The OPC server is always trying to maintain the current values.
What you’re looking for certainly makes sense, but again, I’m not 100% sure this second of what solution is best. My very first inclination is to say that you shouldn’t worry about how FSQL requests the data, and you should work on optimizing communication in Kepware. If you’re running your FSQL group at 5 seconds, but due to bandwidth issues you can only read value changes every 30 seconds or so, that’s fine. FSQL will get the changes as the come in. If bandwidth is costly, and you don’t want the connection to be in constant use, there may be some way of connecting it and disconnecting it on a timer. When it’s not available, Kepware will report “BAD DATA” quality for the items. It wouldn’t surprise me if kepware actually had some way to accomidate an “update schedule”, but I really don’t know about this. At any rate, as a first step, you could set up your devices and just tell kepware to poll them very slowly.
I’ll continue to think about this, but I just wanted to give you my initial response, and see what you think of it. As it is, there is no way to control whether a tag is active/inactive or to control group execution.