Methods to stay organized when writing ladder from scratch

so, im interested in hearing some secret tips people may use to stay organized and on task when writing a program from scratch. I do the typical, get the scope of the project, write down the I/O, alarms, etc. sometimes start off with a scratch pad, move over to excel. im sure there are some other neat ways people out there do this so im hoping some will share.

No one wants to chime in?

I dedicate a routine or FC for each motion. Mode control (manual, auto, auto cycle, dry cycle, runout, etc) gets its own routine. Fault management another, sequencing another, interlocks with other equipment another, any special HMI logic yet another. "Top down design, bottom up implementation".

I think this will depend an awful lot on the platform of choice.

General tips would be to make code re-usable and add capability that can be configured to the block.

Also, either your blocks/routines/whatever tell exactly what happened to the tech on one or more of the outputs, or you have to leave that logic where it is clear to them.

So generally, if there is some sort of interlock condition, that logic is plain for everyone to see why Valve X didn't move.

I try and create all my tags in excel first. Easier to stay consistent and structured. Some specs i get define to the setpoint name. Others are more vague. But i can generally automate using excel and concatenate function to build tags like Process_Equip#_Parameter, or whatever is required.

I also try and create all my Sections / ladders before i write any code so i can clearly think about where stuff needs to go. I always have UnitControl, ProcessControl, Alarms as a minimum per process area or sub system. That's for big plants anyway.

I like to Have a paper copy of the spec so i can highlight as i go, what I've coded. Word doc open for any notes/ questions.

jstolaruk said:

I dedicate a routine or FC for each motion. Mode control (manual, auto, auto cycle, dry cycle, runout, etc) gets its own routine. Fault management another, sequencing another, interlocks with other equipment another, any special HMI logic yet another. "Top down design, bottom up implementation".

Click to expand...

do you try and keep all of your HMI referenced tags in a certain word within the PLC or anything like that? For example all HMI push digital push buttons would be in B3:15, if programming with RS500. I recall reading somewhere where that was beneficial but i dont remember as to why.

JZerb said:

do you try and keep all of your HMI referenced tags in a certain word within the PLC or anything like that? For example all HMI push digital push buttons would be in B3:15, if programming with RS500. I recall reading somewhere where that was beneficial but i dont remember as to why.

Click to expand...

I think that's a good idea so it stays organized. What ever organization method you choose, be consistent. Someone that is coming behind you after the machine is commissioned will recognize that and it will be easier for them. Always in the back of my mind I'm thinking of the person that has to maintain the machine after I'm done, trying to make the code easy to follow so that he doesn't have to call me in the middle of the night.

JZerb said:

do you try and keep all of your HMI referenced tags in a certain word within the PLC or anything like that? For example all HMI push digital push buttons would be in B3:15, if programming with RS500. I recall reading somewhere where that was beneficial but i dont remember as to why.

Click to expand...

We use Studio5000 and do something similar: prefix most HMI tags with "hmi_". While it doesn't always produce the most efficient PLC-HMI network traffic it is handy when you look at a tag and it doesn't get turned off or on in the PLC (thus be a candidate for deletion). This lets you know that the tag is probably being manipulated elsewhere.

JZerb said:

do you try and keep all of your HMI referenced tags in a certain word within the PLC or anything like that? For example all HMI push digital push buttons would be in B3:15, if programming with RS500. I recall reading somewhere where that was beneficial but i dont remember as to why.

Click to expand...

HMI's typically poll entire words, not binaries. If you use single bits in multiple words you're adding unnecessary traffic to whatever network you're using.

http://accautomation.ca/five-steps-to-plc-program-development/

I typically use the above 5 steps.

Regards,

we each have our own method.

here's mine
read specs several times
figure out shall versus should in the specs.
copy specs and highlight the plc part, specs, limits, travel, forces.
write down the sequence in order, forget the I/o
review / rewrite until it makes sense.
add the I/o.

figure out the subroutines routines

write in a step by step manner.

You MUST remember who you are writing the code for, your customer is a given. it's maintenance ! they have to work on the machinery and debug the problem.

find out what they are used to, what plc.
do they know sequencers, grafcet style programming, step logic, function blocks, structured text?

if you write it to where they understand the logic and can work on the machine with little effort, the machine will run. they will recommend using your company again for the next job.

BUT ! write the code that only you know, then the machine won't run because maintenance can't figure out the program. the project manager gets yelled at, your boss gets yelled at, and you get yelled at and have to rewrite the program. the next machine you quote will then have a bunch of stipulations in there and one of them is that maintenance approves the program before
final payment is made. a guy I worked with found it out the hard way.

james

JZerb said:

so, im interested in hearing some secret tips people may use to stay organized and on task when writing a program from scratch. I do the typical, get the scope of the project, write down the I/O, alarms, etc. sometimes start off with a scratch pad, move over to excel. im sure there are some other neat ways people out there do this so im hoping some will share.

Click to expand...

Some stuff I normally do - Rockwell. I have not done Modicon/Schneider, Telemecanique, PLC Direct, etc in a long time :

- I use integer files, not boolean files, for HMI tags

- Each HMI area has it's own READ and WRITE file for bits, READ and WRITE files for analogs

- Alarm logic uses 3 or 4 files per HMI area. Raw alarms, masked alarms, new alarms, acknowledged alarms.

- Motor logic has several standard rungs for small PLCs, a subroutine for larger PLCs. AOIs are preferred over a subroutine if you don't have a continuous process since editing an AOI required a download

- Gate logic is similar to Motor logic. Standard rungs for a normal gate, or valve. A couple added for specialty stuff. A subroutine for larger PLCs. AOI if you can.

The motors and gates have a 16 bit integer for status and a 16 bit integer for alarming. You can copy the status or alarm bits that you need into a tight grouping to transfer to the HMI. But using a status rung that shows you all inputs and outputs as well as a few internal status and alarms I find very helpful when troubleshooting.

This assumes that there are dedicated staff for maintenance. It's tough to teach data structures to personnel without any computer training at all. Masks, binary, and subroutines are confusing but they make my life easier.

This has to be balanced with getting calls at 3 am as has been mentioned. Hard-coding the logic, instead of subroutines, makes it harder to fix global errors - like perhaps all of the limit switches are wired fail-safe .. or their emergency stops are NOT wired fail-safe for some reason.

Lots of times the cost of downtime is high. So commissioning has to be fast. That's where you get into debouncing inputs in a separate subroutine and using bits for your logic. It also makes it easy to change a normally open input into a normally closed input. But it confuses maintenance people to find an input in one place, and the motor logic in another place. Or subroutines, where you can add a minimum off-time to all motors that use the same subroutine with 1 rung.

25% spare is another rule. Everyone adds stuff afterward. If one thing is removed, 2 or 3 will take it's place. Everything needs to be faster, stronger, more production. You will need spare IO in each cabinet. Spare space on the din rails for power supplies and distribution terminal blocks.

Agreed on top down design, bottom up implementation. Look to group common stuff together - valves, motors, process areas.

Have an order. Asset numbers work, areas of the plant. Sometimes process order. So you can search quickly through the logic and find what you need to find.

The rung comment on your status/debug rung should have whatever order you have used - asset, loop, etc, along with a couple of key words that you can search for - pump, belt, screw, drag, valve, butterfly, knife, ball ... if you talk to maintenance people for a few minutes and listen to a couple of stories you should be able to pick out how they refer to the equipment. Beware of brand names - use drag conveyor instead of Redlar, bucket elevator instead of Rexnord, Centrifuge instead of Bird .. for example.

For recipes or sequencing, having the logic for steps separate - like maybe a subroutine or a recipe section of rungs - helps to troubleshoot basic operation. But put the actions - start, stop, open, close, in with the logic for the equipment. So you can see that sequence 7, step 4 starts a bucket elevator, in the group of rungs that control the bucket elevator.

End of rant

I tend to follow the philosophies found in ISA-88, the components of the physical model and procedural model pretty much apply to any process regardless if it is a batch system or not. Following those models I will break down everything into manageable pieces/tasks that are much easier to keep track of and organized, creating a WBS - "Work Breakdown Structure" for those familiar with Project Management terminology. I'll use excel to document the process down into the physical/procedural models, document devices, create an index of process sequences I'll need.

I'll use grafcet/flow diagrams (Functional design specs) to "design on paper" before even touching the PLC so my general process sequencing aligns with the procedures and equipment I've identified. I'll have a pretty good idea of where logic will be simple or complex after this excercise.

From there, I'll start programming. Note, all of this pre-work falls in-line with modular programming concepts making it easy to apply our PLC/SCADA standards, so once it's on paper, translating to code goes pretty quickly. The WBS is how I track progress.

Finally I'll start testing things out. Manual control, semi-automatic control, automatic control. From there I can test the logic function against my functional design spec and get a warm fuzzy that I'm on the right track and ready to FAT with the customer.

So my workflow is:
1 - Create a WBS
2 - Document details as the process/equipment relates to ISA-88 physical/procedural models
3 - Create Functional Specification Document
4 - Programming
5 - Testing