It would help a lot if you are able to provide some additional information:
- What is the configuration for the point?
- What is the PE equation?
- Can you provide an output of the values? Both before and after recalculation would be ideal
- Were there any errors in the message logs?
- What is the interface batch file configuration? Specifically, what are the scan class definitions?
If the PE point was configured to be periodic and calculates off of source point(s), perhaps it's possible that the source point values were delayed, and so they were missed in the scan? Again, it is very hard to say without additional information.
Below is the simple PE tag (clock scheduling) having mismatch in the equation value and the PE tag value at one particular timestamp.
('AU:PRL:WB.P-71003A:ActFlow.CSC') = IF 'AU:PRL:WB.P-71003A:PctUtil.SC'=100 THEN (IF
('PRL:710PI4303.PV' - 'PRL:710PI4302.PV') >= 4.1880414706 THEN 0 ELSE
-460.0606644879*('PRL:710PI4303.PV' - 'PRL:710PI4302.PV')^3
+4228.5169385878*('PRL:710PI4303.PV' - 'PRL:710PI4302.PV')^2
-13260.6235617612*('PRL:710PI4303.PV' - 'PRL:710PI4302.PV')
What kind of mismatch was it? Was it not calculating a value at all? Or was it that the calculated value was unexpected? If your PE is clock-scheduled, then that makes it sensitive to miscalculation, in the case that any of the input point events arrive late on the server. This would also be a possible explanation for why recalculating it provides the correct, expected value (since by then the source point events are all on the server). You may want to consider changing the PE to be naturally-scheduled. The limitation to this is that PE only allows natural scheduling off of one source point, and I can see there are several involved in the equation. Alternatively, you could consider migrating this PE (and maybe others) to use AF's PI Analyses, which allow natural scheduling off of all source points.