S7 vs ControlLogix

I am currently looking at upgrading some old S5 PLCs. The PLCs are used for machine control in a heavy industrial plant and are mostly used for discrete control (conveyors, solenoid valves, drives, etc.). All of them have multiple drops on a profibus network.

Although the 5s have been very reliable, I personally despise their programming software as compared to something like logix. I haven't had anything to do with S7s although I have heard it is much better.

Any comments on what I should do? I realize it would be much simpler to just replace my main racks with s7s and leave the profi, but I want to do what is going to be best in the long term. Also does anyone know if there is a way to convert an S5 program to an S7 program?

thanks

Hi,

While the ControlLogix and the S7 are powerful PLCs; the S5 is still a viable option. For better programming software look at Fastrak software (www.fast-soft.com). They have a useable version now and they are releasing a 32-bit .net version of S5 software in the next few months. For replacement parts contact www.vipa-usa.com. They make S5 compatible CPUs, I/O, Racks, Power supplies, etc. Siemens vendors do offer a service that converts code from the S5 to the S7, but of course, it is impossible to convert 100% of your code. There will need to be some percentage of manual conversion. Please post your decisions, it would be interesting to see how your decision-making process evolves.

I hope this helps,
Kevin

If you have a lot of old s5 spares lying around, get a S7 CPU and a Interface Module. Then you can connect a S7 CPU with the S5 I/O. You will have the full function of the S7 CPU (programming power etc) and slowly as the S5 cards blow you can fase them out by using S7/300 or 200 modules (you will have to replace a whole rack at a time).

[email protected]

Step 7 includes an S5 to S7 program converter. I have never used it, so I can't tell you how well it works. My only Siemens experience is with Step 7 and S7-300 plcs. I have never had any trouble with Step 7, and setting up a profibus network could not be easier. I have heard from people who have used both that the S7 software is much better than the S5 software.

Kevin

I suggest you visit the Siemens website http://www4.ad.siemens.de and go to entry ID 11429143. There you will find further information.

Regards,
Frank

Hello Scott,

Yes, there is a way to convert a S5 programm into S7 by a compiler within the Simatic S7 Manager. But You should be carefull and analyze the logic before and after a compilation. As long it is stright forward ladder logic, no problems. But if some mathematics is involved, it could be difficult to follow the result.
Also if You consider to use control logix, there is a PROFIBUS Master Module for the CLX system available. So You can connect the existing I/O installation to a new CLX. I think it is made by a Canadian company called Woodhead or similar name.

If You need more details, let me know.

Bernd Bauer

[email protected]

Yes, Step7 can convert S5 programs.

You can go with ControlLogix and keep your Profibus network, thanks to solutions from SST and ProLinx Gateways.

I think hardware costs will be pretty close. Obviously, it will cost a fortune to rewrite for Logix.

Try out Step7 and see if you like it any better than S5 or RSLogix.

I don't think there's an easy answer to which you should do.

-James Ingraham
Sage Automation, Inc.

Scott,

Been in this game a long time and have avoided Siemens for a long time, until I employed a good S7 programmer 3 yrs ago. Result? WOW. Step 7's integrated environment is totally different from any other, and in fact most people don't know how to utilise its power. We're now a Siemens Solution Provider as we've deliberately improved and leveraged our skill set. One thing you might not know is that ControLogix is only just emerging as IEC1131 compliant.

On another tangent there is a product called ProDef. Developed in Australia (we now use it extensively) and purchased by Invensys last year, code is developed in a GUI using device "templates", such as motors, valves, transmitters etc from a catalog. An SFC editor allows for sequence design. The great thing is that once finished, you can decide where to deploy - Step 7, RSLogix 500 or 5000, or Concept. Also supports InTouch, RSView and CiTect SCADAs. Finally truly re-usable code.

Rgds.
John

Take a look at the Modicon Quantum PLC line. The concept software is in my opinion much better than the Logix software. The quantum can support profibus networks so you could keep your I/O for now. Since Concept has all 5 IEC languages, you can pick the one of your choice (Ladder Logic (like the AB), Function Block Diagram, Structured Text (similiar to basic), Instruction List (similiar to the S7), and Sequential Function Chart). Its definitely worth a look.

S7 software is totaly different in approach (more object orientated).

What is long term (1 year or 10 years) 1 year stay with S5.

In theory you can convert S5 to S7 with limitations (like indirect adressing).

Eric

The big difference as I see it is two fold.

1. Siemens has a way of storing all your stuff in one place, in the S7 manager. This simplifies a lot of things. Its very handy to have your HMI configs, comm settings, PLC programs, and drive data all in one place where it can be easily backed up and accessed from one place. Of course this is only meaningful if you use all Siemens stuff (drives, HMI, PLC, etc). If you use multiple brands of stuff you lose this advantage.

2. The HUGE advantage is that the S7 PLC allows you to have user defined function blocks, something the contrologix platform badly needs, and AB shows no urgency in providing. User defined function blocks can significantly reduce both your development time and your debug time.

Anon---

Some clarifications:

All members of the Allen-Bradley Logix5000 family support Relay Ladder Logic, Function Block Diagram, Structured Text, and Sequential Function Chart programming.

Existing Profibus elements can be kept and interfaced through a gateway to a Logix processor.

Hope this helps!

Larry Lawver Rexel / Central Florida

However - AB does not support user defined function blocks (at least not yet) and that is enough reason to piuck something else that does (S7 or Quantum) in and of itself if there are no other considerations (such as legacy applications).

Bob Peterson

I'm not sure I agree with the sentiment, though it is technically accurate. You cannot write a routine, and then compile it into a function block to be called from a Function Block Diagram or ladder.

You can, however, seperate logic into routines, which can be called from Ladder or FBD or SFC. This is pretty much the equivalent of an FC or FB in Siemens.

-James Ingraham
Sage Automation, Inc.

Bob---

I have been arguing for UDFBs for two years, but they are still farther out on the schedule than I want. You and everyone else on the list can help this by mentioning it to their Rockwell reps...

Larry Lawver
Rexel / Central Florida

Absolutely NOT. While AB allows you to segregate code into seperate files, it does not allow you to write a function block that can be reused multiple places as a function block. User defined function blocks such as the S7 or the Quantum PLCs have, make a programmer's life much simpler both in programming and especially in testing. if you have not used them, you might not appreciate the huge advantage it gives you.

I think we're getting into a semantic battle here. AB does allow you to do more with files than "segregate code". The subroutine call can have one or more calling arguments (or not) and one or more return arguments (or not). I've written many CLX programs that call the same subroutine many times with different arguments each time (or with the equivalent of pointers). This may not be quite as elegant as a true function block, but it's close. My beef with CLX on this issue is that while you can create user defined data types and user defined code (any routine), UDT's cannot contain methods having to do with that type object, so they lack some of the functionality of true classes.

you can do it in logix ( in lad + ST at least )+ plc 5
but not with SLC 500 series....
rgds

The difference between real user defined function blocks and subroutines is not well appreciated until one has used them extensively.

I have also used subroutines in the manner you suggest, and its a workable thing, but can be a bit difficult to debug, and is certainly not real clear to the end user's techs just what is going on.

Steve Myres wrote:
>I've written many CLX programs that call the same subroutine
>many times with different arguments each time (or with the
equivalent of
>pointers). This may not be quite as elegant as a true function
block, but
>it's close.


I think you oversimplify. The arguments to a ControlLogix subroutine are passed by value (they are copied from their true location into a buffer local to the subroutine). A subroutine is not thread-safe; it cannot be used by more than one task. I once wrote a CLX program where the result of 1+1 was 3.

"I don't use multitasking" you may say. But a similar problem arise with variables that may be modified by communication. Example: Let's suppose variable SP may be modified by the operator (a setpoint for example). Let's suppose the same variable is an input and output parameter of a subroutine (to reset the setpoint under certain conditions). Let's suppose the subroutine is called frequently (under normal circumstances, the setpoint would not be affected; SP would be copied into the subroutine buffer and back into SP upon exit of the subroutine). If an operator change happened to occur while the subroutine is executing then the operator change would be lost. As I mentioned, ControlLogix subroutines are not thread-safe (and communication is a high-priority thread). The problem lies into the fact that subroutines do not use pointers.

Be careful with subroutines; intermittent problems are lurking behind. I'm scared by all those program examples where cyclical FB are calling shared subroutines. They are cans of worms. It's a shame that there is no warning in the documentation about this problem.

Gilles