PDA

View Full Version : tattle tale


deroos
December 9th, 2007, 12:49 AM
Do any of you guys remember a trouble shooting aid called the tattle tale? it was to be wired in paralel to a suspect switch so if that switch opened the voltage would go through the tattle tale and it would burn open so you knew that switch did in fact open. I had a problem with a boiler a while back, and had to narrow it down from about five saftey devices. some of these would have come in handy. Do you know of anything similar being sold today?

panic mode
December 9th, 2007, 01:57 AM
never heard of it... sounds like blown fuse indicator...
could this (http://www.fwmurphy.com/products/magnetic_switches_Tattletale/index.htm) be it?

geniusintraining
December 9th, 2007, 08:12 AM
I have one... (I think)

I never used it, but I had the same issue with a safety chain circuit so we bought one off of eBay, before it showed up in the mail the issue was resolved.

It was hard to find, send me your information and I will mail it to you but it will not be until Wednesday, when you are done you can mail it back... info@plctrainer.net

IF we still have it... I have not see it for a while and the great "5's" have made many of my tools go bye bye

Let me look when I get back and I will let you know (I just serched eBay and nothing)

GMc
December 9th, 2007, 08:16 AM
We have some at work if you want a manufacturer or part number.

Gary

Ron Beaufort
December 9th, 2007, 10:25 AM
it's been years since I've seen one, but (in a previous lifetime) I used them to troubleshoot large AC compressor circuits which had a large number of interlocks wired in series ... (high pressure, low pressure, low oil, etc.) ... the style I remember was a little plastic cube with two pigtail leads coming out of the bottom ... when a voltage was applied across the leads, a link would burn through and a bright red flag would pop up into the cube ...

I've also heard of using a fuse with a VERY LOW current capacity to do the same trick ...

if you can't find them anywhere else, try checking with a well-stocked heating and air-conditioning supply house ... that's where I used to buy mine ...

PS Edit ... Gary ... if you can, please go ahead and post that info that you mentioned ... I'd like to have that for my "just in case" files ...

GMc
December 9th, 2007, 10:34 AM
Ron,

The A/C shop is the ones that purchased them. I will post a reply tomorrow morning when I get to work.

Still having a great time reading your post as always.

Gary

OkiePC
December 9th, 2007, 07:30 PM
You can do the same thing with a relay that has a manual operator and a visible indicator.

Wire to a normally open contact from the relay in series with its coil.

Push the manual operator in and it will stay energized until power drops out.

I used to have 6 of them on a din rail with a magnet base and alligator clips on the leads so I could test up to six points in a series circuit at once.

Someone at work called it a tattle-tale relay:

CR1 CR1
-] [--( )--

geniusintraining
December 9th, 2007, 07:38 PM
Very good idea Paul...

The only thing I don't like about these and Ron's fuse idea or any other for that matter, is these are Safety circuits we are messing with.

What ever you use, buy one or roll-er own, you need to make sure that the logic (wiring) is not going to be by-passed with the device..

Just something to think about

Damn where's Ron... he would of been all over this :)

OkiePC
December 9th, 2007, 07:57 PM
My application was a rubber calendar line controlled by reliance dc drives with a single channel old-school standard relay e-stop circuit with 6 belly bars, 8 rope safeties and about ten pushbuttons wired in series.

Most of the segments were available upstairs in a locked electrical control room. I was more than confident that adding an alternative load to the circuit was a much safer approach than the tried and failed method of jumpering out sections of field devices.

It took two days and three occurences to find the pushbutton with a corroded contact and the bouncing contact in the Namco rope switch with the tattle tale set-up.

This problem occured about once every 4 to 36 hours, and created a more dangerous situation for the machine tenders who had to clean all the rubber off this 300' process line, and start it all back up.

I later used the setup for a run circuit on a bead extruder that had only a few devices.

Later I wrote a ML1000 program called "Trap_PC" that would allow you to detect either change of state of up to 8 (IIRC) inputs very effectively.

I designed it to be faster than the relays, and set the corresponding output to the first one that changed states.

I used that to troubleshoot relay logic where everything had dropped out by the time the fault occured.

I might have that little Golden Nugget of a program still...

Ron Beaufort
December 9th, 2007, 08:04 PM
from my distinguished colleague geniusintraining:



The only thing I don't like about these and Ron's fuse idea or any other for that matter, is these are Safety circuits we are messing with.

What ever you use, buy one or roll-er own, you need to make sure that the logic (wiring) is not going to be by-passed with the device..



absolutely ...



of course ANYtime you do ANYthing to a circuit you run some amount of risk of defeating a safety feature ... no argument there ... but the method that we’re talking about is to use something like a 1/8 amp fuse (or preferably less) in a circuit that pulls in something like a 1.0 amp contactor coil ... IF (big IF) it’s properly sized and connected, the tattle-tale fuse won't defeat the safety switches in the circuit ... so the contactor still drops out ... but ... the advantage is that now we know WHICH SPECIFIC ONE of the many safety devices caused the contactor to drop out ...



the case that I used this approach on was at a large convention center at a resort island that I used to work at ... the A/C compressor would occasionally shut down for no apparent reason - usually right in the middle of a big conference or wedding party ... think: 99 degrees F ... 99% relative humidity ... very unhappy guests ... by the time someone got up on the roof, all of the equipment’s pressures and temperatures had settled down ... no one could ever isolate exactly which of about seven or eight components in the contactor circuit had caused the problem ... the tattle-tales did the trick ... come to find out, it wasn’t actually a real “problem” - just an intermittently defective pressure switch ... specifically, the pressure was always ok - but the switch would flake out from time to time ...

Gil47
December 10th, 2007, 12:14 AM
You can do the same thing with a relay that has a manual operator and a visible indicator.

Wire to a normally open contact from the relay in series with its coil.

Push the manual operator in and it will stay energized until power drops out.



I still have 10 relays of that sort OkiePC describes on a din rail with alligator clips on the leads so I could test all the series circuit all at once.
Mine tends to get an annual outing.

http://www.plctalk.net/qanda/uploads/relayhold.JPG

GMc
December 10th, 2007, 07:40 AM
Ron,


Here are the Tattle Tale (http://www.partsguy.com/cgi-bin/PartsGuy/JB12015.html) monitors that our A/C shop purchased.

They bought them locally but I found this site that has a good picture of the device. Hope this helps

Gary

Ron Beaufort
December 10th, 2007, 10:20 AM
thanks, Gary ... that's the one I remember - from about 30 years ago ...

geniusintraining
December 14th, 2007, 07:39 PM
So I found it...

model number 8878 'Digitective Annunciator'

You can hook 16 devices series or parallel or a combination of, it has a BCD display, it will display what circuit opened up first.

It is made by North American Mfg out of Ohio.

Not sure if it even works anymore... but its kind of neat :)

Someday I will let the magic smoke out of it.... i'm sure :)

OkiePC
December 14th, 2007, 11:22 PM
geniusintraining][/font]So I found it...



Me too...in the dark crevices of my gray matter...I found my best recollection of my Micrologix Tattle Tale.



This revived version is not as perfected as the original, IIRC.

It seems I have one too many rungs or branches. . .

As I recall the original could detect the drop out point of a circuit sealed in the beginning like this:

http://www.plctalk.net/qanda/uploads/TRAP_PC.JPG

It would occasionally show two or more devices, including the button we pressed, but all in all, it was very useful for intermittent problems, and relay race chasing.

I remember wanting to measure or calculate the actual scan time but I never did.

Maybe someone can make it faster.

PiEaCe!
Paul

milldrone
December 15th, 2007, 09:05 AM
OkiePC, Or anyone else.

Can you explain to my feeble mind why this won't work? Or what is wrong with this?
http://www.plctalk.net/qanda/uploads/okiepcmcr.jpg
I have been watching this thread with some interest. And have read in other threads about the dangers of monitoring E stop strings. What I'm looking for is some feedback on what is wrong with this.

geniusintraining
December 15th, 2007, 09:08 AM
Paul,

Ours are close to the same thing but you are using the PLC, but the wiring is the same as per their drawing

We had a conversation last time about this and my only concern then was... the speed, what would be faster? the PLC or micro processor/board

In my thinking they would all go false in a very short time (due to the latch droping out), so you would need something very fast to read this??? or am I wrong

Have you tried yours? I never had the chance... by the time the thing showed up in the mail we resolved our issue

Edit: Milldrone posted while I was typing, but if you wired it that way then that would resolve loosing your power on all points, I don't really see anything wrong with it (its just weird to see it like that) but it may work... good out of the box thinking :)

OkiePC
December 15th, 2007, 09:30 AM
OkiePC, Or anyone else.

Can you explain to my feeble mind why this won't work? Or what is wrong with this?
http://www.plctalk.net/qanda/uploads/okiepcmcr.jpg
I have been watching this thread with some interest. And have read in other threads about the dangers of monitoring E stop strings. What I'm looking for is some feedback on what is wrong with this.

Now that's the way I would have wired the circuit if it were up to me. Then it is a piece of cake to troubleshoot, but unfortunately, most of the "run logic" or e-stop strings I have dealt with put the seal and reset button at the beginning of the line.

EDIT: And the calendar line I worked on was modified to be like this one when we hooked up the tattle tale relays. It was later, that I made one with a Micrologix just for chits and giggles in the office and ended up using it several times.

OkiePC
December 15th, 2007, 09:52 AM
Paul,

Ours are close to the same thing but you are using the PLC, but the wiring is the same as per their drawing

We had a conversation last time about this and my only concern then was... the speed, what would be faster? the PLC or micro processor/board

In my thinking they would all go false in a very short time (due to the latch droping out), so you would need something very fast to read this??? or am I wrong

Have you tried yours? I never had the chance... by the time the thing showed up in the mail we resolved our issue

Edit: Milldrone posted while I was typing, but if you wired it that way then that would resolve loosing your power on all points, I don't really see anything wrong with it (its just weird to see it like that) but it may work... good out of the box thinking :)

Yes, I used mine at goodyear about 10 times in 7 years, and it worked about 8 of ten with immediate accurate results.

One or two times, the relay was too fast for the micrologix, even with my honed little program, which is probably not perfect still.

I am sure a micro-controller would be much much faster. That is an area I need to learn more about. Christmas is coming, maybe I can get someone to buy be a begninner's microcontroler kit. . .Any suggestions?

I am constantly beeching about the firmware in gas pumps, cash registers, consumer electronics and cellphones, maybe I need to inject some of my perspectives into that arena of the world of controls. . .and I have always wanted to roll my own home controller. . .

PiEaCe!

spifldorf
December 15th, 2007, 10:09 AM
Look up First Out Indicators, I think this guy is in N.M. I've used them many times. Very fast, monitors up to 16 inputs I think. 12/12 Designs is the companys name. KEG

milldrone
December 15th, 2007, 10:35 AM
Now that's the way I would have wired the circuit if it were up to me.

Is there a mandate I have overlooked that prevents this method?

allscott
December 15th, 2007, 10:49 AM
Is there a mandate I have overlooked that prevents this method?

I certainly hope not, I have been doing this for years. This is exactly how I do E-stop circuits. I have also been using the latched relay method of tracking down what is dropping out a series interlock circuit and until this thread started I never worried about the safety implications of my "tattle tale relay".

Time to think.........

MajorFault
December 15th, 2007, 04:53 PM
here's a link to the ones we use. I just purchsed dome from the guy last month. http://triptrapsales.com/

OkiePC
December 15th, 2007, 08:49 PM
Is there a mandate I have overlooked that prevents this method?

No, only red tape at the mega corporation I used to work for. They made me put it back after we fixed the switches, and were supposed to contact corporate engineering to approve any changes.

Since the design was 1978 era and grandfathered in to current osha approval, any changes to the controls would require bringing them up to modern safety standards. Instead, they wrote test porcedures, LOTO policies, and taught mill and calendar rescue procedures to minimize the limb loss when accidents occurred.

They were afraid to do anything to this extremely dangerous machinery. I was not about to do anything without upper level approval, so I complied, until I could go to work for a better company with some technical common sense.

The smaller company I work for now is much more progressive. So, now I get to trouble shoot dual channel solid state safety relays with pulsed input strings, output contactor monitoring, and monitored pushbutton reset. But it is way better than seing people at work with missing fingers, broken arms, etc.

I should start another thread about the Allen_Bradley Guardmaster MSR38DP. . .

Ron Beaufort
December 16th, 2007, 11:44 AM
Greetings to all ...

folks I hate to be the harbinger of despair, but the technique that you’re using for your “PLC Tattle Tale” is fundamentally flawed ... in simple terms, you can’t count on it to give consistently reliable results ... this means that (even though this idea might be handy and useful in some cases) the method that you’re using is NOT 100% reliable ...


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



suppose that I use a MicroLogix 1000 with ten 120VAC inputs ... suppose that I jumper all ten of those inputs together ... suppose that I connect just one field device (a NC pushbutton for example) to those ten inputs ... obviously when the button is NOT pressed, the PLC will see ALL ten inputs as electrically ON - and the input data table will have ten ONES all in a row ... so far so good ...



quick question: what will happen to the inputs at the instant that we press the button? ...



softball answer: ALL ten inputs will electrically turn OFF - and ALL ten of the bits on the PLC’s input data table will SIMULTANEOUSLY turn to ZEROS ...



hardball answer: ALL ten inputs will electrically turn OFF - and SOME of the bits on the PLC’s input data table may turn to ZEROS - but SOME bits on the PLC’s input data table may stay as ONES ... in other words, it’s a RANDOM thing ...



oops! ...



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 ...



back to my experiment ... I ran the test 100 times ... at the instant that I pressed the NC button, ALL ten bits SIMULTANEOUSLY turned to ZEROS - EXCEPT on the tests shown below:



test 7 ... results = 00 1111 1111
test 40 ... results = 01 0000 0000
test 60 ... results = 01 0000 0000
test 67 ... results = 11 0000 0000
test 70 ... results = 11 1101 1111
test 75 ... results = 01 0000 0010
test 95 ... results = 01 0000 0010

all other tests ... = 00 0000 0000



now you’ve got to admit, that’s pretty weird ... but when you really think about it, it does make sense ... the PLC’s “inputs” are ten separate electronic devices ... in a perfect world, each of these devices SHOULD have exactly the same electrical characteristics ... in reality there is a certain amount of “fudge factor” (or “range”) in the voltage levels which each device considers to be an ON signal or an OFF signal ...



and so my primary point is this ... the “PLC Tattle Tale” idea is fundamentally flawed DUE TO THE IMPRECISE RESPONSE OF THE INPUTS ...



now in most cases, we’re not concerned if one particular input happens to take one or two scans longer to change state than another particular input ... but in the program you guys are dealing with we ARE concerned ... you’re actually trying to monitor a string of inputs which are WIRED IN SERIES - and trap the SPECIFIC input which flaked out first ...



let’s shift back into softball mode for a second ...



http://www.plctalk.net/qanda/uploads/okiepcmcr_C.JPG



in the figure above, if Input C opens, the PLC will see Input C - and all of the DOWNSTREAM inputs D-E-F-and-G as being electrically turned OFF ... so bits C through G should all turn to ZEROS on the PLC’s input data table ... if we trap and store that “changed” status, we should see that Inputs C through G all SIMULTANEOUSLY changed to ZEROS ... we can now point - with certain assurance - to Input C as being the “first” input which opened ... so apparently we’ve just pinpointed our problem ...

[note: do NOT miss the point that what I've said above is what most people EXPECT to see ... it is NOT always correct] ...

but before we take a deep bow and accept a firm pat on the back, let’s look at this same scenario from the hardball viewpoint ...



in the figure above, if Input C opens, the PLC will see Input C - and all of the DOWNSTREAM inputs D-E-F-and-G as being electrically turned OFF ... but (and here’s the point) bits C through G MAY or MAY NOT all instantly turn to ZEROS on the PLC’s input data table ... remember it’s a RANDOM thing ... so if we trap and store the “changed” bit status, we MAY or MAY NOT see Inputs C through G in a ZERO state ... we could then point to the WRONG input as being the “first” input which opened ...



that’s not going to make the bo$$ happy - especially after we have confidently assured him that his pesky intermittent shut down problem has finally been fixed ...



and so ... this “PLC Tattle Tale” idea COULD be a handy little troubleshooting tool ... BUT ... just a word of advice ... personally I might bet my lunch money on its results - but I would NOT bet the rent ...



I’ve covered this same “non-simultaneous reaction of inputs” issue before ... if anyone is interested, you can see more here (http://www.plctalk.net/qanda/showthread.php?p=108964&postcount=9)and here (http://www.plctalk.net/qanda/showthread.php?p=8478&postcount=8) ...



side trip: personally, I’d sure like to know how one of those “ready made” Tattle Tale input monitoring devices would react to this same “all inputs jumpered together test” ... I’ll bet (pocket change only) that they’ll also give a wrong report from time to time ... anyone want to try one out and post the results? ...



hope this helps ... party on ...

spifldorf
December 16th, 2007, 12:04 PM
Ron,
As I stated above the FOI from 12-12 designs is accurate and fairly cheap. I have used it many times, for these problems and my results made my Boss eat crow. KEG

Ron Beaufort
December 16th, 2007, 12:10 PM
Greetings spifldorf ...

if it's microprocessor based, I'm just wondering if it would be able to nail down the same "all inputs jumpered together" test ...

I have no reason to doubt that it's accurate - but I'd like to know for sure ... can you run a test for us some day? ...

all I'm saying right now is that the "PLC Tattle Tale" only had a 93% accurate response in my tests this morning ... that's good - but it's not 100% reliable ... the gadget you're talking about might be able to beat that percentage ... then on the other hand - I sure would like to see a horserace ...

Lancie1
December 16th, 2007, 12:19 PM
Yes, I used mine at goodyear about 10 times in 7 years, and it worked about 8 of ten with immediate accurate results.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.

folks I hate to be the harbinger of despair, but the technique that you’re using for your “PLC Tattle Tale” is fundamentally flawed ... in simple terms, you can’t count on it to give consistently reliable results ... As your failure analysis is also slightly flawed. You were using a pushbuton, but the circuit in question is using a MCR physical relay. 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. 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.

Sometimes we have to use the tools at hand, even though they do not give 100% success. 100% sucess is something achievable only in the classroom "theoretical" setting. Engineering is all about replacing the "theoretically possible" with the "real-world achievable".

Besides that, 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%?

spifldorf
December 16th, 2007, 12:21 PM
Not sure what you mean by all inputs jumpered together test is. But after I wired the FOI into this gas train and tested ALL 10
switches 3 times each I was ready to serve dinner to my Boss.
Also I might add these switches varied from solid state to vacuum to ice cube relays. We bought 5 more. Our electricians love them, they say NO MORE GUESSING.

Lancie1
December 16th, 2007, 12:45 PM
...all inputs jumpered together" test ... I assume you mean that the interlock test switches are wired in series, and that a separate PLC input is taken from each switch?

Literally "jumpering all inputs together" (into ONE input) would short out an interlocked series switch string, bypassing it, and making the circuit completely useless.

OkiePC
December 16th, 2007, 02:17 PM
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 ... ...

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

Ron Beaufort
December 16th, 2007, 05:53 PM
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.

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.



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.



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 ...


http://www.plctalk.net/qanda/uploads/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 ...



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 ...

Ron Beaufort
December 16th, 2007, 05:54 PM
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.



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%?



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 (http://www.plctalk.net/qanda/showthread.php?p=108964&postcount=9) and here (http://www.plctalk.net/qanda/showthread.php?p=8478&postcount=8), 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 ...

Gil47
December 16th, 2007, 07:12 PM
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.

Ron Beaufort
December 16th, 2007, 07:24 PM
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.



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.



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.



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.



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.



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",



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 ...

Ron Beaufort
December 16th, 2007, 07:32 PM
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 ...

geniusintraining
December 16th, 2007, 09:11 PM
...
I'm short on time - but I'll try again ......

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?

milldrone
December 17th, 2007, 09:18 AM
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" ...


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.

Ron Beaufort
December 17th, 2007, 11:49 AM
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 ...

agarb
December 17th, 2007, 11:56 AM
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?

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

milldrone
December 17th, 2007, 12:31 PM
Thanks Ron,

I know for me this defintely qualifies as more learning as mentioned by you in this thread http://www.plctalk.net/qanda/showthread.php?t=22770&page=2
How many years does it take to understand this
stuff?


15 years ... and counting ...
Thanks to you and others on this forum I pick up a "golden nugget of knolledge", usually when you least expect it!

geniusintraining
December 17th, 2007, 12:35 PM
[....]

Thank You! :)

deroos
December 31st, 2007, 07:34 PM
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.

geniusintraining
January 10th, 2008, 05:02 PM
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

http://www.plctalk.net/qanda/uploads/0110081644.jpg

Lancie1
January 10th, 2008, 06:48 PM
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?

geniusintraining
January 10th, 2008, 08:02 PM
There is never an exact same time... that is impossible

That said how fast it this thing? I have no idea... how fast is electrcity? again I have no idea (even though I am a genius)

I am going to meet with Ron in the near future so I may have to lend it to him for some bench testing :)

Ron Beaufort
January 12th, 2008, 03:42 PM
gosh ... I thought we were through with this ...



again, I apologize for not making myself more clear ...



moving forward ... I still say that my original “all go off at the same time” test is perfectly valid to prove the concept - but for simplicity’s sake, let’s nail this thing down with an apples-to-apples experiment ... I just used some of my student wiring lab equipment and hooked up EIGHT Normally Closed pushbuttons in series with each other ... I used these in a common holding circuit to “seal in” a real world contactor ... here’s the schematic ...



http://www.plctalk.net/qanda/uploads/1STOUT_SCHEMATIC.JPG




I had a MicroLogix1000 handy with TEN inputs ... I connected input 9 to monitor the AC Line ... I connected inputs 8 through 1 to monitor the “stop buttons” ... I connected the last input (0) to monitor the contactor’s auxiliary contacts ...



and here’s a couple of snapshots of the setup ...



http://www.plctalk.net/qanda/uploads/1stout_lab.jpg



http://www.plctalk.net/qanda/uploads/1stout_contactor.jpg

when I energized the contactor, ALL of the Micro’s inputs lit up ...



and here’s the quick “down and dirty” program which I used to record the status of ALL of the input bits as soon as ANY bit went OFF ... (note: if anyone has another program they’d like to try, just post it) ...



http://www.plctalk.net/qanda/uploads/1stout_rss.JPG




with everything ready to roll, I pushed “stop button C” and naturally the contactor dropped out ... I recorded the data ... I reset the contactor ... I reset the trap bit ...



I pushed “stop button C” and the contactor dropped out ... I recorded the data ... I reset the contactor ... I reset the trap bit ...



I pushed “stop button C” and the contactor dropped out ... I recorded the data ... I reset the contactor ... I reset the trap bit ...



I did this same test ONE HUNDRED times in a row ... here’s the data that was recorded ...



http://www.plctalk.net/qanda/uploads/1stout_data.JPG



now even though I pushed the SAME button (C) EVERY SINGLE time, the data that was recorded was NOT always the same ...



I’ve highlighted the actual bit (6) that caused EACH and EVERY drop out condition ... a “good” test would have given a decimal value of 896 ... and most of the time (81%), that’s what was recorded ... BUT ... (and here’s my point) the data was NOT ALWAYS correct ... specifically, 19% of the time a RANDOM bit pattern resulted ...



for a specific example, take a look at the data in test #44 ... that one is especially troublesome ... if we had never covered the issues that I’ve brought up in this thread, what conclusion would most reasonable technicians come up with while considering the data from that particular test? ... I submit that the most logical conclusion would be that the contactor’s auxiliary contacts are causing the contactor to drop out ... but that perfectly logical conclusion is WRONG - because the ONLY button that I ever used to drop out the circuit was button C ...



now an electrically knowledgeable technician might look at all of this ERRONEOUS test data and say: “Wait a minute. If a midstream bit goes OFF, then why don’t all of the bits downstream of that bit go OFF also?” ... bingo! - that’s a very good question ... now how are we going to explain the various “random bit patterns” in those erroneous tests? ... I submit that you can NOT adequately explain those data readings WITHOUT understanding the concepts that I keep harping on ...



regardless of how you choose to slice it, my point has been made ... again ...



personally, I think that I said it best back in post #36 ...



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 ...



in the spirit of the forum, I’m just trying to make more people aware of a POTENTIAL issue that many (most?) technicians never even consider ... anyone who doesn’t believe what I’m saying, is perfectly welcome to set up the test and run the experiments for themselves ... I assure you that I am NOT making this up ...



my question is this: how on earth would you program the PLC to interpret this RANDOM data and come up with an accurate assessment of which was the “first out” bit? ... (and before anyone suggests incorporating a “filter” or “settling” or “debounce” arrangement, please consider how that might adversely affect the ability to spot a defective contact which is only very briefly and intermittently open) ...



now as for the “ready made” Tattle Tale that Geniusintraining kindly showed us in post #44 ... I really do NOT know how that’s going to work ... maybe it will work PERFECTLY ... I really hope that it does ... but as GIT said:



I am going to meet with Ron in the near future so I may have to lend it to him for some bench testing



good to hear that you’re finally coming down this way, Mark ... by all means bring that thing along with you and we’ll test it out while you’re here ... I’ll post the results on the forum as soon as the test is done ... personally I wouldn’t bet more than pocket change on the outcome one way or the other ... but on the PLC Tattle Tale being discussed in this thread - well, that’s a different situation ... I still maintain that a “First Out” tester based on a PLC is not going to be 100% reliable ... it might work well enough to be useful - but if more than one input can electrically change state simultaneously, then personally I wouldn’t bet the rent on its accuracy ...

OkiePC
January 12th, 2008, 09:36 PM
... I still maintain that a “First Out” tester based on a PLC is not going to be 100% reliable ... it might work well enough to be useful - but if more than one input can electrically change state simultaneously, then personally I wouldn’t bet the rent on its accuracy ...

Ron, thanks for taking the time to test this. I had been thinking of trying to find time at work to try it out. My ML1000 test unit performed just about like yours, although your method of testing was much more thorough. I only used mine a handful of times on a variety of real machine problems as opposed to your 100 test runs.

As a tester, it was much better than trial and error, and the best thing we had to use at our disposal.

Pointing out the exact reasons for its drawbacks is a great exercise in understanding how a typical PLC operates and I am sure many will benefit from your experiments, and especially your detailed write-up.

Thanks again,
Paul

Ron Beaufort
January 13th, 2008, 10:27 AM
does anyone else have those experiences where you go to bed and your head keeps working all night even while you’re asleep? ... my head does that all the time ... my wife can’t understand why sometimes I wake up more tired than when I went to sleep ... anyway, at 4:00 o’clock this morning I woke up with the following schematic perfectly drawn out in my head ...

suppose that we use ISOLATED input bits for the PLC “First Out” tester ... that way we can wire them up like this ...


http://www.plctalk.net/qanda/uploads/1STOUT_ISOLATED.JPG


and now at the instant that our “problem” switch (C) opens up, the ONLY bit that will have a voltage (a difference of potential) across it will be bit 6 ... that should make it a lot easier to capture the changed status of that single ON bit and accurately record it as the “First Out” culprit which dropped out the relay ...

disclaimer: I haven't had time to actually test this approach out, but I can't see why it wouldn't work ... I'll try to test it tomorrow and post any significant results ...

of course the MicroLogix1000 we’ve been talking about isn’t going to give us the isolated input wiring that we need – but as long as we can come up with the correct hardware, then I’ve got a very strong hunch that we could get this thing to work reliably even with a PLC ... as I kept saying, it’s not the PLC program that’s been causing the problem, it’s the unpredictable response of the PLC inputs when two or more of them electrically change state simultaneously ... using isolated inputs should eliminate the problem – since only ONE input will electrically change state at a time ...

now then ... I looked (briefly) on the North American Manufacturing website for the ready made Tattle Tale that Geniusintraining brought up – but I couldn’t find it listed ... but even without seeing how the thing is designed, I’d bet significantly more than pocket change that it uses ISOLATED inputs similar to what I’ve drawn above ... and in that case, I’ll bet that it’s going to work just fine when we get around to testing it ...

and to OkiePC ...

Pointing out the exact reasons for its drawbacks is a great exercise in understanding how a typical PLC operates ...

I’m glad that you see it that way, Paul ... that was my main reason for bringing up all of this voodoo in the first place ... I’ve had to help debug one or two systems over the years where these concepts were an issue ...

once in awhile you’ll hear an old-time hardwire electrician talk about a control problem caused by a “relay race” or a “contact timing” issue ... I guess this is the solid-state PLC equivalent of that type of situation ... the random and intermittent nature of the beast makes it pretty hard for most people to track down a problem caused by this effect ... as with most things, once you’re aware that something like this exists, it gets a lot easier to troubleshoot ...

bob1371
January 13th, 2008, 11:05 AM
now then ... I looked (briefly) on the North American Manufacturing website for the ready made Tattle Tale that Geniusintraining brought up – but I couldn’t find it listed ... but even without seeing how the thing is designed, I’d bet significantly more than pocket change that it uses ISOLATED inputs similar to what I’ve drawn above ... and in that case, I’ll bet that it’s going to work just fine when we get around to testing it ...


First off thanks to all for providing a very informative thread. I was unable to find the item at North American MFG but did find the one referred to in post 20.
http://www.1212designs.com/FOI_Compact/default.htm
and as you stated it does use Isolated Inputs.

I think I will order one and see how it works.

thanks again.
bob

Clay B.
January 14th, 2008, 01:53 PM
First off, thanks Ron very informative. I have seen that problem before and never actually knew why it was happening. Since I started as an electrican I went back to what I knew and used a meter. A fluke 85 series meter to be exact.

If you have one of these handy little yellow boxes in your tool box and it has fresh battries (this can be very important). You can check series circuits like this. Basically what you want to do is put your meter in parallel to the suspect switch. Switch meter to whatever voltage the system is using. You will notice a zero voltage reading on your meter. As long as the switch stays closed that reading will stay zero. If the switch opens up then you will get a voltage reading.
No nobody in their right mind is going to stand there and watch the meter. That is where a function on the mter come in. It is the Min Max function.

Remember when we hooked up the voltage was zero because the switch was closed. Well that means when we turn on our min max function the highest voltage is going to be zero (now for those that see some minor mili volt signal that is ok also, we are looking for a bigger change so we are going to call the noise reading zero). Ok now we wait for the event. Event happens, what does our meter read?

Well if Max reads zero then you are on the wrong switch, move to the next one. If it reads the voltage on your circuit or something close to it then you have found your grimlin.

While this does not check all the switches at the same time, It does not lie. I think it could work in conjunction to your relay checker and confirm your findings.

Note: To hamper an interlock (series circuit) you do not always have to have a complete break in the circuit. Depends on the minum voltage required for your coil or input.


Note 2: You can use the divide an conquer with the method described above to narrow down your search. Basically just pick a section of switches and go across those. If you get a zero reading after the event you can elimate those or if you get a voltage reading then the bad componet has to be one of them.

geniusintraining
January 15th, 2008, 12:48 AM
You are correct American Manufacture does not sell this anymore... not sure why (did not work very well??)

any way here are a few pics of the panel on the inside.. they list 3 different ways of wiring up their device, I hope the pictures are ok (from my phone)

http://www.plctalk.net/qanda/uploads/0112081729.jpg
http://www.plctalk.net/qanda/uploads/0112081728.jpg
http://www.plctalk.net/qanda/uploads/0112081729a.jpg

Lancie1
January 15th, 2008, 01:06 PM
..and here’s the quick “down and dirty” program which I used to record the status of ALL of the input bits as soon as ANY bit went OFF ...Ron, I would like to see what happens if you use the method that have used before. I use a different condition as the trigger. Instead of looking for the First changed input (a losing proposition as you have proven several times now), look at the state of the contactor. Use only the state of "Input 0" in your program, the one from the contactor seal-in. When that one drops out, it means the contactor has had time to physically drop out, which means that several PLC scans have passed. That allows enough time for the actual open switch to be identified, as the inputs should settle out by then. Record the other input bit states only AFTER Input 0 goes off. Then compare each bit to see which were still closed. The first non-closed bit is the first place to check for a problem.

Ron Beaufort
January 15th, 2008, 04:18 PM
Greetings Lancie1 ...

I'd love to try out your idea ... is there any way that you can help me out by posting the exact code that you want me to run? ... just write it for a MicroLogix1000 with 10 input points and post it ... you can follow the wiring that I drew out in post #47 ... I'll keep the existing wiring hooked up until I hear from you ... or at least for several more days ... I've got to straighten up the lab sooner or later after my last on-site training gig ...

got to go ... the Red Cross called up and they need a dose of AB+ ...

Lancie1
January 16th, 2008, 09:19 AM
Ron,

I will try to write a Mircologix program for your test setup, but make no guarantees. I am having some health problems right now and have trouble concentrating for more than a few minutes at a time. It seems my thyroid is working overtime (a so-called "hot node"), which tends to make me nervous, irritable, and with the energy of a wet dishrag.

Ron Beaufort
January 16th, 2008, 10:19 AM
take care of yourself ... we can work on this later ... my back is to the wall with year end business matters - and stuff like that ...

hope you're feeling better soon ...

Lancie1
January 16th, 2008, 12:28 PM
Ron,

I managed to concentrate long enough to modify an existimg program. I tried to match your wiring. Please test it. Perhaps someone might have a better method.

Lancie1
January 17th, 2008, 08:20 AM
I see now that my brain wasn't thinking as clearly as I thought...How can one know at the time?

I tried to put in a reset for the first out, but unfortunately it will reset the N7:0 word every time CR energizes. The original program has several functions that reset the First Out, and anyone who uses this will have to make sure s/he has the proper input on Rung 004 to reset it.

RSS
January 17th, 2008, 08:53 AM
I'm new here but as it looks like Gary narrowed it down for you already. In my pre-PLC days we used the relay solution either having the relay open or close for the tattle tale.

With PLC's I now consider it good practice to have the downstream conductor of any chain, usually the E-Stop chain go to an input with all of these inputs to the same word. Then mousetrap which opened first in logic. Current design typically uses a second contact for annuciation but that provides no path to troubleshoot when the chain is faulting do to a failing device.

On a related item is an intermittant short to ground that blows the primary fuse. If it does not violate safety put a suitably sized incandesent lamp in place of the blowing fuse and when the lamp gets brighter via the short go search for the curcuit thats dragging it down.

RSS

Ron Beaufort
August 19th, 2010, 12:28 PM
I hate to dredge up this old thread - but I just got a call from a new member who doesn't have RSLogix500 and can't open the file I attached to post #25 ... so I'm attaching it as a PDF below - and also including a copy in PLC-5 format ...

Craig, if this isn't exactly what you need, let me know and I'll try again ... I enjoyed talking with you ...