"Why can't an input from any member of a collective trigger an analysis?"
ex. Lab tag on a secondary updates (variable1)...fire event-triggered analysis write to (Output Attribute)
Are you referring to a PI Data Archive (PI Server) Collective? If so, a Collective is intended for failover purpose. Clients usually connect to the Primary Collective member and failover to a Secondary Collective member in case there's an issue with the Primary. AF Server acts like a client when connecting against a PI Data Archive Collective.
Why would the lab tag update on a Secondary node only? Whatever mechanism is used to update PI Tags with laboratory data, we recommend using PI Buffer Subsystem to fan updates against all members of a PI Data Archive Collective.
Yes. PI Data Archive collective. We have four geographically dispersed servers in our collective. Clients could be connected to any one of those servers. So would be great if client could send an update to whatever server they are connected to. Understood on PI Buffer subsystem. Just don't want to configure buffering and support it on 20+ different computers. Ok will have to go with UFL or some other scenario.
Let me make sure I understand your use case.
You have a 4 members PI Data Archive Collective, 1 primary, 3 secondaries, and they are all geographically dispersed. You have some clients that connect to any one of these 4 members and your users write Lab data to any one of these 4 members. You want to trigger analyses (AF 2014) based on these Lab inputs. Did I get that right?
Yes...that is correct Steve.
Unfortunately if you write to a member of the collective without using BufSS, the datapipe (what feeds the analytics engine) will not pick up the new value.
I'll buy that. Thanks.
How is your lab data being written? Custom SDK application?
Sounds like you have Data Concurrency issues anyway apart from the Event Triggering of Analyses. I guess you could implement a pseudo "server side fanning" using PI to PI on each of the collective members that pibufss only fans to the other 3 members of your collective, so if the value is updated on any member it is fanned to the others server side rather than on the client (some potential race conditions but this is in-frequent lab data from the sounds of it). This would resolve you concurrency issue plus make the data available for your analyses. Probably more work than you anticipated though.
Would you ever expect 2 clients connected to 2 different collective members to write the same piece of data from the labs at the same time - or near enough the same time?
It is an acknowledgment being written from Processbook via sdk. code writes to a trigger tag then the analysis fans to the ack tag to the collective. Could force primary only but that defeats the purpose of a collective. The two client scenario could happen but that would be acceptable. Alarms are fairly infrequent and for the time being are just performance equations. I'm in process of migrating them to AF and Analysis as it will be so much easier to manage. It doesn't matter that the trigger tag would not match on the collective members just the acknowledged tag as that is the tag that is displayed.
Could go with the PI to PI but thinking it would be simple just to go with a csv file and ufl interface. Would allow for failover and buffering. Another though was writing directly to an AF attribute.
Retrieving data ...