Karnaugh map

[Rod]

Ya got me looking and here is a freebie I found.

http://www.puz.com/sw/karnaugh/karnaugh_12.htm

Thanks for making me remember something from WAYYY BACK.

Rod (The CNC dude)

 

[Terry Woods]

Without a doubt, this can be a handy tool... especially for generating the Boolean Formula. However, I really hate that they don't include parentheses to eliminate all possibility of ambiguous interpretation.

Another thing that bothers me is that the impression is that the K-Map is STATIC... nothing more than a State-Table (a Truth-Table).

The real power of the K-Map is expressed when you simply CHOOSE to use it as a DYNAMIC table. A dynamic table KNOWS how any particular set of conditions came to be... that is, where it is, and where it came from.

Another aspect is that K-Maps can be held small by making them multi-dimensional. Of course, that means that you have more maps to look at, but each small map is easily managed. In this case, each map represents a particular condition or set of conditions.

For example, if you are following 9 conditions (a 4x5 map), this can be quite ugly and tedious on one map. The map in Auto-Code generator does not allow that many. However, you can create 2 maps, each with 4 elements (each map is a 2x2 map). Map-1 represents Condition-9 Asserted. Map-2 represents Condition-9 NOT Asserted.

This can extend to as many map sets as you can handle... essentially, an unlimited number of maps... to whatever extent you can keep track of.

Another thing to bear in mind is reasonable organization of the conditions.

You shouldn't want to go to another map-page except in the case of rare condition changes. Common changes should stay on the same map... unless a rare change has called for your attention to be focused on another map-page.

 

[testsubject]

That is pretty cool. I sure could have used that last semester...

 

[Rod]

Terry,

Ya lost me. <sigh> Now I gotta go dig some more.

Rod (The CNC dude)

 

[Terry Woods]

Rod,

Most people use K-Maps to track the status of various INPUT conditions... as in... Real Inputs from the field.

With respect to a particular rung, an input is an input is an input... whether it is from a real device in the field, or an output, or an internal relay.

The dynamic aspect of the K-Map is developed by using internal relays as "process condition" inputs. This is not to be confused with a "device condition". A "process condition" indicates what the process is doing (or thinks it is doing). Process conditions should be used in conjunction with static conditions.

Let's say that you have a simple punch-press with a feeder and an unloader.

Under the appropriate conditions, the feeder feeds a blank-part to the press. When the part is loaded, a limit switch is tripped. When the limit switch trips, the punch cycles. As the punch cycles, the die leaves home, punches the blank, and returns home. When the die returns home, the unloader removes the part from the press.

A "Modular" approach to this process would be, at least, and nothing more than,...

"Load the Part"
"Punch the Part"
"Unload the Part"

Now, within each of those "modules" there are sub-modules...

"Load the Part"
- "Loading the Part"
- "Part has been Loaded"

"Punch Part"
- "Punching the Part"
- "Part has been Punched"

"Unload Part"
- "Unloading the Part"
- "Part has been Unloaded"

Notice that all of these sub-modules are represented by action-type phrase names. Depending on the complexity of the process, there might be sub-sub-processes under the sub-processes.

These are NOT "static" conditions... these are "dynamic" conditions". These conditions do NOT represent the current static conditions of the various field devices, but rather, the activity that is currently occurring, or the activity that has just completed.

If the K-Map includes these "dynamic" conditions, then...
...if the "Part is Loaded" limit switch goes on, AND the "Loading the Part" signal is on, then, and only then, does the press cycle!

If the K-Map does not include these "dynamic" conditions, then, depending on the programming method...
...if the "Part is Loaded" limit switch is tripped, the press will cycle.

The crucial difference here is that, in the "dynamic" version, the program "knows" that the process is "Loading the Part" and so the process expects to see the "Part is Loaded" limit switch come on.

If, however, the "Part is Loaded" limit switch comes on while the program is NOT expecting the signal to come on, that is, while the process is NOT "Loading the Part", then... something is wrong.

Depending on the situation, that signal can be ignored (if handled properly with a high degree of confidence), or an alarm condition can be initiated.

Now, this has been nothing more than a very, very simple example.

Most experienced programmers can handle this particular process "from the hip" without a K-Map. However, we all know that things can become quite complex very quickly. Also, there are many inexperienced programmers that don't quite have the hang of the relationship between "cause & effect" from a "SYSTEM POINT OF VIEW".

The K-Map is an excellent tool for making the un-manageable more manageable. Of course, that first requires a reasonable definition of modules, sub-modules, sub-sub-modules... etc.

The main point of this discussion is to show how K-Maps can be used to monitor and control "dynamic" conditions.

Now, as far as multi-dimensional K-Maps...
...that is nothing more than spreading a huge K-Map over several, more manageable (from a human point of view), smaller K-Maps. Each separate map represents the "assertion" or "de-assertion" of a particular condition or combination of conditions.

And remember, those conditions might be static conditions (field inputs or outputs) or process conditions.

 

[PhilipW]

Terry...great post. It inspires me to know that there are other guys out there who take their logic seriously.

Depending on the situation, that signal can be ignored (if handled properly with a high degree of confidence), or an alarm condition can be initiated.

I'm finding that about 85% of the work I am doing in new projects is all about messaging and alarming diagnostic information to the operator. Getting the logic to run the machine is usually the easy part....it's correctly trapping and handling ALL the possible errors and exceptions that is a lot of work to get right. I've used K-Maps in anger a couple of times, and it is really quite amazing how powerful a handful of well constructed rungs of this stuff can be.

(I would post one of these projects but regretably neither of them are mine to make public.)

 

[Rod]

Terry,

Your on the beam!

Now allow me to show our real world problem(s). No offense intended - just a heads-up:

I sell a homegrown software package for retrofitting punch presses, turrets, single station punches and even plasma heads.

Search for Punch Wizard - API, or PCcontrols

Now comes the FUN part! Re-entering code/program at ANY point.

Let's say that at ANY point in the program the operator hits the Cycle-Stop, or the machine (NC) throws an error or ,heavens forbid, an E-Stop.

The operator should have COMPLETE control of the machine,IE: axes movement (jogging), turret rotation for tool sharpening and replacement, debris removal, ETC.

Case:
The program just ran 649 hits out of a 987 hit program and the punch/die fractures. The operator sees/hears the error and hits E-Stop (we would prefer he hit Cycle Hold - but he was in a hurry). The machine STOPS RIGHT NOW and the operator looks at the blank and realizes the problem - a blown punch. Part blank is still good up until the broken punch.

So... go to 'Manual' and jog X and Y axes away from the turret, then rotate the turret to the blown tool load station. Replace tool and then (MAGIC HERE) back step through the program to the point in the program when the punch blew out - then hit 'Cycle Start'; all axes return to the point of 'error' and resumes the program.

Does that help you sir? I hope so, cause I could use some help!

Rod (The CNC dude)

 

[PhilipW]

Well Rod I think this totally depends on how your program is structured, but in a program with that many steps, I would expect that there is some variable in the program that is keeping track of which step number you are at?

If so then all that is necessary is to store that step number for the duration of the E-Stop and Manual Clear, and then simply go back to it when put in run mode. Of course it would be necessary to check for any pre-conditions first, and these may well be dynamic depending on the exact point in the cycle you want to go to...but in principle not magic at all.

 

[dandrade]

(I would post one of these projects but regretably neither of them are mine to make public.)

Because, not? It is not the only one it include the diagnostic as part of the solution

 

[Terry Woods]

Rod...

So... the operator is watching the operation and then he sees that one of the punches has blown.

He hits the Cycle Hold button. The operation stops.

While the current status is Hold Cycle... the operator is allowed to operate the various axis in manual.
It doesn't seem reasonable to allow manual operation while the E-Stop is pressed... does it?

He operates the X, Y, and Turret to bring the blown punch to the tool station. The tool is replaced.

Now... he presses the "RESUME" button.

The expectation here is that the machine will "rewind" and return to that point in space and time... just before the first operation of the blown punch. When all is ready the process resumes seamlessly.


Generalizing... There are many types of Punch Sequences. Here are a few cases...

1. Single Punch per Index: The blank is indexed in, the punch happens, the part is ejected, done.
Index, Punch, Eject part - Index, Punch, Eject part

2. Multiple Punch per Index: The blank is indexed in, several punch operations, the part is ejected, done.
Index, Punch-1 ... Punch-X, Eject part, Index, Punch-1 ... Punch-X, Eject part

3. Multi-Stage Punch Operation:
There are several different punch operations happening simultaneously on each punch cycle. The blank feeds in to the first position, punch, index to next position, punch,... repeat until punch at last position, then eject part. The punch-die might consist of any number of positions (steps). It takes as many cycles as there are steps to fill the die. Once the die is full, a part is produced on each cycle.


The general form of Case-1 is...

"Load the Part"
"Punch the Part"
"Unload the Part"

The general form of Case-2 is...

"Load the Part"
"Punch the Part"
"Unload the Part"

The general form of Case-3 is...

"Load the Part"
"Punch the Part"
"Unload the Part"


The only difference shows up in Case-2. In this case, "Punch the Part" consists of several "sub-modules" each controlling a particular punch operation.

"Punch the Part"
--- "Punch with Tool-1"
*
*
*
--- "Punch with Tool-X"

Now, the idea of creating a sub-module for each of the possible tool-positions might or might not seem reasonable. If the only difference in the various sub-modules is the tool... then perhaps a single, general purpose sub-module can be created. If so, then sets of parameters can be passed to the sub-module for each punch operation. An operator can create custom sequences through an interface. Of course, this is easy to say.

Back to the primary issue...

When the operator presses the "Resume" button, he expects the process to return to the point just before the first operation of the blown tool. Of course, the operator doesn't know that the tool is blown until after the fact. The question is, how much "after the fact". The operator might be a little slow on pushing the Hold Cycle button.

How can the program "know" where it needs to go before resuming?

The program can "cache" all of the pertinent operating parameters when the Hold Cycle or E-Stop is pressed. This is a "snap-shot" of where it is and what it is doing when the Hold Cycle or E-Stop is pressed.

Now, it is important to realize that this is nothing more than a "snap-shot" of conditions when the Hold Cycle or E-Stop is pressed... not necessarily the conditions existing when the first blown-operation occurs. This "snap-shot" will always be "after the fact". It would be great if the program could detect a blown-operation as it occurs!

The biggest clue will become obvious when the blown tool is changed. If the particular sequence isn't too complicated then it should simply be a matter of "stepping backwards" through the code to the last point where that tool was used.

Now, the sub-module (or parameter set), where the particular tool was last used, has a beginning and an end. In between the beginning and the end, the tool might go through any number of various operations. For instance, this particular tool might be used to deliver several strikes before the sub-module is complete.

So, having rewound to that particular module, where do you want to resume from? Do you want to resume at the beginning of the several strikes, thus repeating all of the strikes... or the end of the strikes... or somewhere in between? Maybe the number of strikes is important... maybe too few or too many might cause a problem.

I have no idea what any particular sequence might be. The possibilities are unlimited. As such, it becomes very hard to develop a "general solution" for resuming from any particular point within the sub-module. If it won't cause a problem then the easiest point to resume from is the beginning of the sub-module where the last use of the particular tool occurred.

Now, it might be the case that the particular tool was blown earlier than the last use...

1. Tool-1,
2. Tool-2 (blown),
3. Tool-3,
4. Tool-2 (blown - last use of Tool-2),
5. Tool-4
"HOLD CYCLE" => Tool-2 is replaced.
"RESUME"

Now... where should the program go? Step-4... the last use? Or Step-2?

Can the operator "know" that the first failure was on Step-2? Is it important that the process resume from the first blown-operation... or... is it OK to resume from the last blown-operation?

If this is a Multi-Stage process (Case-3), does the material have to be indexed backwards a few places?

All I'm trying to do is cover the possibilities... I have no idea how complex a particular sub-module might be.

The ideal solution is a "general solution". A "general solution" will handle any situation. Of course, the complexity of the "general solution" is entirely dependent upon the worst-case complexity among all of the sub-modules.

So, let's assume that the program "knows" where to "rewind" to.

BTW, if the operator pressed the E-Stop then he would have to pull the E-Stop before being able to change the tool. At this point, the process "expects" to be restarted with "RESUME". If the operator happens to push "START" instead of "RESUME" then maybe there should be a message asking for verification.

The Turret is at the tool-station. The operator presses "RESUME". ("Are you sure? Y/N")

First, the Turret returns to the place where it was when the Hold Cycle or E-Stop was pressed. It has to follow a path that is guaranteed to be safe.

Once in position, the program rewinds and loads the particular parameters. The machine then steps slowly to bring the physical conditions to match the expected conditions for the particular sub-module.

Once completed, the screen indicates that the machine is ready to resume running. This is the last chance for the operator to verify that all is well and that it is OK to run. ("RESUME RUNNING? Y/N")

OK... since I have no idea of the particulars... I pulled all of this out of my a$$...

So... does any of this give you any ideas?

 

[testsubject]

All I can say Terry is "DAMN!!!!"

That is extremely detailed for not knowing the exact operation!!

Kudos!

Bob