bwhinch

Unclear on OTE OTU instructions used together

16 posts in this topic

RSLogix 500/ SLC-500

I have this program where an OTU instruction unlatches a bit that's addressed to a VFD's emergency shutdown over devicenet. The next rung uses a OTE instruction to energize that same bit.

I'm having trouble understanding if those are suppose to work together, and I can't seem to Google the right words. My background is DeltaV, I'm new to PLCs. Unfortunately I'm not able to test the program, I just expected to see a latching and unlatching pair.

1 person likes this

Share this post


Link to post
Share on other sites

I like the Delta V. It's one of the few DCS platforms that I would say that about :-)

It sounds like the OTU is driven by a soft input (like a button from an HMI only this is a signal from DeviceNet). Maybe this is someone's idea of a latch / unlatch?

Imagine that you have a button addressed in an HMI such that "On Button Down" turns the output in the PLC on (this is reverse from what you seem to have). If there's nothing in the PLC to turn the output off, it stays on. In this case you would add an OTU to unlatch the output.

1 person likes this

Share this post


Link to post
Share on other sites

Unless there's a jump or something, the OTE instruction is probably in control. Can you post a screenshot of the 2 rungs in question?

1 person likes this

Share this post


Link to post
Share on other sites

Yea Michael, the OTU and OTE are both enabled by the same N file. If I can import this picture correctly.

Joe, in the image there is only two references to the output bit. My confusion is why the OTU instruction is even necessary, if there is no OTL instruction to latch in the first place.

My understanding is if the value in the N file isn't equal to 3/4 it would disable the bit?

 

otu-ote.png

Share this post


Link to post
Share on other sites

Posted (edited)

N just means integer. Think of an N as being a group of integers and also be aware that you can bit pick the integer (ie use the individual bits if the integer)

If N15:101 = 2 it unlatches an output that is in a VFD that lives on devicenet

If N15:101 = 3 or 4 then it latches the output

Edited by Michael Lloyd

Share this post


Link to post
Share on other sites

Seeing just these two rungs the first seems to be irrelevant

2 people like this

Share this post


Link to post
Share on other sites

Posted (edited)

1 minute ago, b_carlton said:

Seeing just these two rungs the first seems to be irrelevant

But there's always the rest of the story. I'm not familiar with (or a fan of) DeviceNet but doesn't the DN card read the IO point? It looks to me like the output in the first rung is indicating the state of the E-Stop on the drive.

If I had a dollar for every time I looked at someone else's program wondered "wtf was that guy was thinking" I'd have a lot of dollars. Not enough dollars, but a lot. I've currently got an abomination of a CLX program on my right screen and the new program to replace it on the left screen. It's an abomination in CLX... and in the SLC or PLC5 it was written for it's probably sheer genius

Edited by Michael Lloyd
1 person likes this

Share this post


Link to post
Share on other sites

Here's how RSLogix 500 processors work with OTU, OTL, and OTE instructions:

If the logic leading up to an OTU instruction is false, it does nothing.
If the logic leading up to an OTU instruction is true, it writes a 0 to the indicated memory location.
If the logic leading up to an OTL instruction is false, it does nothing.
If the logic leading up to an OTL instruction is true, it writes a 1 to the indicated memory location.

If the logic leading up to an OTE instruction is false, it writes a 0 to the indicated memory location.
If the logic leading up to an OTE instruction is true, it writes a 1 to the indicated memory location.

The big difference is that OTU/OTL instructions only write to the memory location when their preceding logic is true. An OTE instruction always writes to the memory location.

So, after rung 69 executes, O:1/28 will be on if and only if N15:101 is equal to 3 or 4. If N15:101 is equal to anything other than 3 or 4, O:1/28 will be off.

Has this been running fine? Rung 68 is redundant with rung 69 right after it.

 

2 people like this

Share this post


Link to post
Share on other sites
Just now, Joe E. said:

Here's how RSLogix 500 processors work with OTU, OTL, and OTE instructions:

If the logic leading up to an OTU instruction is false, it does nothing.
If the logic leading up to an OTU instruction is true, it writes a 0 to the indicated memory location.
If the logic leading up to an OTL instruction is false, it does nothing.
If the logic leading up to an OTL instruction is true, it writes a 1 to the indicated memory location.

If the logic leading up to an OTE instruction is false, it writes a 0 to the indicated memory location.
If the logic leading up to an OTE instruction is true, it writes a 1 to the indicated memory location.

The big difference is that OTU/OTL instructions only write to the memory location when their preceding logic is true. An OTE instruction always writes to the memory location.

So, after rung 69 executes, O:1/28 will be on if and only if N15:101 is equal to 3 or 4. If N15:101 is equal to anything other than 3 or 4, O:1/28 will be off.

Has this been running fine? Rung 68 is redundant with rung 69 right after it.

 

Except O:1/28 is in a DeviceNet card not an output card

Share this post


Link to post
Share on other sites
Just now, Michael Lloyd said:

Except O:1/28 is in a DeviceNet card not an output card

 I admit that I've never worked with DeviceNet. Are the outputs in a DeviceNet card updated asynchronously? Wouldn't O:1/28 be written every scan by the OTE instruction independent of the OTU?

Share this post


Link to post
Share on other sites

Posted (edited)

Ditto but I don't think it is polled every scan. I think there is a scan rate. so the E-stop status could turn it on as long as the first rung doesn't unlatch it. I am looking at it as if I was monitoring a button with ProSoft serial (modbus) card and the scan rate is every 5s. 

There's is a high probability that I'm wrong but that's how I'm looking at it.

PS - I think it's fairly sloppy programming but am hesitant to be too critical of it

Edited by Michael Lloyd

Share this post


Link to post
Share on other sites

It's been running for 16 years, however I don't think it uses that logic. According to the people who use the equipment regularly that belt always runs, only the main disconnect stops it.

If I'm understanding everything, rung 68 doesn't have a purpose? Maybe it is an unfinished feature.

The reason I am worried about it is because I'm tasked with adding a condition that would stop the belt.. So the OTU not really doing anything would make my life easier. The N15:101 integer of 3 is some sort of recipe value, it doesn't change for our usage.

Share this post


Link to post
Share on other sites

OTU and OTL should not be mixed with OTE

Share this post


Link to post
Share on other sites

Otu and Otl get mixed with Ote alot. Typically when I've seen it done it was a two fold reason.Number one was for Hmi software like wonderware when you build out motor control popups you usually use set instructios in wonderware to turn on a bit in the plc the otu will force the bit to unlatch in wonderware. Two otu will ensure you drop an Ote to a false state if they are properly placed in the program. We do this so the time in my plant. It works fine. Also using integers instead of bits works much better. It allows alot of data to be exchanged in a single word.

1 person likes this

Share this post


Link to post
Share on other sites

Also I would right click on n15:201 and do a find all or a cross reference to see what all changes that value. To me it looks like there is some feed back from the drive or somewhere else in the code that tells it there's an emergency condition.

1 person likes this

Share this post


Link to post
Share on other sites

As this logic is in a  SLC500, the I/O scan is synchronous. Ordinarily, the physical output would have to wait until the Program Scan is finished before

the state of the output bit is transferred to the I/O module.
In this case, the output is a bit is in the DeviceNet transfer block for the Mapped I/O scanlist.

The data is still treated as physical I/O because it has to be transferred down the backplane to the DeviceNet Scanner in the chassis.
The DeviceNet configuration in the scanner would dictate when its value is sent over the DeviceNet network.

To the SLC500 controller, it is still seen (and treated) as physical I/O

I agree with JJackson on the need to determine where N15:201 gets its value (including HMI, external Write messages, etc.) which leads to my agreeing with
Michael Loyd in that on the surface, the top rung seems redundant....but there's always something lurking in the woods.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now