Studio5000 UDTs, aliases, and descriptions

Is there a typical/standard way of when to use UDTs, aliases, and descriptions? When do you use one over the other? What are some pet peeves of yours that others do?

I rely heavily on UDTs but I'm not sure it's the best way to go for everything. For some reason I have Local IO aliased.. I guess I've always just done it that way. I don't use descriptions.

All three serve different purposes.

UDTs - Just good practice to ensure your code maintains structure and you don't end up with tags like this because someone was lazy:


Descriptions, yes they should be used.

Alias, I don't use them for IO addresses, but I do use them for array references and other program scoped tags which are aliased to controller scoped tags (InletValve := V101)

My biggest pet peeves

1. programming a ControlLogix like it's a PLC5/SLC (B[4].6, I[9]...)
2. Long_tag_names_that_try_to_replace_a_description
3. Not using features like AOIs and UDTs (gripe all you want about online changes)
4. Lack of a clear structure. Code that has structure is much easier to read and understand than code that just has long rung descriptions everywhere. A program with structure guides the eyes, making it much easier to follow and replicate without having to read questionable rung descriptions and the manic thoughts of the original programmer.

Paully's5.0 said:

All three serve different purposes.

2. Long_tag_names_that_try_to_replace_a_description

Click to expand...

I agree 95% with what Paully said, but have a different take on #2.

Generally speaking, tag name's should be descriptive enough to not need a description. And it is ok if they are bit longer, within reason. Consider that most computer programming languages don't have both descriptions and names for their variables, just names. They are one and the same and for good reason. Having a descriptive name and a description is redundant. The situation where descriptions are required are for things like physical IO, where the tag name represents the slot and point but doesn't tell you what it actually is.

^ Yup, I agree. I error on longer, more descriptive tag names for sure.

One of the beautiful things about UDTs is that once you have added documentation to the elements of the UDT declaration, the ladder display will use those descriptions in a "Pass-Thru" fashion, so you don't need to spend hours documenting your tag data. It also means you can't get a description wrong, or even slightly different !

Paully's5.0 said:

.....Code that has structure is much easier to read and understand than code that just has long rung descriptions everywhere......

Click to expand...

I've always said that if you can't describe what a rung is doing in the 5 or so lines that are visible by default, then the rung is too complex and should be broken up.

I once worked on code that was driving HMI animation values, and there were about 14 different states. Every rung had the same comment on, describing what the state values were, so you couldn't see them all.

I changed it to use a UDT for the state values, and initialised the named members to the correct values on S:FS.

The UDT members had descriptive enough names, so instead of MOV 5 Pump1_Status, I could use MOV Status.Overheating Pump1_Status, so much easier to read, and did not need rung comments at all.