Understanding how an OTL is reset when there is no OTU

Good morning all,

I'll preface this by saying I've been an electrical tech for about 10 years, but just started doing programming in the last two years. I'd say I'm still beginner to maybe starting to hit intermediate levels so I still miss some of the simpler concepts.

I'm currently working on a robotic packaging cell, the cell provides the product and boxes to pack on separate infeed conveyors. The issue I'm experiencing is that when I have a Box jam on the Infeed, the minor fault does not seem to want to reset all the time.

Our programs are designed over in Italy and it's up to us to interpret them so it presents its own challenge - but we're ultimately responsible for debugging and fixes so this is one I definitely need to get the concept of pretty quickly.

When looking at the logic, we have several sensors in a series with a filter (5 seconds filter) to check for jams, each sensor uses an XIC and if all them are high at the same time under certain conditions for longer than five seconds the system says okay, we have a jam on the infeed box conveyor please check and remove the jammed box. And you cannot resume the operation of the work cell until the jam is cleared.

This minor fault is turned on with an OTL, but when I am looking to see how it is unlatched I don't find an OTU specific to the tag used for the OTL. I believe they generally have a general reset pulse that is set to unlatch all alarms if their conditions are not met for the alarm to go high.

Is it possible that this is part of the reason why we seem to struggle with this particular alarm if it doesn't have an OTU to accompany the OTL?

This is all Allen Bradley btw, on Studio Logix 5000 using version 33.

It's likely being zeroed as a whole word at once. Is the latched bit a bool or the bit level of a word?

Scytes said:

I believe they generally have a general reset pulse that is set to unlatch all alarms if their conditions are not met for the alarm to go high.

Click to expand...

As PLCDontUQuitOnMe notes, it is quite common in this type of setup to have faults be individual bits of word(s) and the reset pulse will zero the whole thing via a MOV, FLL, CLR, etc instead of separate OTUs.

An additional benefit of this setup is that you can check for a state of 'some fault exists' a word at a time instead of each bit requiring its own instruction

Could be a OTE later and based on scan cycle its unlatched by that, you may also want to track it through the HMI. It may have a specific button to unlatch the alarm bit.

"Duplicate destructive bits" in the cross reference should locate that for you I would think

Could it perhaps be that the OTU is living in an AOI somewhere. I have a few projects that an integrator did that operate this way. The OTL is present somewhere in the logic to make the bit go high, then the last rung in the AOI unlatches all the Latched bits pertaining to its UDT. This happens every scan.

I've always thought that when you use an OTL you should always also include an OTU for this very reason. People expect to find an OTU to go with it. Of course it isn't required, but I always thought it was a good practice. Although I have to admit, I do use OTU instruction sometimes without the OTL.

People sometimes want to give special powers to the OTL and OTU instructions. But, the OTL and OTU combined are essentially the same as the OTE.

• The OTL can turn a tag on. but cannot turn it off. Or put another way, it can write a "1" to a tag, but can't write a "0". Thus the term "latch" comes into play. The instruction's only purpose is to turn a tag on.
• The OTU can turn a tag off, but can't turn it on. Again, put another way it can write a "0" to a tag, but cannot write a "1". That is where unlatch comes from. The instruction has one purpose: turn a tag off.

The OTE can turn a tag on (1) and it can turn it off 0). So when an OTE goes true it is doing the exact same thing as a OTL. Writing a "1". When the OTE goes false it is doing the same thing as the OTU, turning the tag off.

So any instruction that turns a tag off can unlatch a latched bit. That could include an OTE or many of the other instructions mentioned here (MOV, CLR, FLL and a few others). I would right-click on the OTL and do a cross-reference. Locate the instructions that have a "Y" in the destructive column. Those are the locations that can affect that tag.

OG

Yes... there could be a move command that is moving a 0 into the OTL bit.
Did you search for the bit?

Operaghost said:

I've always thought that when you use an OTL you should always also include an OTU for this very reason. People expect to find an OTU to go with it. Of course it isn't required, but I always thought it was a good practice. Although I have to admit, I do use OTU instruction sometimes without the OTL.

People sometimes want to give special powers to the OTL and OTU instructions. But, the OTL and OTU combined are essentially the same as the OTE.

• The OTL can turn a tag on. but cannot turn it off. Or put another way, it can write a "1" to a tag, but can't write a "0". Thus the term "latch" comes into play. The instruction's only purpose is to turn a tag on.
• The OTU can turn a tag off, but can't turn it on. Again, put another way it can write a "0" to a tag, but cannot write a "1". That is where unlatch comes from. The instruction has one purpose: turn a tag off.

The OTE can turn a tag on (1) and it can turn it off 0). So when an OTE goes true it is doing the exact same thing as a OTL. Writing a "1". When the OTE goes false it is doing the same thing as the OTU, turning the tag off.

So any instruction that turns a tag off can unlatch a latched bit. That could include an OTE or many of the other instructions mentioned here (MOV, CLR, FLL and a few others). I would right-click on the OTL and do a cross-reference. Locate the instructions that have a "Y" in the destructive column. Those are the locations that can affect that tag.

OG

Click to expand...

This is something we spend a lot of time on in the PLC Boot Camp Class. Helping students understand there are so many possible ways to read and write a 1 or a 0 into a "Bit Box" to control your program and field devices

That's where lots of examples help. The harder point was often explaining why the OTU was highlighted when the device was energized.

OG

I think you can Move a zero into the word and that will unlatch the bit with out using an OTU

HMI push button resetting it? Message writing from another PLC?

If the OTL is addressed to a .BIT sub-element of a DINT/INT/SINT, then I agree that there is very probably a MOV or FLL instruction somewhere that resets the whole integer element to zero.

It would be sneaky to write Resets from an HMI directly; I always set a "HMI_Reset_PB" tag then do the resets explicitly in logic. But it certainly is another way to perform such an action.

I'm thirding the reset the bit from the HMI.
I've seen it before and hate the practice as its not intuitive for troubleshooting (well it isn't for me).