Positive edge detection in SCL (S7)

[Terry Woods]

Ken M,

In my first post, I referred to "WAS-xxx". That was nothing more than my version of Lesa's "x_old".

When I said...

"WAS-xxx" counts... BIG TIME!
And it will ALWAYS work!"

...I was only saying, with respect to transition detection, that the recording, and the usage, of the previous state of an input really counts... BIG TIME! And further, whether you have an edge-detection function or not, the method described below ALWAYS works!

As far as xEdgeDetected...

I wouldn't, and don't, do it that way. I do it like this...

If "X", and NOT "Was-X",
...then SET "Was-X" (as in... the last time I looked, X was ON)
...and turn on "X Just ON!" (for one scan)

If "Was-X" and NOT "X",
...then RST "Was-X" (as in... the last time I looked, X was OFF)
...and turn on "X Just OFF!" (for one scan)

I find that I use both cases, Just ON, and Just OFF, more often than only one or the other. So I generally tend to create both if I find a need to create either. Like so...

      X       Was-X

  ---| |-------|/|---+---( SET ) Was-X (Stays on until X OFF is seen in the next rung)

                     |

                     +---(     ) X Just ON (ON for just one scan)







      X       Was-X

  ---|/|-------| |---+---( RST ) Was-X (Stays off until X ON is seen in the prev rung)

                     |

                     +---(     ) X Just OFF (ON for just one scan)

.
In my next post, I provided a rather cryptic message that making decisions based on current Input conditions (not speaking of control relays) is not necessarily the best thing to do. (After reading the following, the message shouldn't be so cryptic.)

If we assume that only one Input changes at a time, it could be that the condition just prior to condition X,Y,Z could have been any one of the following...

Case-1: NOT-X, Y, Z
Case-2: X, NOT-Y, Z
Case-3: X, Y, NOT-Z

Now... depending on the particular process, it might very well be important as to how the current condition came to be... that is, from Case-1, or Case-2, or Case-3.

If XYZ FROM Case-1, then Do "A"
If XYZ FROM Case-2, then Do "B"
If XYZ FROM Case-3, then Do "C"

How do you KNOW that XYZ came from Case-1? "X Just ON"
How do you KNOW that XYZ came from Case-2? "Y Just ON"
How do you KNOW that XYZ came from Case-3? "Z Just ON"

The same methodology can be applied to any one of those Inputs going Just OFF.

If the combination of concern is NOT-X,Y,Z...

It could be that the condition just prior to condition X,Y,Z could have been any one of the following...

Case-1: X,Y,Z
Case-2: NOT-X, NOT-Y, Z
Case-3: NOT-X, Y, NOT-Z

If NOT-X,Y,Z FROM Case-1, then Do "A"
If NOT-X,Y,Z FROM Case-2, then Do "B"
If NOT-X,Y,Z FROM Case-3, then Do "C"

How do you KNOW that NOT-X,Y,Z came from Case-1? "X Just OFF"
How do you KNOW that NOT-X,Y,Z came from Case-2? "Y Just ON"
How do you KNOW that NOT-X,Y,Z came from Case-3? "Z Just ON"

The point being, "History Counts!"

If you can "get" all of this, then my post prior to this one should make more sense. If not, just say so.

 

[Ken M]

This could last for months!

I fully agree that knowing the previous (WAS) state of an input or flag is useful and sometimes essential. Clearly Lesa also knows this otherwise the first post in this thread would not have been written. What was asked there was not "is this something that needs to be done?" but "is this the way to go about doing this thing which I already know needs to be done?" The importance of trapping previous states and responding to changes in states has never been in question.

Lesa offered the first version of code and asked for opinions. Simon recommended his slightly revised version. Significantly Simon answered using SCL, whereas you've illustrated your most recent explanation by using ladder logic. Peter then answered referring to the use of instructions covered in the IEC ST spec. Again, this seemed entirely relevant. Then Terry chips in saying how important knowing the previous state of an input is. Eh?

I think we're getting in to the realms of angels dancing on a pinhead here, Terry. We both know what we're coming from, and I don't think we're going to change our opinions in this thread at least. Shall we call it quits?

Regards

Ken

 

[Terry Woods]

OK, Ken...

But in the meantime, maybe some of the others can pick-up on and learn some of the nuances of this game.