Tricking out Aliases, Part 2

Scott Thompson's commnet to my last post was a good one.  He couldn't include a screenshot example in his comment, so I'll share it with y'all:

Did you know that you can also use multiple aliases in a single line of code?

In the last action example in the post if the #ARBITRATION# alias pointed to a module which handled arbitration for multiple pieces of shared equipment, each with a named linked composite within the arbitration module, a reference could look like:

Tricking Out Aliases

I’ve been delinquent in blog entries, and while I’ve had several topics floating around in my head, finding the time to get something posted has been tough. I’m not making excuses, but it’s been really busy around here lately. So it took the above video (William Shatner paying tribute to the Shuttle Discovery) to get me writing again. The idea is I’ll pull you in with a DeltaV topic, and then you’ll see my new opening video.

The concept of aliasing has been around in class based phase logic from the introduction of batch with DeltaV. Emerson has gone on to allowing aliasing in equipment modules, but this more recent addition is implemented differently than the method used for phases. I want to touch on the former technique, because I think there’re folks who might not know how to exploit it.

Below is a typical dialog box for an alias I have on a unit class to tell me who I am:

I’ve created an alias named UNIT_MOD and since I’m at the unit class level, the Path: is grayed out. The idea is to have an alias that points to the unit instance, so my phase logic can figure out who I am. If I look at the similar dialog box for an instance of this unit class, I’ll see this:

Since this is at an instance of the unit class, the path is filled in with the name of the unit module for this particular instance. By having this alias, I can have my phase logic address any parameter associated with my unit, like below where I’m setting the U_MODE_LOCK parameter to TRUE:

If you remember from your 7016 batch class (if you haven’t been to 7016, shame on you – as soon as you finish reading this, go online and register for the next available DeltaV batch class), the #’s encapsulate your alias.

So what’s going on here? Well the truth is an alias is just another parameter. It’s a special string parameter, one that you can only add and modify from the unit class and instances. Another thing you might not remember from your batch class is you can have an alias be as high level as a module name, or as specific as an individual parameter in a function block like XV-101/DC1/SP.CV. If you get too specific though, you’ll need a ton of aliases, so common practice is to stop at the module name. When DeltaV encounters the #’s, it replaces them with the string you typed in as part of the alias resolution (it's really a little more involved than that, but it's a least a 2 beer discussion, so we'll keep it simple).

Can you use the aliases without the #’s? Of course - that’s how, if you’ve checked the Ignore box in the alias resolution, you can keep your phase from hanging up, waiting for something that’s never going to happen, by looking for the .IGN of the alias to be True.

Now here’s the trick – you can look at other attributes of an alias parameter, namely .CV. Since an alias is just a string parameter, looking at the .CV attribute will return the string. So if I needed to write who I am (unit metaphorically speaking) into another parameter in another module, I could use the following:

The #UNIT_MODE# is used to resolve the alias while the UNIT_MOD.CV is the alias parameter of the unit. So, if this was running on my SF_100 unit, then the aliased Arbitration module would have SF_100 written to its REQ_ACQUIRE parameter.

Pretty tricky, huh?