Where do you start when making a program

Just curious, what do programmers do before starting a program.

Where do you start?

What do you make your first rung?

Just curious

Thanks

I start on paper and try to work out/list the components of the program and how I want it to work.

1st rung is always XIC B3/99 XIO B3/99 OTE B3/99, or "Always Off"

I always start by filling in all of the documentation for I/O plus timers, counters, and internal coils if at all possible.

I start with a spreadsheet and list out every single sequence in excruciating detail. My sequences are integer based and I force myself to the greatest extent possible to follow a single line, flow chart friendly, program flow. Attached is a screen shot of what it might look like. I then use a global watchdog to detect if the sequence stalls and generate a fault message based on the step it was stuck on. This allows for what I call "context sensitive" faults in the sense that the same device might have several faults associated depending on where in the program it faulted. In the HMI, I add the fault code to the fault text. So for example, one of the faults might read "1501 Pusher failed to leave the AT RAISED prox." If some faults are more time critical I may add additional timers in those nets that force the watchdog on immediately. On those steps where the sequence is just waiting for some other action to continue, I will add a bit to blind out the watchdog while on that step. I usually always put a status indicator on the screen to show when, and for what the machine is waiting for next to continue.

Once I have the sequence down in excel I often go through and actually comment all my networks with the verbage I have in excel prior to writing code.

Search around the threads here as well. This topic has come up quite a few times and there have been a lot of good posts on it.

I agree with the above posters - you start the programming outside the software package, with I/O lists, loop descriptions, set point lists, alarm lists. Knowing full well that they will all likely to change as you work through the actual logic code. Programming, like any other technical endeavor, is an iterative process.

As to the actual programming, the first thing you have to do is get over the intimidation factor of the blank "page". Do not try to work it all out in your head beforehand. Let the program "talk to you" as you work through it. Details and control considerations will come to you as you flesh out the program.

I always start with some simple and manageable parts of the program. This includes converting analog to engineering units, high/low alarms, data filtering, etc. This gets rid of the blank page, is a necessary basis for the control logic, and increases your feel for the physical system.

I'm still pretty new. (2 yrs exp) so take this for what you will. But I try to break down the program into several parts as well. Then I can draw or list out what is required to happen and the what if it doesn't as well before writing any code. At some point the parts begin to overlap but it still feels more manageable in pieces than one big process.

Kraken Fan #69

i gather all the niformation i can as to how the machine is supposed to run and write it down. sequence, tests, alarms, faults.

i then goto the ones designing the machine and discuss things with them to see if our understanding is the same and work out any differences. i also find out what valves they plan to use, part detection sensors, travel sensors, and so on.

i then type it up and go back see if my typed notes agree with specs, go to the designer. we then go to the customer to discuss the machine operations and work out any differences.

this was when i was worked for an oem.

i still do much the same thing today.

i then build the i/o list from that.

everyone will have different programming methods, try to learn what is common at the plant you work at. get with maintenance tech's first. learn what they like / dislike. then goto the programmers and see how they do things.

ALWAYS remember, maintenance is the backbone to machine operations. make the code simple and easy to understand. just because you can write code in 2 rungs doesn't mean that maintenance will understand that code.

regards,
james

James Mcquade said:

ALWAYS remember, maintenance is the backbone to machine operations. make the code simple and easy to understand. just because you can write code in 2 rungs doesn't mean that maintenance will understand that code.

Click to expand...

YES!

I wish more programmers would embrace this fact.

James Mcquade said:

ALWAYS remember, maintenance is the backbone to machine operations. make the code simple and easy to understand. just because you can write code in 2 rungs doesn't mean that maintenance will understand that code.

Click to expand...

I agree also, this is primary to reduce the number of late night phone calls to zero.

As far as the OP's question - top down design, bottom up implementation. And it starts on paper or a spreadsheet as others have pointed out. Resist jumping in and writing code before you've got it on paper.

James Mcquade said:

....

ALWAYS remember, maintenance is the backbone to machine operations. make the code simple and easy to understand. just because you can write code in 2 rungs doesn't mean that maintenance will understand that code.

Click to expand...

Maintenance can also be the crux of progression.

Back in my first years out of school and working maintenance for a plant, I felt this way. Then I changed seats and now work for an OEM/Integrator and I've realized that I'm not going to sacrifice quality, and efficiency because a plant doesn't keep their maintenance staff educated and qualified. At the end of the day, the resulting code provided is done so because it makes MY company money, keeps us in business and puts a paycheck in my wallet. Customers don't want to pay for control systems, yet they want "Cadilac" control systems for the price of a bare-bones F-150 utility truck.

Programs are complicated at times for a reason, sometimes it's the only way to provide the functionality, other times its simply more efficient and cost-effective, and yes sometimes it's because the programmer is a *******. As control systems advance maintenance needs too as well. If a plant can't recognize this it's the fault of the leadership of that plant/company not of the control system engineer. I've worked with great maintenance people/departments and I've worked with poor ones. If you don't know what an IP address is, good luck.

In the world of automation, if you aren't learning your dying, just my take.

I start by mapping I/O. Unless it's a really small program, I generally avoid addressing real-world I/O in the actual program. Even if you don't really need to, there are so many situations where it's preferable that I just end up doing it as a matter of course. If it's a really complicated process, I might do a flow chart of how it's going to work before writing the code. But generally I can just write it as I go along and it usually turns out okay. In RSLogix 500 I try to take advantage of multiple Data Tables as much as I can. I don't like shoving all of my booleans into B3. I might make several depending on what category they are, so for instance I'll make a B file for Alarm bits, one for real world inputs, one for real world outputs, one for HMI inputs, one for HMI outputs, etc. and use the default B3 file for my internal program logic. This really helps keeps things straight so I can look at, say, B10:0/0 and know that this is an internal bit mapped to a real-world output, or B20:1/1 and know that this is an alarm flag immediately.

I also like to make a String file for alarm messages, configure the HMI to have a set number of way more than I'll ever use, configure each message to look at a different string address of the corresponding number (so, alarm 1 would be ST29:1, alarm 2 ST29:2, and so on), and then each alarm flag to a pre-determined boolean address. That way, I can add alarms when I'm online with the PLC without having to touch the HMI program.

Do lil research on ISA88. good starting point.

James Mcquade said:

ALWAYS remember, maintenance is the backbone to machine operations. make the code simple and easy to understand. just because you can write code in 2 rungs doesn't mean that maintenance will understand that code.

Click to expand...

I wholeheartedly agree on this one. Remember: programming is done once, maintenance for the rest of the lifetime of the machine/installation. Winning a few hours (thus a few bucks) on programming can cost a multitude of that in maintenance later on. This is all what corporate thinking is about.

Kind regards,

I start with outside but first thing in the program is tags, I make all the tags needed so that when I start everything is already set up and ready.

Remember: programming is done once, maintenance for the rest of the lifetime of the machine/installation.

Click to expand...

I strongly agree. It seems that a program can be written for the primarly User's skill and knowledge level for his ease-of-use, or on the other hand, a program can be written for the Programmer and Integrator's skill and knowledge level for their ease-of-use.

Which are you paying for, and are you getting what you want?