ControlLogix & FactoryTalk Batch: Design Ideas

I've got a new project coming up involving these two platforms. Unfortunately, I'm not really a PLC programmer, and consequently I have about 5 mins worth of experience with ControlLogix PLCs, and no experience with Factory Talk Batch - but that's my problem for later. Right now, we're only in the User Requirements phase, which means high-level functional requirements: control of conveyors, feeders, solution mixing, dryers, and some level of packaging and cleaning functionality. I'd like to end up with a system that not only fulfills these functional requirements, but goes beyond that with additional features the Operator(s), or Maintenance Techs would appreciate. In other words, I'd like the system to have a "WOW" effect, if that's possible.

What kinds of ideas do you guys like to (or wish you could) incorporate into your systems (hardware or software) to make them more usable, smarter, reliable, or just for the "WOW" effect?

Sounds like a big project, and given you have no experience with a ControlLogix and none with batch, you shouldn't even care about a "wow" factor right now. You need to be doing a lot of homework to build a good foundation to make this functional, worry about wow factor when you have the time and budget to do so.

1. Become very familiar with S88
2. Learn about "Phase Manager" in ControlLogix
3. Build standard code to lay the ground work
4. Learn about FT batch of course
5. I assume FT View SE goes with this? Life just got harder...PlantPax?
6. Design documentation? You mention URS, but don't forget you'll have to create Functional Specs so you know the details of what you need to program. Understanding the process P&IDs.

Sorry to be a downer, but "wow" factory is not a priority until you know exactly what you are working with any how to get the most out of it.

Paully's5.0,

1. I'm sort of familiar with S88, but not how it relates to ControlLogix. I'm used to having an external recipe editor with its data downloaded to the Controller, but that's for an entirely different system. I've also written "modules" running under "Process Units", so it's mostly S88 compliant, but again - different from however ControlLogix implements it.

2.) So "Phase Manager" is the interface in ControlLogix for receiving Recipe data from Factory Talk Batch?

3.) Of course I will be modularizing my logic as much as possible. I like to work from the outside in, meaning - establishing the input and output connectivity first (the actual I/O points & recipe connections), then maybe the common device controllers, then common macros (such as mode decoding for bit control, any transfer logic, PIDs, Dosing, and alarming), then finally the remaining "inner" logic unique to the module that ties it all together. With the system I'm familiar with, a Module is designed in a common structure of nested, hierarchical "trees" of function block logic. At the highest level you have just the Module's macro face as it connects to the outside world (the Process Unit logic that sequences the individual modules and provides recipe data). From there you can 'drill down' into a 'sheet' below that partitions the logic into sub-trees for Devices, Alarming, and Control Logic. Some of the logic at these levels is "common" (or instanced) across all modules. I would probably try to implement a similar structure with this new system. Just not sure exactly *how* in ControlLogix framework. I supposed I could do Function Blocks, but I don't think it'd be quite the same. My inclination, actually, is to use Structured Text because that's what I'm most comfortable with, but I'm not sure how well that's implemented in ControlLogix. If I go that route, I will still probably need some Function Block, and maybe even the dreaded "Ladder Logic" because not all functionality is available in every programming model, right?

4.) I guess I just (initially) need to understand the linkage from ControlLogix to FT Batch, so I can make sure I've got that interface right in the logic, correct? I mean - I may not even *write* the recipes ...

5.) Haven't heard yet if FT View will be the front-end. Does it necessarily go hand-in-hand with FT Batch, or can RS View be used? Is FT View difficult to work with?

6.) Yeah, I know I'll need to do a Functional Spec later, but we're on the URS right now, gutting the detail out of it. While we're doing this, I thought I'd suggest some of the added functionality I'm asking about here. For example - Maintenance Displays that might show all I/O at a glance and whether or not calibration may be needed.

LOL! Just started reading up a bit on Phase Manager. It appears Rockwell has this thing set up to encourage (force?) you to use it, otherwise you're signing up for manually replicating tags and logic between the Batch and Logic sides - even if you *still* use Rockwell Controllers! So there's more to it than just setting up the linkage between the two. It's probably best to build the structure *from* the Batch side, then synchronize the two to create the corresponding structure on the Logic side

Go to version 28 and read up on Sequence Manager.

FTView is just the latest RSView. Not exactly sure when the name changed and it's easy to use.

JKerekes:

That appears to be Rockwell's "scaled-down" Batch solution, which *might* be sufficient, but it sounds sort of limited, too. Less than 32 recipes? This came out *after* FactoryTalk Batch?

I think they want the server solution without any limitations. Probably overkill for this new 4-story, 15,000 sq. ft. standalone facility, but what do I know? It's all so preliminary right now. There's also been talk of adding a 2nd system later (likely), and up to 4 systems eventually. So that alone may rule out the Controller-based solution

MATT116:

Thanks for clarifying. Seems like Rockwell products are so many and so varied that clarification will always be needed...

Software

Your I/O idea is a great tool for t/s. A maintenance screen is another good diagnostic.

Each one in it's own will give the tech alot of information about the machines status. I have had good feedback from the mech techs who use them.

An idea for maintenance

I put a bit from the maintenance page to each of output rungs, just so there can be no accidental engagement. The bit has to be toggled on before any maintenance functions can be performed. The maintenance bit cannot be toggled during a programmed cycle. Be sure to maintain all the safety protocols for each output. I make all the function buttons momentary so they can't leave one on and walk away. In either case they can't start any program functions until the maintenance bit is removed.

Ideas for I/O

Usually I can get all the I/O's on one page, but in the case of this last project there were a hundred and forty inputs. In that case I made separate pages. I put pumps and anything related to pumps on one, valves and related on another, any proxies or other categorical items that make sense to lump together. This is labor intensive for every indicator is pointed at the appropriate tags in the plc.

"Is FTV difficult to work with" Depends on who you ask...........for me it has been a struggle (first one from scratch), but sometimes it's similar to other HMI platforms I have used. The "HELP" button is good information (wore mine out), otherwise I have learned that google is full of videos for almost any subject for FTV.

This stays open on my desktop http://literature.rockwellautomation.com/idc/groups/literature/documents/um/viewme-um004_-en-e.pdf

Then there's 2 tonnes of FTV topics in PLCS.NET. There's no shortage of support for the subject. Last bit of advice here......pick a screen color other than white.

You code in structured text? I envy you, all I know is ladder. I used FB's once, it took me four days to write a simple three cycle program.

Good luck and have fun.

SoftwareJanitor said:

LOL! Just started reading up a bit on Phase Manager. It appears Rockwell has this thing set up to encourage (force?) you to use it, otherwise you're signing up for manually replicating tags and logic between the Batch and Logic sides - even if you *still* use Rockwell Controllers! So there's more to it than just setting up the linkage between the two. It's probably best to build the structure *from* the Batch side, then synchronize the two to create the corresponding structure on the Logic side

Click to expand...

Right if you think you just connect the dots you are completely wrong. Phase manager aligns itself w/S88 concepts. FTBatch would tell the PLC which phase to run according to the recipe, the PLC tells FTBatch the status of the logic...'running', 'held', 'complete', 'abort'...etc. There are going to be tags that control the phase that link back to the batch system.

Of course S88 implementation is not obvious. Philosophical methods and standard terminology do not equate to pre-defined logic. It's like OSHA, they set requirements and standards, but don't necessarily tell you how to implement to achieve compliance.

I highly recommend bringing in an integrator to help you out there is a lot to consider on these systems and starting from absolute scratch is going to be a challenge.

My experience is with ControlLogix and WW InBatch, but concepts are all the same. I've seen many different interpretations of how to create an S88 type system, relying on collective experience will be in the best interest of the project and the only realistic way that you'll be able to focus on the "wow" factor.

John Morris:

Thanks for your input. Really appreciate it. Just a few questions, though:

1.) You say "the bit has to be toggled on before any maintenance functions can be performed". How does *not* toggling the bit stop the tech from just going out in the field and doing his thing? What does the bit do? I'd imagine it masks related alarms? Does it do anything else?

2.) You say you "make all the function buttons momentary so they can't leave one on and walk away". Do you mean you have a button for *each* I/O point? And do you mean each button is on a timer that self-releases (so it doesn't accidentally stay ON forever)? A momentary button would still need to be latched, otherwise it would only be active for a second or less, right?

And yeah - I've started opening those Rockwell PDFs, too, but I'm finding that they have loopholes in their descriptions of how instructions work. For example, I was reading up on the FOR instruction and didn't see any explanation of what happens to the index value once the block completes (ie: when does the value get reset? I'm assuming when the rung goes false, but it left me wondering if I'd have to manually reset it).

And yeah, Structured Text is my background. No Ladder Logic for me if I can avoid it.

===========
Paully's5.0:

It doesn't sound too bad, but the problem with anything new is it's like pulling teeth at first because it's your first time through. I'm guessing the logic in the Controller is still going to look pretty much the same (Batch or not), except now you'll have these new "overhead" data declarations to pass parameters *to* the PLC, and others to pass 'done' status *back* to the Batch program (so it can proceed to the next phase). I'm also guessing the functionality of these things are fairly automated so that the programmer just needs to remember to read and write these tags. The other 'trick' will be in setting up the initial framework so the two know how to work together, but that's not coding per-se, it's more higher-level system infrastructure layout (I think).

But, of course, I'll probably find I'm completely wrong (LOL!)

Not sure how this is going to turn out.

1.) You say "the bit has to be toggled on before any maintenance functions can be performed". How does *not* toggling the bit stop the tech from just going out in the field and doing his thing? What does the bit do? I'd imagine it masks related alarms? Does it do anything else?

Click to expand...

View attachment out put wash pump.zip

It's nothing that elaborate.

A single output could have several branches to it. The top line is the primary program command turn on the pump for a wash cycle. the second branch is the maintenance bit giving power to the HMI button that turns on the pump for maintenance. Third line is a standby routine, if the machine is idle too long it mixes the tank up to keep it from thermally stratifying.

The maintenance toggle bit is locked elsewhere in the program during a cycle. This unit is part of an automated system, and even to get to the maintenance page, the unit has to be put into local control. no it does nothing else but that.

2.) You say you "make all the function buttons momentary so they can't leave one on and walk away". Do you mean you have a button for *each* I/O point? And do you mean each button is on a timer that self-releases (so it doesn't accidentally stay ON forever)? A momentary button would still need to be latched, otherwise it would only be active for a second or less, right?

Click to expand...

I have a button for all outputs to be tested, yes. As long as the tech maintains contact with the button icon, it will maintain the "state1" condition. when he releases it will return to "state 0"


I'm not sure how all this can be translated into structured text.

John Morris:

I see, said the blind man (LOL!). Good idea with the momentary buttons. Hadn't thought of holding the key down (da!). I think they want touch panels with my project, but I assume the data entry method doesn't matter to implement that?

Not sure how that would be done in structured text, however. I would like to think you'd get an event for depressing the button, and another for releasing it, but I don't know if PLCs function like that. Have to look it up.

SoftwareJanitor said:

JKerekes:

That appears to be Rockwell's "scaled-down" Batch solution, which *might* be sufficient, but it sounds sort of limited, too. Less than 32 recipes? This came out *after* FactoryTalk Batch?

I think they want the server solution without any limitations. Probably overkill for this new 4-story, 15,000 sq. ft. standalone facility, but what do I know? It's all so preliminary right now. There's also been talk of adding a 2nd system later (likely), and up to 4 systems eventually. So that alone may rule out the Controller-based solution

MATT116:

Thanks for clarifying. Seems like Rockwell products are so many and so varied that clarification will always be needed...

Click to expand...

Sequence Manager is part of Logix. It's manages the execution of phases. It will be in the future be able to be controlled by Batch.