Tips and Wisdom for a New Programmer?

Hey all,
thanks for having me, this place has been a most excellent resource. So I am new to programming after a few years of doing controls installation I was finally lucky enough to land a programming gig.
So far its going very smooth, the company I work with deals mainly in rockwell and siemens systems and designs modular fluid equipment, mainly for the paper and pulp industry.
I very much enjoy the challenge of always having something new to learn everyday, and am looking to be as valuable of an asset as possible. Im looking for any tidbits of wisdom or tips some of you vets might be willing to pass on to a youngin like myself.

Any good reading resources you would recommend?

Any organizational tips to keep from getting yourself lost when dealing with a large project?

Any absolute do-nots I should be aware of before making the mistake myself?

Any tips on streamlining the HMI creation with PLC program development?

Hey thanks a bunch, and excuse my newbness when I get stuck and ask dumb questions. chow


Brian

Any absolute do-nots I should be aware of before making the mistake myself?

Click to expand...

Don't use an "Examine if Open" instruction for a Normally Closed Stop pushubtton. Don't use two Output instructions that have the same address (the double-coil syndrome).

Thanks, Noted

Don't write "look what I can do!" programs.

What I mean by that is don't use "fancy" instructions for simple tasks. Just because you CAN write a complicated program with two rungs and a bunch of bit shifts and sequencers doesn't mean you SHOULD. That said, don't be afraid to use those instructions if you need to. But a lot of them are really just left in there for legacy reasons.

Remember, invariably other people are going to look at your program when the machine goes down. Ladder logic has a single purpose: to make complicated automation routines easy for non-programmers to read and troubleshoot. It doesn't behave EXACTLY like a hard wired system would, but in most cases it's close enough. It's designed so that a maintenance electrician can fire up a laptop, hook up, and see that Relay 5 isn't firing because Limit Switch 3 isn't made. Don't run contrary to that purpose.

Looking back at when I started programming, I think the biggest improvement I've made is writing logic in a style that is straightforward to understand and troubleshoot. Back then, I enjoyed (and still do) the challenge of machine control. But I tended to go overboard on making my programs as efficient as possible without much regard for the fact that, inevitably, someone else will have to work on it at some point in the future. After many instances of having to be that "someone" on other people's programs, I've come to realize that designing logic for maintenance accessibility and readability is of utmost concern.

I'm sure most of us have had those "what on EARTH was I thinking???" moments when we've gone back to work on some of our old/rookie programs.

brstilson said:

What I mean by that is don't use "fancy" instructions for simple tasks. Just because you CAN write a complicated program with two rungs and a bunch of bit shifts and sequencers doesn't mean you SHOULD.

Click to expand...

This made me chuckle. I had an embarrassing moment last week when I had to help one of our electricians troubleshoot a bad output on a program that I had written years ago. Basically, I had used an XOR to toggle the output with a bit mask, but he was frustrated (and rightfully so) because he couldn't locate the output with a Find All in RSLogix. It took me awhile just to figure out what I had done. I felt like one of those kids I remember from elementary school who couldn't read their own handwriting.

Shiro485 said:

Hey all,

Any absolute do-nots I should be aware of before making the mistake myself?

Click to expand...

Don't wait until the end to do comments. Fully comment the code as you write it, no matter what the deadline is. Sometimes it can help catch major mistakes early if you have to explain to yourself what you just wrote.

1) Don't tie up your sequence of operations so tightly that, if you need to insert an operation somewhere in the middle, any changes become a three-hour tour. A three-hour tour. (note the Gilligan reference. Something that should be easy turns into being marooned at the machine you're working on...)

2) Nearly all processes can be broken down into a lot of small process. Writing your program as a set of smaller processes will help you to streamline the overall process.

I tend to roll my own "sequencer", meaning that instead of one held rung triggering the next held rung, triggering the next..., I use an integer. Step 10 loads a part, step 20 clamps it in, and so on. Note that I will number my steps by 10, a throwback to BASIC days. This will let me:

• easily insert a process. Hence my first bit of advice.
• even if I'm looking at the top of my logic, I can zero in on where the process is currently.
• use the same integer to display process messages on the HMI

Not saying that all process can conform to it, but if it's something you can use, that's great!

brstilson said:

Don't write "look what I can do!" programs.

What I mean by that is don't use "fancy" instructions for simple tasks. Just because you CAN write a complicated program with two rungs and a bunch of bit shifts and sequencers doesn't mean you SHOULD. That said, don't be afraid to use those instructions if you need to. But a lot of them are really just left in there for legacy reasons.

Remember, invariably other people are going to look at your program when the machine goes down. Ladder logic has a single purpose: to make complicated automation routines easy for non-programmers to read and troubleshoot. It doesn't behave EXACTLY like a hard wired system would, but in most cases it's close enough. It's designed so that a maintenance electrician can fire up a laptop, hook up, and see that Relay 5 isn't firing because Limit Switch 3 isn't made. Don't run contrary to that purpose.

Click to expand...

Well said Sir.

Thank you so much for all the replies

Get to know the *habits* of your co-workers. Be careful in looking to be as valuable of an asset as possible.

I have consistently experienced the 'If you will, They will let you' mentality.
What I mean is that lazy people will let you HELP. Then they will let you DO IT. Then they will depend on you to do everything for them.
See where I am going with this?
Figure out WHERE to draw the line between HELPING and DOING.

He is my two cents.... keep in mind how your inputs interact with the program... I try to make sure that hitting a limit switch or other inputs will not cause any adverse effects. I can remember way back in the day some 35 years ago a co-worker programmed a press so when the down limit was met the operator could let go of the dual start push buttons... seemed like a good thought at the time until the operator hit the down limit loading a part.. the machine cycled....scared the operator and I learned a great lesson. Be safe and enjoy!!!!!

Then they will let you DO IT. Then they will depend on you to do everything for them.
See where I am going with this?

Click to expand...

I think you are going down the wrong attitude path. I always loved it when I worked up to where they depended on me to do everything for them. Then I knew who was going to get the biggest profit-sharing bonus at the end of the year, and the next raise, and the next promotion.

Lancie1 said:

I think you are going down the wrong attitude path. I always loved it when I worked up to where they depended on me to do everything for them. Then I knew who was going to get the biggest profit-sharing bonus at the end of the year, and the next raise, and the next promotion.

Click to expand...

I wholeheartedly agree. I can't wait till I get to that point.

IMHO Kwade and Lancie1 have good points.

You want to be the go to guy but you also don't want to be taken advantage of and in my experience it's a very fine line and has to be considered on a case by case basis.