Integer

I haven't learned a lot about programs but I thought if everything on the rung in front of an OTE was true, then the outputs would be true.
While I was trouble shooting a conveyor line today I found that to be not true. Some outputs were not true and everything on the rung,including an integer, was true. Can anyone tell me why?

Are the OTE's in a subroutine that isnt being executed? Also make sure that nothing is writing a 0 to that word/bit.

Pesky outputs!

The OTE instruction is a great little bit toggler. Based on rung logic the OTE addressed bit is either off, if the rung is false, or on if the rung is true. Now that is a good thing and a bad thing all in one. If you address the OTE to a bit, no matter the file, everything is ok until you address that same bit with an OTE in another rung, no matter where it is located. Then the rung logic will dictate the state of the bit. If you happen to be looking at a rung as you described, that is true but the OTE is still off! Bets are there is another rung controlling that same bit address with an OTE that the conditions are false and the bit is off. Which rung wins? At the scan rate of the processor, it is kind of a toss up. I have seen bits on that the rung logic should have off because the logic is false. Check your program for duplicate addresses with OTEs controlling them. As Bob mentioned, you can also have this problem if any MOV or some type of data instruction is writing a zero to your file where the OTE bit is. Let us know what you find.

An MCR instruction can produce the same results.

Here is a copy and paste from rslogix:

MCR

This output instruction (sometimes known as "Zone Control") is used to set up areas or "zones" of your ladder program where all non-retentive outputs may be disabled at the same time for the same length of time. It is used in pairs, one MCR to define the start of the ladder area to be affected and one MCR to define the end of the area.

An input instruction is programmed on the rung of the first MCR to control rung logic continuity. When the rung goes "false" all non-retentive outputs within the controlled zone are disabled. When the rung goes "true" all rungs are scanned according to their normal rung conditions (disregarding the zone control instruction).

I think as Randy said - you are probably "double coiling" your output, then looking at one occurence that is not "controlling".

The short answer - the last rung scanned before the IO update wins . . .

Good luck,

Marc


PS: If you search for "double coil" you'll get lots to look at.

Just watching this thing work the OTE O:4/13 is suppose to come on to energize a solinoid. On the same rung in line with the OTE is O:4/12
which is a true XIC and I:1/6 which is a XIO and its not true. In parallel with I:1/6 is N7:0/7 which is an XIC and it is true. There are times when the OTE becomes true and nothing else on the rung changes. There are no other O:4/13 but there are 3 OTE for N7:0/7 and several XIC and XIO for it.

Can you post your program?

zip your program file and you can then attach it to your post


Ken

I don't know. Is that possible?

Got real troubles here it seems!

Well, all that has been said so far is true in its own right as possible what IFs.
The pic below is the rung you described in your last post as I understand your description. You also said:

There are no other O:4/13 but there are 3 OTE for N7:0/7 and several XIC and XIO for it.

Click to expand...

. There is no problem with the XIC XIO instructions being addressed multiple times to the N7:0/7 address, but there should only be one OTE for that address or you will get the problem I mentioned earlier which could produce the problem in the rung you are looking at.

tonym said:

There are no other O:4/13

Click to expand...

Are than any OTU's?

Also try doing a cross reference on O:4. Any MOV's, CLR's, FLL's, etc. to O:4?

Is that rung actively being scanned?

Good luck,

Marc

tonym said:

I don't know. Is that [attaching a program] possible?

Click to expand...

yes ... take a look at this ...

link to "how to attach program" example post

OK here it is rung 21 ladder 5

Tony

I don't see any issue with your program yet, so I'm curious if the logic is okay but the speed of data between your PC/Laptop and the Processor are too slow to show you the "real picture". If the output is on for a small amount of time and the baud rate from computer to processor is slow, you may not "see" the output go true on the computer. Can you see what the baud rate is and maybe speed it up?

This may not be the case since I reviewed your logic. It appears you have N7:0/7 true at all times in rung 9, true when I:1/7 & I:1/8 are true in rung 20 and true whenI:1/10 & I:1/11 are true in rung 38. If I were you, I would clean this confusing logic up and see if this causes the issue to go away.

sorry that I'm so short on time ... but maybe this will help ... notice that you have three OTE's controlling N7:0/7 ... and N7:0/7 is used as part of the control for your "108SOL" output ... that's probably got something to do with your problem ... I'll look at it some more as my work schedule permits ... but I'll bet that someone else nails it down real soon ...

plus ...

here is a

previous post about a very similar problem

the whole thread is worth reading but I think you'll find the troubleshooting techniques described in the "linked" post #14 to be VERY helpful in your situation ...

This is on a conveyor line and there is also the same kind of stuff on another conveyor. This program actually works but I don't know how.