planning stage of the program

[Maintenance Man]

I know there are many ways to program a PLC with ladder logic, but I am not sure the best way to plan out the sequence of operation. If some of you could please let me know how you plan out your programs. I have done some programming and troubleshooting with RsLogix 500 software, but would like to have some ideas on the planning stage of the program. Thank you all very much for your help.

Sincerely:
Maintenance man

 

[Maintenance Man]

I am just looking for a good way to set down with paper and pencil and be able to quickly plan out a PLC program when a manager asks me to make changes to a machine( have it do something different). I want to take what I put on paper and have it work in the program the first time with minimal changes.
Thank you all for your help.
Sincerely:
Maintenance man

 

[DamianInRochester]

I usually plan everything out in excel.

Usually these questions are paramount:

Alarms & Warnings (how many flavors will you have?, Will you have a cripple mode?, Some alarms may shut down the process, others may not.)

Will there be an HMI, and what will be its function? What variables will you give them access to? etc. I usally have a separate subroutine just dealing with the HMI and when using RSLogix500 also a separate set of data files related to the varaibles and operators on the screen.

Manual functions (Will they be latching, momentary, interlocked to prevent damage, etc)

Auto Cycle (Will you require a stepping feature for debug? Will you require a recovery at the point of failure, or will it have to be tooling returned from home each time, will you need a clean out mode?)

I have one tab where I outline all the subroutines I will need.
I have one tab for each subroutine. For each subroutine I type out every single step in plain english, one step per row. I only perform one single operation per step (with rare exceptions). I use integer based sequences, so my steps usually jump by 100. I also jump up to the next 1000 after a sub sequence is complete. This makes additions and modification a breeze. I number my steps as I am typing them.

Most situations can get away with a global watchdog alarm based off a single timer. If the cycle becomes too long I record the step it faulted on and base the fault on that. If I need to perform a check mid sequence, I might dump it to a dead end step just to trigger the watchdog on a unique step value.

I don't write any code until I have a specific step by step written word account of everything that must take place.

I also have a separate subroutine for physical Inputs, where I may debounce them or change the active level.

I also have a seprate subroutine for physical Ouputs where if I change between various modes (Auto, Semi Auto, Manual, etc), and also interlock things together like dual solenoid valves or reversing starters.


Once I have all the sequences written out, I then create the subroutines and then go down through writing the comments into to each network outlining what that network will do.

I go through and comment all the I/O appropriately ahead of time as well. If using RSLogix 500 I will make sure some data files align exaclty to the I/O.

Then finally I go through and write the code. If I take care to keep everything consistent, it may be as simple as copy and paste of the network text on each rung. Never really having to do too much ladder building. For example a typical step will test for a step number, wait for a condition, and then load the next step number once that condition is met. So I could just type this directly in (or CTRL-V from the clipboard), filling in the ? appropriately. EQU ? N7:0 XIC ? MOV ? N7:0 where N7:0 is my StepNumber.

If you have planned everything out well, this stage fast. After you have done it a few times, you will get more accurate with and and find that things tend to work exactly how you layed it out without a lot of code debug.

Put just as much time planning your data files and data organization as you do your code. Well organized data files can really slash development time.

I have always found that every minute of effort invested in the planning stage I get back many fold in the coding and debug time.

Try not to glaze over important details until later. Often you will find that if you haven't accounted for them right from the beginning you end up putting yourself in a corner and you have to re-write code to accomodate it later.

Sometimes it is best to experiment and test your concepts first before comitting them to code. If you are unsure of how something will process, and you will be using that same cocept a lot, you owe it to yourself to test it first.

 

[robw53]

lots of good points there. the one problem i encounter is production after sitting down and telling me what they want it to do, is then once its running they always come back wanting more on it, sometimes meaning having to re-write code because its such a big change to the sequence! but it all helps towards my experience!

 

[Mickey]

Here is a good read..

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#entry77274

 

[Archie]

Here is a little food for thought on one technique of documenting program flow, then translating to ladder. Having this program "road map" at hand can be very helpful with troubleshooting and explaining complex programs to non-programmers:

http://www.youtube.com/watch?v=rCa_U6YATTA

 

[The Plc Kid]

I usually plan everything out in excel.

Usually these questions are paramount:

Alarms & Warnings (how many flavors will you have?, Will you have a cripple mode?, Some alarms may shut down the process, others may not.)

Will there be an HMI, and what will be its function? What variables will you give them access to? etc. I usally have a separate subroutine just dealing with the HMI and when using RSLogix500 also a separate set of data files related to the varaibles and operators on the screen.

Manual functions (Will they be latching, momentary, interlocked to prevent damage, etc)

Auto Cycle (Will you require a stepping feature for debug? Will you require a recovery at the point of failure, or will it have to be tooling returned from home each time, will you need a clean out mode?)

I have one tab where I outline all the subroutines I will need.
I have one tab for each subroutine. For each subroutine I type out every single step in plain english, one step per row. I only perform one single operation per step (with rare exceptions). I use integer based sequences, so my steps usually jump by 100. I also jump up to the next 1000 after a sub sequence is complete. This makes additions and modification a breeze. I number my steps as I am typing them.

Most situations can get away with a global watchdog alarm based off a single timer. If the cycle becomes too long I record the step it faulted on and base the fault on that. If I need to perform a check mid sequence, I might dump it to a dead end step just to trigger the watchdog on a unique step value.

I don't write any code until I have a specific step by step written word account of everything that must take place.

I also have a separate subroutine for physical Inputs, where I may debounce them or change the active level.

I also have a seprate subroutine for physical Ouputs where if I change between various modes (Auto, Semi Auto, Manual, etc), and also interlock things together like dual solenoid valves or reversing starters.


Once I have all the sequences written out, I then create the subroutines and then go down through writing the comments into to each network outlining what that network will do.

I go through and comment all the I/O appropriately ahead of time as well. If using RSLogix 500 I will make sure some data files align exaclty to the I/O.

Then finally I go through and write the code. If I take care to keep everything consistent, it may be as simple as copy and paste of the network text on each rung. Never really having to do too much ladder building. For example a typical step will test for a step number, wait for a condition, and then load the next step number once that condition is met. So I could just type this directly in (or CTRL-V from the clipboard), filling in the ? appropriately. EQU ? N7:0 XIC ? MOV ? N7:0 where N7:0 is my StepNumber.

If you have planned everything out well, this stage fast. After you have done it a few times, you will get more accurate with and and find that things tend to work exactly how you layed it out without a lot of code debug.

Put just as much time planning your data files and data organization as you do your code. Well organized data files can really slash development time.

I have always found that every minute of effort invested in the planning stage I get back many fold in the coding and debug time.

Try not to glaze over important details until later. Often you will find that if you haven't accounted for them right from the beginning you end up putting yourself in a corner and you have to re-write code to accomodate it later.

Sometimes it is best to experiment and test your concepts first before comitting them to code. If you are unsure of how something will process, and you will be using that same cocept a lot, you owe it to yourself to test it first.

Sounds like a real neat way to lay things out. Do you have a example excel spreadsheet you could share?

 

[MikeW]

Damain's got it correct: Fight the urge to code until you have it completely thought out and documented line by line in Excel. I do much the same, down to testing code concepts prior to putting it into the spreadsheet. Leave no assumptions about how something might work, define everything completely during the planning stage, if you do not have time to do it on the front end, what makes you think there will be more time to figure it out on the fly when something doesn't work the way you thought it would? The last minute changes may also affect something else that you did not plan for.

Also remember there are three Phases of a Project: As Designed, As Built, and Current State. The initial plan is the design and is what Damain described, when you initially get it released to production is As Built, and Current State is what it is at this instant. Make sure you update your spreadsheet at each of the last two steps so that the next time you have to work on it you know exactly what it does as this make changes many years down the road much easier. The program specification is everything, as Norman Dziedzic, Jr. has in his signature line, "Programming to a specification and walking on water are easy, so long as both are frozen."

 

[parky]

One of the best ways is to put all your outputs in a block then use markers (Memory bits) to drive them try & get away from setting/resetting outputs in the code as this gets messy when you try to modify.
for example if you have a motor then set/reset markers in your sequence blocks then in a separate block use the markers to drive the outputs, This means that different markers for sequence control & say manual control with interlocks can easily be modified i.e. if in a step sequence you want the motor to not run on step 8 then just remove the step 8 marker from the output logic & if adding an extra step in the sequence it's easy to add a marker in the sequence then add this to the output logic.
Setting/resetting outputs in the sequence code gets messy.
As others have said plan well before coding, create small blocks of code not a few large ones as this makes it easier.
Also as you may not know what markers you will need create spreadsheets with blocks of markers & memory areas & leave gaps as you need extra you can add the symbol information to the spreadsheet so you have a record of memory areas used.
Hope this helps

 

[DamianInRochester]

Damain's got it correct: Fight the urge to code until you have it completely thought out and documented line by line in Excel. I do much the same, down to testing code concepts prior to putting it into the spreadsheet. Leave no assumptions about how something might work, define everything completely during the planning stage, if you do not have time to do it on the front end, what makes you think there will be more time to figure it out on the fly when something doesn't work the way you thought it would? The last minute changes may also affect something else that you did not plan for.

Also remember there are three Phases of a Project: As Designed, As Built, and Current State. The initial plan is the design and is what Damain described, when you initially get it released to production is As Built, and Current State is what it is at this instant. Make sure you update your spreadsheet at each of the last two steps so that the next time you have to work on it you know exactly what it does as this make changes many years down the road much easier. The program specification is everything, as Norman Dziedzic, Jr. has in his signature line, "Programming to a specification and walking on water are easy, so long as both are frozen."

I ended up doing things this way out of self preservation. As the controls guys, we always get the machine after it is already late. We are usually expected to start debug while wires are being frantically hooked up and mechanics taking parts off and putting parts back on. And the project manager then simply points his finger at you because you're clearly the one holding everything up.

If I am using something new I always try to get ahold of it first to play with it. Nothing is worse than writing a high volume of code based on assumptions and then having to junk it because it didn't work the way you expected.

You can also look at it like this as well. You wouldn't expect to just start wiring something without first making electrical prints first, and you wouldn't expect to just start building a machine mechanically without designing it first, so why would building a program be any different?

I am really tollerant of a lot of different styles, but I don't consider seat of the pants evolutionary latch logic as a style.

From my standpoint in a really good program the vast majority of the code deals with what happens when things on the machine don't function as intended. Getting things to work as intended is the EASY part because it is usually obvious what has to happen for things to go right. The nightmare programs are the ones where the coder gave no consideration whatsoever to when things get out of sequence. The old "we have to cycle power to the machine to get it back running" syndrome. Or changing one little thing cascades out and messes up several other areas of the program because it wasn't written sequentially even though it could have been.

I am making modifications to someone elses old program as we speak. He or she put all 400+ rungs in ONE subroutine. I'm not sure if he just didn't realize he could make subroutines or if he just figured it all looked better that way. 20-30% of it is uncommented. There is no organization to it whatsoever. It is so bad that I am having difficulty myself trying to break it up into subroutines. ARGHH!!!

 

[Maintenance Man]

Thank you all for your great advice. The answers are going to help me a lot.

 

[Maintenance Man]

A few years ago, I had went to a weeklong Rock Well PLC troubleshooting class, in which the instructor had told us, that one should plan a program to get it working, then plan for the what ifs. How do you all feel about this approach?

 

[OkiePC]

All the what if's deserve consideration. Every combination of sensor failure need not be scrutinized but those combinations that are in related sections of code...yes, always consider what happens when each of the sensors individually fails in either state, or starts flickering on and off erratically. You will find your self designing logic that either avoids some of those concerns by design, or deals with them inherently.

 

[HJTRBO]

I love this forum. I usually do my code as im thinking about the overall picture which usually results in rewrites. BUT yesterday i read this thread and today I mapped out a micrologix modbus to power meter program in excel including the layout of my for next loops for byte order changes. I wrote the code LAST and it almost worked first download. Only 1 change required. Simply awesome. Excellent advice from all that posted. Big thank you.

 

[Manglemender]

One more very important think to consider when designing and writing your code is:

"How can I write this code so that it will be of more use to me on my next project?"

So if your writing a function that controls the sequence of some XYZ machine, write it so that if you want to add another one next week it will be easier. Tips for this include: avoid absolute addressing inside your function - pass parameters in and out. Avoid the use of "Magic Numbers" in calculations to make things work - use real units or normalised values (0-100%).

One more slightly more contentious point: Avoid using Set and Reset in sequence controls - use a state engine and then use the state to drive the outputs.

Nick