Tips on Using Phase Manager With Factory Talk Batch

Title

TIPS ON USING PHASEMANAGER WITH FACTORYTALK BATCH BY DON SMITH SENIOR PROCESS AUTOMATION CONSULTANT ROCKWELL SOFTWARE

Copyright © 2007 Rockwell Automation, Inc. All rights reserved.

TIPS ON USING PHASEMANAGER WITH FACTORYTALK BATCH

Introduction

What is PhaseManager?

PhaseManager™ is a collection of features that integrates the FactoryTalk ® Batch software with the RSLogix™ 5000 programming software and the Logix5000™ family of controllers. The integration of these products simplifies the configuration and maintenance of your Batch automation system, provides a superior means of communication between the FactoryTalk Batch server and the Logix5000 controller, and significantly reduces the programming effort required to develop the phase logic code that resides in your Logix5000 controller.

In the FactoryTalk Batch Equipment Editor, you create a phase to represent a group of equipment that performs a minor processing activity in a manufacturing plant, and you create an equipment phase when you add a specific instance of a phase to a unit. PhaseManager is a collection of features in FactoryTalk Batch, RSLogix™ 5000, and an addition of capabilities in the Logix5000 family of controllers that extend the concept and definition of Batch phases to the RSLogix 5000 software and the Logix5000 family of controllers. PhaseManager adds an equipment phase object to the Logix5000 family of controllers and gives you the ability to create equipment phases in the RSLogix 5000 programming software. You can create or update equipment phases in RSLogix 5000 by adding or modifying them directly in your project, or by synchronizing your project with an area model that contains PhaseManager equipment phases. Likewise, you can create or update equipment phases in your area model by synchronizing with an RSLogix 5000 project file that contains PhaseManager equipment phases.

1


Tip 1: PXRQ and the Phase Instruction

PXRQ – the phase external request command The PXRQ instruction is used to request data or services from the batch server. This command requires several things to implement it: 1) A data array to store information, q[ ], type integer. 2) A phase instruction to store information in as part of the request, Download_Inputs, type phase instruction. Note that you must have a clear phase instruction register for each PXRQ. When a phase is reset, the Phase Instruction is cleared and ready to use again. If, during the life of the running logic, a PXRQ is used, it must use a phase instruction register that has been reset. To manage phase instructions you will need two phase instructions. The first is the one you use in the PXRQ, call it Download_Inputs. The second one is not used, but is used to reset the first, call it Empty_PXRQ. After using a phase instruction, reset it by using a COP instruction to copy the Empty_PXRQ to the Download_Inputs, length = 1. This concept is demonstrated in Tip 2, below.

See the Quick Reference for Configuring the PXRQ Instruction located in the FactoryTalk Batch PhaseManager User’s Guide (batch_phasemanager.pdf) for information on the value that should be placed in the q[] array for each command class to achieve a specific functionality.

2


Tip 2: Transfer of Control

Transfer of control (TOC) must work in the same fashion as outlined in Tip 1 – a clear phase instruction register is required each time you generate a request. Again, using an COP instruction with a Empty_PXRQ each time works well. To build a TOC phase: 1.

Set local variables for the PXRQ instruction:

The q array is a DINT, set at a size of 4. The Download_TOC_Pamrs of type PHASE INSTRUCTION. The EMPTY_PXRQ of type PHASE_INSTRUCTION . Note: You need to move an appropriate number into the q array prior to using the PXRQ instruction. For the below example, a 2 has been moved into q[0] to tell the PXRQ to use the TOC parameters.

2.

Now, wait for an indication that the phase has new parameters (Phase.NewInputParameters, formerly the DL bit), then do something – make sure the phase instruction is clear. The PXRQ instruction with the batch server is next line. It will begin the communications. Note – the rung driving the PXRQ must be held on during the life of the PXRQ communications with the batch server.

3


The .PC indicates the PXRQ instruction with the batch server is now complete. It will then clear the New Instructions (PRNP) and clear the Phase Instruction using a COP command. The COP resets the phase instruction by copying an empty instruction. See Tip 1 above for more discussion. The .ER is used to determine whether or not there was in error in the communications.

4


3.

It is good practice to reset PXRQ instruction in the resetting logic to account for an abnormal termination during a PXRQ. This rung will turn off a pending request that was left running.

You must give the TOC time to exchange data with the server. If the transitions between phases become true too quickly, then the server and the phase can get out of synchronization.

5


Tip 3: Hold Logic

PhaseManager does not have the native StepBuffer / Hold Index management that is part of the PLI with OPC-based phases. The following steps discuss building hold index management structure. 1.

Build a User Defined Data Type and call it StepBuffer. It should contain the following elements: •

•

2.

HoldIndex – of DINT data type, which holds the desired Running State Re-entry Step Index for any given time. Restore – of BOOL data type; condition when to restore the Step Index back to the StepBuffer.

Build a Local Phase Tag of type StepBuffer; call it StepBuffer.

6


•

The states of Running, Holding and Resetting will each have some logic. Place the logic at the top of the each state routine. The logic (shown in Structured Text format) is as follows: // For the Running logic, if the Restore flag is on, then restore the holdindex to the stepindex. IF StepBuffer.Restore THEN Phz.StepIndex := StepBuffer.HoldIndex; StepBuffer.Restore := 0; END_IF;

// For the holding logic , set the restore flag; StepBuffer.Restore := 1;

// For the Resetting logic , turn off the RESTORE flag (in case we aborted / stopped from a hold state). StepBuffer.Restore := 0;

7


The ladder implementation of the structured text is shown in the three examples below:

Running Logic

Holding Logic

Resetting Logic

8


In the running logic: // set the HoldIndex to the current step if this is a desired point of return from hold IF Phz.StepIndex = 200 THEN Step Instructions … StepBuffer.HoldIndex := Phz.StepIndex END_IF;

Tip 4: Unit Tags

Unit Tags still access the CLX registers using an OPC topic. If you have unit tags you must create an additional CLX (of type OPC / RSLinx) in the area model. Since we are using OPC to talk to the CLX, you must also create the watchdog handshake routine in the CLX (to make ensure OPC communication integrity).

9


Tip 5: Using Local Aliases

There are major advantages in using local aliases to build phase logic. If you use a local tag aliased to global tags, you can copy and paste code between phases. For example:

The “phz” tag is an alias to the phase named K300_Agitator. The “”agitatormotor” is aliased to the control module M300. In the logic then:

In this example, the code uses the phz alias for all references to the phase; all commands to the control module are to the alias control module. This code can be copied and pasted into another agitator phase. By implementing aliases that point to a new phase and control module, the phase would be complete and ready to run. You can also alias the local parameters and reports to global tags if you want to make them visible on an HMI or to another phase.

10


Tip 6: Group the Phases by Unit

After running a SYNC from the Equipment Editor (select Synchronize Logix5000 Data Servers from the Edit menu), all the phases will be placed in the “unscheduled program.” It is a good practice to move the phases into periodic tasks named after the units, as shown below. The SYNC will still synchronize changes made to either the area model or the phases even though you have moved them to a different task. The periodic task should only be as fast as needed to conserve CPU; 100 msec for most processes.

11


Tip 7: Do Not Implement if Not Required

If you do not have any logic to put in a phase, such as the holding, restarting or resetting logic, you do not need to create a phase state routine for it. But make sure you have the “Complete State Immediately if not Implemented” box checked on the phase properties, as shown below.

12


Tip 8: Loss of Communications

You need to set up the phase to handle loss of communications. Two settings under phase > options need to be set. External Sequencer Loss of Communication Command should be set to Hold . None is the default. This will put the phase to hold when it losses communications with the batch server. The External Request Hold Action should be set to Clear . None is the default. This will clear any PXRQ instructions that are running when the phase goes to hold. Make sure you return to a point above the PXRQ step that will clear the Phase Instruction (see Tips 1 and 2) and then re-run the PXRQ.

Tip 9: RSLinx

The batch server uses CIP protocol to talk to the PhaseManager equipment phases. RSLinx® Lite and RSLinx Single Node do not support the CIP protocol. Use RSLinx OEM, Gateway or Classic for communications between the batch server and PhaseManager equipment phases.

13


Tip 10: Equipment ID

When the Batch Server synchronizes with a Logix project, it saves the equipment ID in the equipment phase. If you right-click on the phase in Logix 5000 and select Properties, you will see the Equipment ID.

If you attempt to synchronize this Logix project with a new / different Batch Server area model you will receive the error “Cannot synchronize.” The error is generated because the project is in synchronization with a different Batch Server area model. If you want to remove the equipment ID so you can upload a phase to a different area model, you must remove the Equipment ID information from the Logix project. To remove the ID, save the Logix project as a L5K type. Edit the file; for each program of type Equipment Phase that you want to remove the ID, remove the properties Equipment ID and Recipe Phase Names by deleting the lines “EquipmentID := xxxx,” “RecipePhaseNames := “aaaaaa” where xxxx is the Equipment ID and “aaaaaa” is the Area Model Phase Name. Be sure to include the commas that separate the different property lines as well as the ending parenthesis. Now import the L5K file into a new project.

14


Tip 11: Use Resetting Logic on Back-to-Back Phases

Tip 12: Synchronization

If your phase has the possibility running two instances of the phase back to back in a recipe, always implement a resetting routine. The routine can be limited to a single rung with PSC. This will force a reset and scan of the phase before the next instance.

Keeping the area model and the Logix project in sync can sometimes run into problem. There are few rules. •

•

•

Do not modify both the Logix project and the Area Model. Make one of these the master and make the changes there and sync. If you are using phase classes with multiple phase instances, it is best to make all the changes in the area model and then push the changes down to the Logix project. Specials — the parameters and reports created as part of Control Strategies, Material Track and Deviation Limits should not be modified in the controller. They must be modified in the Equipment Editor and pushed down into the Logix project. (See Tip 13: Reserved Names.) For a “non-special” phase, if both 1) the unique id changes and 2) the user modified any parameters or reports in the Logix project, the Equipment Editor shows “cannot synch” and the Details button indicates a “duplicate name” error. If the user then manually fixes up the parameters and reports of the phase class in the Equipment Editor so that they “match” — that is, the user manually fixes item 2) above — then the Equipment Editor allows the “update area model” option and the Details button describes the “UID mismatch” scenario. 15


•

It is possible to change the name of the Logix project file and the re-sync to it after correcting the path in the data servers, but there are issues that can arise if changes are implemented in the area model and the Logix project. If file name changes are implemented, re-sync before implementing changes.

What are the minimum essential requirements that must be present in a Logix-created phase in order for successful synchronization with the FactoryTalk Batch area model? If you are starting from RSLogix 5000, all you need to do is to create an equipment phase. An equipment phase, with no input or output parameters or state routines can be synchronized to the Batch area model. On the FactoryTalk Batch side, you must have previously configured: A data server (pointing to the RSL5K project file) At least one process cell At least one unit

Tip 13: Reserved Names

The batch server has reserved names for parameters and reports. If you use them in a project, you will not be able to later implement these features without renaming them first. Also, you must be aware of the tags that will be created in the Logix project.

Material Track: Parameters: Amount, Amount, Container, Label, Lot, Material, Material Class Reports: Feed_Complete, Actual_Amount

Control Strategy: Parameter: Control_Strategy

Limits: Parameters: ParameterName_H, _L, _M Reports: ReportName_H, _L, _M The tags that are created in the Logix project are the same as above, but a prefix underscore (_Amount).

16


For an additional source of examples for PhaseManager see the Web site: http://samplecode.rockwellautomation.com One example project available for download from the sample code Web site that shows using PhaseManager in a variety of ways is the sample project “PhaseManager and a Scalable Batching Solution.”

Publication FTALK-WP001B-EN-E - September 2007

17

Copyright © 2007 Rockwell Automation, Inc. All rights reserved.

Tips on Using Phase Manager With Factory Talk Batch

Recommend Documents