To all of you who write applicable comments:

Wish I could say "Your Welcome" but the reason why I comment the hell out of my programs is mostly for ME to remember why I did it that way. While I want my programs to be readable and usable for any tech to come in after me, I do it for pure selfish reasons.

I work on a lot of systems and every one is a little different that the last. Since the programs dont change much and I normally have learn a lot since I was last in the program, I need to know what I was thinking when I wrote it. :)
 
Me, training our new recruit on PLC's:


"Okay. First question for you: how much trouble do you think you will get into if I find you writing code without comments?"


New recruit, who turns out to be pretty bright:


"...well, I'm new to this, but I'm going to guess: a lot?"


Me:


"right on. As long as you comment every rung of code you write, you and I will get along just fine."




New recruit is a keeper.
 
I go along with Bullzi.

Every time I do something, or think of something for the future, and don't write it down thinking it is so obvious I will remember it later, I end up remembering there was something I wanted to remember, but never remember what it was.

Comment every line and change to any line

Describe every bit, counter, timer, integer, real number and all I/O - and not just an abbreviated symbol name
 
my boss and others told me to stop commenting my program rungs.
well, I wrote a 2400 line program for a 10 station machine and everyone loved it.
5 years later, I can barely understand it. Never again.

comment, comment, comment

james
 
I would just add that properly named variables go an awful long way in understanding code... not the overall sequence or process, but the nitty gritty of the implementation.
 
"right on. As long as you comment every rung of code you write, you and I will get along just fine."
Commenting for the sake of comments can be as useless as no comments. If a line consist of you adding a factor to a variable and your comment is "Multiply with 2.8", then you are not helping anyone.

So the purpose of comments should be exactly that: the purpose of the code. Not what you are doing, but why.
 
Commenting for the sake of comments can be as useless as no comments. If a line consist of you adding a factor to a variable and your comment is "Multiply with 2.8", then you are not helping anyone.

So the purpose of comments should be exactly that: the purpose of the code. Not what you are doing, but why.

+1

I don't need a comment on every rung, and I have no use for a comment that simply re-states what the instructions on the rung already tell me. Tell me why, give me perspective, if there is an abbreviated compute block, give the full formula from which it was derived. If you are doing something weird, write a paragraph or two, but otherwise short and sweet is fine.

Every address should have a description though.
 
I have learned that:
- I make things more complex than they need to be. But it's what I do. And the complicated solution is usually more a more flexible solution than the simple one.
- No one wants to read the book that I write on why I did this, or what else didn't work ... UNTIL THEY NEED TO CHANGE IT
- Brief comments for each rung or each group of rungs explain what the group does and how it fits into the rest of the program
- Write the EXHAUSTIVE comments on rungs at the end of the program or subroutine or AOI.
- THEN write the summary comment (Brief) described above, and reference the longer description at the end of the program. Sort of like footnotes?
 
- Write the EXHAUSTIVE comments on rungs at the end of the program or subroutine or AOI.
- THEN write the summary comment (Brief) described above, and reference the longer description at the end of the program. Sort of like footnotes?

I never thought of using a blank rung at the end to add detailed comments.
I will give it a go.
 
- Write the EXHAUSTIVE comments on rungs at the end of the program or subroutine or AOI.
- THEN write the summary comment (Brief) described above, and reference the longer description at the end of the program. Sort of like footnotes?

That is an interesting idea. You find that the end works better than the beginning just to avoid extra scrolling at the top of the program?
 
That is an interesting idea. You find that the end works better than the beginning just to avoid extra scrolling at the top of the program?

I have come across some programs where the comment on the first rung was so long that trying to see the rung itself was difficult - Windows kept jumping down to the next rung if the down arrow was pressed to read the next line of the comment or get to the actual rung.

I have cut the comment and pasted it on the END line of the ladder during online edits, and usually put it back when I am done and go to save.

Comments over 3 or 4 lines get too verbose, and seem to fill the ego of the programmer?
 

Similar Topics

I've gotten to the learning curve where I can program a call for pump to come on at set point but I'm not sure how to turn the same pump off when...
Replies
0
Views
19
Hi everyone, I am working on a project that needs to expose the SV (Set Value) of a temperature controller to a SCADA system. SCADA <-...
Replies
4
Views
134
Thank you for any and all responses/help. I have an RSLogix 5000 v20 and a Cognex In-Sight v5.9 spreadsheet (8502P). I can not figure out how to...
Replies
0
Views
101
Hello, This is my first exposure to CCW Micro8xx family. Someone will write to my existing micro850. Modbus TCP is turned on and I created a...
Replies
2
Views
131
When using System Platform, I can use the object viewer to directly manipulate attributes/tags/whatever. When I have a standalone InTouch...
Replies
11
Views
929
Back
Top Bottom