Professional Documents
Culture Documents
The variety of uses for the hardware, software and firmware (hereinafter “Products”) described in this Documentation, mandates
that those responsible for the application and use of those Products must satisfy themselves that all necessary steps have been
taken to ensure that each application and actual use meets all performance and safety requirements, including any applicable
laws, regulations, codes and standards in addition to any applicable technical documents.
In no event will Rockwell Automation, Inc., or any of its affiliate or subsidiary companies (hereinafter “Rockwell Automation”) be
responsible or liable for any indirect or consequential damages resulting from the use or application of the Products described in
this Documentation. Rockwell Automation does not assume responsibility or liability for damages of any kind based on the
alleged use of, or reliance on, this Documentation.
No patent liability is assumed by Rockwell Automation with respect to use of information, circuits, equipment, or software
described in the Documentation.
Except as specifically agreed in writing as part of a maintenance or support contract, equipment users are responsible for:
• properly using, calibrating, operating, monitoring and maintaining all Products consistent with all Rockwell Automation
or third-party provided instructions, warnings, recommendations and documentation;
• ensuring that only properly trained personnel use, operate and maintain the Products at all times;
• staying informed of all Product updates and alerts and implementing all updates and fixes; and
• all other factors affecting the Products that are outside of the direct control of Rockwell Automation.
Reproduction of the contents of the Documentation, in whole or in part, without written permission of Rockwell Automation is
prohibited.
Throughout this manual we use the following notes to make you aware of safety considerations:
Identifies information that is critical for successful application and understanding of the product.
Identifies information about practices or circumstances that can lead to personal injury or death, property
damage, or economic loss. Attentions help you:
• identify a hazard
• avoid a hazard
• recognize the consequence
Labels may be located on or inside the drive to alert people that dangerous voltage may be present.
Labels may be located on or inside the drive to alert people that surfaces may be dangerous temperatures.
Understanding Advanced Programming and Editing Techniques in Studio 5000 with
Logix designer
Contents
Before you begin ........................................................................................................................................... 4
About this lab ............................................................................................................................................................................... 4
Tools & prerequisites ................................................................................................................................................................. 4
Lab 1 Atomic, Predefined and Module defined Data Types 8 Minutes ......................................................... 6
3 of 74
Before you begin
Software
• Logix Designer programming software v22
®
• RSLinx Classic v3.60
• FactoryTalk View v7.0
Files required:
This hands-on lab uses the following files located in the C:\Lab Files\L03-Advanced Programming and
Editing Techniques folder for which a shortcut to Lab Files folder exists on the computer desktop:
• Advanced_Base.ACD
• Motor_Control_Ladder_Only.L5X
• Motor_Sim_AOI.L5X
• Global_Objects_Start.apa
4 of 74
Hardware devices required: 1796-CL31 demo box.
5 of 74
Lab 1: Atomic, Predefined and Module defined Data
Types
Programmable Controllers have different ways to define the size and layout of memory for use by the
logic designer. The designer must have a way to define, at minimum, Boolean and analog data. The
international standard, IEC 61131-3, defines basic data types, including BOOL, BYTE, WORD, DWORD
and INTEGER. Logix controllers use these as the most basic, or atomic data types. In Logix controllers,
data types can be atomic (most basic form), structure (comprised of a set of members) or array.
The following sections explain what you’ll be doing in this lab session, and what you will need to do to
complete the hands-on exercises.
6 of 74
1. Go to the desktop and launch Studio 5000 using the Studio 5000 icon.
Note that you are running in a VM Ware environment and it will take a few moments to
launch Studio 5000.
Note that you are running in a VM Ware environment and it will take a few moments to
open this project.
7 of 74
4. Notice the folders listed below the Data Types folder in the Controller Organizer
8 of 74
5. Click on the Plus Sign next to the Predefined folder. Notice the long list of predefined
data types. These data types consist of Atomic tags and Rockwell created predefined
tags that simplify the user experience by providing descriptive tags that can use self
documenting nomenclature.
Atomic Tags are the simplest of data types BOOL, INTEGER, DINT, SINT and REAL in the Logix
controller. Atomic tags are the building blocks for all other tags. Atomic tags can be used in various
combinations to build descriptive and useful tags. These tags can be Rockwell/Predefined or user defined.
6. In the Predefined folder Locate the Predefined tag for a COUNTER and Double Click
on it. It consists of 2 Atomic DINT tags PRE (PREset), ACC (ACCumulator) and 5
Atomic BOOL tags. The Counter is a Rockwell Predefined tag that most people are
familiar with and most people understand how it operates.
9 of 74
7. Scroll down the Predefined folder until you find the PID_ENHANCED tag. Double Click
on it. Scroll down through the PID_ENHANCED tag. You will see that it is a combination
of BOOLs, REALS and DINTS with a descriptive tag name. Having these predefined
tags can greatly simplify your operation by providing self descriptive nomenclature for
the various elements of a PID instruction.
10 of 74
8. Double Click on Controller Tags in the controller organizer. Using the Plus sign
expand and browse through the existing Module Defined tags Local:8:I and Local:8:C.
These tags are Module Defined tags specific to the 1756-IF6I Analog Input module
located in slot 8 of your chassis. This module was already configured when you opened
the project. As you scroll through these tags notice that the tags with an "I" for input,
come from the module into controller memory and tags with a "C" for configuration go
from the controller memory to the module. "O" for output tags can also exist but do not
exist for this specific module. "I" tags consist of descriptive tag names containing
information coming from the module on such things as faults, alarms and channel data.
"C" tags consist of descriptive tag names going to the module for such information as
alarm limits, deadband and filter values.
11 of 74
Tie it All Together So far we have examined Atomic, Predefined and Module defined tags. As a programmer
how can this help me? Remember as you scrolled through the various types of tags we saw that they all had
descriptive names. Descriptive names are helpful because they can be self documenting, meaning they do
not necessarily need to have you type additional comments, as the name says it all. IE .CH5HHAlarm is
obviously a Channel 5 High High Alarm. It can also help you as you program because as you scroll through
the tags looking for a certain sub element you can easily identify which sub element you are looking for.
Examine the rung below and read all of the comments associated with it and read the individual tag names of
the instructions, think how the predefined descriptive tags could help you. Note that the rung does not exist in
your program and is only shown here for illustrative purpose only.
The following rung does not exist in your program and is shown for illustrative
purposes only. It illustrates how descriptive tag names can help in your
programming.
12 of 74
Lab 1 Summary
We have learned:
Some basic principles of the tag structure of a Logix controller.
How self-descriptive nomenclature can help us more quickly and easily develop a program.
13 of 74
Lab 2: User-Defined Data Types, UDT
Now that you understand the basics of various Data Types, we will create a User-Defined Data
Type (UDT). In this section of the lab, you will create a User-Defined Data Type for a generic
Conveyor. During typical system design, it becomes apparent that there will be certain
“constructs” which will need to be instantiated repeatedly. We will look at the case where there
will be a number of conveyors installed into the system where each conveyor will have roughly
the same data associated with it. We will be able to define this conveyor once as a User-
Defined Data Type (UDT) and then use this Data Type repeatedly as required, saving a great
deal of design time and enforcing a high level of standardization.
Instantiate definition: To create such an instance by, for example, defining one particular
variation of object within a class, giving it a name, and locating it in some physical place. In
layman's terms, that means create something reusable but each new use of it gets configured
with specific values unique to that use.
14 of 74
1. Right Click on the User-Defined Folder and select New Data Type...
3. From discussions with your engineering department you have been told that the
conveyor UDT needs the following elements.
• HMI_Start_PB • BOOL
• HMI_Stop_PB • BOOL
• Machine_Permissives • BOOL
• Run_Motor • BOOL
• Motor_Running_Light • BOOL
• Part_Entering_PE • BOOL
• Part_Exiting_PE • BOOL
• Jam_Detected_Light • BOOL
• Motor_Commanded_Speed • REAL
• Parts_On_Conveyor_Count • DINT
• Production_Count • DINT
• Reject_Count • DINT
• Percent_Scrap • REAL
15 of 74
4. We will now begin adding new members to build our conveyor UDT. Click on Add
Member. It will change to a white space and we can now type the name of our first
member HMI_Start_PB.
5. Double Click in the Data Type column next to the name HMI_Start_PB that we just
entered. Type BOOL for Boolean data type. Select Apply. You could have also clicked
on the ellipses and found the BOOL data type by scrolling to it.
16 of 74
6. Your UDT should now look as shown below.
7. In a similar manner continue adding new elements of the correct data type until your
UDT looks as shown below. Click Add Member... Fill in the correct name... Select the
correct Data Type. Add the optional Description as shown. Select Apply when finished,
then Select OK.
17 of 74
Some important words on UDTs We grouped all of the BOOLs (each takes up a single bit in memory)
together followed by various DINTs and REALs (DINTS and REALs take up 32 bits of memory each). This is
not required but is more memory efficient. This particular UDT uses 24 bytes of memory. But if you were to
analyze it you might think that it should only need 21 bytes. There are 3 bytes of BOOLs that were allocated
but not displayed or used. Every time you create one non consecutive BOOL you are really creating 32
BOOLs total. That is why it is more memory efficient to group BOOLs together. Each instance of Data Type
'Conveyor' will use 24 bytes.
Some optional comments were added. These comments do not subtract from controller memory. You will
see later that the comments will be carried through as you create multiple instances of Data Type 'Conveyor'.
UDTs can be created and edited on-line but can only be edited off-line once an instance is created.
For more information on UDTs see publications 1756-RM094 and 1756-PM020.
8. In the Controller Organizer Expand the User-Defined Data type folder and you will see that the
new Conveyor type exists. This new data type is now available to be used multiple times
throughout our program.
9. So far we have designed a UDT to meet some specific goals of our application. This UDT can be
used multiple times throughout our program. It has been designed to meet certain goals dictated
by our application. It is created from various Atomic tags within the controller. We have saved our
®
UDT, by saving it we have essentially created a new ControlLogix predefined tag. We will now
create some new tags of data type Conveyor.
10. In the Controller organizer, Double Click on Controller Tags.
18 of 74
11. The following window will appear. Be sure the Edit Tags tab is selected. Scroll to the bottom of
the screen and Click on the white space at the bottom in the Name column. Type Conveyor_1.
19 of 74
12. Move the mouse to the Data Type column in the Conveyor_1 row, by default the data
type is DINT. Click the white space, then on the Ellipses.
13. This will bring up the Select Data Type dialog. Scroll to the Conveyor data type or
begin typing Conveyor (the Auto Complete function will find Conveyor after the first few
characters). Select OK. Then Hit the Enter Key.
20 of 74
14. Expand the + next to the newly created Conveyor_1 tag. Observe that all of the
elements of our previously created data type Conveyor have been created with our new
Conveyor_1 tag. Notice also that the comments we added into the original UDT have
come along as well.
Commented UDTs While the comments we typed when we created our UDT did come forward, notice that
they are a light grey. This means that the "Parent" Data Type Conveyor had comments and they were
brought forward. After creating a new Data Type, of type conveyor you can type over the Descriptions in the
"Child" if desired.
So far we have created a single instance of the Conveyor UDT. If you desire you could create multiple
instances each with a unique name or even an array of Conveyor data types.
21 of 74
15. Now that we have created this UDT called Conveyor_1 what does this all mean? First
we created a new Data type called Conveyor. This data type consisted of members that
had nomenclature specific to operational tasks of a generic conveyor. We then created a
tag called Conveyor_1 of data type Conveyor. Now think about these few tasks from a
larger machine perspective, lets say a packaging machine, because a packaging
machine would tend to have 1 or more conveyors on it. By creating this UDT we have
created a reusable piece of code that can help us build new machines in a more
productive manner. Using our new UDT we can now more easily create multiple
conveyors for our packaging machine, while leveraging existing work. We can take this
one step further, let us say that we work for an OEM who builds packaging machines.
The OEM programmer could spend a lot of time developing a UDT and some associated
ladder code to go with it that could be stored for future use on multiple machines. In our
example we could develop code for a simple conveyor. Now think about a machine or a
system that would have a conveyor, a pump, a safety gate etc. on it, you could develop
a UDT and associated ladder code for each of these machine parts. Reusable code can
be a great way to increase productivity.
Reusable Code can be a valuable tool to increase productivity and decrease engineering development time.
While a UDT is not a direct corollary to Object Oriented Design it is very similar. In Object Oriented Design
terms when we created the new data type Conveyor we created a Class. We then Instantiated an Object
called Conveyor_1. We could Instantiate multiple instances of the Class Conveyor by creating multiple
Objects each with a unique name, one object for each conveyor on our machine.
Study the diagram below to get a base understanding of our accomplishments
UDT Conveyor_1
New Data
Type
Conveyor Conveyor IN_Feed_Conveyor
22 of 74
16. To be truly effective our new UDT would need some associated ladder code to go with it.
In following reusable code principles this code would be developed and saved for use in
conjunction with our UDT. This UDT and ladder code would be capable of being used on
our current machine and all future machines. The ladder code specific to our conveyor
will not be covered here. In the spirit of reusable code this ladder code could be placed
in an Add-On Instruction (AOI). AOIs will be discussed in greater detail in the next Lab.
23 of 74
Lab 2 Summary
We have learned:
Some basic principles of the tag structure of a Logix controller.
How self-descriptive nomenclature can help us more quickly and easily develop a program.
Laid a foundation for the concept of reusable code.
24 of 74
Notes:
25 of 74
Lab 3: Making an Add-On-Instruction AOI
This section introduces many of the features and techniques used to create user defined Add-On
Instructions.
Add-On Instructions are re-usable code objects that allow you to encapsulate your most commonly used
logic as reusable instructions, similar to the built-in instructions already in the Logix controllers. This
saves you time by allowing you to easily re-use your commonly used instructions in your projects. It also
helps promote consistency in your projects since commonly used algorithms will all work in the same
manner, regardless of who is implementing the project.
Your Add-On Instructions may be created using the standard Ladder, Function Block Diagram, and
Structured Text editors already available in Studio 5000. Once created, an Add-On Instruction may then
be used in any of the Studio 5000 editors without any additional effort on your part. Online
troubleshooting of your Add-On Instructions is simplified by the provision of context views which allow you
to visualize the logic for your instruction for a specific instance of its use. Custom help for your
instructions also make it easier for users of the instructions to get the help they need for a successful
implementation.
Note: This is an advanced lab concentrating on the Studio 5000 and ControlLogix controller Add-
On Instruction capabilities. As such, little or no time is spent on basic concepts such as
programming techniques of the controller or tag scoping and creation. If you are unfamiliar with
these concepts, you may not attain maximum benefit from this lab.
26 of 74
Create a New ‘Add On Instruction’
In this lab, you will create a general purpose Motor Control AOI.
The Logic definition for the Motor Control will be the standard ladder logic seal-in circuit with a fault timer
to indicate disagreement between the motor’s commanded and actual states.
The Logic will also include arbitration between operator and programmatic commands.
27 of 74
1. Right Click on the Add-On Instruction folder and select New Add-On Instruction… from the drop-
down menu.
28 of 74
3. The Add-On Instruction Definition editor should now be visible.
4. Click on the Parameters tab to view the parameters in the instruction. The EnableIn and EnableOut
are default parameters that are created automatically whenever a new AOI is created.
29 of 74
5. Enter your fist parameter, Start_Oper by selecting the white space at the bottom and Typing
Start_Oper. Complete Start_Oper making sure that the Usage is Input and that Data Type is BOOL.
30 of 74
6. In a method similar to the previous step, enter the rest of the parameters and their specifications into
the definition parameter table as shown below. Be sure to set the Operator_Mode_Enabled default
value to 1, the Aux_Fault_Time default value to 5000 and check the appropriate Visibility (Vis) boxes.
Click Apply when complete.
31 of 74
Vis (Visibility) This field determines whether the Parameter is visible on the Ladder Diagram or Function
Block Diagram AOI instruction. We have not yet seen the fruits of our labor but the AOI we are building will
eventually become a ladder instruction as shown below. The Vis field causes the Parameter, Input or
Output, to be displayed on the actual instruction.
7. We will now need to add several rungs to perform our desired Motor Control function. These rungs
are shown below. Sometimes it’s good to practice our rung adding skills but since this is advanced
lab and your skills are sharp we will import our rungs instead of manually entering them.
32 of 74
Importing In this lab we are importing our rungs. This will save you a lot of time, help prevent some sort of
"typo" that could keep our final project from operating and give you an overview about Importing.
Exporting/Importing is a useful way to save tried and tested code to be used in the future. Individual rungs or
groups of rungs can be exported/imported. While not covered in this lab we could export for future use the
entire AOI currently under development.
Be aware that if rung comments were included on the export they will be imported.
While we are talking about exporting and importing ladder rungs the discussion also applies to FBD and
Structured text as well.
8. Click on the Logic box at the bottom of the Add-On Instruction Definition dialog.
9. This will close the dialog and bring up the standard ladder editor for our AOI routine. Right Click on
the empty End rung and Select Import Rungs....
33 of 74
10. Browse to the Desktop\ Lab Files\L03-Advanced Programming and Editing Techniques
34 of 74
11. The following dialog appears. Click OK.
35 of 74
12. We have now successfully imported all of or rungs into the Motor_Control AOI. The rungs have been
placed into the Routine titled Logic.
13. Scan/Scroll through the rungs we just imported. Sometimes, usually as the first or last rung, there is a
rung similar to shown below with the Left Power Rail indicating e e e e e for edit mode. If you have a
rung like this simply Select it near the Left Power Rail and then Hit the Delete Key.
36 of 74
14. At this time let us Save our work. Then Verify your controller project.
15. If the error pane is not already displayed simultaneously Press the Alt and 1 keys (Press Alt+1). This
will bring up the Errors pane at the bottom of your screen. If there are any errors review this section
as needed.
16. We have just completed adding a Motor Control AOI. This AOI can be used over and over to control
multiple motors both within this project or the Motor Control AOI can be exported for use in future
projects. The goal is to test our work and eventually couple it with an HMI project. Since we do not
have an actual motor to test our AOI with we will use some simulation code to test with. We could go
and repeat some of our previous steps and create a new simulation AOI. But for the sake of ease and
time will just import the simulation AOI.
17. Right Click on the Add-On Instruction folder and Select Import Add-On Instruction.
37 of 74
18. Browse to the Desktop\ Lab Files\L03-Advanced Programming and Editing Technique folder.
38 of 74
19. When the following dialog appears Select OK.
39 of 74
21. Notice in the Add-On Instruction folder that the Icons of the main routines of both instructions are
different. The Motor_Control icon represents a Ladder Logic routine
and the Motor_Sim icon represents a Function Block Diagram routine (FBD).
22. Double Click on the FBD Logic routine. This will bring up the code for this routine. It will look as
shown below. We will not focus on this code or on Function Blocks as part of this lab. Just pointing
out that AOIs can be other languages besides ladder.
What have we done so far? We have created a reusable piece of code to do some simple motor control.
We did a combination of creating some of it and importing the rest of it. We imported a different AOI to run a
motor simulation that will be "married" to our motor control AOI. One AOI is written in ladder and one in
Function Block. Both AOIs can be exported and/or imported for use in other projects or stored for future use
as part of a library of reusable code. Either AOI can be used just once in our current project or multiple times
throughout our current project.
40 of 74
23. In the Main Task Double Click on the Main routine. That will bring up a blank editable rung.
24. In the Language Element Tool bar Select the Add-On tab. Next Click on the Motor_Control AOI.
25. This will insert our newly created Motor_Control instruction into Rung 0. Select the space next to the
AOI name (Motor_Control) and type MC1 and hit Enter.
41 of 74
26. Right Click on the name MC1 and Select New "MC1".
42 of 74
Backing Tag We just created a new tag MC1 that is referred to as a Backing tag for a data type
Motor_Control. Previously we had covered that a Class gets Instantiated and becomes an Object. That may
all seem a bit complicated right now but the backing tag MC1 is a unique instance of data type
Motor_Control. This backing tag must have a unique name for each instance of our AOI. The backing tag will
contain all of the elements that were manually entered for our Motor_Control data type
43 of 74
28. Double Click on the End rung to insert a new rung. In a manner similar to adding our Motor_Control
AOI, add a Motor_Sim AOI. This time create a backing tag called MS1.
29. We must now "tie" our Motor_Control AOI to our Motor_Sim AOI. This is done by entering a
Motor_Control tag into the Cmnd and Aux element of the Motor_Sim AOI. One at a time Select the
Cmnd and Aux boxes and Browse to the MC1.Motor_Output for Cmnd and the MC1.Aux_Input for
Aux tags.
44 of 74
Input, Output and InOut Usage So far we created tags to be used within our AOI and configured some of
those tags to be Input or Output, there also is a third type InOut. These tags represent a way of "passing"
data between your application code and the AOI itself. Tags defined as Input will receive data from the
program to be used within the AOI. Tags defined as Output will return data to the program from the AOI.
Tags defined as In/Out can perform either Input or Output functions.
When we entered the Motor_Sim AOI we had an additional step as compared to the Motor_Control AOI. We
needed to configure two of the Motor_Sim, Vis (visible) tags. By doing this we directed the two AOIs how to
"share" information with each other.
In the physical Motor_Sim instruction for the Cmnd (Input) tag we entered the Motor_Control, Motor_Output
(Output) tag. This essentially passed the result of the Motor_Control AOI to the Motor_Sim AOI for
processing.
In the physical Motor_Sim instruction for the Aux (Output) tag we entered the Motor_Control, Aux_Input
(Input) tag. This essentially passed the result of the Motor_Sim AOI to the Motor_Control AOI.
45 of 74
30. When complete your rung should look as shown below.
31. At this time let us Save Our work and Verify our project.
If needed remember Press Alt+1 to see the Errors dialog. If there are any errors review this section as
needed.
46 of 74
32. Download your program to the controller. Select Communications... Who Active.
Note that you are running in a VM Ware environment and it may take a few moments
to complete the browse.
47 of 74
33. Click Download when the following appears.
Download Project Documentation and Extended Properties This is a new optional feature in V21. In
previous versions all rung and instruction comments etc. were stored on the computer as part of the off-line
project. So if you went online to a controller with a new computer you could upload the program and see the
rungs but not be able to see and comments. In V21 and later, if Download Project Documentation is selected
all comments and documentation are downloaded and stored on the controller itself. So if you went online
with a new computer you would be able to see all the documentation even without the original project file.
Be aware that in larger systems, downloading the Project documentation can significantly increase
upload/download times since more data is being transferred.
The area of memory where documentation is stored is separate from regular controller memory. This means
that an L75 with 32 meg of memory still has 32 meg available for user program regardless of how much
memory the documentation takes up.
48 of 74
34. Place the controller in Run Mode. Depending on the exact state your controller is in, you will either
be prompted on download to go to Run Mode OR you may have to place it in Run mode manually.
OR
49 of 74
Lab 3 Summary
We have learned:
Created our on AOI.
Imported a pre-existing AOI.
Learned some basic principles of re-usable code.
Learned about Input, Output and InOut tags.
Used our AOIs in a program.
Learned that a feature of Logix Designer V21 and above is the ability to store comments in
controller memory. And that storing these comments do not subtract from controller memory.
Downloaded our program to the controller.
50 of 74
Notes:
51 of 74
Lab 4: Making a Global Object in FactoryTalk View
FactoryTalk View adds more flexibility to using global objects in your application by the use of global
object parameters. Global object parameters allow you to assign the data source of a reference object
without breaking its link to the global object. Because the link is not broken, the reference object retains
its unique data source and it is still updated with changes to other aspects of the global object.
An AOI in Logix Designer together with a global object in FactoryTalk View form a powerful and reusable
functional pair allowing for “drag-and-drop” HMI capabilities.
Global objects with parameters can be referenced in different ways depending on programmer preference
or needs of the application.
Note: This is an advanced lab concentrating on the FactoryTalk View capabilities with global
objects interfacing to AOI instructions. As such, little or no time is spent on basic concepts such
as display creation, graphic design, and RSLinx configuration. As such, a basic application with
screens and navigation has already been created for this lab.
52 of 74
1. Use the shortcut on the desktop to launch FactoryTalk View Studio.
53 of 74
Discussion You have just opened an existing application. To be honest a large amount of work has already
been done for you. Screens were created, objects created tags configured etc. This was done because of
limited time in our lab, creating this on your own would likely incur "typos" and we wanted to increase your
odds of successfully completing this lab. However that is the point of Global Objects. A developer would do
all of the overhead work for you by creating the Objects and you would increase your productivity by
leveraging that work.
Here are three key things already done for you:
1 The Global Object goMotorMain has been created. This is the key element of our lab.
2 An RSLinx Enterprise shortcut to our controller titled AdvLogix has been configured.
54 of 74
3 A Display titled Motor_Faceplate was created. On that screen a Button named Motor 1 was added. The
Action of Motor 1 is to call up the Display popMotorMain using a /T parameter. When using a popup as a
faceplate, the data source can be assigned in the calling button using the /T parameter (tag reference). This
means that you can easily call a single Global Object multiple times and easily change the base tag used as
your source.
When you develop a Global Object, you are developing a re-usable component that can be developed once
and referenced mutiple times in your HMI application. Child reference objects can have different data
sources while still maintaining the link to all other aspects of the parent global objects. Your global object will
be mapped to different parameters of your AOI. When deployed, the user only has to reference the AOI
backing tag and does not have to care what the “guts” of the global object are.
The figure below is key to understanding what happens when you call a
Global Object. You call the Global Object which brings forward all of the
attributes you have designed into it. When you call it you make a simple
configuration statement (below) that allows multiple, simultaneous uses
of your Global Object. This is what makes your Global Object re-usable.
MC1 Is the backing tag in the controller that this instance of our Global Object will use.
Remember earlier while working in ladder we created a Motor_Control AOI with a
backing tag called MC1
AdvLogix RSLinx
Enterprise shortcut to
controller
55 of 74
Tip Because the global object on our popup only contained one global object parameter,
we only had to specify one tag after /T. If there were more, we would specify more tags
for the /T switch, with each tag separated by a comma.
4. Double Click on the popMotorMain Display to open it. This display is an empty shell of what will
soon be a soon be very useful popup.
Empty shell of
popup
56 of 74
6. Select the global object in the goMotorMain Global Object pane. Drag and Drop the global object
into the popMotorMain Display. Your project should look as below when finished.
7. Using the "X", Close both the popMotorMain and goMotorMain windows. Say
Yes to any request to Save changes.
57 of 74
8. We will now drive home the power of Global Objects by adding a second Global Object to our
application. We will add a Global Object of a rotating fan animation. In a manner similar to before
Open both the Motor_Faceplate Display and the goFan Global Object. Select just the fan in the
Global Object Display and Drag and Drop the fan into the square in the Motor_Faceplate Display.
It should look as show below when complete.
58 of 74
9. Right Click on the Fan in the Motor_Faceplate Display. Select Global Object Parameter Values.
59 of 74
10. Select the Tag browser Ellipsis.
11. In the Tag Browser window, browse to and Select MC1. Remember MC1 is the previously created
backing tag for our Motor_Control AOI. Notice that we only selected the main previously created
MC1 and did not need to drill down to any sub elements of the backing tag. That is because the
Global Object for our fan takes care of everything else. Select OK.
60 of 74
12. Select OK.
61 of 74
15. Select OK when you see this screen.
16. Your screen should look as follows. The fan may or may not be rotating, see Tip below which
explains when the fan rotates.
Tip The fans rotation is determined by our AOI, MC1 backing tag. Specifically the state of the member
.Motor_Output (MC1.Motor_Output). Keep in mind that our display only referenced the tag MC1 with no
specific reference to .Motor_Output. The speed of rotation is fixed and determined by the original fan Global
Object.
62 of 74
17. Click on the Motor 1 button.
18. That should bring up the following display. This display works with our previously created
Motor_Control AOI. Remember that this display only referenced the MC1 backing tag but uses all of
the elements within that backing tag. So not only did the FactoryTalk View Global Object increase
our productivity we could easily point to a single tag and reference all the elements within that tag
saving a lot of "tag browsing".
19. "Play" with the buttons on the Motor Control display. Keep in mind that "Start" and Stop" are only
active in the "Operator" state. When in "Program" state the ControlLogix controller is in charge of
"Start": and "Stop", however we have not yet included any logic for that purpose. We will add those
rungs in the next lab.
63 of 74
Lab 4 Summary
We have learned:
Basics of Global Objects.
Taking an existing Global Object and using it in our HMI project.
Learned some basic principles of re-usable code.
Witnessed how Global Objects can increase our productivity.
Finalized an existing SE application and watched it control our simple motor.
64 of 74
Notes:
65 of 74
Lab 5: Module Discovery and Free Form
Logix Designer has the ability to browse a chassis or network for CIP compatible devices. After this
browse a user can on command insert any "browsed" modules into the I/O tree. For many modules this
can be accomplished while on-line and in Run mode. This ability can be very important especially in
industries that implement a continuous process.
66 of 74
1. Bring up Studio 5000. It should still be active from Lab 3. If not launch Studio 5000, open the current
project and go on-line.
2. Go to the I/O Configuration folder. Right Click on the 1756-Backplane and Select Discover Modules.
67 of 74
3. The following Dialog will appear. Click on Create next to the 1756-OB16D in slot 0.
4. On the New Module Dialog Enter Local_Output in the name field. Then Select OK.
68 of 74
5. Select Yes on the Module Creation dialog.
6. We have just added a new I/O module into the controllers I/O tree.
69 of 74
7. In a manner similar to before Open the Discovery Dialog and Create the 1756-IB16D in slot 2. Name
it Local_Input .
8. Earlier in our lab we used a FactoryTalk View application to control our simulated motor. The HMI
only controlled the motor when in Operator Mode. We will now add logic to allow control the motor
when in Program Mode. In this case Program Mode means that the L75 controller program
has control of the motor.
70 of 74
9. Go to the Main Task and Double click on the Main routine to open it.
71 of 74
11. Add the following rung.
Note: This is an advanced lab concentrating on the Studio 5000 and ControlLogix controller. As
such, little or no time is spent on basic concepts such as rung creation. If you are unfamiliar with
these concepts, you may not attain maximum benefit from this lab.
Discussion Since this is an advanced lab it is assumed that you no how to enter a rung without detailed
instruction. This rung will accomplish two tasks.
1 Determine if the motor is active via the MC1.Motor_Output state and display the result on the first green
pilot light of your demo box. This pilot light will correspond to the state of the rotating fan in your FactoryTalk
View application.
2 When MC1.Program_Mode_Enabled is active, (remember in this case Program mode means the L75 is in
control of the motor instead of the HMI application) allow the first two Green PBs on the demo box to start
and stop the motor.
72 of 74
12. Bring up your instance of FactoryTalk View. On the Display Select the Program control button, this
will place the control of our motor to Program. When in this mode the first two green push buttons on
our demo box have control of our motors operation. Remember that in this context Program means
that the motor is controlled by the L75 controller.
13. Continue to "Play" with and test your AOI/View Global Object display.
73 of 74
Lab 5 Summary
We have learned:
How to "Discover" I/O modules.
That I/O can be added on-line and in Run mode in a Logix controller.
Continued to add functionality to out Motor_Control AOI
Preformed additional testing of our Motor_Control AOI
74 of 74