RSLogix 5000: alias tag in an UDT.

Hi all,
I'm working on my first RSLogix 5000 program. Thanks to the help of some of you guys I am taking advantage of the AOIs (add on instructions) and the UDTs (user defined data types).
Since I have a bunch of motors to control, I created a UDT named "Motor", containing the variables start, stop, amperage, speed, etc. I also created an AOI to start/stop the motor, using the UDT as a parameter.
I was very excited with this easy way of doing things!
The problem appeared when I tried to associate one of the UDT internal tags to an input. I cannot associate a member of the UDT to a input slot in the input card!!!
Am I wrong? Is there a workarund?

Thank you!

No workaround, UDT Tags aren't meant (at least as of now) to be aliased to physical I/O.

Good and bad points I guess. Bad point, is there is a bit more work involved.

The good point, is it allows for some good off-line (as in not wired) testing possibilities.

I create two routines, generally called '_000_Scan_Physical_Inputs' and '_999_Update_Physical_Outputs'.

In the first, I just use XIC (PhysicalInput) OTE UDT.Member
The second should be obvious too, XIC UDT.Member OTE (PhysicalOutput)

The good part is doing that, you can also create the same routines, '_000_Scan_Physical_Inputs_DIAG', and put in logic there so you can simulate everything for testing purposes.

Another reason for using rdast's method is the asynchronous nature of the ControlLogix Processor. It's not like the old days where a PLCs I/O update followed a given Update Input -> Do Logic -> Update Outputs. A ControlLogix can update it's I/O anywhere in the scan (asynchronously). Now, most times and with good progamming practices that's not a problem, but the above method will also enforce the traditional scan sequence of I/O updates.

Also, as a minor point...I use a simulation routine also to mimic real world functionality. You can turn on Inputs with output instructions (have logic that turns a motor aux on when a motor starter is turned on to simulate logic) without doing the above. You can do that to aliased tags direct. Just inhibit the I/O module in the configuration and the processor will leave them alone and let you control Input and Output states with logic.

Thank you for your responses!
I also found an explanation from AB:
http://rockwellautomation.custhelp....td_adp.php?p_faqid=29568&p_created=1093924800

I already created the "read inputs" and "update outputs" add-ons.

Hi Elcan,

Off the initially subject. If you have a bunch of motors to control, provided that the process allows it, you can create a UDT, whether direct or variable, with all the necessary members and their respective datatypes. You use this UDT as an datatype for all your specified drives and the master UDT, that are defined in the controller tags.

You then create a master routine with all the necessary checks and balances with the master UDT. Then to drive the motors, you need to create a routine with the necessary logic to do that. This should run in a seperate task. You create a new task called "Motors". You dump the master routine for the spesific drive, linked to the master UDT, where JSR are used to call each block or drive.

These blocks monitors and controls that spesific drive's I/O's and scan the master routine and tag continuously. The advantage is the following;
1. There are no cluttering of the code and the tag database.
2. Each drive looks exactly similiar in design. Once the maintenance guys understands one drive, they will understand all of the drives, due to the master scanning of the UDT.

Disadvantage:
1. Certain 3rd party software does not yet recognise the UDT data type for data exchange.

Greetings from sunny South Africa.

Thank you for your comments, Manny!
To be honest, I cannot understand your idea, probably because I'm a novice with RSLogix5000. Could you upload some images?

Here's what I have done for each motor:

I created an UDT for the motor.
I created 3 add-ons: one to copy the inputs to the Motor UDT, one to Start/Stop the motor, and one to copy the corresponding Motor UDT members to the outputs.

Since I have near 100 motors, the task of adding the tags to the add-ons is very tedious. I've been wondering if there's an easier or efficient way of doing this, or if I'm too lazy!

All comments are always welcome!

You should globally copy your I/O in one routine at the beginning of your main scan (for inputs) and at the end (for outputs).

Where are you in NC, BTW? I'm in the RTP area.

What would be the best way to do that? Just a rung by rung strategy? I hope not...

I'm in Greensboro.

Well it depends on tag organization, but yeah, typically use an XIC to OTE rung for each of your physical inputs and outputs. Note rdrast's first post in this thread and he described that procedure.

Personally I find the AOI at the start would be way to hard to quickly fault find. Use XIC of the real world input mapped to an OTE for the UDT bit. Anyone can look at it and see what is happening without knowing what an AOI or a UDT is.
Dont use an AOI to start stop motors, do it in long hand with the UDT bits. Each motor has its own routine. Search and replace the UDT bits is easy for 100 motors in 100 routines. You just need to change your real IO. This is a lot easier for someone to fault find and follow later.

Map the inputs at the start of your individual motor routine.
Map the UDT outputs at the end of the routine.

Just because you can doesnt mean you should.
Kepp it simple, document it well and those that follow you will appreciate your work. If I saw a program written like the way you started I would think, some wanker was trying to prove how much he knows about the software without any consideration of practicalities.

And I have seen a lot of programs done like this. Motor starting passed to subroutines etc. Near impossible to fault find if something goes wrong.
AGAIN. KEEP IT SIMPLE.

Regards Alan Case

Elcan said:

Thank you for your comments, Manny!
To be honest, I cannot understand your idea, probably because I'm a novice with RSLogix5000. Could you upload some images?

Here's what I have done for each motor:

I created an UDT for the motor.
I created 3 add-ons: one to copy the inputs to the Motor UDT, one to Start/Stop the motor, and one to copy the corresponding Motor UDT members to the outputs.

Since I have near 100 motors, the task of adding the tags to the add-ons is very tedious. I've been wondering if there's an easier or efficient way of doing this, or if I'm too lazy!

All comments are always welcome!

Click to expand...

Elcan, I suggest you take a look at this thread
http://www.plctalk.net/qanda/showthread.php?t=42810 to see a simple example of what Manny is talking about. It starts on a slightly different topic but as we determined what the OP was doing with more detail it ended lining up with what you are also trying to do.

Hi Elcan,

I agree with Alan Case. There is a fine line between writing "good" coding and "bad" coding. You need to "visibily" map your I/O's, to and as per defined datatype of the drive. This is highly appreciated if you need to do fault finding, although any HMI could identify the actual cause of failure by using various tools e.g. scripting.

If you use an UDT, and as Alan said, input mapping prior to copying the spesific drives data to the UDT and scanning the master UDT logic. Post scanning, do all your output mapping. I have applied this a few times, and never had any issues.

The idea is not to do fault finding on PLC code. The HMI should have all the necessary user information. In some HMI's, the same can be done, where "indirect addressing" can be done, thereby having only one script and window, and calling the data from here.

Good designs cuts at least 50% of development time and issues.

Greetins from sunny South Africa.

Thank you very much folks!
The link was very descriptive, Alaric.
OK, I decided to get ride of those Add-Ons I had showed in the picture in one of my previous posts. Now I created one routine for the inputs, one for the outputs, one to start/stop the motors, and one as the "main routine" where I call all the others.
Since I have so many motors, I had decided to create a program for each sub-process, under the main task. Each program has the routines I described above. I think this arrangement will make the program easier to maintain.
The problem with the "start/stop motor" subroutine is that I have to duplicate it in every program, since I cannot have a "global routine" that you an call from all the programs. One alternative could be to use only one program and put all the subroutines under it, but I concerned about making it more difficult to manage.
This is a sample of what I've done:


Please give me your thoughts about this!

Why not have a routine for each motor with the inputs and outputs for that motor in that routine.
Develop 1 motor routine then copy the routine multiple times.
Do a search and replace on the udt tags.
Keep the auto control of all motors in the one routine, just set the run required bit for each motor in this routine.
Regards Alan Case

Hi Elcan,

Create a "motor master routine" using the "motor master UDT" tag. Then, create a routine for each motor as follows;
1. Map the inputs to the spesific motor's UDT - "motor A".
2. Copy that motor's values to the master UDT - Source: "motor A", Destination: "motor master UDT", Length: 1.
3. In the same rung, JSR to routine name: "motor master routine", input par: "motor master UDT", return Par: "motor A".
4. Map the outputs to the spesific motor's UDT - "motor A".

You do exactly the same for all your other motors, keeping them in seperate routines. For ease of quick viewing, you can call these motor routines the same as your field tagging as displayed on the engineering drawings.

Greetings from sunny South Africa.