software design

I have been practicing writing code for a few months. Got the traffic light, a soda vending machine and a few others. In the end they all worked. My next adventure is an elevator. One thing I noticed was that as I added features to my soda machine I started having to add flags so different parts don't interfere with each other. Flags, flags everywhere!!!!!!!! I was told that this is not a good practice. My question is where can I find information on how to design the software before you start. Is a flow chart enough or are there other ways to avoid the last minute blast of flags?

You might want to check out the link below. A main objective of the book is to address structured design techniques.

http://claymore.engineer.gvsu.edu/~jackh/books/plcs

Welcome Mr. Jack! Your reputation precedes you. Folks here have been posting links to your excellent book for many months. I hope you'll become a member.

Done

Welcome Professor Jack! So often your material has been quoted on good quality design practice and creating good foundations in PLC knowledge. Feel free to jump in there and comment anytime!

Glad to have you here, Professor. Your references and downloads are part of my new hire training - great work.

Welcome Professor Hugh Jack

Professor Hugh Jack.
I am wonder when you are here.
Also,I quite very glad and happy to see you on PLCS.net
Your's document very nice for us.
Thank you a lot for your's kindness.

Respectively,

Platootod

I also admire you and appreciate your book.

If there is a problem please let me know.

Back to original question

You will no doubt be wanting to move onto bigger and more complex programs in the future.
If this is so then I would advice the following:-

1. Write down in the shortest ammount possible the goal of the project. This helps to keep the focus.

2. Enlarge this and create a FDS Function Design Specification.

3. Create a list of 'What if' and actions required. Add a tick box to use later.

4. Create a flow diagram showing the main parts, using only a single page. This is hard to do using the single page constraint but worth it.

5. Sometimes construction of timing diagrams can be an aid.

6. Break down each section of the master flow diagram into smaller units. Look for units that are almost identical. With slight modification you could then use a common function block for the task.

7. At this point start a list of inputs-outputs-flags-storage-timers-etc. This will assist in selection and whether additional PLC's are needed for the task.

8. Review all that you have done to see if anything as not be covered.

9. When you cannot make the flow diagram no simplier then is the time to convert to the actual PLC program.

10. Look at the inputs etc and see if they group together. Using this method it is possible to say control a group of motors using Word logic rather than Bit logic.

Using the above should result in a program with a good structure and easy to follow documentation. The program is easier to commission and more robust in operation.

You are also producing a libary of non PLC specific solutions that can prove usefull in the future.

Martin

Welcome Back, Hugh!

Jim,

As far as having flags going here, flags going there, flags apparently going everywhere...

Flags are good... in fact, flags are excellent... that is, if they are "meaningful" in terms of the process.

Very small programs might not need to be "modularized" simply because they are so small - there is only one module. At the other extreme, there are incredibly huge programs that absolutely MUST be modularized (that is, if you want to maintain any kind of sanity).

If modules are properly derived... that is, if you draw the line separating modules in the right place, then any given module should be nearly complete unto itself. The module is "aware" of the status of all inputs/outputs associated with the particular module. However, at this point, the module can not function.

The module is almost ready to go... it just needs to have a little more information... things like...

Hey! Down-Line Module, are you ready for me to operate?

Hey, Up-Line Module, Whaz-up?

Those are flags... flags are good.

There is another thread ("skip process detection problem") where three processes, on three different PLC's, in the same machine, are allowed to operate out of sequence... no control flags. My answer to that thread provided "flags". If you read the thread, I think you'll see the merit of flags.

Think of it this way...
Several houses along a street. All of the residents are involved in some kind of process from House-1 to House-X.

Each house represents a module. Within each house/module, a certain action is performed. House number-3 does not need to know what is going on inside of house number-2. That doesn't mean that they aren't friendly neighbors... they do "talk" to each other. They "talk" by flags, or status messages.

I will go so far as to say...
...a well designed system consists of a certain number of modules...
...by themselves, none of these modules can function (subject to circumstance)...
...the "flags" make it all happen...

In other words...
while a system is "ready to go", simply walking up to and manually tripping a limit switch, in the middle of some module, in the middle of the process, does NOT cause anything to happen!

Why "Slice the Pickle" if there is no pickle?

Why "Hand-Off" something when there is nothing to hand-off?

A properly designed system "KNOWS" if the tripped limit switch is valid or not, and then what action to take or not take. This "Knowledge" is passed between modules by flags... flags are good!

I want to thank all you gentlemen for your input. I will try and put into practice the information you have allowed me to access. Hugh, it sounds like you are the "God Father", may I kiss your ring?

Thanks for the welcome. I find the last two replies by Martin and Terry very useful. They both emphasize the need for careful design, before programming. Many beginners rush to programming and spend much longer writing the program than is actually needed. And, even longer debugging! Even experienced designers will sit down and sketch out a design before trying to implement.

Within the context of the original question - the elevator - there are some 'flags' I would expect in any design.

going_up - the elevator is going to higher floors
going_down - the elevator is going to lower floors
moving - the elevator is traveling between floors
service - the elevator only responds to local requests
door_opening - the door is opening
door_closing - the door is closing

I would also expect an array of bits to indicate the floors where buttons have been pushed.

local[FLOORS] - floor buttons pushed in the elevator
lobby[FLOORS] - floor buttons pushed on each floor

There would also be some interger/floating point values for the position of the elevator.

target_floor - the next floor to move to
current_floor - the current location of the elevator

The next thing is to figure out how the flags go on/off. For example you might write rules like the one below. You could also use sketches, lists or whatever tool you find comfortable.

1. if moving==true and // only do while moving
current_floor==target_floor then // when at the floor
moving:=false, // stop the motion
local[current_floor]:=false, // turn off the floor request lights
lobby[current_floor]:=false,
door_opening:=true // start opening the door

The complete set of rules will take some time to write out, but by the time they are done the ladder logic is much simpler.

Something that would not be obvious here is that the system would also have some sort of position control system that will run in the background. It would deal with starting/stoping and maximum velocities. In this case a PID loop, or something along those lines might be needed to control the lift motor.

I agree, Planning is everything! I used program computers before I started programming PLC's. When programming computers, I learnt that through thorough planning, the project would decompose like this: 80% Planning, 15% Coding, 5% Debuging. I've tried this with PLC's and it's still very true. The more planning I do, the less programming and debuggin I have to do later. In my feild, shutting down a line to do some debugging costs lots of $$$ and make the customer very MAD. PLAN, PLAN, PLAN.

and Jack, its nice to know you're here. I've red the files on your site. Great stuff!

Denis Lamarche

Jim,
There are often as many ways to program a solution as there are programmers, but for an example of one possible approach you might want to take a look at:
http://www.thelearningpit.com/lp/doc/elv/vator.html

To reduce the number of individual flags look to using a byte or word to represent the lift position. The lift direction is thus emulated by shifting a bit either left or right. The bit location is the present level. Another flag byte contains the requests for each level, this is why grouping of inputs is important. A simple AND of the two flage bytes will then tell the PLC whether to stop at that level.

I have over simplfied the approach but this should cut down the programming you require.