a learning opportunity ...
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 ...
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 and
here ...
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 ...