LAST EDITED ON Feb-18-01 AT 03:45 PM (EST)So, you make a little of this, a little of that, throw in a few physical laws, sprinkle lightly with a random factor (Murphy?), then randomly set off a big-bang or two.
Then sit back and watch what develops.
You might have to tweak it here and there, now and then.
Meanwhile, intelligence develops here and there. Half the time it extinguishes itself before it gets going very far.
Sound pretty haphazard? Well, YEAH!!!
There is a better way.
The smaller the system you are trying to develop, the easier it is. Which of course means that more complicated systems are harder to develop.
Small systems can generally be described completely by using a Karnaugh Map. This is a method where EVERY POSSIBLE COMBINATION OF CONDITIONS is identified and then associated with a particular response or set of responses.
When properly laid out, a Karnaugh Map will present the complete and simplified solution.
If used carefully, a Karnaugh Map can provide the steps necessary to proceed through a Sequence.
Karnaugh Maps are fabulous for SMALL systems. However, they become quite unmanagable very quickly as the number of conditions increases.
A System does not have to be looked at as being a single entity. As is the case in real world stuff, systems are usually composed of a multitude of sub-systems!
If a sub-system can be made small enough (without losing its function or identity) then that sub-system can be completely solved with a Karnaugh Map.
So, now you have a large system that is composed of a plethora (a sh*t-load!) of sub-systems... how do you keep these in line???
The next design tool available to you is the Flow Chart. A Flow Chart is a method whereby you identify all of the sub-systems, the relationships between those sub-systems, and any/all communication signals (flags) that need to be communicated between those sub-systems to cause and/or allow the process to proceed.
I prefer developing systems with an OverLord. That is, while there certainly is some direct communication between many of the sub-systems, some communications go back to an OverLord Controller. This is like a General on the battlefield receiving status reports from the field.
This General, or OverLord, is responsible for watching the entire process (based on reports from the field) and making sure that all is unfolding as it should!
He, the General, is also responsible for reporting back to the Commander-in-Chief, YOU! He does this through a User Interface.
At any time, the General might see something wrong. He then needs to issue whatever commands that might be necessary to handle the problem. Those commands either rectify the problem and allow the process to continue, or they bring the system to a controlled halt.
In either case, the condition is identified, handled and reported!
Since the General has a large area of responsibility, it would be good if a lot of the smaller problems were handled at the local level. However, those problems should still be reported back to the General so that he can report them back to YOU!
If you keep seeing the same problems showing up, then it is time to reconsider your strategy in that particular area! Don't let the problems continue simply because you have ways to handle them. Get rid of the causes of any and all problems!
Now then, in general, the process goes something like this...
1. Simply identify all of the sub-systems in your process.
Sub-System-A does such and such.
Sub-System-B does such and such.
(Don't try to create any code for them yet.)
.
2. Do a rough layout of the relationships between the sub-processes.
If Sub-System-B says it's OK, Sub-System-A feeds product to Sub-System-B.
When Sub-System-B is done doing its thing, it looks for a
flag from Sub-Process-C saying it is OK to feed the part.
.
3. After Sub-Sys-B feeds the part to Sub-Sys-C, Sub-Sys-B then
raises a flag to Sub-Sys-A to indicate that its OK for
Sub-Sys-A to feed a new part.
So, you spend most of your preliminary efforts trying to identify the sub-systems and their relationships.
After you have that, then you start going into the detail of how each sub-system works.
Meanwhile, keep in mind that the General needs to be kept informed about whats going on.
As your development process goes on you will undoubtedly think of more things that need to be handled, in which case you'll be going back and forth between Flow Charts and Karnaugh Maps.
The main thing to keep in mind is that you should develop your process in a TOP-DOWN manner!
BOTTOM-UP invariably leads to spaghetti-code!
Envision how the system would look from the operators point of view. He definitely wants a simple system!
There is an Inverse Relationship between your efforts and the Operators perception of the System.
That is, the operator should see the system as simple to operate. This requires that you put in much more effort to make it simple for the operator.
The less effort you put in, the more complicated the system will appear to the operator.
So, it appears I've been off on another 10K run...
I'm gonna shut-up now. See ya!
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
Email this topic to a friend
Printer-friendly version of this topic
Conferences
- (8 posts) 
HOW to CREATE a UNIVERSE (101):,
Terry Woods, Feb-18-01, (1)