Writing Ladder Code

Hi ,

I am sure this has been addressed on this site already. I would like to ask the senior members for advice on how they write programs. I am looking for a structured approach and suggestions. When you get into writing new programs beyond the basic machine and starting from scratch how do you break the programming up into routines. Do you follow a sequence? Do you take similar programs and re-invent or paste in working code? Any links, examples or sites you would recommend for this. I use Rockwell software.
Is there such a thing as automatic code developer for ladder logic or do integrators employ their own style to each application?

I would like to help, but as i dont consider myself senior i think i'll pass and wait for the others

/shrug. To each their own.
I start by breaking the line down into functional sections, including every individual machine section. Then I add in Safeties and interlocks, then an overall line control section.

I also create very re-usable UDT's, and NEVER use I/O Directly in the program. I have seperate routines to scan in physical inputs, and then to update physical outputs. That lets me develop the code, and HMI's, and test quite a bit, without ever having to actually know the I/O assignments.

ALL units in the program are in actual engineering units, I handle any scaling between raw and engineering 'behind the scenes'.

I suppose I have other individual tricks, but those give a gross overview of my style.

Oh, for Logix, I name each routine "_nnn_Mach_Section", with the _nnn being numbers from 000 to 999, often skipping by 10's or 100's, to keep the program logic in machine logical order. Otherwise, Logix wants to alphabetize the logic, which is generally not what I desire.

First you need to define the problem

Derick123 said:

Hi ,

I am sure this has been addressed on this site already. I would like to ask the senior members for advice on how they write programs. I am looking for a structured approach and suggestions.

Click to expand...

So many people that ask questions here don't really understand what they are trying to do.

When you get into writing new programs beyond the basic machine and starting from scratch how do you break the programming up into routines.

Click to expand...

By steps or what they do.

Do you follow a sequence?

Click to expand...

That is the case in machine control. Do something, wait for some event before going to the next step. Do something else and wait for the condition to go to the next step. This should all be done in a flow chart before you start. The flow chart can be in your head but you still need to think of all the ways you can enter and exit each step.

Do you take similar programs and re-invent or paste in working code?

Click to expand...

Yes, whenever possible but I usually put the extra effort into writing reusable modules unless speed is the most critical thing.

Is there such a thing as automatic code developer for ladder logic or do integrators employ their own style to each application?

Click to expand...

I don't know of any. If you are good you will survive long enough to gain the experience needed to pretty much know what needs to be done immediately. You will think about how to exit a step when the estop button is hit, or how you can restart the machine without turning parts in the machine into scrap.

Programs

It really depends on the company. Some want all motor control in one sub then all "signals" ie vibration, current, oil or lube temps in another. Many use one control subroutine for all motors, then interlocks and monitor logic
ie) speed, temp, lube temp, bearing temp, current, etc in a process sub. Also it depends on if you are using program tags or memory addresses. The engineer or EIT on the project will make these decisions. Some will ask you for input, and some will just tell you what they want.....

I do the same, break things apart. I have some program sections that are 2 rungs long, simply because it is different equipment, and the ladder section is labelled thusly, and easy to find.

There are two things to consider:

1. avoid SPAGHETTI
2. Notes. Notes. Notes.

Everything else is mainly details. If you can write a program that works, you haven't done half bad. There is no hard and fast "programming" rule... even though I have seen some that works and makes me cringe...

Thanks to all who replied. I appreciate your input. I found the response from rdrast useful thanks!

Peter Natchwey, your initial response was off track but I did find the rest of your reply helpful, thank you. I know what I want to ask but there did not seem to be a single thread directed towards it on this site so I was asking a general question(s) about specific programming styles used by professionals. I am interested in how PLC programmers think and what knowledge and skills they could share. I am well past the basics and have now be assigned to program my own applications. I have over the years been very impressed by the organization, sequencing, thought process and logic that has gone in several PLC programs from machines I worked on and I have wanted to know the thought process that goes into a "beyond the basics" application. This website seemed to be the right site to ask PLC programmers how they approach an application. Thank you to all who replied. I appreciated your input!

I'll stand by that statement.

Derick123 said:

Peter Natchwey, your initial response was off track

Click to expand...

I assume you are complaining my statement about too many that post problems here don't understand the problem.

Do you want me to find some examples?

Defining and understanding the problem is the first step, the strategic thinking. Writing ladder code is just tactics.

Hi Peter,

If you examples of ladder code I am interested. If you want to show me examples of people that don't understand the problem that is fine I am sure you are right and I will work on asking more accurate questions. Thanks

No need to stand by your statement

It is to bad that some people in here think they are above and beyond the people that use this forum as a learning tool. If everyone understood the questions they were asking then we would not have any questions. Guess the coffee sucked this morning or they didn't get any last night.

Just my opinion !!!!!!!!!!!

Derick123 and JasSha

I think you both missed the point.

Title: First you need to define the problem

First Statement: So many people that ask questions here don't really understand what they are trying to do.

It's not an insult directed at Derick123. Which is how I think you took it. It's simply pointing out that the first step in a project is defining the problem and that a lot of people who ask questions here skip right past it.

Maybe you'll understand his response better now.

Mellis

Maybe I misunderstood what the response was. To me it seemed pretty obvious that he was asking for methods and opinions on how to go about writing a program from scratch. I know that I don't use the same method as everyone else does. Myself I prefer the step method as described by Peter. My point was that he is learning. I don't think in this situation he actually had a problem and was looking for advise.

OK, one more attempt, then I give up...

The point, which you seem to be missing is:

First you need to define the problem

Click to expand...

So many people that ask questions here don't really understand what they are trying to do.

Click to expand...

Is not an off-topic comment. It is good programming practice that is often overlooked. In the rush to dive into the details of coding, important decisions are bypassed leading to code that doesn't quite do what it was supposed to. This is a very good response to any question about programming style.

In my opinion, of all the advice Peter gave in his post, this was clearly the most important.

Everybody has their own way some good some bad & then there are the diabolical, It's good to ask the more experienced guys (PC correction) gals on this site for their ideas.
I come across lots of software written by other engineers & in my opinion the guide below seems to work.
First get lists of variables i.e. the I/O symbolic lists should have these at the hardware design stage.
Create sheets for the other variables as per type of plc (this takes many forms as some have fixed data areas others are created).
Set out your stall hopefully with a software design spec.
When coding break your code into control sections also drive outputs with "FLAGS" in a seperate routine(s) for example a block for a particular control i.e. elevator(s) step sequence then using the sequence bits to drive the outputs in a seperate block it makes faultfinding easier.
i.e. progam 1 = elevators 1-5 sequence
program block 6 elevator outputs

Find the most comfortable way that suits you as we all think we have the best way.
Finally when you get in a bit of a mess with code that does'nt seen to work sit back & think for a while, don't just keep hacking at it to get it to work this creates spaghetti code with loads of redundant bits that do nothing.
Elevator outputs:

Derick,
Before you dive in and start developing the program, you may need to check if the Customer or end user has any predefined or existing standards you need to work to. For example, one customer I deal with wants a summary rung at the start of every routine, another customer has predefined routine names that must be in every program and most customers have some sort of tag naming structure. Like the other posts said you need to start with a list or a flowchart to get the sequence of operations right before you start developing the program.
Tim.