I think i found an undocumented property of PIACEPoint class. I checked piace help file but get no match.
It's called 'IsUsed'.
Someone know what's this used for ?
From our famous support database: The PIACEPoint.IsUsed property is for internal use only. Thus, it is not documented and should be ignored.
Thank you Andreas.
I thought it could be usefull for me, I was wrong.
I was wondering how to determine if a tag is checked as a trigger tag when calculation is in natural mode.
I used an other approach for my issue, but I still found no answer on this.
I suggest you take a look at the .IsTrigger property of the PIACEPoint
IsTrigger will give me the tag(s) that triggered my calculation.
What i'm searching for is a list of all trigger tags like i have in 'the edit schedule & property' form of the ACE Manager.
I found them in MDB : %OSI\ACEClassLibraries\ExecutableName\ModuleName\ContextN\ScheduleInfo\TagN
But I don't know if you can get it in a dot Net way.
I'm sure you can read from the Module Database both with PI SDK and PI OLEDB - just look it up in the manuals.
But I have one question: Don't you set up the trigger tags while going through the ACE Wizard, when you create your ACE project in Visual Studio?
If you do, then you'll already have declared and initialized all the trigger tags associated with you calculation, and you can use them directly as PIACEPoints.
I see one situation where you perhaps would need to know which tags are set up as trigger tags: If you set up 10 trigger tags while going through the ACE Wizard in Visual Studio, and after you've tested and registered the calculation - you disable 4 of them, so that only the remaining 6 tags act as trigger tags. Is this the situation you have?
I have done a project with similar settings last year, where I had one calculation which needed to be set up 20-30 times, with 3-6 trigger tags for each context. So I made a setup in the Module Database where I created 6 aliases and 1 property, for each of the different calculation setups. The 6 aliases were named Triggertag1, Triggertag2, etc. and the property was called NumberOfTriggerTags. Then I set up my ACE project in Visual Studio by defining the 6 aliases as input points, used module dependent initialization in my code - so that I got the correct tags and property, and registered the ACE calculation for each of the 20-30 different contexts. By reading the property, I would know how many of the aliases to read from - and these aliases contained the current trigger tags.
Exactly same aim !
For example if you develop a generic module that take a maximum of (X) trigger tags but in some case there's only (X-Y) trigger tags, then you will prefer to know what the selected tags and avoid the other while calculating.
So the only difference between my setup and your setup, would be that I don't uncheck any of the triggers in the 'edit schedule...' dialog in ACE Manager.
All my aliases will always act as triggers, the difference is:
Of course you can implement your own logic for setting this up. For example it could be an upgrade for my project to include one or more new properties, which could be a comma separated value specifying that only TriggerTag2, TriggerTag3 and TriggerTag6 should be used. But for my current needs, the 4 first triggertags are always the same for all calcs :)
Retrieving data ...