Best programming practices

ganutenator · May 9, 2016

I'll start.
Name coils with their true state.
For example, if the photo eye is light operate, make the coil PE Clear.
That way, when you see the normally closed ref, you just read the normally closed contact as NOT the comment.

dogleg43 · May 10, 2016

Amen, amen, amen!

rollinstone · May 10, 2016

1 Code comments don't cost you so much
2 KISS - Keep it simple stupid

ganutenator · May 10, 2016

poor comment: this oneshot runs the timer for 5 seconds.
good comment: i put this timer in here to try and keep those kids from playing zz top.

gclshortt · May 10, 2016

rollinstone said:
1 Code comments don't cost you so much
2 KISS - Keep it simple stupid

KISS - Keep it Stupidly Simple

Code should read like a book. Show it to the people that are going to be troubleshooting the system. Use their terms for the devices and parts of the machine in your code.

J E · May 10, 2016

When making additions to a program, consider how your contribution will fit with the overall flow of the program.

Does the system already have 30 valves programmed a certain way and you are adding a new, similar valve? Mimic the existing programming unless there is a very good reason not to. Is all of the analog scaling done in function block and you usually write scaling in ladder? Put your new scaling in function block anyway.

This idea can also apply to tag naming, comments, subroutines, etc. It can be painful to troubleshoot a system with a program that has been worked on by many different people, all doing things their own way.

mk42 · May 10, 2016

ganutenator said:
poor comment: this oneshot runs the timer for 5 seconds.
good comment: i put this timer in here to try and keep those kids from playing zz top.

Agree with this. Having comments isn't useful unless they have a point. Most code is relatively straightforward in WHAT it does, the bigger question is WHY are we doing that.

padees · May 10, 2016

Seeing comments like "This is my work around" to an issue that could have been fixed quite easily sends chills up and down my spine. Why are you even doing this?

dogleg43 · May 10, 2016

A comment that irritates me is something like "Move data to XXX".

I can readily see that from the instructions. What I want to know is why was the data moved.

RussB · May 10, 2016

gclshortt said:
KISS - Keep it Stupidly Simple

Code should read like a book. Show it to the people that are going to be troubleshooting the system. Use their terms for the devices and parts of the machine in your code.

By using multiple simple rungs instead of one complex rung.

Modern PLCs have lots of RAM, Internals and speed.

Jeev · May 10, 2016

ganutenator said:
good comment: i put this timer in here to try and keep those kids from playing zz top.

She's got tags. She knows how to use them.

Geoff White · May 10, 2016

For the love of sanity -
Don't put multiple contacts before a one-shot
Expect any Set/Reset to get stuck in the wrong state and plan accordingly
If you send a signal to another piece of code have the recipient destroy it
Scan order matters

rollinstone · May 11, 2016

gclshortt said:
KISS - Keep it Stupidly Simple

Correct. My fault

Also - don't forget do remove your bypasses at the end of comissioning

PLC Pie Guy · May 11, 2016

I have many small snippets of code from one of our integrator projects that contains multiple bits called "do_not_forget". I guess he forgot!

AustralIan · May 11, 2016

If during coding you figure out that the design documentation is incorrect or doesn't match your implementation, UPDATE THE DESIGN DOCUMENTATION.

Have complete design documentation.

Best programming practices

ganutenator

Lifetime Supporting Member

dogleg43

Member

rollinstone

Member

ganutenator

Lifetime Supporting Member

gclshortt

Member

J E

Member

mk42

Lifetime Supporting Member

padees

Member

dogleg43

Member

RussB

Lifetime Supporting Member

Jeev

Member

Geoff White

Member

rollinstone

Member

PLC Pie Guy

Member

AustralIan

Member

Similar Topics