Structure for programming.

bendanator

Member
Join Date
Dec 2018
Location
convington
Posts
27
Hello everyone,

Was curious if anyone had some tips on how to start form scratch on programming. I’ve done some very small and more simple programs but now I’m wanting to take on a bit more. I have to write a program and also do the electrical drawings and I wanted to get some tips on how other people line out there work or how they stay organized throughout the process.

Thanks in advance,
 
Take this with a grain of salt, as I haven't worked on many large programs myself, but I don't worry too much about the initial structure of the program, as things can be moved around as the project takes shape. Depending on the equipment involved, I like to create subroutines for each piece of equipment, for example I'll have a routine for each pump and each motor etc. (don't forget your JSRs!) I've seen analog scaling be handled in its own routine, as well as in the routines for the equipment, such as a level transmitter being scaled in the routine with the level tank/pump.


As far as starting from scratch, I try to sit down beforehand and list out all of the I/O and tags I will require and get that set up beforehand, just to be a bit more efficient. Again, it may not be super important because you can usually add as you go (unless you're using an older PLC like a MicroLogix/SLC or something along those lines). I generally find that I've improved my programming layout and technique as I've gained more experience, which is only natural. If possible, try to take a look at some more complex programs to see how other people approach certain problems and evaluate their methods based on how you like to do things. I think that every time I look at a new program, I see something that I've never thought of and try to keep it in mind for the next time I could use it.
 
A good start is to think about the safety very early and build with that idea in mind, modifying it after everything is designed can be quite annoying.

You can then organize into safety areas (safety sensors and then actuators that need to be safely shut down at the same time) and then into functional areas. What I call functionnal areas are group of equipments that share the same mode (auto, manual, init) at the same time. You can then divide them between "entities" like conveyor 1, Robot 2, Elevator A.
 
Hi, and welcome to the forum. I have written a lot of programs from scratch at this job I have now. What I did that helps me a lot is if possible follow the sequencing you're given for the project, or write out your own sequencing and then program it in some order. For instance, the air handler job I did I was given a sequence of operation ..."when machine is placed in auto, then PLC shall..." "when outside temperature is less than 40 degrees, in occupied mode, the PLC shall modulate the heat valve..."
You get the idea. Then each routine I made into part of the sequence; control, heat, cool, fans, scaling, humidifier, etc. So it was easier for me to keep track of it that way, and much easier for the electricians and techs out there to follow it. Hope this helps.
 
I always do the electrical drawings first. If there is an HMI involved it helps me to hand sketch the screens to refer to while I'm writing the PLC program. Then I plug in all my I/O, which really helps me start thinking about how to structure the program. I like to break things up into small tasks/blocks of logic and piece it all together. After that it's a hot mess of notes scribbled everywhere, lots of coffee and chaos. A few tech. support calls and some 🔨 later and you're done! Easy! :) Good luck! Oh and do everyone a favor and comment your logic!
 
The drawing set can help a lot to organize your program. The process industry is different from the manufacturing industry. For example, if you had an 8 station rotary indexer, you could do something like the following. The data would be similar. You would use mostly program scope data. You can determine where to use controller scope tags.

Just off the top of my head. It could be combined more.

0 Main JSRs

1 Input mapping. Depending on the PLC.
2 HMI
3 IT interface

4 Station 1 mode control. Auto/Manual etc.
5 Station 2 mode control. Auto/Manual etc.
6 Station 3 mode control. Auto/Manual etc.
7 Station 4 mode control. Auto/Manual etc.
8 Station 5 mode control. Auto/Manual etc.
9 Station 6 mode control. Auto/Manual etc.
10 Station 7 mode control. Auto/Manual etc.
11 Station 8 mode control. Auto/Manual etc.

12 Station 1 Sequencing logic.
13 Station 2 Sequencing logic.
14 Station 3 Sequencing logic.
15 Station 4 Sequencing logic.
16 Station 5 Sequencing logic.
17 Station 6 Sequencing logic.
18 Station 7 Sequencing logic.
19 Station 8 Sequencing logic.

20 Station 1 Outputs. Manual control/Single step/Single cycle.
21 Station 2 Outputs. Manual control/Single step/Single cycle.
22 Station 3 Outputs. Manual control/Single step/Single cycle.
23 Station 4 Outputs. Manual control/Single step/Single cycle.
24 Station 5 Outputs. Manual control/Single step/Single cycle.
25 Station 6 Outputs. Manual control/Single step/Single cycle.
26 Station 7 Outputs. Manual control/Single step/Single cycle.
27 Station 8 Outputs. Manual control/Single step/Single cycle.

28 Indexer mode control. Auto/Manual etc.
29 Indexer Sequencing logic.
30 Indexer Outputs. Manual control/Single step/Single cycle.

31 Output mapping. Depending on the PLC.
32 Alarms
33 Utilities/Safety etc.
 
This is my method.

For any given homework assignment or task at work, you must consider these instructions as the customers specifications.
1. read the specifications several times.
2. write down your understanding of what you read in a step by step fashion.
3. review what you wrote down and see if it makes since, modify if necessary.
4. step through your notes again this time, you are the one following the instructions.
In other words, you are the plc. Write down on paper the events you are doing.
For example, turn on hydraulic motor 1, write down hydraulic motor 1 on.
If a sensor is needed, write that down.
5. continue through the instructions. When you turn off the motor, mark a line thru it.
6. go through your instructions with all the sensors, motor aux. contacts, outputs
Documented. Modify if necessary.
7. repeat step 6 until no changes are made.
8. Try to group your data words into some organized fashion.
The more programs you write, the more organized you become
9. write the plc program using your notes.
10. install the program and leave in program mode if possible so you can to debug your i/o
11. Question for you, when is a machine and plc the most dangerous and why?
When it’s first powered on – when power is first applied to a machine, you don’t know
How things are wired. When you energize the plc outputs, you don’t know how things
are wired. When the plc is put into run mode the first time, it will do what you told it to do,
NOT what you wanted it to do.
12. debug the program.
13. DOCUMENT EVERYTHING!!!
you may remember things today, but in 5 years and hundreds of programs later, you won't
remember, so DOCUMENT EVERYTHING.
14. MAINTENANCE is your best friend or your worst enemy.
if you work with them and find out what they can do, write the program where they can
trouble shoot the program. they will be able to fix the problem and everyone will be happy.
BUT
if you write the program to where you are the only one who understands what is going on,
maintenance can't fix the issue, the machine is down, production is down, management hears about
it, your boss hears about it, then you hear about it - rewrite the program or else.
you get calls all hours of the day and night.

this still holds true, a machine can cost a billion dollars, but it's not worth 10 cents if
maintenance cannot trouble shoot the issue and fix the issue.

everyone has their own style of programming and you must develop your own way as well.

this is the best advice I can give anyone.
of others has more / better suggestions, feel free to post.

Also, program (1) always off bit and (1) always on bit to help debug your logic. One of each only. when you are happy with the code, look for those bits and see if they are in your logic. modify the program accordingly.

james
 
Just a few suggestions:

1. Any input you have in the program from a switch, bring it to a timer. Use the timer done bit to drive the logic.

Reed switches can be passed, gate switches can 'bounce' and tons of other things can happen. Set the timer to half a second to start (500mS or so). It will almost always happen that you need to pause somewhere or put extra dwell time in, especially during start-up. If the process is time sensitive, lower the timer to 10ms or so. When you have switches on a timer, it makes this easy to change at a later date.

2. Make it easy to find things. Typically I will have separate ladder programs for:

Scaling
Input timers
Outputs
Faults
Sequence 1
Sequence 2 (etc)
HMI

The 'outputs' ladder is what kills me most when I look at other's programs. They are sometimes buried in other ladder logic, and usually maintenance people are trying to immediately find why the output isn't (or is) energizing.

3. If using an HMI, try to make all or nearly all of the changes from the PLC. Send the text from the PLC, send the numbers and logic from the PLC, etc. The HMI should just be a shell that can be updated from the PLC. HMIs are so varied that people might not have software for both or want to deal with the graphical side of things. If they can change the text from the PLC it makes life easier. (Personal opinion)
 

Similar Topics

Hello everyone, I am a beginner in PLC programming. I want to acquire pressure data from the sensor (water pressure) which give output value 0-5V...
Replies
4
Views
1,677
Hello Im building a final project for school and I was looking for some input on how to structure my program, first I'll cover what it does, how...
Replies
52
Views
16,618
I am looking for a good text reference for structuring a complex program. I am using Automation Directs "DirectSOFT32". I am a documentation nut...
Replies
5
Views
3,701
When adding an IFM AL1322 IO-Link Master Module to a 1756-EN2T Ethernet Card on a 1756-L82E Controller, The Input and Output data file does not...
Replies
0
Views
93
I have quite a large number of recipes in CASE form that I'm writing in structured text. I'm hoping to keep things clean and efficient when...
Replies
13
Views
1,461
Back
Top Bottom