UDT's and physical IO

This is kind of a best-practice question. This is the first time i've made significant use of UDT's in a project. Whereas in the past, I've used actual IO (local:1:I.data.1), this time around, I'm using UDTs (U1.is_full).

So, I notice I can't alias a member of a UDT in any easy way, so I set up a huge routine that just maps things around:

--| local:1:I.data.1 |------( U1.is_full )

and

--| U1.start_pump |-------( local:2:O.data.1)


This method will also work well for data living on the MCM card. The rung count in this routine is going to be huge however, so the question is:

Is this "best practice" for wiring up a UDT to the physical world?

You can't alias a UDT to physical IO becasue a UDT is a definition of a memory structure, its not actual memory. It's like a blueprint for a building - but not the building itself. And like a blueprint, it can be used to create multiple memory structures when you create a tag of the UDT type. You can create aliases to any tag that exists, but not with the UDT itself because it is not a tag - only a definition by which a tag is built. You are going about it the right way.

Alaric, you are perfectly correct in your reply, although mainstreetmark's "UDT" may be an acronym for User-Defined Tag, not User-Defined Type.

I'd like to summarise, and hopefully make things clearer to the many people who haven't got a handle on what aliases are in the Logix5000 world.

An Alias Tag is a tag, just like any other in the database, but it holds no data, and merely acts as a redirector to where the data is actually stored.

An alias tag cannot have a data-type, neither pre-defined nor user-defined, the data-type shown for an alias tag in RSLogix5000 is the data-type of the data that the alias tag is an alias for. You do not select a data-type for an alias tag, and it follows that an alias tag cannot have a "structure".

Therefore, an alias tag cannot have "elements" contained within it, it is simply a named item in the database that refers to something else in the database.

That "something else" can be another tag (whole), or part of (a sub-element) of another tag.

If it helps, think of the alias tag as a symbolic reference to data stored in the database, although it actually isn't just a symbolic reference, it acts like one.


mainstreetmark - your approach of mapping the physical I/O into the elements of a UDTag is perfectly valid.

There are a few ways to get a grip on your I/O, one of which involves creating "handling function" code for your plant items. typically 95% of I/O is drives to, and feedback from, plant items - e.g. Valves, Pumps, Level Probes, Proximity Switches, Flowmeters etc. Even those Inputs and Outputs that are not plant related (eg pushbuttons/lamps, etc.), can be handled with the same handling code as plant devices (eg. a pushbutton could use the same "debounce" handler as a level-probe, with 0 seconds debounce)

Your physical I/O points can be passed as parameters to your "plant item" handling function code routines, either as parameters in JSR/SBR/RET instructions, or as parameters to Add-On Instructions. Either way performs the mapping of physical I/O points to UDT elements as you require, directly, and without the need for hundreds of "mapping" rungs.

Note to mainstreetmark:
If you want to cut down on the apparent size of the mapping logic, one thing I do is map all inputs in one routine, all outputs in another.

Then, since no actual logic is performed (just assignments), I usually write those routines in Structured Text, which is denser on the screen then LAD:

MC.DRV.RunSt := Local:4:I.Data.01
MC.DRV.Speed := CNB01:3:I.Ch01Data

Great information, thanks.

My AOIs wound up using far too many parameters to be useful, so I pass it a single UDT.

I would love to use Structured Text, but evidently we didn't pay for that feature. We can only create Ladder. I guess AB isn't making enough money yet. In any event, I made an excel spreadsheet with the inputs, and with a clever formula, has a column that contained XIC [in] OTE [out], which I was able to cut&paste into the Ladder. Brilliant.

This post was just to clarify that physical mapping was required, and that aliasing isn't available. It would be nice if you could. You know, in Controller tags, when you expand your UDT, you could type an alias for those tags as well.

mainstreetmark said:

This post was just to clarify that physical mapping was required, and that aliasing isn't available. It would be nice if you could. You know, in Controller tags, when you expand your UDT, you could type an alias for those tags as well.

Click to expand...

Well, yes, and no.
One of the primary reasons I use for the physical mapping, is that I can easily write an entire program, without caring where the I/O ends up, and then (worst case) I map it point by point during startup (which helps to verify that things exist, are wired properly, and function in the correct sense). Secondly, I often have two set's of physical input mapping, one being the real "Live" one, the second being a dummy one, often driven by the system non-physical outputs, for simulating the system live, but with no I/O (or controller).