tattle tale

Ron Beaufort said:
Greetings to all ...

but don’t just take my word for it ... let’s run an experiment to prove the point ...

I just ran a quick experiment using a “trap the difference” program similar to the one which my distinguished colleague OkiePC attached to his post #15 ... (I’ve attached my program below if anyone is interested in looking at it) ... actually ANY program which is capable of recording a difference from ONE SCAN TO THE NEXT will prove the point that I’m trying to make ... ...
Click to expand...

Hey, Ron I am glad you took the time to test this.

Note that my circuit is different than yours in that it had the unseal in circuit at the beginning of the string.

I call it the unseal circuit, because in the case of my application, it keeps the circuit alive until the little metal flapper inside the relay has a chance to flex back away from the normally open contact.

The micrologix 1000 is faster than the flapper in the relays I tested.

That's my backwoods take on it in lumberjack terminology, just to help others learn.

So, please if you have the time, unzip my file, and try it on your platform. You can leave it wired that way, and/or move the seal in to the beginning. I would expect the former to perform better.

I was using AC inputs, with relay outputs, 20in, 12 out I believe. I never actually attached more than six alligator test inputs at a time, it became to cumbersome to store and carry around with more than 6. I never took the time to enclose it. I wanted to box it with banana plugs on front and output LEDs.

I am confident, provided you have a slow enough opening relay, the results will be inverted, and you will get 80% useful results.

And, thanks for calling me distinguished! I am honored.

Paul
 
Last edited:
I apologize for not making myself clear ... you guys seem to be totally missing my point - and if you are, then I’ll admit that it's MY fault for not being more precise ...



I'm short on time - but I'll try again ...



the point is that when two PLC inputs happen to ELECTRICALLY change state at precisely the same time, both of those changes of state will not always (I repeat: NOT ALWAYS) be reflected on the input data table AT PRECISELY THE SAME TIME ... usually they will - but NOT always ...



this point is hardly ever (never?) brought out in most PLC classes - so most people just assume that whenever the field inputs ELECTRICALLY change state, then the PLC will ALWAYS correctly update its data table with “the latest” information from the field ... and in a perfect world it would ...



let me say it another way ... when two inputs ELECTRICALLY change state at precisely the same time, the PLC is not guaranteed to “see” the changed status of both of those inputs at precisely the same time ... nor is it guaranteed to reflect the changed status on its input data table at precisely the same time ... specifically, there may be a “delay” of one scan (or more?) during which ONE input might show up on the data table as “changed” but the other might still be “unchanged” ...



in normal programs this potential “delayed update” doesn’t matter because the “slower” inputs tend to “catch up” on the next scan ... the program that you guys are writing is different ... you (correct here me if I’m wrong) are trying to tell which one of several inputs was the “first out” ...



now the LADDER LOGIC of the program that you’re writing is not the issue ... the issue relates to how the PLC updates its input image table with the status of the field inputs ...



from Lancie1:



I believe that Okie is an honest fellow, and I also have used this method as a First Out indicator for a gas-fired burner. It worked well enough to determine which of the interlock switches was not staying closed during light-off.
Click to expand...
I too believe that Okie is honest - and I apologize profusely if I gave the impression that I somehow doubted his honesty ...

let me nail this down ... take a look (in post #25) at the data from the test I ran this morning ... I ran six tests in which the program functioned EXACTLY as I expected ... for many people that would have been enough evidence to prove that the system could be expected to work perfectly in the future ... the only reason that I kept right on testing is because I personally KNOW from past experience that the system is indeed RANDOMLY and INTERMITTENTLY flawed ... now in spite of making a LARGE number of “good” tests, I’d have still bet the rent (and won) that if I kept right on testing, eventually (randomly) I’d get a “bad” result ... it’s the nature of the beast ...



analogy: the first six dogs didn’t bite me ... does that PROVE that NO dog will ever bite me? ...

and then after test #7 was “bad” I kept on testing ... the next “bad” test didn’t come around until test #40 ... that’s a LOT of “good” tests and just a couple of “bad” tests ... but it would be unwise to ignore the fact that those “bad” tests did, in fact, occur ...

As your failure analysis is also slightly flawed. You were using a pushbuton, but the circuit in question is using a MCR physical relay.
Click to expand...


I respectfully submit that my test method was NOT flawed ... specifically, the test was intended to show that when ALL ten field inputs ELECTRICALLY change state at precisely the same, the PLC will not always reflect ALL ten of those changes at precisely the same time on its data table ... I’m convinced that my testing method conclusively proves that point ...



The relay will not drop out for several scans after a switch contact opens. This is usually enough time for the PLC to detect which switch opened.
Click to expand...


I’ve got no argument there ... let’s look at this picture again ... I’ll allow that maybe you’re right - and maybe I’m wrong ... so put me out of my misery and tell me where I’m making my mistake ...


okiepcmcr_C.JPG




for discussion, let’s say that we’re dealing with a PERFECT WORLD ...



let’s suppose that the system is up and running and the MCR is “sealed in” ... all of the inputs A-B-C-D-E-F-and-G are all electrically ON ... all of the PLC bits A-B-C-D-E-F-and-G are showing a status of ONE on the input data table ... do you agree or disagree? ... I’ll assume that you agree and continue ...



suddenly the “weak contact” at switch C electrically opens - even just momentarily ... while switch C is open, there will be NO current flow to the MCR coil ... the MCR will “drop out” ... do you agree or disagree? ... I’ll assume that you agree and continue ...



now IN A PERFECT WORLD, while the switch C is momentarily open, the inputs to the PLC would have the following status:



input A DOES have voltage and the bit’s status is ONE ...

input B DOES have voltage and the bit’s status is ONE ...

input C does NOT have voltage and the bit’s status is ZERO ...

input D does NOT have voltage and the bit’s status is ZERO ...

input E does NOT have voltage and the bit’s status is ZERO ...

input F does NOT have voltage and the bit’s status is ZERO ...

input G does NOT have voltage and the bit’s status is ZERO ...



remember that we’re assuming a perfect world here ... do you agree or disagree with all of this? ... I’ll assume that you agree and continue ...



side trip: now Lancie I know that you’re not going to make a mistake and think that ONLY input C is going to show a change of state to the PLC - but some of our beginner readers might ... let me just draw their attention to the fact that we’re dealing with a series circuit ... so when the contacts go “open” at switch C, inputs D-E-F-and-G will also go OFF ...
Click to expand...


now suppose that our program perfectly records an accurate “snapshot” of the data above ... based on that record, what conclusion would we come to? ... looks like switch C is the “first out” culprit ... the fact that those other “downstream” inputs went OFF doesn’t really bother us - because of the way the inputs are wired in series ... do you agree or disagree with my conclusion? ... I’ll assume that you agree and continue ...



now let’s leave the perfect world behind and deal with reality ...

continued in next post ...
 
Last edited:
continued from previous post ...

in a REAL WORLD situation ...



again, suppose that the system is up and running and the MCR is “sealed in” ... all of the inputs A-B-C-D-E-F-and-G are all electrically ON ... all of the PLC bits A-B-C-D-E-F-and-G are showing a status of ONE on the input data table ... do you agree or disagree? ... I’ll assume that you agree and continue ...



suddenly the “weak contact” at switch C electrically opens - even just momentarily ... while the switch is open, there will be NO current flow to the MCR coil ... the MCR will “drop out” ... do you agree or disagree? ... I’ll assume that you agree and continue ...



now in our REAL WORLD while switch C is momentarily open, the inputs to the PLC would have the following ELECTRICAL status:



input A DOES have voltage ...

input B DOES have voltage ...

input C does NOT have voltage ...

input D does NOT have voltage ...

input E does NOT have voltage ...

input F does NOT have voltage ...

input G does NOT have voltage ...



do you agree or disagree? ... I’ll assume that you agree and continue ...



now while switch C is momentarily open, let’s talk about the PLC’s input data table ... (and now we come to my point) ...



input bit A has a status of ONE ...

input bit B has a status of ONE ...

input bit C could have a status of ONE ... (NO voltage - but STILL ONE - not a typo)

input bit D could have a status of ONE ... (NO voltage - but STILL ONE - not a typo)

input bit E could have a status of ZERO ... (not a typo)

input bit F could have a status of ZERO ... (not a typo)

input bit G could have a status of ZERO ... (not a typo)



remember that we’re dealing with a real and IMPERFECT world here ... so even though inputs C and D have NO voltage applied, the status of bits C and D could STILL BE SHOWING a status of ONE on the input data table ...



now at this point, I wouldn’t be surprised to have you disagree ... but I’ll assure you that if you’ll run your own experiments, you’ll find that this “randomly scattered” update of the PLC’s input table is a fact that cannot be simply ignored ... so even though I expect a (temporary) disagreement, let’s move on ...



now suppose that our program perfectly records an accurate “snapshot” of that “flawed” data above ... based on that record, what conclusion would we come to? ... looks like input E is the “first out” culprit ... the fact that those other “downstream” inputs went OFF doesn’t really bother us - because of the way the inputs are wired in series ... do you agree or disagree with my conclusion? ... I’ll assume that you agree and continue ...



and so ... we confidently tell the boss that we’ve found the problem that’s been driving everyone else crazy ... we replace switch E and crank the machine up ... the sun is shining ... the birds are singing ... life is lovely ... but then all of sudden switch C flakes out again ... oops! ...

Not perfect, but a lot better than sending an electrician out without ANY clue which switch opened. Think fuzzy logic instead of precision logic. If there is a bad switch in a string of 10, and we don't want to have to check all 10, then which of the 10 is the most likely to be causing the problem? That is all we need, a place to start checking.
Click to expand...


PLEASE read what I originally posted and you’ll find that I am NOT arguing with you about this ... YES, this “PLC Tattle Tale” method can be useful ... I didn’t say that it was “useless” ...



my point is different ... my point is that although it’s USEFUL, it should NOT be considered “error proof” ... you and I apparently saying the same thing ...

if someone has developed a more reliable PLC First Out method, I will be one of the first to adopt it. Anyone got one that is better than 93%?
Click to expand...


to that I would add this ... as you search for that more reliable PLC “first out” method, keep in mind that the PLC doesn’t see its field inputs in “real time” ... that means that even a program which has been perfectly WRITTEN is still likely to be flawed by the imperfect registering of the PLC’s input bits ...



in closing ... I had NO INTENTION of “spoiling the soup” that you guys have been working on ... I just wanted to make you aware of an issue that most people do NOT know about ... in most programs that issue doesn’t matter - because a delay of “one scan” more or less doesn’t affect the operation of the program ... but in other cases, a delay of “one scan” can cause quite a bit of heartburn ... the “PLC Tattle Tale” program being discussed in this thread is such a case ...



once again, if you haven’t read the material here and here, I’d highly recommend that you do so ... other posters in those threads actually tried the experiments that I suggested for themselves - and confirmed that what I’m saying is indeed true ...



now if anyone disagrees with what I’m saying, it’s probably because either:

(1) you haven’t tried the experiment for yourself ... or

(2) you don’t understand what I’m trying to tell you ...



if you don’t understand, please post and give me another chance to explain ... I will GUARANTEE that what I’m saying is correct ...



side trip: often I’ll have students in my classes with very little (or NO) prior PLC experience ... in the same class I might have students with many years of experience ... one of the topics that I assign to the “beyond beginners” is almost exactly the same “first out” exercise being discussed in this thread ... I actually keep a spare PLC swingarm permanently wired up with all of the inputs neatly jumpered together ... once the student has the swingarm installed on his station and the “status trap” program entered, I ask what results he expects to see when the inputs ALL change state AT THE SAME TIME ... then we discuss the difference between “theoretically expected” and “actually witnessed” ... more than once or twice I’ve had a student say something like: “So THAT’S what was happening to Machine #5” ...



finally ... would I personally ever use something like the “PLC Tattle Tale” program that we’ve been discussing? ... YES! ... ABSOLUTELY I would! ... I said in my earlier post that it could definitely come in handy ... but at the same time, I’d also realize that it has certain limitations - and I’d keep in mind that those limitations could give erroneous (and embarrassing) results ...



so all in all, I don’t really think that we’re disagreeing on anything ... again, I apologize if I didn’t make myself clear before ... hopefully I’ve done a better job this time around ...
 
Last edited:
The word that came to my mind was Latency of the input electronics but I wanted to test my thoughts first, then Ron posted, and I agree with what he has written as it describes my thoughts on Latency related to the inputs.

Another Ron used to talk about the WAS bit, in this case the input was on, then in the next scan it is now off, but the electronics on the input has not fully discharged in the last 10 mSec, and could yet give either answer, on or off, but on the next scan will most likely be off after a further 10 mSec.
 
PS Edit ... this post answers one that was posted by Lancie1 - but now it looks like he's deleted his post - probably to do some rewriting ... I'll leave this one here - but some of the items might need to be reworked once Lancie gets back to us ...

from Lancie1:

Only if you are talking about what happens during 1 scan.
Click to expand...


bingo! ... that is PRECISELY what I’m talking about ... that one little sliver of time when the inputs first change state ...



After enough time has passed (and several scans), Inputs C & D should change to 0.
Click to expand...


absolutely ... they will ... but (and here’s the catch) by the time those bits make the change to ZEROS, the “PLC Tattle Tale” will already have their status incorrectly recorded as ONES on the “troubleshooting chart” ...



Perhaps we are not talking about the same situation. You did mention something about the inputs switching at the exact same instant. That is not the case that my First Out is designed to catch.
Click to expand...


maybe that’s where I’m misunderstanding you ... ARE you - or are you NOT - working on a string of SERIES inputs set up like the ones in the picture that I’ve posted? ... if NOT, then please show me what type of wiring you are working with ... and could you also please post the program that you’ve been using? ... like you said, something’s not adding up ... this shouldn’t be that difficult ...



I always compare the switch in question to the one immediately upstream. If the one upstream is closed, but this one opens, then I latch in a bit.
Click to expand...


ok then ... we MUST not be talking about the same type of wiring as shown in the picture ... because in THAT circuit, when ONE switch opens (example: switch C) then all of the switches “downstream” of switch C are going to look “open” too as far as the PLC is concerned ... if your system can pick out ONE PARTICULAR switch in the middle of a string of several wired in series, then I’m definitely not getting a clear picture of your setup ...



If it doesn't open(or more importantly, the PLC doesn't "see" it open), then the program would not know that there was a problem and would take no action (yet) so there is nothing to record.
Click to expand...


the issue that I’m harping on is that the PLC might see some of the “downstream” switches as OFF and record their ZERO status - and then quit recording BEFORE it has a chance to see the actual “culprit” switch go OFF ... this is due to the “random delay effect” of the inputs ...



You are arguing that the PLC is incapable of seeing the "change",
Click to expand...


no - you’ve misunderstood ... I’m saying that in the series circuit that I’ve shown, the PLC will see SEVERAL inputs change state ... ELECTRICALLY the inputs are changing state at precisely the same time ... the PLC MAY see all of the inputs change state on the same scan ... but then again, it might NOT see all of the changes on the same scan ... in most “First Out” programs (but maybe not yours), when the PLC sees ANY of the monitored inputs change state, it records the status of ALL of the monitored inputs - and then it quits recording ... if another input happens to “show up one scan too late for the dance” then its status doesn’t get recorded ... and if that particular input just happens to be the one that caused the “drop out” condition, then we’re going to come to an erroneous conclusion about what’s causing our machine to shut down ...



if this doesn’t do it, maybe we can hash this out by phone ... I’m teaching this week but I’ll have some time available in the afternoon ... PM me your number and I’ll pay for the call ... we’re not arguing - we’re just not understanding each other ...
 
Last edited:
to Gil47 ...

"latency" is not the term that I use - but I'm 99.99% positive that you and I are talking about the very same thing ... I've heard other people say that sometimes a "signal is straddling the fence" at the instant that the PLC updates its input image table ... so the coin MAY land on heads - or it MAY land on tails ... now on the next scan, things should have had time to "settle out" ... but the primary objective of the "First Out" program is to nail down the conditions at the very instant that the "problem" occurs ...

so we don't always have the luxury of waiting for another scan or two for things to "settle out" ...

in a nutshell: PLCs are fast - but they are NOT instantaneous ... and (KEY POINT) some of their inputs may react quicker than others ... many (most?) people don't know that ...
 
Ron Beaufort said:
...
I'm short on time - but I'll try again ......
Click to expand...

If you had more time we would have a book :)

---------------------------------------------



When I get back to work I will take some pictures of the device that I have and try some test with it as I am sure its faster then a PLC, but I think it records the one that drops out first.

Like Paul, I also want to play with the micro processor, I have started looking for parts, but I'm kind of lost any ideas??

Where can I get the software and devices/parts? Paul have you found any?
 
Last edited:
Ron Beaufort said:
but the primary objective of the "First Out" program is to nail down the conditions at the very instant that the "problem" occurs ...

so we don't always have the luxury of waiting for another scan or two for things to "settle out" ...
Click to expand...


Ron,

So if we had this "luxury of waiting for another plc scan". Should we should take advantage of it? I think I can envision a way to do this in my application because the "unseal circuit" as Paul calls it is placed just like the picture. If there was a discrepancy between the two plc scans after an event, I could log and note the difference, and display accordingly.
 
Greetings Milldrone ...

I'm teaching this week so no time to write ... but I've set up "recorders" before to use indirect addresses and incrementing pointers to build a "scan-by-scan" chart of various bits ... basically a histogram on steroids ...

you could (at least in some applications) let "any change" in the monitored bits initiate a "settle down" timer ... once the timer has run for its (very brief) setting THEN take the snapshot of the "settled down" input data ...

I'll try to write more as time permits ...
 
Last edited:
geniusintraining said:
Like Paul, I also want to play with the micro processor, I have started looking for parts, but I'm kind of lost any ideas??

Where can I get the software and devices/parts? Paul have you found any?
Click to expand...

Google for Parallax's Basic Stamp. Has lots of shortcomings, but it is easy to get your feet wet.

I've moved on to Atmel's AVR microcontroller line. Here is one hobby project using an AVR that I designed and built.
http://i104.photobucket.com/albums/m168/agarb6/misc/avr.jpg

And a stepper motor driver:
http://www.bright.net/~agarb/STMD/Photos/Full%20Size/STMD_from_kit.jpg
 
Thanks alot for all of your replies. I got side tracked and honestly forgot that I had even posted this question. I like the relay idea, but would have had to set up about 5 of them to test all of the switches at once. My problem wound up being a bad diff. pressure switch. sorry for not replying sooner. Thanks again guy's.
 
So this the pic of the one I have... just thought I would share it, I still have not tested it... it is made by North American Mfg

If I ever get a chance I will try it, on the other side it has a single display for a number of the one that failed

0110081644.jpg
 
GIT,

How will it ever work? I know it can't be faster than a PLC, so according to Ron B it can't ever work....

He keeps saying that "if all the inputs go off at the same time..."

Why would anyone be interested in that scenario? It is when only one of them go off (AND ALL THE OTHERS ARE STILL CLOSED) and drop out a circuit that I want to know about. If there are 3 or 4 that are still on at the time, then it is not so hard to let the PLC determine which were still on at the time the relay dropped out.

Because power flows from left to right in schematic, the leftmost ones will still have power when one farther downstream drops out and deenergizes the relay. If you have an input from the junction between each switch to a PLC, and then set up comparisons between each input switch and its next downstream neighbor, then the first comparison that is different identifies the problem switch.

If all physical switches do open at the exact same moment, then you do have a problem. If the relay is an internal PLC device, then perhaps a First Out detector to detect when it drops out cannot be made to work. But on burners with a physical burner relay, a lot of times one P.O.C. switch will drop out several PLC scans before the others (however long it takes the burner relay to physically drop out).

PS: If you decide that it there is no hope for that device in the picture to ever work and do the job it was built to do, then I might buy it from you. No need in keeping useless equipment around, right?
 
Last edited:

Similar Topics

I
ControlLogix FTView DLR - Stale DATA AOI Faulted
Hi Guys, I just wanted to ask regarding to an error that we got troubleshooting the PLC system. Everything is working well then we tried to add a...
2
Replies
15
Views
5,360
Contr_Conn
Contr_Conn
I
ControlLogix DLR - Stale DATA AOI Faulted
Hi Guys, I just wanted to ask regarding to an error that we got troubleshooting the PLC system. Everything is working well then we tried to add a...
Replies
0
Views
1,005
ivanjoseph21
I
Back
Top Bottom