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.
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