RSTechED 2009

DM02 – FactoryTalk Transaction Manager

Advanced

Presenter: Christopher Di Biase

Rockwell Software
DM02 — FactoryTalk Transaction Manager
Advanced

Contents

Before you begin......................................................................................................................................... 4

About this lab ................................................................................................................................................ 4

Tools & prerequisites .................................................................................................................................... 4

Review the Database .................................................................................................................................. 5

Creating a Configuration using the Checklist.......................................................................................... 8

Step 3: Where in the Control System is my data? ....................................................................................... 9

Step 4: Connecting up to the Database ..................................................................................................... 12

Step 5: Defining Transactions for Data Logging ......................................................................................... 17

Running Transactions .............................................................................................................................. 21

A Simple Change to FactoryTalk Transaction Manager while it is Logging....................................... 25

Taking Data from the DB to the Controller ............................................................................................. 28

Using FactoryTalk Transaction Manager’s Bidirectional Transaction for Logic in Logix................. 32

That’s All Folks.......................................................................................................................................... 34

3 of 35
Before you begin

This is the FactoryTalk Transaction Manager Advanced lab. If you’ve completed the Basics lab, you
can skip to page 18 of the Advanced lab manual, do that page, then skip to page 23 and finish the
Advanced lab.

About this lab

This is the FactoryTalk Transaction Manager Advanced lab, and we will focus on the primary purpose of
the product in this lab, which is to do fast, secure and robust data logging. We will be monitoring a
conveyor system that has some boxes moving down the line and we need to log some data in both a time
based and event driven way. The same example will be used for the other FactoryTalk Transaction
Manager labs.

This lab uses a simple conveyor line to illustrate some FactoryTalk Transaction Manager functions, we
have a RSEmulate 5000 program running and an FactoryTalk View SE application which helps you
visualize a bit of what is happening in the controller.

Note that most of the steps have the text on top and the image just below it. The image routinely shows
you how to perform the action described in the text.

Tools & prerequisites

Hardware devices required
PC with VMware v6.0
Software programs required
The “FT Transaction Manger” VMware Image consisting of:
Windows Server 2003 R2 SP2
SQL Server 2005 SP2
FactoryTalk Transaction Manager v9.0 (CPR9)
FactoryTalk View Site Edition v5.0 (CPR9)
RSLinx Enterprise v5.00 (CPR9)
RSLinx Classic v2.52 (CPR9)
RSLogix 5000 v16.0
RSLogix Emulate 5000 v16.0
Files required
FactoryTalk View Site Edition Project (simple screen and a few tags)
SQL Database scripts (tables already created for this lab)
Ladder logic

4 of 35
Review the Database

This first step is to familiarize your self with the tables inside the database. FactoryTalk Transaction
Manager can log into just about any table you create. In this lab we will use 2 tables inside a SQL Server
2005 database. So let’s review the 2 tables:

1. Start SQL Server Management Studio. From the Start menu, select Programs > Microsoft SQL
Server 2005> SQL Server Management Studio.

2. You have to log in to the SQL Server, but this has been pre-configured for you using Windows
Authentication, so simply click Connect.

5 of 35
3. Within SQL Server Management Studio, use the Object Explorer to browse to the tables of the
FactoryTalk Transaction Manager database as shown below:

4. Expand the dbo.my_box table and the columns folder as shown below:

6 of 35
 Review the columns. Box_Id will hold a unique identifier of a box, most likely this is something
scanned from a barcode. The other fields have height, width, depth and weight information. The
last information you see that we will track is SCAN_MACHINE_NAME and date/time info, this
tells us when and where we acquired this data from.

5. The next table we are going to look at is the conveyor table. Collapse the dbo.my_box table and
expand the dbo.my_conveyor table as shown below:

Looking at the conveyor table you can see that we have conveyor_id to identify the asset and the
other information about how the conveyor has been performing.

6. Minimize SQL Server Management Studio.

7 of 35
Creating a Configuration using the Checklist

Our first task is to create the FactoryTalk Transaction Manager configuration itself. (Actually, we’ve pre-
loaded the ladder logic into the RSEmulate 5000 on the image, otherwise you might consider that the first
step.) Since this Advanced lab assumes previous experience with FactoryTalk Transaction Manager,
only the basic information to create the configuration is provided. Note: If you cannot create the
configuration using only the information provided below, you should probably attempt the Basics lab
instead.
Launch the RSLogix Emulate 5000 Chassis Monitor by double clicking on the desktop
shortcut.

1. Using the FactoryTalk Transaction Manager GUI, create a new configuration using the following
information for Checklist steps 1 & 2:
• Name: conveyor_config
• Path: C:\DM02
• Enable Online Edits
• Control Connector: FactoryTalk Live Data
• Enterprise Connector: ODBC
• Service Credentials: Administrator/rockwell
• ODBC Connector Name: odbc

8 of 35
Step 3: Where in the Control System is my data?
Now that you have Checklist steps 1 and 2 completed, adding data points is the next step. We need to
go select the tags we want to be part of this configuration.

1. Click on Step 3 of the checklist.

2. First you must select a FactoryTalk application, in our case we’ll use the my_demo application
and click OK.

You will then be viewing the FactoryTalk data point screen, which then shows you the embedded
FactoryTalk browser on the top, and then after you navigate to a tag on the top of the screen, you
can either double-click on it or click the Add Selected Tag(s) button to tell FactoryTalk
Transaction Manager that it can use that tag in a transaction. The tag shows then at the bottom
of the screen and you can set properties about the tag concerning the rate at which the tag is
scanned and also how substitution policies are enforced. We’ve already added an FactoryTalk

9 of 35
 View SE HMI server at the root of the my_demo application. In addition to that we’ve created an
area called “area51” which inside it contains an RSLinx Enterprise data server.

3. Clicking on the plus sign next to area51 expands the tree and you see the shortcuts inside of
RSLinx Enterprise, in this case there is only one, the RSEmulate5000 shortcut. We need to
expand RSEmulate5000 and you see inside the shortcut, to available items such as the built in
Diagnostics items and the Online folder. Expanding all the way down and selecting the Online
folder we can see structures that have controller scope as well as the program names listed.

4. Since we are in the Advanced lab, we’re going to leave the tag browsing up to you! Simply make
sure that your tag list matches the one below. You need to be mindful of a few things:
• All of the tags we need are inside the conveyor1 program
• Make sure all fields are identical to those illustrated below – especially Data Types and Mode
(not all defaults are acceptable (hint: machine_name is string)
• The SystemClock tag is added using the instructions in Step 5 below (even for advanced
users like yourself, you may need pointers)

5. See these steps for the System Clock tag configuration:

a) We’ll use an array for our timestamps coming from the controller and use the length feature in
FactoryTalk Transaction Manager to grab the data all at once. Let’s browse out in the left hand
pane to the SystemClock tag, and down inside it to Current, and we’ll select the very first
element instead of every single one. Then click the Add Selected Tag(s).

10 of 35
b) Then go down to the lower half of the FactoryTalk Transaction Manager screen and edit the item
string for that tag (double click in the field or select the field and hit F2) and add a ,L6 at the end
(adding the comma, the letter L and the number 6), which tells FactoryTalk Transaction Manager
that starting at the first point, grab 6 contiguous memory locations.

c) We also need to tell the rest of FactoryTalk Transaction Manager this is going to be 6 items inside
there, so we need to edit the element field and change it to 6 as seen below.

d) The final change we need for the timestamp is to tell FactoryTalk Transaction Manager that unlike
a packed array of your average old integers, this structure is mapped out like a PLC5 time and
date structure to make converting to Logix systems easier (and because we already had the data
type in FactoryTalk Transaction Manger). So we need to select the PLC Timestamp data type
from the data type pulldown list.

11 of 35
Step 4: Connecting up to the Database
Now that we have completed step 3, we can go into step 4 to setup our database information. Our lab
requires logging to two tables and so we need to basically tell FactoryTalk Transaction Manager about
those two tables. The ODBC Data Object definition screen allows us to reference database objects such
as tables and stored procedures.

1. Click on Step 4 of the checklist.

2. The data object screen pops up, let’s type in box_table for the name.

3. We have to build a Database Connection to the database first, so we need a connection to an

ODBC System DSN (data source name). We get there by clicking on the browse button (the
ellipsis or three periods button) which are next to the database connection pull down list.

4. Then we are in the connection screen, pull down the list of available System DSNs (if you have
not completed the basics lab, see page 23, steps 5-11 of the basics lab manual to create a DSN).
Select FTTM _DB as the System DSN and the connection name is filled in for you. We just need
to put in our username password which is user sa password rockwell.

12 of 35
5. Now we need to use that connection to find our tables we need. We have two tables and we’ll
make two data objects out of them. When we get back to the FactoryTalk Transaction Manager
data object definition screen, we can pull down from the table list the dbo.my_box table:

13 of 35
6. Once we have our table selected you see the available columns from the database on the left
side of the lower part of the screen, the right side is for the columns we want FactoryTalk
Transaction Manager to use. We need to select all the columns (using click down and
rubberband or select the top column and shift-click the last column) and then using the arrow
button ( >> ) in the middle of the screen, send the columns to the right as ones we choose to use.
Your screen should now look like this:

7. Click Apply to save the data object.

8. We’ll click on Close to dismiss the data object definition screen, and it returns us to the check list
with step four now having a green checkbox. We’ll click on Step 4 again to re-enter the data
object screen, we want to create a connection to one more table.

9. When we enter into the data object screen again, we’ll type in my_conveyor for the name of the
data object, and in the middle of the screen, select the FTTM_DB connection. Then we pull from
the table pull down list the table dbo.my_conveyor. Again you see the available columns on the
left side of the lower half of the screen.

14 of 35
10. In this case, we want all the columns except for fault_count, your screen will end up looking like
the following:

11. We are then done with our data object, click on Apply to save and Close to exit the screen.

15 of 35
12. We have just one more data object to create, so click Step 4 for a 3rd time, then enter in
package_checker for the name of the data object. Select the same connection in the middle of
the screen but this time select the Stored Procedure radio button, and pull down
package_checker. Select all the parameters/columns as shown below:

Click Apply and Close. This stored procedure will help run the diverter on our made-up line we
are logging data from and to. You will see how the stored procedure is used later on in the lab.

16 of 35
Step 5: Defining Transactions for Data Logging
In this step we’ll add our transactions which do the data logging

1. We are back at the checklist, going for the green check for step five, so click on Step 5 to enter
into the transaction screen.

2. Entering into the transaction screen, we need to give our transaction a name, so type in
conveyor_trans for our transaction name

3. We then want to pull down the list of data objects and pick my_conveyor, you then see the
bottom of the screen show you the columns we’ve selected to use back when we created the
data object.

4. Next you need to double click anywhere in the bound value column (or right click and choose
Filter & Select Data points)

17 of 35
Make the bindings match the following table (and image above):
Data Object Column DataPoint Binding
Conveyor_id 1 [use expression editor]
ave_speed (unbound for now)
diverted_count machine_divert_count
the_date TransTimestamp(“local”) [use expression
editor]
speed conveyor_speed

5. We need to schedule this transaction to run a little bit faster then the default 1 minute (or else this
lab will really take forever). We need to select the Trigger/Storage… button.

6. Once on the Trigger and Storage Parameters screen, we need to change the Scan Rate to 10
seconds. Then click OK to leave this screen and get back to the transaction definition screen.

7. Finally we need to enable the transaction, so we just need to select Enable in the Transaction
Status part of the screen. Behind the scenes, FactoryTalk Transaction Manager checks the
validity of a transaction when it enables it (making sure no basic rules of FactoryTalk Transaction
Manager are broken). Disabling transactions are an easy way to stop transactions from running
but not deleting their definition, in case you want to change them later or add things to them.

8. Our final step, clicking on Apply to save the transaction changes, then Close.

A powerful feature in FactoryTalk Transaction Manager is the ability to log data only when an event
occurs in the control system, we’ll illustrate that with a different type of transaction.

9. We’ll enter Step 5 again by clicking on the button from the checklist.

10. From the Transaction Definition screen, we’ll call the new transaction package_trans so type that
into the transaction name field. Also pull down the box_table for the data object.

11. You’ll see the columns appear for the box_table data object, right click on the bottom of the
screen and select the Filter & Select Data points option.

18 of 35
 12. We need to bind the data points in a very distinct method.

Make the bindings match the following table (and image above):
Data Object Column DataPoint Binding
box_id current_box_4_
height current_box_0_
width current_box_1_
depth current_box_2_
weight current_box_3_
scan_machine_name machine_name
the_date SystemClock.Current_0_

13. This transaction will not fire on a time basis, but on an event so we have to set the trigger, click
on the Trigger/Storage… button.

14. The trigger will be the unscheduled point conveyor1.inspection, meaning this will only fire when
the box is inspected. Select the On Unscheduled Event and select our only available
unscheduled trigger.

Note: If the data point conveyor1_inspection is not listed in the pull down list box, then you missed
the unsched configuration back in Step 3: Where in the Control System is my data, sub step 4.

19 of 35
15. We only want to perform this action when the bit goes high, so we’ll check On High Transition.

16. We also don’t want a false fire (something that happens when FactoryTalk Transaction Manager
first starts, every unscheduled event looks like it changes since FactoryTalk Transaction Manager
never had a value before), so we’ll select the Ignore the First Unscheduled Event option.

17. We’ll click on OK to accept the changes on the Trigger screen, then we’ll enable the transaction.

18. Next we’ll click Apply to accept those transaction changes and we are back at the main
FactoryTalk Transaction Manager screen.
Now we have two transactions both doing data logging. One scans every 10 seconds and loads the
data into a table, the other scans only when the inspection bit goes high and then FactoryTalk
Transaction Manager fires the transaction to log data into a different table.
We’re now ready to start our transactions and begin data logging!

20 of 35
Running Transactions

We have to do a few housekeeping items before we start up the FactoryTalk Transaction Manager
configuration. First we’ll turn on debugging so we can find out if anything is not running correctly in
FactoryTalk Transaction Manager and we’ll also start up the FactoryTalk View SE HMI project and
RSEmulate 5000 Chassis Monitor.

1. We’ll make one more change to FactoryTalk Transaction Manager before we start it, which is to
turn on debugging. This will assist us with troubleshooting in case anything goes wrong (just as a
precaution), and will be easier to determine just what happened. In the main FactoryTalk
Transaction Manager user interface, select the configuration name then right-click and select
Configuration Properties.

2. From there you can see all the Configuration level settings. Information about the cache files,
error log files (what we want to change in this step) and connectors. We want to select the Error
Log tab.

3. On the Error Log tab, make sure Debug, Informational, Warning, Error and Fatal are all checked
(checking Millisecond Time is optional).

4. Click OK to accept your changes.

5. We have to make sure the controller (RSEmuate 5000 Chassis Monitor) is in run mode. Using the
RSEmulate 5000 Chassis Monitor, right click on the Emulator controller in slot 2 and select Run,
Click Yes to place into Run mode.

21 of 35
6. Next we have to launch the FactoryTalk View SE client so we can see our fake conveyor system.
On the desktop, there is a shortcut for the my_demo client file (Shortcut to my_client.cli),
double click it.

7. The screen that comes up has only one button on it, as you might surmise, click on it (it was used
for debugging purposes, so you could make changes to the following screen and save it in the
FactoryTalk View SE Studio without having to restart the client application each time). You will
see the following screen:

22 of 35
8. If the Use FT Int. switch is set to ON, set it to OFF for right now (or you will get an error on the
display because FactoryTalk Transaction Manager is not running yet). You can set the
Conveyor switch to On.
This screen shows a very simple conveyor system. Each time a box passes the first scanning system
(like a pretend vision system) we check to see what the height of the box is. If the box is shorter then
41 (inches) we divert it down the rollers, if not, we let it continue down the conveyor. If we divert it,
you’ll see the light above the DIVERT-A-TRON go off and the diverter shoot out and direct the box
down the rollers. With the ‘Use FT Int.’ switch set to off, the decision on the lesser then 41 inch logic
takes place in the controller. Later on we will create a FactoryTalk Transaction Manager transaction
that uses a stored procedure to perform the same logic so when you flip the ‘Use FT Int.’ switch to on
then the logic will take place in the database. There are several advantages of putting the logic in the
database. One huge advantage is we could use web pages to update the tables the logic uses (there
is a table that has a machine name and minimum height data in our case and the stored procedure
merely looks that up and uses it for the decision) instead of changing values in the controller.
Additionally, complex logic can be used using SQL instead of coding it in ladder. Finally many of
these “set points” can be downloaded at once, including at machine/line startup making the logic in
the controllers more generic.

9. Now that everything else is running, our data will change and we can fire up FactoryTalk
Transaction Manager and watch how it behaves. Start the configuration by using the main
FactoryTalk Transaction Manager GUI and clicking on the VCR style play button.

10. Switch over to the transaction monitor view (the bridge with the magnifying glass or View >
Transaction Monitor) to see how many transactions we have passed so far. If you don’t see
both transactions listed or you have failed transactions, raise your hand and wave it vigorously
back and forth to gain the attention of the room monitors.

23 of 35
11. If your transactions are passing, you can open SQL Server Management Console and look at the
newly inserted records in the dbo.my_conveyor table. Right-click the table dbo.my_conveyor
and select Open Table as shown below:

When you are there, note the NULL in column AVG_SPEED. We will address this issue in the
next section.

24 of 35
A Simple Change to FactoryTalk Transaction Manager while it is
Logging

Since we don’t really want a null for average speed, we are going to perform an online edit in FactoryTalk
Transaction Manager to change that value. FactoryTalk Transaction Manager has had the capability to
add/modify data points and transactions online for several releases.

1. Change the view back to Transaction Definition (the toolbar icon that looks like a bridge).

2. Double clicking on the transaction conveyor_trans will bring up the definition.

3. Click on the Create Edits to enter into edit mode, you’ll notice several buttons now are available
that were not when you entered into the screen.

4. On the bottom of the screen for data point bindings, you notice that avg_speed is not bound to
any data point. We’ll use the FactoryTalk Transaction Manager average expression to put in the
average speed. Select the avg_speed column, right-click and select Bind Expression.

You will then see the expression editor. You can click on the question mark in the title bar (all the
way over to the right) and then click on the AVG() expression to find out more information about
it. Basically you could add several data points together in one AVG function or the more powerful
feature is what we will use and that you can average over the same point being acquired in
subsequent transactions. That is to say if you can set up the average so if a transaction fires 3
times, you take the average of the different values you acquired for each of those executions of
the transactions and log that value.

5. Building expressions is delicate work (punctuation counts: commas and brackets and
parenthesis all mean something) so follow the instructions carefully. Click on the AVG() button
and it will toss the AVG() in the expression string text box.

6. Next, select the data point we want from the bottom of the screen, so pull down the list and select
conveyor_speed.

25 of 35
7. Finally click the Data Point Range button. This will tell FactoryTalk Transaction Manager to keep
the values for this datapoint when the transactions fire and build up a rolling average and log that
value. We’ll accept the default of a range of 4 and your expression string will look like the image
below:

8. Click on Validate which is always a good idea when building expressions, it checks the syntax of
the string. That should pass and then click OK to accept and exit the expression editor. Note:
When the transaction fires the first 4 times, FactoryTalk Transaction Manager will not have built
this average up yet, so the transactions will fail (this is by design). When the average is “built up”
then the data will be logged into the database.

9. Now you need to Save Edits (remember that in FactoryTalk Transaction Manager terms, saving
the edits does not effect the running transaction just saves your changes you have made).

26 of 35
10. Then click on Close to close out the transaction definition screen. Back on the main FactoryTalk
Transaction Manager window, make sure you are looking at the Transaction Definition view, and
you can see the pending edit of our conveyor_trans. The current displays the definition that is
currently running, the edit pending row has the changes we just made.

You can view the pending edit alerts if you want to (the glasses icon) but we don’t have any for
this transaction. Pending Edit alerts attempt to warn you when a transaction you have edited will
loose some type of “state” information. For instance, our transaction added an average function
so it isn’t loosing any state, however if we changed the data point used the average, a pending
edit alert will warn you that the current average state (or buffer) will be discarded when you
assemble the transaction and the new state will be built up.

12. Now you can click on the Assemble All button (don’t bother looking at the alerts you get
prompted to view) which looks like a green arrow (just to the left of the eyeglasses). The act of
assembling is what takes changes the running transaction.

13. Wait at least 30 seconds and then return to SQL Server Management Studio. Refresh the
conveyor table and scroll to the very bottom. You should see the average value start to populate
the avg_speed column.
You should also notice the failed transactions on the transaction monitor view, as mentioned
previously, this is a result of the buffer being built up and these “errors” can be ignored.

27 of 35
Taking Data from the DB to the Controller

In this step, we’ll actually change the logic about the diverter from happening in the controller to the logic
happening in the database (you can inspect the logic in the Conveyor1 program, it is not that complicated,
just a CMP statement). The stored procedure we will use is called package_checker and we created the
data object in an earlier step (if you would like to view the logic of the stored procedure, you can use SQL
Server Management Studio)

We will also use a feature in FactoryTalk Transaction Manager called the Bind Transaction Result
(BTR) that takes the status of the transaction and writes it back to the control system so the control
system can determine if FactoryTalk Transaction Manager was successful or not. When ever using
outputs from a stored procedure, you should use the BTR to determine when FactoryTalk Transaction
Manager has completed the transaction, instead of inspecting where FactoryTalk Transaction Manager is
writing the outputs to (since the outputs could be written in any order). You can also use the BTR when
logging data, and then the control system can inspect the BTR and determine if FactoryTalk Transaction
Manager has the data logged for sure. We are using the BTR to perform some error checking in our faux
system, namely if the BTR comes back as anything other then a 1 (one) then the transaction somehow
failed and we show this to the operator. If you inspect the logic, we check to see if the BTR is anything
other then a 1, we flip the bit we_have_a_problem which then shows an error condition in the RSView SE
client.

1. To start with we will put the main FactoryTalk Transaction Manager window into Transaction
Definition view.

2. From there, we need to add data points so we will double-click on the FT on the tree (when you
aren’t using the checklist, double clicking on the leaf-nodes of the tree will bring up the respective
definition screens).

3. We will be presented the data point screen as we saw earlier. We need to add three new points
to the system. Inside the conveyor1 program in the controller, double click each one individually
tag or select each tag and press the Add Selected Tag(s) button for the points:
fire_box_check, rssql_should_divert and rssql_transact_result.

28 of 35
4. Since this is an online edit, the data points show the font in red for pending definitions, you have
to make sure to change the Mode of the fire_box_check to Unsched

5. You must then highlight all three rows that have the pending edits in them, then click on Save
Edits, then Assemble Edits. We’ve created these new points, saved and assembled them but
have we affected the running configuration? Remember that you don’t effect the running
configuration until you select Assemble, however since these points are not yet used in a
transaction, no new points have really been put on scan. It is important to note that if you did not
assemble at this point, you wouldn’t be able to see these new data points when we go to the
transactions screen. A key to knowing when this step is finished is if there are no red italics
points left on the screen when go to close the screen. Remember you have to highlight the points
for the save and assemble buttons to “act” on them.

6. Now we are ready to go create our new transaction. If you are in transaction definition view
mode, you can right-click anywhere in the right hand pane to then select Define Transaction.

7. When we enter into the transaction screen, we’ll call the transaction check_da_package and for
the data object, pull down from the list package_checker.

29 of 35
 8. You see the parameters for the stored procedure and you need to bind the data points in the
following manner:

Data Object Column DataPoint Binding

@RETURN_VALUE [leave blank]
@box_id current_box_4_
@height current_box_0_
@width current_box_1_
@depth current_box_2_
@weight current_box_3_
@scan_machine_name machine_name
@in_date SystemClock.Current_0_
@out_divert [leave blank]

A few things worth noting about this stored procedure. As you can see, we are binding box_id,
height, width… so we have box info that is going to the stored procedure. Also we have the machine
name is also going up (if you check the controller, the machine name is SCANNER1). The stored
procedure checks to find a record in a table that matches the machine name, and then in that table is
a minimum height. Then based on that height, if the value coming in from the box is less, the write
back to the controller (out_divert) will be a 1, and otherwise it will be a 0. If the write back is a 1, the
controller logic diverts. We have not bound the output yet.

30 of 35
9. We need to select the @out_divert parameter and right click. Then select Separate
Input/Output Parameters, this takes the fact that the @out_divert looks like both an input/output
to FactoryTalk Transaction Manager (it actually is only an output, but any stored procedure in
SQL Server shows outputs as input/outputs). This will allow us to NOT bind a value to the
parameter as an input which would be discarded by SQL Server anyway.

10. Now that you have them separated, right click on the @out_divert input parameter (labeled with
the letter “I”), and select Bind Null Value.

11. Once we have done that, we need to bind a point to the output, so drag over the
rssql_should_divert data point.

31 of 35
 12. One more binding to go, we are going to bind a point to the Bind Transaction Result (BTR) field.
Check the box next to the BTR to enable it, then drag over or use the drop down list to select the
rssql_transac_result data point.

13. Next we’ll set the trigger so this transaction fires only when we want it to, so click on the
Trigger/Storage button.

14. From there, we need to select On Unscheduled Event and select the fire_box_check datapoint,
and as before we want to check the Ignore the First Unscheduled Event checkbox.

15. Press OK to exit the Trigger/Storage window, make sure to Enable the transaction then click on
Save Edits.

16. Click on Assemble Edits (don’t bother viewing the warnings, there are none) to bring that
transaction online. The transaction won’t start to fire until we flip our Use FT Int. switch in
RSView SE, so we don’t have to worry about anything happening until we want it to.

17. Close the transaction definition window.

Using FactoryTalk Transaction Manager’s Bidirectional Transaction for

Logic in Logix

Now in this section we’ll flip the logic in RSEmulate 5000 to use FactoryTalk Transaction Manager and
the database to perform our diverter logic instead of the simple check in ladder.

1. Now let’s go back to the RSView SE client screen (if you have closed it you can bring it back up
from the desktop icon).

2. The FactoryTalk Transaction Manager “engine” is running, so now we only have to flip our Use
FT Int. over to On.

32 of 35
3. The box height is randomly generated and will oscillate from 50 to 60 to 40. Remember our
check is anything less than 41 is diverted when we use the logic in the controller. The
FactoryTalk Transaction Manager stored procedure logic is similar but looks up the value by
machine name in a table. This would allow the system to be changed easily and securely via the
database, and have the same logic be used for multiple machines. Watch the height variable as
a new box is loaded on the conveyor. If the height is 50 or 60, the box is not diverted. However,
if the height is 40, you should see a few things happen:

a. When the box passes the scanner, the “boxcheck” value on the client (which shows you
the value of fire_box_check in the controller) should flip to 1

b. FactoryTalk Transaction Manager then fires and writes back two outputs: one is the BTR
or result of the transaction, shown by the FT Int. result on the SE screen (remember that
1 is good, anything else is bad) and should_divert should go to 1 (1 is “true” meaning
divert, 0 is “false” meaning not to divert) and also the FT Int. speed is a timer measured
in milliseconds that times the FactoryTalk Transaction Manager transaction. In testing
the lab, this was taking place in just a hair over 1 second.

c. When the should_divert is 1, the DIVERT-A-TRON has it’s light blink and the diverter
immediately shoots out to redirect the box.

d. Everything is reset when the box hits the end of either the rollers or the conveyor.

33 of 35
That’s All Folks

The lab is complete! You have made two transactions to log data, one on a timed basis and one that is
event driven. You’ve made changes to one of the transactions while it was online to add the average.
You’ve also changed the logic of the system to use a database to determine actions down on the control
platform instead of being buried inside of ladder logic!

Those of you more industrious students can try a few things:

ƒ Go into SQL Server Management Studio and stop the SQL Server service to shutdown the
database, you should see distinct errors on the screen and the FactoryTalk Transaction Manager
BTR should NOT be 1.

ƒ Change the value in the database table machine_scan_rule so that SCANNER1’s height value
is now 51 (more boxes will be diverted). (Remember to restart the Sql Server Service if needed)

34 of 35
35 of 35