The Perfect Plant?

D

Thread Starter

Darren Farnworth

If I have to go with AB for a multiple plant layout, what would be my ultimate plant in terms of options available today? Do I head straight for ControlLogix and host all my separate PLC's in one panel? Do I head down the road of thin clients or do fat clients still hold the simplicity key? There are so many options available today I am not sure where to turn and for what advantage. So far I am thinking of DeviceNet to slc 5/05's, hooked up via Ethernet to thin clients running WonderWare. Should I be considering ControlLogix now? Is that the way forward? Can anybody shed any light on this? Is my dinner really getting cold? Guess I better go! Thanx for any input or oppinions you may have.
 
S

Sam Stratton

Are Your plants connected with a Wide Area Network(WAN)? If so, then you would choose some form of an Ethernet processor such as the 5/05 or a Control Logix configuration with an Ethernet module. As far as Wonderware goes, the clients may be thin but the server to support them will be extremely fat. Take a look at RSView32 with it's active display client/server add on.
 
W

Walt Flannagan

We have both the 5/05 and the Control Logix in our lab. Both really cool but the Control Logix is just too sweet to pass up. It interfaces with Device Net super easy which is good cause I have a short attention span. We can't deny Cimplicity as our HMI of choice but whatever, RSView 32 has clout, Wonderware has been pretty easy to interface to it. If I was your integrator I would drop on all fours and beg for Control Logix and Device Net. Just my 2 cents.

 
What your dream configuration could be will probably depend on your plant's operation, speed required in processing, your budget and what do you want out of the system. The Controllogix platform opens a lot of doors - either to connect to your SLC's (5/04's) or to process the info directly. Do you need redundancy? Anyway there are too many variables with no info to really discuss anything of significance. If you wish to sound ideas back and forth I would be up for discussion. I recently finished a packaging system using Controllogix 5550's, SLC 5/04's, Panelviews, RSView32 and Devicenet(comm with VFD's). If you want to e-mail at [email protected]
 
E

Eduardo Manuel C. Cipriano

Hi

My suggestion is go over with the Contrologix and Rsview32 instead of wonderware

We have inplemented a lot of Contrologix and Rsview project here in Nestle Philippines and Lafarge Cement the architecture is perfect..........

But if your process is very critical try using our DCS of Yokogawa

if you have any problem email me at
[email protected]

Eduardo Manuel C. Cipriano
Sr. Systems Engr.
Yokogawa Phils. Inc.
 
Darren:

ControlLogix, from what I've seen is not a bad way to go - ControlLogix/FlexLogix gives you the ability to remove and insert I/O under power, if that helps any - Costs another $100/module on average than more traditional I/O. If removal/insert under power isn't needed, the
CompactLogix (same family) uses Micrologix I/O, which is quite a bit cheaper than ControlLogix/FlexLogix I/O. You'd have to wait 'till next year sometime before CompactLogix comes out with an Ethernet port, though. Of
course, your AB rep can tell you all this.

Programming Logix5000 has some neat features not in the SLC500:
- User-definable types.
- Can pass parameters in/out of subroutines (except bits - they need to get packed into words, or UDTs)
- No fixed register addresses unless you need them - all points are tagname based. Removes the tedious task of developing and maintaining
register/tagname mapping tables in HMI, programming software, and local operator stations (panelview)

Good luck
 
T

Timothy P. Heckman

If you like the idea of DeviceNet I/O, then why not look into using the PC-based programming engine Steeplechase. It is a solid control engine
with flow chart based programming and you get the added advantage of having your MMI and control engine on the same box, e.g. - common tagname database, no extra software, etc.

Tim Heckman
[email protected]
 
R

Robert Burgman

Have you considered ProcessLogix from Allen Bradley?

Do not underestimate the significant manpower reduction in the support of a true plant wide
control system that a single database DCS offers.

You can kiss the file to file interprocessor communications, the need to change zero and
span information in multiple PLC databases and HMI databases, the need to worry about
0-4095, 0-16384, floating point verses integer, etc. good-bye. No need for redundant HMI
SCADA nodes and the like.

In addition, you'll have concurrent engineering capability. Multiple users working on
multiple controllers and multiple graphics screens all at the same time - on one single
database that looks after all system wide updates for you. Change an item in one
controller and all other equipment that references that item are updated automatically.

In addition, the redundant highway permits on-line addition or removal of controllers and
consoles without disrupting other processes. Also, you won't be limited in your choice of
programming languages.

I think the answer to your question is Honeywell's Plantscape, which uses AB hardware.
 
T
Why do you have to go with AB? There are so many better manufacturers to choose from. Have
you considered an Open Automation solution using an embedded controller with rack I/O that
programs with products such as Entivity's Think & Do or Isagraph. There are a few brands
available with ethernet on the processor module and then you could use the rack I/O along
with any Byte or bit level I/O networks such as DeviceNet,Profibus,Slink, and SDS. An Open
Control system also free's you up to use anyone's AC Drives, Servo's,Steppers, and Vision
that you want. You can use anyones Operator Interface that supports Modubus, and you could
use a real powerful Scada/HMI package like Iconics or Citech instead of RSView. It will
cost you a whole lot less, and it will give you a much more open and powerful facility.

If you have any questions feel free to contact me.

 
G

Gary Majkowski

My plant has RS-View, Wonderware, Control Logix and PLC-5's. We asked WW about switching one area of the plant from 21 thick clients to thin clients, the answer was; Buy a new full price thin client license for each HMI.
Thankyouverymuch.
The perfect plant gets it's control and HMI systems from a single reputable vendor because from start up to decomissioning your plant is nearly immune from control related system dysfunction, i.e. Your problem becomes their
problem. My experience with Rockwell on the phone and on the web has been outstanding. You can get expert application engineering when (and if) you need it from people who know how it's all supposed to work together. All these things make a system cost less to own.
You can't appreciate a Control Logix processor until you've installed and comissioned one. It is an incredible value. Don't omit the function block diagramming option if you've got any amount of non-discrete control, and check out the the FlexLogic option if you've got remote I/O.
Good Luck!
 
I am currently implementing a sytem with 5/05 processors interfacing to ONSPEC. I have been using ONSPEC for a number of years and like its
ease of programming and robust power for alarming and historical data collection.

Tim Rich, MCP
 
Have you tried the Think & Do route. It can communicate with multiple vendor types and do report to ERP system. It also has SQL faclities.
Another system you could look at is the distributed I/O using Ethernet IO.

The logic is written in flow chart, so making it easier to write and to debug.
 
R

Rob Hulsebos Philips CFT

>> The logic is written in flow chart, so making it easier to write and
>> to debug.
>How... *sixties*...
>Surely the Perfect Plant would use more advanced programming
>techniques?

Well, in an age where many a PLC-programmer still
works assembly-like, flowchart programming is quite advanced... and beyond that, a structured programming language like ST (Structured Text) in IEC-61131/3 is quite new too. I recall that when I worked for a company that introduced IEC 61131/3 in this country, we had a lot of explaining to do about 'if/then/else' and 'while' etc. constructions. And this was just 5 years ago.

Anyway, the industrial automation sw community is
lagging behind. In other areas we are doing OO, component technology and beyond. I have seen some companies attempting to introduce OO-like concepts, but don't have the impression that this is going very fast...

Rob
 
D

David McGilvray

Lagging behind!! OO (object orientation), while a very useful and effective technology, seems to be widely misunderstood in the industrial automation market. I have reviewed a number of products that claim to feature object orientation that clearly don't (based on the conventional definition). Generally, it seems, the existence of a library of useful pictures for HMI is sufficient to claim OO.

Briefly, an object is the marriage of code (functions) and data into a single indivisible thing. A number of concepts and key advantages from OO are the following:

Concepts
1. encapsulation: functions remain "private" while user friendly public interface provided to user. 2. class: generic container of functions and data. Build once use many times as defined objects. 3. inheritance: object inherits data and functions from class. Build once, implement many times. Advantages 1. Increase development speed: build once, implement many times 2. Fewer bugs: fewer lines of code (fewer functions) since building once and using many times. 3. Lower maintenance cost: fewer bugs, less code to maintain, easier change implementation (make change once, changes inherited by all affected objects). 4. Greater functionality: Since developed once, increased functionality easier, cheaper and therefore more likely.

For more detail, the web is a rich resource. One nice introduction I found is "http://catalog.com/softinfo/objects.html":http://catalog.com/softinfo/objects.html .

David McGilvray
automationX
www.mnrcan.com
 
R

Rob Hulsebos Philips CFT

>OO (object orientation), while a very useful and effective technology,
>seems to be widely misunderstood in the industrial automation market.
>I have reviewed a number of products that claim to feature object
>orientation that clearly don't (based on the conventional definition).
>Generally, it seems, the existence of a library of useful pictures for
>HMI is sufficient to claim OO.

>Briefly, an object is the marriage of code (functions) and data into a
>single indivisible thing. A number of concepts and key advantages from
>OO are the following:

Although the list below is familiar, to many people it is unclear how OO differs here from 'conventional' programming languages (like C, Pascal) and IEC-61131 languages (like functionblocks). For example, in a conventional C library I can also encapsulate, and I can re-use a library as many times as I want too. I found that in discussions with OO-proponents the discussion usually quickly stops and that I can't get any deeper explanation of the advantages of OO in comparison with current traditional programming techniques.

Because the OO community does not get this clear, the OO
is seen as just mumbo-jumbo because "structured programming languages" claim the same (although perhaps using different wording). Same is true for design patterns: one collegue of mine just called it "experience". The design pattern one most often sees is the "singleton", and the well-known Gamma book only explains one of the many possible singleton patterns - not the one that is encountered in machine building.

Take re-use - many companies have >90% re-use without OO. Especially when you're in the business of selling products, who may have several releases during years to come, one never starts from scratch. Perhaps 5% of the source-code is modified, 5% thrown out and replaced by something new, and the other 90% remains unchanged. I even once worked for a company which had a source-deck of 5 million lines of code, copied/pasted it to another directory and made modifications for a new productline, and claimed some 75% re-use. All this just plain C, no OO.

Only inheritance is a concept that it unique to OO, but it is usually so badly explained that I guess most people don't understand it fully for several years after being introduced to it. For my job, machine building, it does not often occur that one machine has the same hardware as the previous one, and usually is has a completely different product to make. So there is not much inheritance here as there is not much in common from which I can inherit. Re-use is possible in the generic (machine-independent) parts of course.

>Concepts
>1. encapsulation: functions remain "private" while user friendly
>public interface provided to user. 2. class: generic container of
>functions and data. Build once use many times as defined objects.
>3. inheritance: object inherits data and functions from class. Build once,
>implement many times.

Rob Hulsebos
 
C
I agree that OO is oversold for small software projects. I also can envision situations where it should be manditory. I simply don't do those classes of programming lately. It depends a lot on what you are building. After the first 50 end-all fads you gain some perspective. CASE, OO, Structured Programming, etc. they all fit someplace. SP is just the most universal. All programming needs structure. (except for this quick hack I'm working on) ;^) I've been saved so many times now.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
> >Briefly, an object is the marriage of code (functions) and data into
> >a single indivisible thing. A number of concepts and key advantages
> >from OO are the following:

Rob Hulsebos:
> Although the list below is familiar, to many people it is unclear how
> OO differs here from 'conventional' programming languages (like C,
> Pascal) and IEC-61131 languages (like functionblocks). For example, in
> a conventional C library I can also encapsulate, and I can re-use a
> library as many times as I want too.

- In OO, you can designate some (or all) fields of a struct as `private',
and this is enforced by the compiler. Access is then through the
functions of the library, which means that you can change how the data is
stored without affecting the rest of the program.

- Polymorphism - avoids printf-style hacks. You can say foo.print() or
print(foo), depending on the language, and the correct print() function
will be called, depending on what kind of thing foo is.

> I even once worked for a company which had a source-deck of 5 million
> lines of code, copied/pasted it to another directory and made
> modifications for a new productline, and claimed some 75% re-use. All
> this just plain C, no OO.

The disadvantage (and advantage) of this is that there are now two copies of that code. If an improvement is to be made to it (or a bug is found) it must be made in two places - or however many there are.

This can be done, of course, but your version management system better be good...

(Obviously, the OO way has its own version management concerns.)

> For my job, machine building, it does not often occur that one machine
> has the same hardware as the previous one, and usually is has a
> completely different product to make. So there is not much inheritance
> here as there is not much in common from which I can inherit. Re-use
> is possible in the generic (machine-independent) parts of course.

There might also be re-usable subsystems - an electric motor with a pair of limit switches, for instance.

Re-use depends greatly on the quality of the original design - if the design is poor, not much will be in a shape to be re-used.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 
R

Richard Higginbotham

>>Briefly, an object is the marriage of code (functions) and data into a
>>single indivisible thing. A number of concepts and key advantages
>>from OO are the following:
>Although the list below is familiar, to many people it is unclear how
>OO differs here from 'conventional' programming languages (like C,
>Pascal) and IEC-61131 languages (like functionblocks). For example, in
>a conventional C library I can also encapsulate, and I can re-use a
>library as many times as I want too. I found that in discussions with
>OO-proponents the discussion usually quickly stops and that I can't get
>any deeper explanation of the advantages of OO in comparison with
>current traditional programming techniques.

IMHO, its simply a way of looking at a particular problem(s) and possible solutions and the tools that help you do that. The idea is that if something is easier to understand conceptually and the programing language takes into account a more intuitive way of describing systems, then it takes less time to implement it and you have a greater potiential to reuse code. Theres no guarentee here (like everything else, its heavily base on the implementors ie. us) and it can be done without OO languages. OO is a conceptual approach, and OO language just seek to enable/enhance using that approach. You can use OO to design a solution and then implement in C or any language. I do it all the time with APT.

One advantage of OO languages is that they (more intuitively) limit your scope. By that I mean they encourage you to put things into smaller and smaller "objects", so that at a particular point in time you should only be concerned with a small(er) amount of code, one or two objects say. You can do this in just about any language mind you (limit your scope) using comments and clearly organizing your code into managable chunks, its just more convenient to use one (language) that helps you out.

Having said all that does it make much of a difference with a small project, probably not. The bigger the probject the bigger the OO *conceptualizing* advantage becomes. And just because you use a OO language doesn't mean your going to see any difference, you might even be worse off (if you just don't "get it"). Being more of a conceptual methodology, it doesn't matter if you use C++ over C or Python (which rocks, btw) over Pearl.. I think that creates the most confusion. People are more interested in the "buzzword" than spending the time to think about how best to describe systems with code/solve problems/etc. Then they rant, "its OO, its just better". Its no more valid an argument that using C (etc.) because "its what i've always used and I don't need that new crap". Its like having different cliche in high school. Silly.

> I even once worked for a company which
>had a source-deck of 5 million lines of code, copied/pasted it to
>another directory and made modifications for a new productline, and
>claimed some 75% re-use. All this just plain C, no OO

For all that matters, it could have been assembly or even machine code. Copy paste, copy paste, change names. I've reused 90% of my code, now if I could just get it to work.... ;)

>Only inheritance is a concept that it unique to OO, but it is usually
>so badly explained that I guess most people don't understand it fully
>for several years after being introduced to it.

Never had any problems with it and I'm a Chem E self taut programmer. But again, inheritance is just a programming language feature. If you don't understand the conceptual pieces, its not going to help you.

Richard Higginbotham


 
M

Michael Griffin

At 08:48 10/12/01 +0100, Rob Hulsebos wrote:
<clip>
>Although the list below is familiar, to many people it is unclear how
>OO differs here from 'conventional' programming languages (like C,
>Pascal) and IEC-61131 languages (like functionblocks). For example, in
>a conventional C library I can also encapsulate, and I can re-use a
>library as many times as I want too. I found that in discussions with
>OO-proponents the discussion usually quickly stops and that I can't get
>any deeper explanation of the advantages of OO in comparison with
>current traditional programming techniques.
<clip>

I think this question has been addressed in previous replies, but I thought I would put a different slant on things. I agree with you that most discussions of object oriented (OO) programming are obscure and loaded with excessive and unecessary jargon. You can use object oriented techniques in many conventional languages. Languages with object oriented features simply make this more convenient and easy to use.

My own view of O-O is that it provides a means of packaging data structures in with the code that uses it in a manner that allows you to share the data, but to still control access to these data structures. This makes it easier to not just make your program design more modular, but to make sure it *stays* that way. If access to the data is controlled via carefully designed access methods, you can be sure that nobody is using the data in ways which were not part of the design intent.
The advantages to this come not only from code re-use, but also in ensuring that program modules are used in the intended manner within the project they were created for. I found by experience that writing a 10,000 line program requires a different approach than writing a 1,000 line program. Even if you write all the code yourself, by the time you are half way through the project you cannot be sure you understand the original design intent of the earlier modules. If you can enforce access rules (even enforce them upon yourself), there is less likelyhood of difficult to find bugs creeping into your program.


>Only inheritance is a concept that it unique to OO, but it is usually
>so badly explained that I guess most people don't understand it fully
>for several years after being introduced to it.

I haven't seen many people actually taking advantage of inheritance in code that they write themselves. It takes careful planning and experience to design a class whose properties can be usefully inheritanced. Inheritance though, isn't the central point of O-O. The key point is the encapsulation of data with code.
The original object oriented languages were designed to solve a general software problem. At about the same time as these were being created, there were other people working on the same problem but using a different approach. For example, Modula-2 (which evolved from Pascal) included a feature called "opaque types" which addressed the data encapsulation problem in a different (and simpler) way, but didn't include inheritance.

>For my job, machine building, it does not often occur that one machine
>has the same hardware as the previous one, and usually is has a
>completely different product to make. So there is not much inheritance
>here as there is not much in common from which I can inherit. Re-use is
>possible in the generic (machine-independent) parts of course.

I don't see much use for an "object oriented ladder logic" language. Typical machine control programs are written at such a high level that the advantages of object oriented methods are less tangible. A timer function (or "class", if you will) is already an inherent part of a typical PLC system.
However, if you were writing large computer programs for test equipment using conventional programming languages, you may find O-O a useful approach to making your program modular. Well written computer code is usually by its nature re-usable regardless of the methods used, but code re-use shouldn't be the sole criteria by which object oriented methods are judged.

I also think that some of the negative opinions many people have of O-O techniques comes from the fact that their sole exposure to it has been with C++ and Visual Basic. Both of these are poor programming languages with rag-bags of features which accumulated over the years. Tacking on O-O features to them has not improved them much.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
Top