I am currently involved in a 'Soft-PLC' programming project where the 'owners' of the project are implementing the PLC code using a combination of the following 1131-3 programming languagues:
Ladder (LD)
Function Block Diagram (FBD)
Sequential Function Chart (SFC), &
Structured Text (ST)

There is a large use of user-defined function blocks to build up systems similar to an Object Oriented programming. Internal to these function blocks are a mix of SFC, LD and ST an C-code.

Additional to this, function blocks are also being used to read in parameters from text-based databases to set items such as timers (as opposed to hard-coding these inside the PLC code).
(Sounds like a nightmare I know)

Having dealt with only LD and SFC, I am interested in the views of other programmers out there who have dealt with PLC projects involving a mix of all of these languages. In particular how such a mix is viewed by maintenance/service personnel who may need to view/edit this code in the future.

 

Hi Michael,

I agree that such a mix of languages can be a headache for
maintenance/service people. However sometimes for some tasks some IEC languages are more suitable than others. There're many factors to be taken into consideration like (order is unintentional):
- type of task,
- speed/size of code,
- controller price,
- development time,
- preferences/knowledge of a programmer
- requirements of the customer, etc.

The only problem is to weight them carefully.
BTW, if maintenance people have to look into the program to see what's wrong with a machine it means that something is wrong with programmer(s) who wrote the program. In my opinion main task of control program is to diagnose the
state of a machine and being proof to all failures possible to detect. When it's done then there's a place for controlling.

Regards,

Jacek Dobrowolski, Ms. Sc. E. E.
Software Eng.

 

I would suggest that:

1. Most maint and service personnel will hate you if you put a lot of stuff in SFC or ST that could just as easily be done in LD. LD is much, much easier to debug problems on most running machines.

2. If you limit your SFC and ST to stuff that is not really oriented around the machine's basic sequence, and are careful to fully document it, you probably won't get many squawks.

3. As long as your function blocks are well desribed and actually worked, most people will be quite happy to use them. They are used to calling blocks from LD (timers, PID, etc.). The biggest problem I see with such things is they are often very poorly defined, badly described, and poorly tested. make sure that the blocks actually work the way they are described and make sure the description is complete. A lot of times programmers do not spend the few minutes to describe what it is they are doing and it can create major hassles down the road.

4. I would be inclined to encapsulate any ST I could inside function blocks.

 

There are two factors that you have to take into consideration:

1. The knowledge of the maintenance or PLC owner of the different 1131-3 languages.

2. The region of the world that the PLC will be utilized.

In Europe, a large portion of the maintenance technicians have basic knowledge of the different 1131-3 languages and how they are implemented. In North America, technicians have stuck with proprietary implementations of ladder logic, sequencial function charts and maybe function blocks if they had contact with DCS systems.

 

Most maintenance folks seem to prefer ladder logic to anything else. This from someone who is in maintenance and would prefer none of the above, but grudgingly admits that ladder is probably best for finding out why something isn't running, which is mostly what maintanance is interested in. I just finished consulting on some complex S5 STL, and I would prefer not to have to explain that to anyone who is not a programmer and _very_ keenly interested. :^)

Regards

cww

 

More than a nightmare I would say it is quite interesting.

We have got a project similar to yours where we are using ISaGRAF supporting all IEC 1131-3 languages with user functions programmed in C. We are mainly using ST and SFC but some easier programs are made in LD or FBD.

We are using your strategy for reading parameters from configuration files once and use these parameters through normal operation. If you want to change parameters then you simply change configuration file and reload the logic by setting one variable (no need to change and download PLC code). This requires a harder programming for the PLC since you are makind code much open but changes are easier as long as you have made programming well enough.

Our worse experience arised when we need to change some of the user defined functions in C that we were using through all our code. This really required a lot of patiente since we reviewed every call to the function to check there were no problem by changing function itself, but we succeded, we need to change very few programs that called the function.

ISaGRAF for this kind of thing is a very good tool since it provides you with Cross references and you are able also of tracking directly text files with the code.

Anyway our best tool was a log file with all the relevant information made by the code, this is a log file provided by our ISaGRAF kernel implementation. It reflected every database access and call to external function block so at last we were able of tracking the whole path.

Dig into your application and see how you can organize it and which tools it provides to you.

Good luck.

 

check out plcopen.org for info on IEC 61131 and the various languages

Cheers from: Jeremy Pollard, CET The Crazy Canuckian!
Integration and Automation Training, Consulting, and Software
http://www.tsuonline.com

Please note Address Change..............

3 Red Pine Court,
RR# 2 Shanty Bay
Ontario L0L 2L0
705.739.7155
Cell # 705.725.3579