Steps for writing a program

hello sir,

I have been writing small programs on ladder logic, but never wrote a complete industrial project from scratch.

I have the line diagram with me, the client has not given the complete sequence, I know without it program cannot start, but in the mean time what should I doo.

and once I get the sequence, how should I start writing the program

help needed, your support/help will be highly appreciated

thank you

regards

Zee

Hi,

It is advised to hire a programmer for one or two projects in starting, Later try developing programs by yourself with that experience. 

Sorry,I am sure that you won't like my answer, But that is the fact.

zzohaibhl

Why is anybody not replying.?

There are several discussions that handles similar themes that you are trying to convey. The trouble with your (emotional?) question is that it is not focussed on something specific and thus difficult to give answer to.

I suggest.. organise your thoughts into "headings" and focus your questions in this way. Remember we are "blind" to your situation.. you give us vision by what you describe to us.

You are welcome to follow my discussion at [LINK].

w

Hello zee;

What do you mean by "line diagram"? Electrical schematics for the process? A detailed sequence of operations?

If you have a basic uunderstanding of ladder logic, then maybe this document is not very useful. But please have a look and see if anything interesting can be found in it:

Basic Steps In PLC Programming | EEP

The most important (and delicate) aspect of programming a Siemens PLC is the program structure, learning to use FCs, FBs and DBs to optimize the development and implementation  of a program.

You must define "areas" or "sections" in your process that are repeatable, so you only have to program them once, in a general (non-specific) manner, either as a Function or a Function Block. This can be done for motors, pumps, fans, valves, instruments... Then you must learn to call these FCs and FBs with parameters, so that they can be used for a specific motor or valve.

This mode of programming is described in Chapter 3 ("Working out the Automation concept  ") of this basic manual:

Programming with step 7 v.5.5

I suggest you also go through the rest of the manual, it contains very necessary and pertinent information for your project.

DBs are user-configurable sections of memory that can be used to gather setpoints, process values... any information required by your program. They can be automatically linked with a Function Block (this is called an Instance DB), or used as a general-purpose memory area.

You will find a lot of help in the following modules:

Training modules and documents (use the links to Step 7 Classic, TIA PortaL, PCS 7, or Logo! for specialized training).

And also these links collected by our friend Khaled Ezzat could prove very useful:

Basic Training Tutorials

But if you are planning to program an application to control a process, and you want to do it professionally, I recommend you get some help for your first application. Much of what is required for this type of programming must be learned by experience, and it would be best to have someone with this experience guiding you through this. The learning curve can be very steep and difficult.

Hope this helps,

Daniel Chartier.

Thanks a lot, it was a great help. I will go through each and every tutorial and manual and get back when I will have any problem again

and yes by line diagram I mean electrical schematics

Dear  zzohaibhl,

 I do had the same problem while starting my programming , 1st ask the client for project sequence explanation with line diagram that u having now..we dont have any rule to start the sequence ..if had any sample program have a look in to it and u try creating the sequence from the very begining step of the process and try to simulate it ..u get an some idea to proceed further..or better be with any programmer to one or two sites and start doing it ,it gives good start...

Allow me to give you the benefit of my extensive experience.

I would suggest that you spend a good proportion of your time on the requirements and design specifications and not jump straight into the coding phase. Jumping straight into the coding phase can lead to a poor program implementation and possiblity of not meeting the requirements of the project, meaning re-work and patching of the code leading to a very ineffeicent solution, or even a total redesign at a later time which will cost you more time in the long run. You should be fully aware of what is required before you even contemplte writing one line of code. Time spent here will more than be recooped / rewarded later in the project due to smoother coding, better understanding of what is required and a much better finished project. If you fail to prepare, you had better be prepared to fail.

Firstly, capture your requirements. This should concentrate on the "what" and "why", not the "how" and "when". It should encapsulate what the program is excpected to do, without thinking of how it is to be achieved. For example: the program will take up to 20 real numbers and calculate the mean, mode and median of the data set. The specification can be a few sentences to many pages depending on the size / complexity of the project.

Secondly, decide how you are going to realise the functionality. The is the design specification. This goes into a lot of detail as to how the code will be designed to perform the required functions. This includes, the programming language, data structures, algorithms, formulas, block I/O's etc. When designing any user interfaces / block interfaces try to put yourself in the place of the user. Ask yourself what they would like to see. Time spend on this is rewarded by making the program easier to use and less difficult to write user documentation for. The easier it is to use will reduce the amount of support / questions you will get when the program is released on an ususpecting world.  It is permissible and probably inevitable that you will have to perform some code prototyping at this stage to give you an idea of what is possible and indentify any pitfalls before you commit to a particular design. E.g. test if it is possible to store the amount of data required for a large system. This will take the form of small test snippets of code to test particular concepts are acheivable.

Thirdly, you start to write the code. When writing code, I normally start by deciding block I/O variable names, program constants and structure. There are 2 methodologies for code design:-
a) Top down. This is where you write the main routine and then calls to any subrouties / FB/FC's, which you then write later. b) Bottom up. This is where you write the subroutines / FB/FC's and then write the main routine to call them. My personal favourite is bottom up.

Forthly, you need a test specification. This details the tests required to validate the code. This should be written using the requirements specification as a guide. The tests should test that the code meets the requirements laid out in the requirements specification. Do not fall into the trap of writing the test specification to test the code that you have written as that will completetly miss the point; If you write the tests by looking at the completed code, the tests could all pass, but sadly if the code is not wriiten to actually meets the requirements, the code will not be correct. Ideally, in a perfect world, the test specification should not be wriiten by the coder as there is a temptation to design the tests to simply test the code whereby someone who has no knowledge of the code will simply design the tests to meet the requirements. When designing the tests you should also try not to fall into the trap of assuming that some events "cannot happen". Where reasonabaly possible, you should test all possible events and outcomes. If you have a test for x > 50, you should test for values <50, >50 and exactly 50. Do not just test for what you expect; test for the unexpected too.

Lastly, is to write the user documentation. Again this is should ideally not be written by the programmer as they know the code too well and will make assumptions which can (and does) lead to poor / incomplete documentation. A person with no knowledge of the code will not fall into this trap.

I hope this is of some help. Good luck.

smiffy

Allow me to give you the benefit of my extensive experience...

smiffy - 5 stars are not enough to rate your entry. Thanks for the share.

hello mr Zzohaibhl,

perhaps try to start with the document that i attached

gr gerard