Crimosn 3 - Tag properties in code

Hi folks,
I am looking at a project that needs to send alternate, shorter/longer, alarm messages by mail.
I am aware an alarm can send mail.
I know how to send mail AdHock as it were.
I also know that the alarm message can be a reference to a string Tag, dynamically generated or otherwise.

I know that array events can use the 'i' property to pass the element number, ordinal, to the handler and I know that there is an AsText(), function?, that can be used to cast none textural data as text BUT

I dont know, and cant find, what properties are available or for that matter how to access them.

Examples...
Tag1.Name is valid, returning a string,
Tag1.Label & Tag1.Desc also work.

AsText(i) will return the ordinal of an array element, without the preceding qualifier Tag1. In an alarm, this can be used to create a dynamic message, of sorts...
Event Name: =AsText(i) or ="Some Messege" + AsText(i)

Clearly the alarm event knows which tag is in context/scope because if it didnt then 'i' would not mean anything.

However Name,Label and Desc will not work unless preceded by 'TagName.'

So, specific questions...
Does Crimson have a context/scope sensitive qualifier, like VB or C
E.G. Me.Name or Me.Label

What else, tag properties, can be accessed or modified in code/script? Is there a list anywhere?

Assuming I set up alarms, using Flag Tags, in the 'Normal' way can anyone suggest generic code that every alarm can carry to call a custom handler for the 'On Active' event that would pass in a reference to the tag that spawned the alarm.
Obviously I appreciate each alarm could be configured with either a unique call to a common routine, which wouldn't be the end of the world, but I was hoping to have a common call that passed a unique identifier extracted from the Tag Object.

Essentially...
If I have to say MyProg(Tag1.Desc) then I may as well just say MyProg("SomID")

MyProg(Me.Desc) is much cleaner, at laest it would be if it wasnt also wrong!

Thoughts folks?

http://www.plctalk.net/qanda/showthread.php?t=56916

The above thread may help you out.
Regards,

Well that is in the ballpark but falls int the category of stuff I spent way too long finding out about.
The comment 'AsText isn't documented' is interesting, you have to know about it to find it... silly
.Name . Desc .Label I cant find even though I know they work what I am actually hoping to return is the alarm category or priority.

Redlion are bad at this stuff, documentation I mean, I I had a £ for every hour I spent finding a solution that took seconds to implement I would be much richer.

Did they ever fix the array index error, (i) returning 0 for some tag types in events?
Last time I checked, two years after I first raised the issue, it was still broken.
I use Schneider now, too many issues not getting addressed.
Nothing is perfect, including Schneider HMI's but they at least seem to fix stuff.

Thanks for the input though, everything is worth a look.

Al

Dyslexicbloke said:

Well that is in the ballpark but falls int the category of stuff I spent way too long finding out about.
The comment 'AsText isn't documented' is interesting, you have to know about it to find it... silly
.Name . Desc .Label I cant find even though I know they work what I am actually hoping to return is the alarm category or priority.

Redlion are bad at this stuff, documentation I mean, I I had a £ for every hour I spent finding a solution that took seconds to implement I would be much richer.

Did they ever fix the array index error, (i) returning 0 for some tag types in events?
Last time I checked, two years after I first raised the issue, it was still broken.
I use Schneider now, too many issues not getting addressed.
Nothing is perfect, including Schneider HMI's but they at least seem to fix stuff.

Thanks for the input though, everything is worth a look.

Al

Click to expand...

I agree that the documentation isn't always 100%, but AsText is documented in the current manual as has been for as long as I can remember. The problem with these manuals (and everyone's manuals) is that they are written by someone who knows how to use the product. That means that even though a feature is documented, the user may not know that "this is the feature I need to use to do what I want to do."

The benefit of Crimson is that there are a number of folks who frequent this board who have a great deal of experience with Crimson. In many ways we are groupies and really like helping people who ask questions about Redlion and Crimson.