RSLogix500 OTE not behaving correctly.

[Mister Mac]

Hi Everyone,

I am supporting a system which runs on a SLC 500 (1747-L532). A fault has developed whereby the output state of some digital outputs do not change within the ladder logic. Basically, on a rung, an XIO controls an OTE. When the XIO is high the OTE should be also high, however the OTE is not changing state. The OTE is only used on this 1 rung within the program and the routine is being scanned. I have trended the XIO bit to confirm no oscillation and at a trend refresh rate I cannot see any change of state. The XIO is controlled via a compare instruction which is stable.

I have plugged out the comms to the machine HMI to confirm nothing is being written from the HMI that may be causing the issue. I have also tried another processor from spares but issue remains.

Is there something very simple I could be missing here?

All suggestions appreciated.

 

[plvlce]

Scroll up a little in your cross-reference -- is there anything addressing the output word as a whole? Reference would be O:6.0 or the like. Or is there any indirect addressing that might point to it?

Is N30:6/8 used anywhere other than these two places? I'm not particularly familiar with trending in 500; if the bit were to change from zero to one and back within each scan would a trend catch it, or does a trend only show states at the end of each scan cycle?

That's the potential culprits I can think of:

• Something else is writing to the output (and since your xref shows nothing else is directly addressing that bit, it would have to be either an indirect address or addressing a block of memory including it)
• Your bit that controls the output is in the opposite state when that rung is scanned, but not when the trend looks at it.

 

[Level]

Hmmm... a strange one...

Absolutely check if the word is being influenced in it's entirety.

Are the adjacent outputs experiencing the same thing, or just this single one?

Can you set up a series of of latches as debug bits in and around your conditions for the output to be high, and then branch the output itself with another OTL.

This should prove out whether your trend is just missing it due to refresh/scan rates.

 

[jkerekes]

Is the Ladder Routine being scanned?

 

[Level]

Looks like it from that 4th screenshot - but OP could confirm as well...

 

[Mickey]

If you can post the whole program. The .rss file. (zip it first)

Someone may spot something.

 

[joseph_e2]

Also be aware that the RSLogix software is showing you the state of the bits at the end of the scan, which isn't necessarily the same value at the point it's being evaluated. As an experiment, add these 3 lines of code:

OTL B3:x/y
XIC B3:x/y OTE B3:a/b
OTU B3:x/y

Where B3:x/7 and B3:a/b are otherwise unused memory addresses. You'll find that RSLogix shows B3:a/b is on and B3:x/y is off.

 

[Aardwizz]

The question is, is O:6 being stomped on by something else, or is the N30:6 bits turning off in a routine before the JSR and then turned back on after the JSR (as joseph_e2 suggests) ?

To answer that question, add a "latch trap" to the rung with the "faulty" OTE O:6 coil -- a branch with an OTL B3/(something unused).

It the bit doesn't come on, then the problem is with N30:6. If it does, then the problem is with O:6.


There are some ways of coding can make finding the issue very hard to track down. Indirect addressing, such as N30:[N7:0] (where N7:0 = 6) or N[N7:1]:6 (where N7:1 = 30) could stomp on the word / bit. Indexed addressing, #N30:0 with S:26 (?) having a value of 6 would also be pointing to N30:6.

 

[drbitboy]

As others have said, more or less, it is very rare that the program will do anything other what it has been told (programmed) to do, so if there is any difference between what it has been told to do and what you expect it to do, the fault is essentially always in your expectations and/or your assumptions behind those expectations.

So in this kind of debugging, you arrive at a resolution far quicker when you search for the error in your assumptions and expectations than when you search for why an XIO/OTE pair is not behaving as it is designed to behave.

If you have any doubt about that, first wrap the "offending" rung with some rungs of logic writing to new and otherwise unused data file bits that will convince you that the XIO/OTE pair is behaving as it is programmed to behave. Once you convince yourself of that, you will realize that it your expectations that must be at fault.

 

[Ken Roach]

The instructions you can see at the top of the last screenshot make me uneasy: there's an XIO, LEQ, and CLR with the destination address O:4.2.

But the O:4.2 is itself then examined in the very next rung.

I suppose that because it's word 2 of Slot 4 that the logic involves analog modules but I'm not too comfortable with that, and am concerned there might be a similar "write to the Output table, then evaluate parts of the Output table in later rungs" logic.

I agree that "some of the OTEs don't appear to function" with no cross-references directly to the bits is weird. But it very, very probably results from a word-level write to that Output module.

 

[I_Automation]

What I do to test if a line is being scanned is add a line right after in online edit,


On that line BST, OTE an [unused test bit] LADDER 28 IS BEING SCANNED, NXB, XIC O:6/6 OTE [Test bit2] OUTPUT 6/6 WAS ON



Then on ladder 2 before the JSR 28 add a rung BST, OTU [Test Bit] NXB OTU [Test Bit2]


The ladder 2 line will turn off both bits every scan and when the ladder IS being scanned the first bit will show on online and if it turns the output ON but it is turned OFF somewhere else in the program your test Bit2 will still be on.


This will let you know if the ladder, or that section of the ladder, is being scanned and if the output is being turned on and thus off somewhere else.


-If it's not being scanned you need to find out why, (MCR zone, conditional RETURN before that rung)
-if it's not being turned on then somehow N30:6/6 is being turned on later in the program after that output control,
-if it is being turned on then find out what is turning it off later in the scan.