May I ask why the flow rate is recorded at PIsrv1 and the valve Position on PIsrv2?
Personally I wouldn't feel comfortable about this and recommend to at least consider replicating either point to the other server if moving it is no option.
The following syntax allows you to refer a PI Point on a specific PI Data Archive node directly but I am not sure if the time filtering works because this is usually done server side and I wouldn't know PIsrv1 would reach out to PIsrv2 for the valve position:
The flow rate is not a real flow rate. Its a simulation that comes from a system that simulates a estimated flow. This system does not see the status of the valve, so it keeps outputting a flow rate even if the valve is off. Thats why we need to check the valve status to consider the simulated flow rate.
I already tried using this sintax on datalink, with the following expression, but it gives me an erros saying I can't have points from different servers at one single expression.
Moving from one server to another is not an option (I don't know the reason. Our IT team says it must remain on different servers).
On server has only data from many other systems (like this simulating system) and the other servers has the data from the process (that's where we need to get the valve status from)
I am not sure how this replication option would work. Could explain it better?
I am not a PI administrator, I am just an end user.
I asked the administrator team to give me a solution to this but they are having a hard time so I decided to try to find a solution here because I know from previous questions that you guys are awesome.
There are two options for you:
1) Retrieve all the raw data into your Excel spreadsheet. Then do the multiplication and the event-weighted average using Excel math functions
2) Use AF and create two PIPoint DR attributes to point to the two tags. Then create a Formula attribute to do the multiplication. And then use DataLink summary call on the Formula attribute.
There may be other options but those are the two I can think of off the top of my head.
I hope this helps,
All users are in a satellite internet connection, which is very slow due to high latency, so I am going to the second option.
In fact, I already have what you suggested.
An then I use datalink to calculate the average.
I was hopping to find a way to calculate the average in this Formula attribute in AF, this way on Datalink I would only use ArcVal function.
The only reason to do this is because, like I said, the users have a very slow internet connection and ArcVal looks to work much better than calculating an average.
Do you think this could work?
I was think to create an attribute with an expression like this:
And then use analyses to calculate the average in the last 24 hours (starting at '*-24h' until '*')
1 of 1 people found this helpful
What you are suggesting will work. You can also map the output of the analysis to a PI tag (if history is required) and pull in the values into DataLink.
One caveat that I could think of: when you multiply flow tag to valve tag (FlowTag*ValveTag) in an expression (e.g. formula), you are essentially multiplying the two values at every timestamp where archive values exist for either tag. e.g.
Flow tag (non-step):
Valve tag (step):
Flow tag * valve tag (non-step):
Taking a time-weighted average of the flow tag * valve tag (above) is different from taking the time-weighted average of the following (below):
12:00:30 from 0 to 10
12:01:30 from 20 to 0
12:02:30 from 0 to 30
I'm not sure which condition you are looking for in your final results, but just make sure the boundary conditions satisfy what you are trying to calculate.
Would not be a problem this boundary, but what I did was the following.
Created an attribute: RealFlow = FlowTag * ValveTag with stepped = True
And then, created an analyses to calculate the average from RealFlow.
Also mapped the output to a TAG so we have history and can pull it using PiArcVal in Datalink.
This way I think I won't have that "transition" problem when the TAG is going from some value to 0 or from 0 to some value. Right?
Glad I found this solution. It was causing a lot of problem for us.
1 of 1 people found this helpful
Setting the RealFlow tag as a step tag has implications. Using the previous example, the flow rate from 12:00:30 to 12:01:00 is 10, instead of an increasing value from 10 to 20. You might want to visualize the realflow attribute on a trend to make sure this is what you are looking for.
That won't be a problem. The most critical part is when the value goes to/from zero. Thank you again!