K-MAP & Allen's Challenge

Terry Woods

Member
Join Date
Apr 2002
Posts
3,170
So... the Pirates (my Keepers, don't cha know) urged me to consider this challenge... even if only as an intellectual exercise.
(This turned out to be pretty long, longer than I expected. If you have ADS, you might change the channel right now.)

I considered the basic actions/reactions.

In general...

Start-Up:
If the Valve is NOT moving and the CLOSE_PB is pressed, begin Closing the Valve.
-OR-
If the Valve is NOT moving and the OPEN_PB is pressed, begin Opening the Valve.

Then...

Stop:
If the Valve IS Closing and the OPEN_PB is pressed, stop Closing the Valve.
-OR-
If the Valve IS Opening and the CLOSE_PB is pressed, stop Opening the Valve.

At that point, regardless of which way the Valve WAS going, it is back in the Start-Up situation.

So, I plotted-out a K-Map.

Everything seemed to be going along well until I ran into the following case...

Assume the Valve is Closing. If I then press the OPEN_PB to Stop Closing the Valve, the Valve does indeed Stop Closing.
HOWEVER...
Since the Valve is no longer Opening or Closing, having the OPEN_PB pressed (which was done for the purpose of STOPPING the Valve) is sufficient to cause the Valve to begin OPENING immediately! That certainly is not the intent.

The same effect occurs when pressing the CLOSE_PB to Stop Opening the Valve. That is, the Valve immediately begins to CLOSE! Again, not what was intended!

So... What is it that we are really looking for...???

A little head-scratching, an MGD or two (or three) and the fog started to lift. In order to START in either direction, what we need is to "see" one button or the other Come-On WHILE the Valve is neither Closing nor Opening. If a button Comes-On in that circumstance, that is, the Valve is neither Opening, nor is it Closing, then the function related to the particular button is activated.

If the Valve is Closing, then pressing the OPEN_PB Stops the Closing, but does NOT begin Opening because the button is not seen to come-on while the valve is stopped.

So.... how the hell do you get this into a K-Map???

Many look at K-Maps as State-Maps ONLY. They look at it only as a tool for minimizing code. This is a mistake... especially when they are used for PLC Programming.

PLC's are "Conditional Sequencers". If you use a K-Map to plan out a program, that K-Map, when used with a PLC Program, can be plotted as a sequencer. That is, the K-Map doesn't have to be seen and used as a state-machine only.

The following is the K-Map I came up with. The explanation follows the map.

(INSERT MAP)
3dd6dcd66e8b3809.gif


IN GENERAL, decisions are made according to the states of the Inputs. The Inputs are shown along the left side and across the top.

The various combination conditions of the OPEN_PB and CLOSE_PB are shown along the left side of the map.

Across the top, you see the STATUS. The STATUS is the State of the Outputs. (I'm gonna speak in terms of the PLC Outputs ONLY because this is an intellectual exercise. The right way to do it is to read the Open/Close AUX Contacts on the motor.)

Continued in Part 2
 
Part 2 of Allen's Challenge

This is Part 2...

You'll notice that, in the map, there are a bunch of colored arrows. They might seem to go here and there without reason, but, trust me, there is method behind this madness! For now, ignore that "Armed to Start" in the top-left box.

The arrows are color-grouped. Each color-group represents a particular set of circumstances. You'll also notice that there are dashed lines and solid lines. Ignore the BLACK Lines for now.

The solid lines represent Input activity by the operator. These are the "ACTIONS".
The dashed lines represent Logical activity generated by the map. These are the "REACTIONS".

In the following, the XX / YY indicates a particular square in the map. The XX refers to the PB combination. The YY refers to the Status combination. For example, 1 1 / 1 0 refers to the square just above the square in the lower-right-hand corner.

So, let's pretend that the system has just been brought on line... (remember, ignore the Black Lines)

The current state of the Map is 0 0 / 0 0. No buttons are pushed and the Valve is not moving.

Let's do some NORMAL Start / Stop activity by push button only... Let's OPEN the Valve (we'll look at the limit switches later).

BEGIN OPENING THE VALVE
The operator presses the OPEN_PB. This "ACTION" path, indicated by the Downward Solid Dark Blue line, results in a map state of 1 0 / 0 0 . At 1 0 / 0 0, the map responds by turning ON "OPENING". This "REACTION", indicated by the Dashed Dark Blue line, results in a map state of 1 0 / 1 0 . The Valve is now Opening.

The OPEN_PB is still pressed at this point. The operator can do one of two things. He could release the OPEN_PB
-OR- he could press the CLOSE_PB. Those are the only two possibilities. Since we are doing NORMAL stuff right now, let's assume the operator releases the OPEN_PB. In this case, the "ACTION" path, indicated by the Upward Solid Dark Blue line, results in a map state of 0 0 / 1 0 . No buttons are pressed and the valve is opening.

STOPPING THE VALVE (Press CLOSE_PB to Stop OPENING)
The current state of the map is 0 0 / 1 0 , the valve is Opening. Now the operator presses the CLOSE_PB. This "ACTION" is indicated by the Downward Solid Green line and results in a state of 0 1 / 1 0 . At 0 1 / 1 0, the map responds by turning OFF "OPENING". This "REACTION", indicated by the Dashed Green line, results in a map state of 0 1 / 0 0 . The Valve is now Stopped. (Yeah, there's an issue here, we'll get to it later.)

The CLOSE_PB is still pressed at this point. The operator can do one of two things. He could release the CLOSE_PB
-OR- he could press the OPEN_PB. Those are the only two possibilities. Again, since we are doing NORMAL stuff right now, let's assume the operator releases the CLOSE_PB. In this case, the "ACTION" path, indicated by the Upward Solid Green line, results in a map state of 0 0 / 0 0 . No buttons are pressed and the valve is stopped.

BEGIN CLOSING THE VALVE
The current state of the map is 0 0 / 0 0 . No buttons are pressed and the valve is not moving. Now, the operator presses the CLOSE_PB. This "ACTION" path, indicated by the Downward Solid Red line, results in a map state of 0 1 / 0 0 . At 0 1 / 0 0, the map responds by turning ON "CLOSING". This "REACTION", indicated by the Dashed Red line, results in a map state of 0 1 / 0 1 . The Valve is now Closing.

The CLOSE_PB is still pressed at this point. The operator can do one of two things. He could release the CLOSE_PB
-OR- he could press the OPEN_PB. Those are the only two possibilities. Since we are doing NORMAL stuff right now, let's assume the operator releases the CLOSE_PB. In this case, the "ACTION" path, indicated by the Upward Solid Red line, results in a map state of 0 0 / 0 1 . No buttons are pressed and the valve is Closing.

STOPPING THE VALVE (Press OPEN_PB to Stop CLOSING)
The current state of the map is 0 0 / 0 1 , the valve is Closing. Now the operator presses the OPEN_PB. This "ACTION" is indicated by the Downward Solid Magenta line and results in a state of 1 0 / 0 1 . At 1 0 / 0 1, the map responds by turning OFF "CLOSING". This "REACTION", indicated by the Dashed Magenta line, results in a map state of 1 0 / 0 0 . The Valve is now Stopped. (Yeah, there's an issue here as well, we'll get to it later.)

The OPEN_PB is still pressed at this point. The operator can do one of two things. He could release the OPEN_PB
-OR- he could press the CLOSE_PB. Those are the only two possibilities. Again, since we are doing NORMAL stuff right now, let's assume the operator releases the OPEN_PB. In this case, the "ACTION" path, indicated by the Upward Solid Magenta line, results in a map state of 0 0 / 0 0 . No buttons are pressed and the valve is stopped.


Pressing Both buttons simply causes the valve to stop. Follow the map!

ISSUES
Everything sounds pretty good except for the aforementioned "issues". Those "issue" occurs while Stopping the valve. There appears to be a conflict if the state of the map is 1 0 / 0 0 or 0 1 / 0 0 .

At map-state 1 0 / 0 0 , the Dashed Dark Blue line indicates that the processor wants to turn ON "OPENING". However, if we arrived at 1 0 / 0 0 from 1 0 / 0 1 , then we are trying to STOP a Closing Valve - NOT OPEN the valve.

Likewise, at map-state 0 1 / 0 0 , the Dashed Red line indicates that the processor wants to turn ON "CLOSING". However, if we arrived at 0 1 / 0 0 from 0 1 / 1 0 , then we are trying to STOP an Opening Valve - NOT CLOSE the valve.

So....... how the hell do we handle this conflict ???? The trick is to determine where the map is coming from when it arrives in one of these states.

In general, at those locations, follow the Solid Lines OUT of those locations to 0 0 / 0 0 UNLESS you are arriving at these locations from 0 0 / 0 0 !!

So, how do you KNOW that you are arriving from 0 0 / 0 0 ??

This is where the sequential nature of the PLC comes in real handy. Now is the time to refer to that "ARMED TO START" in 0 0 / 0 0 . We can specify that the system is "ARMED TO START" if, neither button is pressed and the valve is NOT moving. In this condition, the valve is "READY to START MOVING". This means that if you arrive at 1 0 / 0 0 from anywhere but 0 0 / 0 0 , then it is NOT READY TO START! Likewise for 0 1 / 0 0 .

Sooooo.... how do you actually produce this effect ???? You do it in Ladder using "ARMED TO START"!

(INSERT CLOSING)
3dd6dd8e2d9b81f3.gif


(INSERT OPENING)
3dd6de031715e129.gif


(INSERT ARMED)
3dd6de8c61098bb4.gif


I hate saying "obviously" so instead I'll say, I reckon you should be able to simply look at the ladder code and see what I mean. If there are ANY questions, PLEASE, ASK! (Maybe I'm missing something)

The Ladder listing above also includes Limit Switches. I hope the implementation of the Limit Switches is apparent. If not, PLEASE, ASK!
 
My Solution (part 1)

Wow.

I'm almost embarrassed to post my solution/methodology now. But perhaps a lurker can benefit from it, or the discussion that it might bring, so here goes.

My first attempt used oneshots (to capture just the initial push of the button), and then latched in the "instruction" that the push meant. That produced the following:


OPEN_PB CLOSE DO_OPEN
---| |---|ONS|---+---|/|-----(L)
|
| DO_CLOSE
+-----------(U)


CLOSE_PB OPEN DO_CLOSE
---| |---|ONS|---+---|/|-----(L)
|
| DO_OPEN
+-----------(U)


DO_OPEN OPEN
---| |-----------------------( )


DO_CLOSE CLOSE
---| |-----------------------( )


.
(NOTE: For simplicity sake, I'm leaving out other conditions, such as interlocks and the Open and Closed limit switches in all my examples.)

This works, but as I said, it felt unsatisfactory. Putting oneshots onto contacts that were already "almost" oneshots themselves (but were not necessarily so, due to asynchronous communications), and using the Latches (which I'm not 100% against - sometimes they ARE appropriate - but I always look to see if there's a different way when I'm "forced" to use them.)

I don't speak STL well, but I think that this is the same code that Karl POSTED HERE .

<hr>

So, as I said, I went through some old posts...

http://www.plctalk.net/qanda/showthread.php?s=&threadid=188
http://www.plcs.net/dcforum/DCForumID5/1282.html - follow the link to URL=http://www.geocities.com/plctech99/ButtonLadderAllPages.pdf]HERE[/URL]

... and started to draw a State Diagram. Since I'm still not good with K-maps, I started it freehand.

Start with a State in which the valve is neither being opened or closed. Call this State A.



+-----------+
| A |
| OPEN = 0 |
| CLOSE = 0 |
+-----------+


.
Pushing the OPEN_PB transitions the system to State B, where the Open output is ON.



+-----------+ Press +-----------+
| A | OPEN_PB | B |
| OPEN = 0 |-->-->-->-->--| OPEN = 1 |
| CLOSE = 0 | | CLOSE = 0 |
+-----------+ +-----------+


.
The system stays in State B as long as the OPEN_PB is pressed. This part is VERY important.



/---<--<--+
V \ Press
+-----------+ Press +-----------+ | OPEN_PB
| A | OPEN_PB | B | / (cont)
| OPEN = 0 |-->-->-->-->--| OPEN = 1 |-->-+
| CLOSE = 0 | | CLOSE = 0 |
+-----------+ +-----------+


.

Rather than trying to draw this out in ASCII, I created the following complete State Diagram:

[attachment]

Now to (try to) make the K-map. Again, since I don't know what I'm doing, I start with a table:

<table border="2" cellspacing="1" cellpadding="2"><tr><td> STATE </td><td> OPEN </td><td> CLOSE </td></tr><tr><td>A</td><td>0</td> <td>0</td></tr> <tr><td>B</td><td>1</td><td>0</td></tr><tr><td>C</td> <td>1</td><td>0</td></tr> <tr><td>D</td><td>0</td><td>0</td></tr><tr> <td>E</td><td>0</td><td>1</td></tr><tr><td>F</td><td>0</td><td>1</td> </tr><tr><td>G</td><td>0</td><td>0</td></tr></table>

What was clear from this table was that there was not a unique combination of bits describing each state. State A was the same as States D and G; States B and C were the same. So I knew I'd need some "helper" bits to make each state unique.

Since I've got 3 states that are identical, I would need to add at least 2 extra bits, even though, with 7 states, I should be able to describe the system with only 3. But since OPEN and CLOSE are never ON at the same time, that forces the need to describe it with 4 bits.

This is what I decided on:
<table border="2" cellspacing="1" cellpadding="2"><tr><td>STATE</td><td>OPEN</td><td>CLOSE</td><td>__X__</td><td>__Y__</td></tr><tr><td>A</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>B</td><td>1</td><td>0</td><td>0</td><td>0</td></tr><tr><td>C</td><td>1</td><td>0</td><td>1</td><td>0</td></tr><tr><td>D</td><td>0</td><td>0</td><td>1</td><td>0</td></tr><tr><td>E</td><td>0</td><td>1</td><td>0</td><td>0</td></tr><tr><td>F</td><td>0</td><td>1</td><td>0</td><td>1</td></tr><tr><td>G</td><td>0</td><td>0</td><td>0</td><td>1</td></tr></table>
I think, but haven't bothered to check, that a solution would be worked out if X and Y were set on other States as well. But I also knew that putting them where I did would work out neatly.

With each state having a unique combination, I could program it as I have done sequencers in the past. Just assign each State a number (from the table, using binary, A=0, B=8, C=10, etc), and the logic:


+--- EQU --+ OPEN_PB +------ MOV --+
| STEP = 0 |-----+----| |------| 8 ==> STEP |
+----------+ | +-------------+
|
| CLOSE_PB +------ MOV --+
+----| |------| 4 ==> STEP |
+-------------+


+--- EQU --+ OPEN_PB +------ MOV --+
| STEP = 8 |----------|/|------| 10 ==> STEP |
+----------+ +-------------+


.
And so on, and drive the outputs when the STEP was on the approprate numbers.

But that's not what I wanted.

Terry could convert the above table to a proper K-map, and show how to reduce it. I went straight to the ladder.

The question has always been "When do I energize the OPEN output?". Fron the table above, the answer is "When I'm in States B and C".

Well then, when do I get into States B and C?
Answer:
When in State A, and OPEN_PB is pressed, OR
When in State B, and OPEN_PB is (continued to be) pressed, OR
When in State B, and OPEN_PB is released, OR
When in State C, and OPEN_PB is (continued to be) released.

In Ladder, this would look like this:


+-------- STATE DESCRIPTION ------+ +--- TRANSITION --+
/ \ / \

OPEN CLOSE X Y OPEN_PB CLOSE_PB OPEN
A ==> B ---|/|-------|/|-------|/|-------|/|-------| |-------|/|----+-----( )
|
OPEN CLOSE X Y OPEN_PB CLOSE_PB |
B ==> B ---| |-------|/|-------|/|-------|/|-------| |-------|/|----+
|
OPEN CLOSE X Y OPEN_PB CLOSE_PB |
B ==> C ---| |-------|/|-------|/|-------|/|-------|/|-------|/|----+
|
OPEN CLOSE X Y OPEN_PB CLOSE_PB |
C ==> C ---| |-------|/|-------| |-------|/|-------|/|-------|/|----+


.
Now this can be reduced quite a bit. For example, each branch contains a -|/|- CLOSE, Y, and CLOSE_PB. These can be made into a single contact on a common branch.

Rearranging, produces this:

CLOSE_PB OPEN_PB OPEN X CLOSE Y OPEN
-----|/|---+---| |-------|/|-------|/|---+---|/|-------|/|-------( )
| |
| OPEN_PB OPEN X |
+---| |-------| |-------|/|---+
| |
| OPEN_PB OPEN X |
+---|/|-------| |-------|/|---+
| |
| OPEN_PB OPEN X |
+---|/|-------| |-------| |---+


.
This can be further reduced to:

CLOSE_PB OPEN_PB X CLOSE Y OPEN
-----|/|---+---| |-------|/|---+---|/|-------|/|-------( )
| |
| OPEN_PB OPEN |
+---|/|-------| |---+


.
In the same manner, the other 3 rungs can be generated:

OPEN_PB CLOSE_PB OPEN CLOSE Y X
-----|/|---+---|/|-------| |---+---|/|-------|/|-------( )
| |
| CLOSE_PB X |
+---| |-------| |---+


OPEN_PB CLOSE_PB Y OPEN X CLOSE
-----|/|---+---| |-------|/|---+---|/|-------|/|-------( )
| |
| CLOSE_PB CLOSE |
+---|/|-------| |---+


CLOSE_PB OPEN_PB CLOSE OPEN X Y
-----|/|---+---|/|-------|/|---+---|/|-------|/|-------( )
| |
| OPEN_PB Y |
+---| |-------| |---+



If you watch when the two helper bits come on, X comes on after OPEN (and the OPEN_PB has been released). Therefore, a better name than 'X' is "WAS_OPENED". Similarly, "Y" should be renamed "WAS_CLOSED".

And that's it!

statediag.jpg
 
My Solution (Part 2)

Only it's not it!

After generating the above, I started playing "WHAT IF".

"WHAT IF the OPEN_PB is pressed when the valve is opening?"

While the valve is opening, both OPEN and WAS_OPENED ("X") are ON. Pressing OPEN_PB causes BOTH to DROP OUT! If the OPEN_PB is still ON during the next scan, then OPEN comes back on.

Clearly, this isn't right.

What's happening is that when the OPEN_PB is pressed, I'm in State C, and I go from State C to State A for one scan, and then onto State B in the next scan. The State Diagram I drew up needed to include an arrow going directly from State C to State B is OPEN_PB is pressed.

But that means that there are 5, not 4, ways to set OPEN. I would need to add the following branch to the rung:
 
OPEN CLOSE X Y OPEN_PB CLOSE_PB |
C ==> B ---| |-------|/|-------| |-------|/|-------| |-------|/|----+


.

This would result in the final rung looking like this:


CLOSE_PB OPEN_PB X CLOSE Y OPEN
-----|/|---+---| |---------------|/|---+---|/|-------|/|-------( )
| |
| OPEN_PB OPEN |
+---|/|-------| |-----------+
| |
| OPEN_PB OPEN X |
+---| |-------| |-----| |---+


.
You can see that the added branch does exaclt what it needs to - maintaining the OPEN if in state C and the OPEN_PB is pressed.

The next WHAT IF was the stuck valve scenario. The state diagram allows a single PB to be stuck (for example, if OPEN_PB is stuck, the system stays in State B). But what happens if it's stuck in State B, and then the CLOSE_PB is pressed? The state logic doesn't say. Following the ladder, the OPEN will drop out (going to State A), but as soon as the CLOSE_PB is released, it will OPEN back up.

No good.

What it needs to do is go from state B to state G. This will turn off the outputs, but state G can't be left until OPEN_PB is fixed. This adds a new branch to the WAS_CLOSED rung. I'll leave it to anyone who cares to work it out.

<hr>

Well, that's my solution. Not as elegant as either Terry's or Norm's .

But I thought some folks might be interested in the methodology.
 
Allen,
I went through your reply and went to those early threads you referenced.

Gee, memories... huh? I miss Pierre!

Anyway, looking at those earlier posts, and your reply, I see the common question is...

"K-Maps are cute! So What! How do you make code out of it ???

Here's how.

The first map that I posted was to show what was happening within the process. This "ACTION" caused that "REACTION" etc. It also pointed out, in a glaring fashion, that there were special issues that needed to be addressed.

The ultimate aim of the map is to identify when the Valve should be Closing, and when the Valve should be Opening. That is, under what conditions do we ASSERT "CLOSING", or ASSERT "OPENING". If we are not asserting the Closing or Opening of the valve, then the valve should not move.

So, after having shown the map that illustrates the ACTION/REACTION relationships, now we look at the map in terms of generating code to support those Action/Reaction relationships. The following map identifies those locations in the map that produce the desired effect... either OPENING or CLOSING.

(INSERT NEW MAP)
3dd7f69b1d2bc938.gif

.
Notice that, out of the 16 possible locations, there are only two locations where the valve is told to CLOSE. Likewise, only two locations where the valve is told to OPEN.


Simplify OPEN:

0 0 1 0
1 0 1 0
-------
X 0 1 0


CLOSE
P B OPENING CLOSING
------| / |----------| |----------| / |------------( OPENING )



Simplify CLOSE:

0 0 0 1
0 1 0 1
-------
0 X 0 1


OPEN
P B OPENING CLOSING
------| / |----------| / |----------| |------------( CLOSING )



.
According to the map, either one of those condition-sets will maintain themselves.

Once in either set of conditions, the output is self-sustaining. The problem is... How do we get into one of those condition-sets?

Seems we can go to Closing by bringing the map to 0 1 0 0 . Also seems we can go to Opening by bringing the map to 1 0 0 0 . But then, Damn! Wouldn't you know it... there's two ways to get into 0 1 0 0 and 1 0 0 0 .

If the Valve is OPENING and we press the CLOSE_PB then the map goes from 0 0 1 0 to 0 1 1 0 to 0 1 0 0.

"0 1 0 0" seems to be what we need to START CLOSING! So, having pressed the CLOSE_PB to Stop the Valve we go right into CLOSING!

If the Valve is CLOSING and we press the OPEN_PB then the map goes from 0 0 0 1 to 1 0 0 1 to 1 0 0 0.

"1 0 0 0" seems to be what we need to START OPENING! So, having pressed the OPEN_PB to Stop the Valve we go right into OPENING!

After getting to this stage, I see that I could have made the ladder a little better. (Another one of the great things about K-Maps is that they show you what you missed.)

In order to handle this problem we simply need to know where the map is coming from when it gets to one of those locations. Actually, we only need to know if the map WAS at 0 0 0 0 . The Ladder Code provides the means to "KNOW" if that is where the map WAS.

(INSERT NEW LADDER)
3dd7f6e963f73ddc.gif

.
The last segment of code in this module looks to see if Neither PB is Pressed and that the Valve is NOT Moving. If so, then the map is ARMED TO START a move. Otherwise, the process is NOT ARMED TO START a Move. So, if the map enters one of those locations and the map is NOT ARMED, then the map goes to 0 0 0 0.

Does that explain any better how the code is generated from the map?
 
I understand, but I don't grok

Terry:

I can follow everything that you've done.

I can echo it back to you.

But I'm not sure that I can set up one of my own with a different problem. There's something that I can feel that I'm not getting, but I can't figure out what it is. I don't think of it as a failure of you as a teacher, but of me as a student.

That was in part why I went through the exercise (and, if I were to give myself a grade, got a C+). I'll keep my eyes open for another example to test myself on, as time permits. (One thing I noticed was that my first solution, with the latches and oneshots, took about 5 minutes to whip up - the other code took almost an hour (longer to present it here).)

One thing that interested me about the code that I got, was that the rungs are not scan-order dependent. You can put them in any order you like, and you'll get the same results. Your code (an Norm's) depend on the scan order. If you move the ARMED_TO_START rung ahead of the other two, the valve will never move.

Not that it means anything, I just thought it was interesting.

Keep preaching the use of tools like K-maps (and any other techniques you know), and maybe the light will dawn one day. I know that this is the hardest thing to teach - HOW to think. HOW to set up problems so that they solve themselves.

Thanks again.

Allen
 
There's something that I can feel that I'm not getting, but I can't figure out what it is.

I can relate to that one. I still don't get why the trig functions work in Calculus! I know they do, but WHY???

I don't think of it as a failure of you as a teacher, but of me as a student.

It's both of us until it's resolved, or one of us quits.

...if I were to give myself a grade, got a C+.

aaaaaaah don't be so hard... not yet.

I'll keep my eyes open for another example to test myself on, as time permits.

ME TOO! I'll keep my eyes open for some more simple examples. Actually, a guy named John just posted a "Request for Code" for a very simple sequencer. I'll look at it in terms of the K-Map.

And, I'VE JUST GOT TO GET KALLE'S TWO-GUYS/TWO-GALS thing finished! It's a good exercise in Multi-Dimensional K-Maps! And besides, referring back to those early posts you pointed to, Ron's accusation that K-Maps are useless because I couldn't post those particular maps is (and has been) nagging at the back of my very busy brain!


(One thing I noticed was that my first solution, with the latches and oneshots, took about 5 minutes to whip up - the other code took almost an hour (longer to present it here)

To which I can only say...
As the number of variables increases, the possibilities also increase, but much more so! Without some kind of organizational tool, it doesn't take much more than a few variables to have a system become unmanageable! Sure, the easy ones are easy. But the harder ones are Damned Hard!


One thing that interested me about the code that I got, was that the rungs are not scan-order dependent. You can put them in any order you like, and you'll get the same results.

I do GROK what you are saying! And, the map I made could have done the same thing IF I had included a bit in the map to indicate "ARMED".

We would have needed a 2x3 or 3x2 map instead of the 2x2 map. Simply because even K-Maps can become unmanageable, you should try to keep the number of entries (inputs) as minimal as possible.

If we used 5-elements instead of 4, we would not have run into the situation of arriving at 1000 or 0100 and not known if the map was "ARMED". Actually, we would have arrived at 01000 or 00100.

If we assume that the leading bit indicates "ARMED" (0 = "NOT ARMED" and 1 = "IS ARMED"), then arriving at 01000 or 00100 would direct the map to 00000 without any conflict at all!

In that case, the sequence in LADDER would not matter. HOWEVER, bear in mind, the sequence in the map DOES MATTER!

The sequence in the K-Map ALWAYS Matters - not necessarily from square to square, but certainly from column to column, and row to row. This deserves more discussion - later... tomorrow?

Sooner or later, either here or there, the sequence matters.


Not that it means anything, I just thought it was interesting.

It does mean something... it means that sequencing responsibility is shifting from the map to the ladder, at least, in this particular case.

I know that this is the hardest thing to teach - HOW to think.

I reckon teaching to think is just about as hard as it is to learn to think. But, at some point, maybe while you are sleeping, a little hunk of grey-matter will connect to another little hunk, and in the morning you'll have the AHA!!! DAMN!!! I LOVE WHEN THAT HAPPENS!!!

HOW to set up problems so that they solve themselves.

Now, that is the Holy Grail!
 
Another View

I used Moore diagrams. I think this is much simpler and straightforward when handling states. Why? Because Karnaugh maps depend on the inputs not changing during the scan. This happens because of the sequential nature of a PLC scan. Terry alluded to that fact in his first post. In a FPGA, all the inputs are latched for the clock cycle and don't change for that clock cycle. In this case Karnaugh maps work flawlessly, but not so in PLCs.

Look at the state diagram below. It generates code of similar complexity as Terry's but I think it is more obvious as to how it is generated. This method too can have the race conditions that jump two states in one scan. The trick is to place the transitional state at the end of the scan. This way only one state can change at a time.

How does one post a bitmap. It kept asking for a URL? How can that be if the bitmap is on my computer? NO HELP IN THE FAQ PHIL!
Tell me quick and I will edit this post.
 
Last edited:
Re: Another View

Peter Nachtwey said:
How does one post a bitmap. It kept asking for a URL? How can that be if the bitmap is on my computer? NO HELP IN THE FAQ PHIL!
Tell me quick and I will edit this post.

Hi Peter,
If you use the 'img' button it expects that the image is on a website somewhere.(hence it asks for the url) So, if the image is on your pc and not somewhere on the Inet, use the 'attach file' function by clicking the 'browse' button.
You did it correctly in the end. :D

For reference, gif and jpg images are displayed in the forum and bmp (bitmaps) files must be downloaded by the viewer. (like a zip file)
So, if you have the software, try and save your images as gif or jpegs if you want them displayed in the forum.(gif is best as they are smaller file sizes and in particular when you use text in the image they display better)
Sorry for the inconvenience...
Enjoy,
 
No cigar for Peter.

I'm sorry Peter, but I don't think your solution works.

I've added the ladder that you have the boolean for to your state diagram drawing (I converted it to a JPG using Microsoft PhotoEditor - it comes as part of Office, but it may not be part of the default installation.)

[attachment]

I've toggled the bits to produce the OPENNING condition, and everything looks OK.

But, if on the next scan, CLOSE_PB is pressed, nothing will happen to CLOSING (correct), OPENNING will drop out (correct), but since OPENNING has dropped out on the previous rung, STOPPED won't come on (incorrect). Releasing the button won't help.

This is the kind of scan-race that makes this problem tricky. Moving the STOPPED rung doesn't solve the problem.

It's a shame, because it would have been a cleaner solution.

open and close.jpg
 
Yes, I know and Terry's has a flaw too.

openclose.bmp


OPENNING = NOT CLOSEPB AND (STOPPED OR OPENPB)

CLOSING = NOT OPENPB AND (STOPPED OR CLOSEPB)

STOPPED = (STOPPED AND NOT (OPENPB OR CLOSEPB))
OR (WASOPENNING AND NOT CLOSEPB)
OR (WASCLOSING AND NOT OPENPB)

WASOPENNING = (WASOPENNING OR OPENNING) AND CLOSEPB

WASCLOSING = (WASCLOSING OR CLOSING) AND OPENPB

As one can see another step is required to handle the case where the OPEN PB is immediately followed by the CLOSE PB. Terry's solution requires that the is a state where both the OPEN PB and CLOSE PB are both off at the same time before the other input is turned on. Mine will handle the case where CLOSE PB is immediately followed by OPEN PB on the next scan.

Notice that the equation are generated using the diagram. One just must have an equation for each state. The must be a term for each state that indicates how the state is entered or maintained.

Allen, don't be sorry for my mistake. I know you were being polite but I am a big boy and can admit I made a mistake. I knew I screwed up shortly after posting. I corrected it once and it was still screwed up, but I couldn't edit it anymore because I ran out of time. I just hate to make mistakes.
 
Terry, wow, you really put the meat and potatoes behind this one. I was flying by the seat of my pants to come up w/ my inhibit logic which is kind of the opposite of your Armed (or what I would call enable) method.

Your three rung answer is definately the most elegant for this problem. I tried to whittle mine down but kept getting stuck. Of course, you have the power of MGD while my standard fuel consists only of Diet Coke and Snickers Bars :p (I'm not a tea totaler or anything, just getting too old for the morning after)

Great thread which brings back memories of my digital EE class they made us Mechanical Engineers take. I had remembered what the K-maps looked like but not how to use them. Thanks for the refresher
 

Similar Topics

I was looking for this because I did not have the EDS file for the camera. I also just like to know what all the bits do sometimes. If you want to...
Replies
0
Views
914
Hey guys, I am using the logging function of the Productivity PLC (P-550) to log 64 tags into a CSV file. I can access these files using the...
Replies
10
Views
4,300
Hi, I use a 1768-L43S CompactLogix5343S Controller to connect with Rexroth with Air Weld Gun. the problem is when I use this controller to program...
Replies
14
Views
2,119
In my mind there is a clear rationale to favour the use of input map routines with compactlogix controllers. The inputs are updated...
Replies
5
Views
2,002
Hi All, I am new to Modbus so please be kind. I have a Modbus temperature sensor (R444A0). Details of the R444A01 Digital display Modbus...
Replies
1
Views
1,887
Back
Top Bottom