Why/How is this OTE energized?

LoganB · Mar 15, 2018

Hoping someone can shed some light on this... I didn't write this program, but I inherited it and constantly find myself shaking my head while trying to streamline it.

I noticed this today while combing through looking for an indexing problem. How is this output even energizing? With an indexer only allowing one of the rungs to be true at a time, wouldn't there always be a de-energized version of the output holding it in the "off" state?

harryting · Mar 15, 2018

No, the one that aren't being scanned would stay in the same state because the logic aren't being "scanned" similar being in a routine that aren't being called.

At least, that's what I think would happen.

Steve Bailey · Mar 15, 2018

While the state register value is 90 it turns on in rung 25 and immediately off in rung 26. When the LH TQX Press reaches the tool position, the state register value is driven to 100 and the output remains on. Then, depending on the state of the RH TQX Press or the RH TQX Locator Pin the state register value is driven to 150 or 110 and the output goes off.

Ron Beaufort · Mar 15, 2018

your screen shot is so small that I might be misreading it – but according to what I think I see here, the bit/box B90[11].10 is actually alternating between a status of ZERO – and a status of ONE ...

specifically, the OTE instruction in your rung 25 is being executed with FALSE logic – and is therefore writing a status of ZERO into the bit/box ...

then the OTE instruction in your rung 26 is being executed with TRUE logic – and is therefore writing a status of ONE into the bit/box ...

the "green on the screen" indication that seems to be confusing you, is based on the RSLogix5000 software's "best guess" as to whether the bit/box contains a status of ONE – or a status of ZERO ... since the software USUALLY is witnessing a status of ONE, then the software represents the OTE with a "green on the screen" highlight ...

Ron Beaufort · Mar 15, 2018

as I said earlier, I certainly MIGHT be misinterpreting what you're asking about ... but if I do understand your question - and your screen shot, then the following test/experiment might help you understand what you're seeing on the screen ...

put ONE of the following rungs (TEST_A) DIRECTLY BELOW your first "problem" rung ...

then put the OTHER rung I've shown (TEST_B) DIRECTLY BELOW the second "problem" rung ...

if my "guess" is correct, then the value of TEST_A will remain at ZERO ... and the value of TEST_B will rapidly increase ...

REGARDLESS OF WHATEVER THE "GREEN ON THE SCREEN" INDICATION SHOWS YOU ...
.

LoganB · Mar 15, 2018

Ron Beaufort said:
as I said earlier, I certainly MIGHT be misinterpreting what you're asking about ... but if I do understand, the following test might help you understand what you're seeing on the screen ...

put ONE of the following rungs DIRECTLY BELOW your first "problem" rung ...

then put the OTHER rung I've shown DIRECTLY BELOW the second "problem" rung ...

if my "guess" is correct, then the value of TEST_A will remain at ZERO ... and the value of TEST_B will rapidly increase ...

REGARDLESS OF WHATEVER THE "GREEN ON THE SCREEN" INDICATION SHOWS YOU ...
.

Should the second rung be an XIO? I will give this a shot, I bet you're right on the flickering.

Ron Beaufort · Mar 15, 2018

while trying to streamline it.

is it working the way that's it's written now? ... if so, remember the old adage: "if it ain't broke - don't fix it" ...

Should the second rung be an XIO?

the original programmer might have had a valid reason for writing it this way ...

in the words of Dr. Emmett Brown: "You have to think fourth dimensionally" ...

personally I'm not fond of this type of "partial scan status change" approach – but I see it occasionally in some customers' programs ...

Gomez_ · Mar 15, 2018

Ron Beaufort said:
your screen shot is so small that I might be misreading it – but according to what I think I see here, the bit/box B90[11].10 is actually alternating between a status of ZERO – and a status of ONE ...

specifically, the OTE instruction in your rung 25 is being executed with FALSE logic – and is therefore writing a status of ZERO into the bit/box ...

then the OTE instruction in your rung 26 is being executed with TRUE logic – and is therefore writing a status of ONE into the bit/box ...

the "green on the screen" indication that seems to be confusing you, is based on the RSLogix5000 software's "best guess" as to whether the bit/box contains a status of ONE – or a status of ZERO ... since the software USUALLY is witnessing a status of ONE, then the software represents the OTE with a "green on the screen" highlight ...

I agree with Ron, its because there are multiple OTE instructions for the same tag. ( very bad practice imo ). The reason the OTE is green is because its only false for one rung, then goes back to being true the rest of the scan. From what I see in the program, its reads like "If the register equals 90 or 100 then turn on the OTE".

AustralIan · Mar 15, 2018

This is part of a state machine.

I suspect the duplicate OTE is a mistake, although in this case it will have no programatical consequence.

The program will never be left in state 90.

you could simplify by replacing all of the occurrences of XIC B90[11].10 with EQU N93[20] 100, and removing both of the OTEs. If you do this for all similar state booleans, this will avoid accidentally having two states on at once.

Another alternative simplification would be simply removing the first OTE.

LoganB · Mar 15, 2018

Ron Beaufort said:
is it working the way that's it's written now? ... if so, remember the old adage: "if it ain't broke - don't fix it" ...

I love any adage that minimizes my time working on someone else's horrible program, but unfortunately, this one IS broken. This particular part isn't the cause I don't think, but as I said in the OP it's just another thing making me shake my head.

Thanks for the input guys, as always, I greatly appreciate it!

Steve Bailey · Mar 15, 2018

working on someone else's horrible program

Let him who is without sin cast the first stone. I've lost count of the number of times I've come back to a program I wrote some months or years earlier and thought, "what idiot wrote this POS". As we gain experience we learn better ways of doing things.
Of course, in this business once you touch something you own it. So sometimes, when you know you're the one who will be maintaining the production line with the hard-to-follow logic, it makes sense to rewrite someone else's code in a manner that you can understand.

LoganB · Mar 15, 2018

I wish I could, but the line only has about a year left in production so management has decided to just suffer through it, since I'm the only one that will have to suffer

All the complaining is good-natured on my part, I totally understand. This line was originally authored in 500, and I've converted it to a 5000 processor, so there are a lot of functions I have at my disposal now that the original programmer didn't have.

Why/How is this OTE energized?

LoganB

Lifetime Supporting Member

harryting

Lifetime Supporting Member

Steve Bailey

Lifetime Supporting Member + Moderator

Ron Beaufort

Lifetime Supporting Member

Ron Beaufort

Lifetime Supporting Member

LoganB

Lifetime Supporting Member

Ron Beaufort

Lifetime Supporting Member

Gomez_

Lifetime Supporting Member

AustralIan

Member

LoganB

Lifetime Supporting Member

Steve Bailey

Lifetime Supporting Member + Moderator

LoganB

Lifetime Supporting Member

Similar Topics