Can you confirm all the values involved are "good" values (i.e. not error statuses)? And related to bad values, are you using any "substitution" settings? Do you have If/Then/Else logic around your calculations, to handle bad data?
You also need to pay attention to the optional PctGood argument you are using in the PIACEPoint.Max method... should there be less than 50% of good values in the preceding hour, an error/exception will occur when you try to substract the non-numerical values.
So again, make sure you implement some If/Then/Else logic around this, to make sure you get everything covered. I would try logging data to the PI Message Log, to check what the value of your output tags are just before exiting the ACECalculations() method.
yes, I checked all of that. To make sure I wasn't getting hammered by a bad value, I set the pct good to 1. Still no luck. Then to really remove all doubt, I hardcoded the result, basically the code below:
myoutputtag.value = 0
Still the ACE program wrote the previous value of the output tag. I added debug such as PIACELOGMSG to write out the intermediate results, they were correct, the output of the program still wrote the same value it had written for days.
So my final change to "correct" the problem was to remove the tag and readd it to the program. Still no luck.
Now I have figured it out. When I remove the tag from the input list and only have it as an output, it works.
so now the really big question, can't an output tag also be an input to ACE? I need to look at the previous value to decide what to output. I can reproduce this if you or the developer wants to see it live.
I have found that sometimes when changes to an ACE executable don't take effect, it helps to stop the ACE executable in the ACE manager. Then test and register while the executable is stopped. Wait for a while. Then restart the executable. If that doesn't work, a more extreme hammer sometimes hits the nail. Sometimes I've had to force it even farther by just stopping the ACE scheduler, test and register the ACE executable, and restart the scheduler. It's a sledge hammer, but I've resorted to it with success in the past. Maybe someone from OSIsoft might have ideas about why this might work. I wonder if it has to do with our plant having more than one PI server with ACE. If a network issue prevents the "right" server from responding to edits, maybe the edits go to another server? I'm not sure why it has worked for me in the past. I only know that this has helped.
Carrie RancuretYou normally don't have to take that "extreme hammer" approach you described, in order for changes in a PI ACE module to take effect
Maybe someone from OSIsoft might have ideas about why this might work
You do need, however, to restart the executable (DLL).
Essentially, the PI ACE Scheduler makes a copy of your DLL to work with (<moduleName>_aceshadowcopy.dll), which lets you make changes to the code and re-compile the original assembly (using the Debug or Test functionalities). When you stop and restart the executable, it compares the original assembly and the "shadow copy" and replaces the latter with the new assembly, if it detects it's newer. Just be patient as it may takes several seconds for the stop/restart process to take place. Also make sure you always are in Debug configuration - not Release.
Hope this helps!
Robert LowA tag can very well be both input and output in PI ACE; it's the first time I hear about such a problem and I could not reproduce your issue. What version of PI ACE are you using?
can't an output tag also be an input to ACE?
Note that when using a tag as both an input and an output tag, the Debug and Test functionalities will not function as expected (i.e. the Value of the remains which at the start of the Debug/Test). It will function correctly when being executed by the PI ACE Scheduler though.
If you are using the latest version of PI ACE, then it sounds like a bug that should be addressed; I encourage you to file this in by opening a call with our regular Technical Support - this way it'll get escalated as appropriate to eventually find and fix the bug, if that's the case.
I have also experienced issues in the past, on ACE calculations that happened to use the same input and output tag. I have resolved these. One thing I saw was an intermittent issue, where the output just would not be sent. OSIsoft tech support helped me to resolve this. Maybe it would help if I explain what the resolution was. Here is what I experienced.
I never saw it to the degree you are experiencing. In my case, an output would be skipped 2-3 times per day on a calculation that happened once per minute. It turned out that the ACE configuration was using "localhost", instead of the PI server node name, but only some of the time. Other times, it was apparently using the server node name. Current versions of the PI server and of ACE will correct this problem, but older versions of PI servers and ACE may have this problem. Maybe it would be worth mentioning this to TechSupport so they can verify whether or not the "localhost" PI connection may be playing a role in your case.
I have observed with tags that are both input and output, unless you actually do an input first every time (ie read the Value property before setting it), you haven't changed it as far as the ACE wrapper is concerned, although when you inspect the updated Value in debug mode or print it in a message, it looks as if it has changed. (The implication is that if you had updated it again after you output the message, it would have worked!)
I don't know whether I would class this as a bug or a sensible precaution. After all, if you define a tag as both input and output, it would be poor practice to write to it before reading it, surely? If you don't care about its existing value, then it shouldn't be in the Input list.
@Jeremy: I'm not sure I totally understand what you are implying with the "if you had updated it again after you output the message, it would have worked!" statement, but here is how it goes: PI ACE will write a value to PI for all points listed as Output (or Input+Output), at the time it exits the ACECalculations method. It will write whatever the value of the Value property is at that time.
In other words, you can do whatever you'd like with a PIACEPoint object's Value property throughout the execution of your ACE module (i.e. read and write multiple times), only the latest value will be written to PI when exiting the method. Unless you use the PIACEPoint.PutValue() method somewhere before the end of the ACECalculations() method. The PutValue method instructs PI ACE to effectively send the value(s) to PI - this is what is used internally to send values to PI at the end of the calculation and it is normally not called explicitely by the PI ACE programmer, unless there is a need to send a value before the end of the ACECalculations method is reached.
Please let me know whether that addresses your questions or you need further assistance with this.