@Jason: The answer is no, PI ACE does not do exception - only PI Interfaces do. The compression settings will apply though. Have you configured compression settings on the output point?
PI Interfaces are using a different library (PI API) to connect to a PI Server and implement exception validation test logic.
I will report this problem to the documentation team to fix the misleading information.
Thanks for the response Mathieu.
We do have compression settings configured on the output tag. They are compdev=1 and compmax = 5 minutes. Sorry for not including those in my original post.
While investigating this we switched to clock based calculatoin and then back to our original natural scheduling. Now the archive events seem to be providing data that's more like what I would expect with compression working. We didn't do any changes on the input or output tags that I can recall, though, so I'm not sure what's changed now.
207 28/03/2012 2:56:38 PM
211.2 28/03/2012 2:56:42 PM
211.9 28/03/2012 2:57:21 PM
208.1 28/03/2012 2:57:24 PM
207.7 28/03/2012 3:00:32 PM
211.5 28/03/2012 3:00:34 PM
210 28/03/2012 3:01:38 PM
206.1 28/03/2012 3:01:55 PM
210.3 28/03/2012 3:01:58 PM
210.3 28/03/2012 3:02:24 PM
206.5 28/03/2012 3:02:26 PM
206.6 28/03/2012 3:02:44 PM
210.9 28/03/2012 3:02:54 PM
206.6 28/03/2012 3:03:09 PM
210.4 28/03/2012 3:03:10 PM
It's hard to tell if we cannot reproduce the problem. Now the first question is if there was at least one snapshot event for the input tag(s) for each output event in your first post. And then we can investigate why compression on the output tag did not kick in.
@Jason: After some verifications, PI ACE Calculation module using standard write methods (PutValue or assigning a value to the Value property) will benefit from the PI API library to do exception reporting. Although, the exception attributes from the PI Points will be picked up by the PI ACE module only when the calculation is restarted.
If you are using PI SDK methods within your PI ACE Calculation module, exception reporting won't be applied.
When you switch to clock-based calculation and then back to your original natural scheduling, you have "restarted" the module and force it to pick the new exception reporting settings.
Can you validate if this is what you obtained in term of behavior? If it is not the case, let me know and we will escalate this issue.