Control.com - Nerds in Control

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).

rayno.powell@larox.com

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

bbauerberk@aol.com

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

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.

I am not here to defend ControlLogix, in fact, my stance is "you may find a better product, but you won't pay more for it". I just want to clarify a flase statement. User defined function blocks can also be developed in C-Logix. It is called by a differnt name, but serves the same purpose. In C-Logic it is called an Add-On. No one does UDFB's as well as Giddings&Lewis. If you truly want a IEC16311 system with reusable code, check out what G&L has to offer.

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.

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.

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.

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.

Yes, I agree that it's not as clean as I would like, and suborutines used in this fashion can be difficult to debug, though I don't see why they should be any more difficult than UDBF's. I have been complaining to Rockwell about this for a while now, but I don't see it as an enormous issue.

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

Pointers to parameters can be passed if the data is structured correctly. Or, you could have the setpoint passed back from the routine in a scratch variable, and check for user changes before updating the setpoint (outside the subroutine).

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

Actually, you can do this in a SLC in a kind of kludgey, assembly language sort of way. For each reusable subroutine, define fixed memory locations for the arguments and returns. Load your live data into the predefined registers, call the JSR, and fetch the returns from the registers. This is obviously suitable only for subroutines with small lists of arguments and returns or the move time overhead will be prohibitive. It can be done a lot more efficiently if the data is structured suitably. Using the same method, pass a single pointer to data locations, and the subtorutine can work on the real data using indexed or indirect addressing. This eliminates all the MOV or COP statements.

That having been said, I freely admit that function blocks or subroutine calls that accept and return values (like in the CLX or TI505 PGTS command) are much better. Just pointing out what can be done.

Compilable function blocks also hold the potential for encapsulation of proprietary procedures without locking the user out of the whole program, which I see as a plus.

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

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