best programming practice

[santu2421991]

hi al..

i am a bigginer to plc programming..ladder logic

can anybody pls suggest the best programming practices using in industries..

 

[janner_10]

It like asking the best way to make a cake, but not telling anyone what cake you want to make.

 

[santu2421991]

sir,
i am using ladder diagram method to program a plc.
my query is that, what are all the things we should keep in mind to make program successfull??
step by step approach of programming in an industrial project?

 

[Geoff White]

1. Learn best industry practice
2. Program
3. Profit

For real - get hold of as many machine programs as you can and learn from them
There are different styles and frameworks for different PLCs and industries.

 

[santu2421991]

tq

 

[BobB]

At the end of the day all this programming practice is quite irrelevant - understanding the process/machine control is the most important thing to me. Then good programming practice comes into place.

 

[Paullys50]

At the end of the day all this programming practice is quite irrelevant - understanding the process/machine control is the most important thing to me. Then good programming practice comes into place.

Depends on the definition of "programming practice". Completely agree understanding what you are programming is extremely important. Disagree that good programming practice comes into place. I've seen a lot of code that "works" and does control the machine or process, but is by no means programmed with any "best practice".

OP, as others have said it's an open question. I ensure that my code is:
1. Modular
2. Structured
3. Follows good practices found in higher level languages: Naming Conventions, structured programming.
4. Tend to create code that aligns with S-88 concepts, regardless if it is for an S-88 system or not.
5. Design on paper first.
6. 50/50 code, 50% is already "standard" for every project, how I control motors/valves/analogs/sequencing/alarming...the only thing that changes from project to project is the amount of code required for the actual process, less project specific features.

Hard to quantify it all without going through an exercise to model an system.

 

[James Mcquade]

everyone has their own style of programming.

in my opinion this is how a program should be developed.
let's say you build machines for companies.
1. your customer contacts you and tells you what he wants.
2. you meet a week later and discuss how the machine is to operate.
3. you (the controls guy / programmer) write down how the machine operates in general terms.
4. repeat step 3 and this time determine what sensors, outputs, manual controls you need.
5. determine the plc to use and add 20% spares - you will always add something later.
6. write down in detail how the machine operates - this time the machine is dead. how to power the system on, e-stops , power on buttons, everything from start to finish.
7. get with the customer and explain how the machine operates in detail. change the operation based on the customers suggestions.
8. write the scope of the project and sequence of events and send to the customer for approval.

9. does the sequence match up with the plc I/o?
10. write the code based on you sequence of events.

I know that you are a beginner, but asking a lot of questions up front before the project starts saves lots of heartache later on.

Documentation, documentation, documentation !!!
you write a program today, and a year later you have to modify it, with little or no documentation, you must relearn the program.

get with maintenance, what is their capabilities? what do they like and dislike?
work with them, don't throw a machine at them, they are the ones who have to fix it! they are your best friends AND your worst enemies!!!

if you throw a program at them, they will hate the program and the machine will never run the way it's supposed to. BUT, if you work with them and train them, they will bend over backwards to fix the problem.

regards,
james

 

[proof]

1) The code should be written to make maintaining the system easy at the expense of making programming easy.
A) All tags used in the program should be commented describing the purpose of the tag.
B) Code should have comment describing the purpose of the logic.
B) The programmer should NEVER EVER create a tag alias.
C) I/O should not be directly referenced by HMI's, but use a copy of the tag.
D) Faults and trips should be captured and displayed to the operator until they are acknowledged.
E) Use standard naming conventions for the project.
For example use tag that correspond to P&ID loop number like T5100 or use tags that are short be somewhat descriptive, L5BrnrTemp for line 5 dryer burner temperature, but whatever is chosen, stick with it.
F) Do not code to save using memory at the expense of complicating the code.
G) Data transfers from other systems should be Read from not writes to, and these tags should have comments indicating the foreign source of the values.
H) Always save your code before downloading to the PLC.

 

[ryangriggs]

Can you add clarification for point 'G' below? Why always read, not write? Is this to make the program easier to understand later? (I.e. where did this value come from???)

In a telemetry scenario, wouldn't it be more efficient (i.e. less bandwidth used) to write values to the master only when the values change, rather than repetitive read polling?

1) The code should be written to make maintaining the system easy at the expense of making programming easy.
A) All tags used in the program should be commented describing the purpose of the tag.
B) Code should have comment describing the purpose of the logic.
B) The programmer should NEVER EVER create a tag alias.
C) I/O should not be directly referenced by HMI's, but use a copy of the tag.
D) Faults and trips should be captured and displayed to the operator until they are acknowledged.
E) Use standard naming conventions for the project.
For example use tag that correspond to P&ID loop number like T5100 or use tags that are short be somewhat descriptive, L5BrnrTemp for line 5 dryer burner temperature, but whatever is chosen, stick with it.
F) Do not code to save using memory at the expense of complicating the code.
G) Data transfers from other systems should be Read from not writes to, and these tags should have comments indicating the foreign source of the values.
H) Always save your code before downloading to the PLC.

 

[proof]

Can you add clarification for point 'G' below? Why always read, not write? Is this to make the program easier to understand later? (I.e. where did this value come from???)

In a telemetry scenario, wouldn't it be more efficient (i.e. less bandwidth used) to write values to the master only when the values change, rather than repetitive read polling?

If you see a tag and need to know more about it, say its scaling or what not, you may need to follow it back to its source. If the tag is read from a different PLC, you can use cross reference and searches to find the code that is reading tag and then see where it comes from. Then you know where to go next to trace the tag back to its source. But if it is being written to the PLC, a cross reference or search shows nothing. You'll need to take your best guesses and check those sources to see if they are writing anything.

It the code and tags are well commented, it is not as big of a deal, but then again, "best practices" would be to read the data AND have the comments. In your example, in a bandwidth limited system, communication efficiency may be a good reason to make an exception.

 

[robertmee]

If you see a tag and need to know more about it, say its scaling or what not, you may need to follow it back to its source. If the tag is read from a different PLC, you can use cross reference and searches to find the code that is reading tag and then see where it comes from. Then you know where to go next to trace the tag back to its source. But if it is being written to the PLC, a cross reference or search shows nothing. You'll need to take your best guesses and check those sources to see if they are writing anything.

It the code and tags are well commented, it is not as big of a deal, but then again, "best practices" would be to read the data AND have the comments. In your example, in a bandwidth limited system, communication efficiency may be a good reason to make an exception.

Writing to PLCs is always a No-No for me. One typo of the wrong path or register, and you could adversely affect the target PLC...And troubleshooting it is a nightmare. Consider the scenario of 10 PLC's on a network. Suddenly PLC 8 starts to **** out. You check the logic and all looks sound in PLC 8. After a week of pulling your hair, you finally notice that some register in PLC 8 has a value that it couldn't possibly have from your logic. Now you have to track down 9 other PLC's to see who could possibly be writing to this #8 PLC. If you always READ, then you've limited the error to the one PLC you're working in.

 

[gclshortt]

These five steps will help you in your PLC programming.

1 - Define the task
2 - Define the inputs and outputs
3 - Develop a logical sequence of operation
4 - Develop the PLC program
5 - Test the program

The five steps form the basis of all PLC development. You will notice that the actual programming does not occur until the second last step. Usually more time is spent on understanding the task and sequence of operation.
http://accautomation.ca/five-steps-to-plc-program-development/

Regards,

 

[ryangriggs]

I'm working with a system right now which has a master PLC at the main office, and several remotes connected by serial radio. This master PLC reads all the remotes, then writes pertinent data to the remotes which need it. The master is the only PLC that performs any reading or writing in the entire setup.

Would it be better to configure each remote to read the master? This can get a bit hairy when you don't want radios to step on each other (read/write at the same time).

 

[dwoodlock]

Establish a structure that makes sense and then adhere to that structure throughout the program.

Break the program into sections that are relatable to real world sections.

Keep your spaghetti in the kitchen.