PLC5/20E - Bit did not execute when rung condition true

RedKingRory

Member
Join Date
Aug 2018
Location
Ontario
Posts
7
Hello everyone,

My colleague and I have encountered an odd situation. We noted that, according to the historian trends, the bits in a particular rung were all such that the rung condition was true at a particular time, yet the OTE on that rung did not appear to execute (go true). This was on a PLC5/20 Enhanced.

Obviously this is a troubling thought, since the entire PLC control scheme relies on proper functioning of the rung conditions.

Has anybody ever encountered such a situation? Is there anything which might cause reliability of the output table being written to in these PLC's?

Any thoughts would be most appreciated.
 
Questions to ask are:

1. Is logic being scanned? JSR to the routine the rung is in.

2. Duplicate output? Search for all references of the bit.

3. Bit's word being cleared or over written? Search for all references of the the word the bit is in.
 
Hello everyone,

My colleague and I have encountered an odd situation. We noted that, according to the historian trends, the bits in a particular rung were all such that the rung condition was true at a particular time, yet the OTE on that rung did not appear to execute (go true). This was on a PLC5/20 Enhanced.

Obviously this is a troubling thought, since the entire PLC control scheme relies on proper functioning of the rung conditions.

Has anybody ever encountered such a situation? Is there anything which might cause reliability of the output table being written to in these PLC's?

Any thoughts would be most appreciated.

Yes, I have, once. A PLC 5/60 with hundreds of online edits done while commissioning .. on a project that the requirements changed over and over and over ... and over and over

In that case, I didn't have enough memory left to edit the rung and create a new copy of the rung, so that the PLC could switch between the edited rung and the executing rung. It was a *REALLY* old version of ICOM software (before Rockwell bought Icom) .. on DOS ...

If your firmware is from .. 1996 or so ... and you have a bunch of online edits, and almost no memory left ...

Heck, the fix was to save the PLC program, export it, import to a new file name, and load the program into the PLC again. It's worth a shot for you to try it, but I think you have a better chance of winning the lottery than of this helping you. :(
 
Look for duplicate destructive bits, Last one scanned wins.

ICOM ! . . . holy cow, I still have that laptop terminal around here somewhere. That's some vintage stuff.
 
We noted that, according to the historian trends,

if none of the other suggestions pan out for you, the following might be helpful ...

TIP: if your ONLY indication that the bit did not "turn on" (go to a status of ONE) is what you can see on a "trend" feature - then there is a VERY good chance that you just "missed" seeing the bit in the "ON" state ...

in simple terms, the "trend" features just aren't always "fast enough" to catch the status of a bit which is only "ON" for just one "scan" of the program code ...

you might try this "trap" idea instead ... temporarily modify the "questionable" rung by putting a branch under the OTE instruction ... put a single ADD instruction in that new branch ... set Source A to an UNUSED floating point address (example: F8:0) ... set Source B to the simple value of 1.0 ... set the Destination to the SAME UNUSED floating point address that you entered for Source A (for example: F8:0 again) ...

now watch the value in the Destination and see if it increments upward ... if it DOES increment, then the OTE is being "fired" ...

if properly applied, this "trap" approach for testing can be MUCH more dependable for testing the status of a bit even when the trend features can't be fully trusted ...

IMPORTANT: make SURE that the floating point address that you enter is UNUSED for anything else ...

and do NOT use a CTU "counter" instruction for your test ... use the ADD instruction instead ...
.

TRAP_TEST.PNG
 
Thanks for the feedback, everybody.

No, there are no duplicate OTE's, the JSR is executing the routine and the word (memory B3) is not being overwritten by anything else.

I've taken the suggestions and may implement a counter or some other trap so we can monitor the operation of this bit in more detail. I'll follow up with any updates.

Cheers,
 
may implement a counter or some other trap

well, be advised that most "traps" based on a CTU (Count Up) instruction won't give accurate results ... that's because the CTU usually needs to see a FALSE to TRUE transition before it can count each time ...

that's why I said:

and do NOT use a CTU "counter" instruction for your test ... use the ADD instruction instead ...

sometimes using the wrong type of "test" can leave you more confused than you were to begin with ... it's sort of like trying to troubleshoot an electrical fault by using a voltmeter that has worn out leads ...

good luck with your project ...
 
Another thing to consider with PLC 5's that differ from SLC's, CL's, ML's and almost all other brands is when the status is written to RSLogix.



In a training class I was shown a rung in RSL500 that showed as I thought it should, but the identical rung in RSL5 showed the output OFF when all of the rung conditions were true. I was told it had to do with when the PLC communicated during a scan cycle, as when it was controlling a real output the output was on while RSL5 showed it off.
 

Similar Topics

I swapped out a 1771 ofe1 with a 1771 ofe2/b. Got the config in and the btw/btr rslogix created. I am having an issue with the scaling registers...
Replies
8
Views
2,046
I need to make a PLC5/20E communicate over Ethernet with an ML1100. I have the option to place the MSG in either PLC but I can't get either side...
Replies
2
Views
2,353
Hello everybody, I have to display a message on panelview 1200 from plc5/20E when a digital input changes its state. The message has to appear...
Replies
2
Views
3,378
Hi guys, I've a strange request here; 1) Can the ethernet port of the L20E CPU use as programming port? How can this 15 pins connector be...
Replies
7
Views
5,996
Hi, just a short question... I'm using Allen Bradley 1771-IR to monitor a PT100 RTD (3-wire RTD). According to the manual, if I remove the A...
Replies
0
Views
3,432
Back
Top Bottom