Status Point Energize (STE) – An Easier Way to Keep Track of Process Status

Please rate the STE instruction

  • very useful

    Votes: 1 12.5%
  • useful

    Votes: 0 0.0%
  • not useful

    Votes: 6 75.0%
  • worthless

    Votes: 1 12.5%

  • Total voters
    8

RichardE

Member
Join Date
Oct 2010
Location
TN
Posts
10
Status Point Energize (STE) – An Easier Way to Keep Track of Process Status

Let’s first look at the reasons the STE instruction was written.

The first person to provide me with any kind of PLC programming guidance was an electrician. The bit of advice that has proved most useful over the years was to keep the use of OTL (latch) and OTU (un-latch) instructions to a minimum. All of my training up to that point was with languages such as C, Pascal and Fortran. The latch and un-latch instructions seemed to be easier for me to follow at the time. To the electrician’s contempt, I used these instructions a lot.

From the electrician’s point of view using an OTE (coil) and latching it in with a branch and a normally open contact referencing the coil represented what he was familiar with. The analogy is that of latching and un-latching a hardware relay.

From a PLC programming standpoint the main issue with using the latch and un-latch instructions is that it tends to lead to “spaghetti code”. There seems to be a tendency to put several latch and un-latch instructions controlling the same bit in the ladder logic. The use of multiple latch and un-latch instructions on the same bit leads to code that is difficult to understand. The authors using this technique often don’t fully understand the resulting logic. Many times it seems that this type of code is a “Band-Aid” approach based on “lucking” into some logic that works most of the time based on observing the machine run. This is not to say that a solid program can’t be written with latch and un-latch instructions. It’s possible that most of us don’t have the discipline to write solid code with these instructions.

Let’s look at the OTE instruction. The OTE instruction turns the referenced bit on when the rung in conditions are true and off otherwise. It’s a simple command. If the OTE instruction is used as shown below to latch a status bit, there is one problem. If the processor is switched from Run to Program and back again, the status bit will be lost. In some cases this is fine. The process inputs will just latch it up again if it’s called for. In other cases it just won’t work. For instance, say you have a switch that denotes a carrier of some kind is at one point – call it SW1 – and another switch that denotes that the carrier is at another point – call is SW2. Say you define a status bit that denotes that the carrier is between SW1 and SW2. Call the bit zone 1 status – Z1.

****see attached file for ladder examples****

Z1 will be lost if the processor is switched from Run to Program and back again. The switches are not situated to correctly latch Z1 after the mode switch.

PLC programming languages are very un-structured. They could be roughly compared to Assembly Language Programming. The successful programmer learns quickly to impose structure or rules. Most will agree that OTE instructions should never reference a given bit in more than one place in the program. A bit referenced by an OTE instruction should not, as a rule, be referenced by an OTL or OTU instruction.

For our purposes, let’s say that we will only reference a given status bit with one OTE instruction in a given program. One positive outcome of this is that basically all of the logic that drives the status bit is clearly provided on one rung. Let’s consider Z1 again. If there is a problem with Z1, you can review the logic immediately without searching through the program. Some status bits will have more involved logic than Z1. If there are status bits used in the logic controlling another status bit, some searching could be necessary to diagnose a problem. If the rules are applied, you at least will only have to look in one place to find the logic for each of the other status bits.

Now let’s consider the STE instruction. The STE instruction can be thought of as an OTE instruction that will survive a processor mode switch. It should be applied using the same rules mentioned above for the OTE instruction. Only reference a given status in one STE instruction in a program.

Very often it is useful to trigger an event based on the leading edge of a signal or the trailing edge of a signal. The STE instruction actually has three signals embedded in it. STE is a user defined instruction. It has data and logic. Let’s say you declare a tag called STATUS and set its data type to STE. Let’s say you reference STATUS in an STE instruction using the rules mentioned. Then STATUS.PT is on when the rung in conditions are true and is off otherwise. This is just like the OTE instruction behaves. The difference is that if STATUS.PT is true when a processor mode change is made, it will also be true after switching back to Run Mode. STATUS.PT survives a processor mode switch. Another signal embedded in the STE instruction is denoted by STATUS.LE given our example. STATUS.LE is on for the first scan that the STATUS.PT is true. The last signal embedded in the STE instruction is denoted by STATUS.TE given our example. It is on the first scan STATUS.PT is off. PT stands for point. LE stands for leading edge. TE stands for trailing edge.

Consider the following example:

****see attached file for ladder examples****


The STE instruction implementation for RSLogix 5000 is included with this document in most cases. This instruction was written recently and the document at hand is all that’s available so far. I’ve done quite a bit of testing to make sure the instruction performs as indicated. The instruction was also used extensively to control machinery. Please contact Richard Edington at [email protected] with questions, comments or for more information.
 
Keep in mind that this instruction is only posiable due to fairly recent features provided in PLC programming languages. Specifically, the ability to define logic for when the rung in conditions are false in user defined instructions.
 
The ability to define actions for the false state is merely a convention. If you define an action for the false state that is pretty much a latch/unlatch.

I believe this code will function identically.

XIC STE_In BST OTL STE_Out NXB ONS Oneshot.0 OTE STE_LE BND
XIO STE_In BST OTU STE_Out NXB ONS Oneshot.1 OTE STE_TE BND

Bottom line if it looks like a duck and acts like a duck it's still a duck, no matter what you call it.
 
The ability to define actions for the false state is merely a convention. If you define an action for the false state that is pretty much a latch/unlatch.

*****Reply*******
There is a little more to being able to define actions for the false state than latch/unlatch.
*****************

I believe this code will function identically.

XIC STE_In BST OTL STE_Out NXB ONS Oneshot.0 OTE STE_LE BND
XIO STE_In BST OTU STE_Out NXB ONS Oneshot.1 OTE STE_TE BND

******Reply********
I believe the two rungs you wrote here will provide the same status points as

XIC ste_in STE ste_yours.

The question is, which would you rather code? Which is easire to read when your under the gun to get something running.

The status points availiable from this short line of code are ste_yours.pt, ste_yours.le and ste_yours.te.

Both will survive a processor mode switch.
 
Keep in mind that this instruction is only posiable due to fairly recent features provided in PLC programming languages. Specifically, the ability to define logic for when the rung in conditions are false in user defined instructions.


Really? All PLC's??? are you sure??


:sleep:
 
Not real sure of the point here. I can see the STE as a test bit to see something that is happening faster than your Laptop updates but after that I do not see the point. I understand that when you change between run and program and back you need to know where things are at but I do not see where the STE is anymore usefull than a simple bit. Flipping between run and program mode is overused anyway and most people do it just to clear latches. Personally if your using the reboot switch like a light switch you really need to see what the heck is going wrong.

A little disclaimer I have only recently started even using the STE. Prior to this I made use of move comands and loaded an integer anytime I can between steps in my programs. Infact on alot of programs I do I use this integer value to prevent the program from going back a step or going forward a step.

I still find the use of a ineger to be the best method.
 
Not real sure of the point here. I can see the STE as a test bit to see something that is happening faster than your Laptop updates but after that I do not see the point. I understand that when you change between run and program and back you need to know where things are at but I do not see where the STE is anymore usefull than a simple bit. Flipping between run and program mode is overused anyway and most people do it just to clear latches. Personally if your using the reboot switch like a light switch you really need to see what the heck is going wrong.

A little disclaimer I have only recently started even using the STE. Prior to this I made use of move comands and loaded an integer anytime I can between steps in my programs. Infact on alot of programs I do I use this integer value to prevent the program from going back a step or going forward a step.

I still find the use of a ineger to be the best method.
*******

I'm wondering if you were 1 of 5 people that downloaded the STE command and hopefully imported it to a program and tried it. To my knowledge, that's the only STE avaliable. The point is with switching between Run and Program is that it can happen and will happen. If an OTE is used as described you will loose the status it represents.

I added clarification to the "Status Point Energize 2.doc".

It's not so much a matter of keeping track of steps although STE could be used to step through a process.

Take a look at the code comparisons of usign STE vs. not in the "Status Point Energize 2.doc"

I should probably include instructions to import the instruction and some code to show it's use.
 
My point was that it is functionally equivalent to a simple latch/unlatch pair with a couple oneshots grafted on.

It's a latch/unlatch for people who are afraid of latch/unlatch.

And I stand by my comment that being able to define actions for the false state is a convenient convention. An OTU instruction lets you define conditions for the false state too, and it's a standard instruction. I could wrap my code in a AOI and you couldn't tell the difference from the outside.

Bottom line. If you find it useful, great. It seems kind of silly to me, but then I know how to use latch/unlatch.
 
Last edited:
*******

I'm wondering if you were 1 of 5 people that downloaded the STE command and hopefully imported it to a program and tried it. To my knowledge, that's the only STE avaliable. The point is with switching between Run and Program is that it can happen and will happen. If an OTE is used as described you will loose the status it represents.

I added clarification to the "Status Point Energize 2.doc".

It's not so much a matter of keeping track of steps although STE could be used to step through a process.

Take a look at the code comparisons of usign STE vs. not in the "Status Point Energize 2.doc"

I should probably include instructions to import the instruction and some code to show it's use.


Yes I did download it. I have used it but as I said other than changing between program and run I do not see the advantage of it. I work on alot of other platforms other than RS5000 so I guess I look at it from that perspective.

Also for people that have never seen this function seeing it for the first time can lead to alot of confusion. Other than being used as a "test" bit for me it is just adding complication to a program that is not needed.
 
No fear here. I fully intend to follow the herd and use latch and un-latch instructions instead of the STE instruction. That is, unless I convince a customer of the benifit of using the STE instruction.

Once you get past the fear of considering a different approach, here's the facts:

1. It takes roughly twice as many instructions to accomplish the same thing with latch and unlatch.

2. The code is more readable. A person can concentrate on the logic not the syntax.

3. The instruction has been tested and used to run reasonably complex machinery.

4. A better comparison is that STE is an OTE instruction that will retain it's status through a processor mode change.

Here's my belief:

1. There is at least one person out there who finds wading through rediculously low level code an un-necessary waste of time.
 
Change the name.

I read half the original post before I realized we weren't talking about the built in STE instruction in lesser platforms. Its the Selectable Timed interrupt Enable instruction.

Call it OES. Ouput Energize with Status. Yeah, I don't think that mnemonic is taken in A/B world...someone correct me if I am wrong.

I can see it being quite useful, but not necessarily functional enough to replace my existing constructs. Add an On delay and an Off delay. Then call it the TOS. Timed Output with Status. Then it could make a handy alarm detector, or photocell debouncer, or pump short cycle preventer...

If I see some code that could benefit, I may give it a try though.
 
I like agreement.

I attached a new version of the article. It has the code you mentioned, more explination and less philosophical rambling.

I was not aware of the name conflict. I like your suggestions.

Below is a text only partial copy of the article (limited reply space; I recommend downloading the pdf):
***********
Status Point Energize (STE) – An Easier Way to Keep Track of Process Status

Let’s look at the OTE instruction. The OTE instruction turns the referenced bit on when the rung in conditions are true and off otherwise. It’s a simple command. If the OTE instruction is used as shown below to latch a status bit, there is one problem.

{
BST XIC SW1 NXB XIC Z1 BND XIO SW2 OTE Z1
}
***SEE PDF FILE FOR LADDER EXAMPLES***

If the processor is switched from Run to Program and back again, the status bit will be lost. In some cases this is fine. The process inputs will just latch it up again if it’s called for. In other cases it just won’t work. For instance, say you have a switch that denotes a carrier of some kind is at one point – call it SW1 – and another switch that denotes that the carrier is at another point – call it SW2. Say you define a status bit that denotes that the carrier is between SW1 and SW2 – Call it Z1. If coded as shown above; Z1 will be lost if the processor is switched from Run to Program and back again. The switches are not situated to correctly latch Z1 after the processor mode change. The carrier is in “no man’s land” so to speak. It’s between the two switches and there is no way to detect this from a “cold start”.

The typical code used to handle this is shown below.
{
XIC SW1 OTL Z1

XIC SW2 OTU Z1
}
***SEE PDF FILE FOR LADDER EXAMPLES***


Both methods use 4 instructions. The first example has the advantage that it is on only one rung but it should not be used because it can cause a loss of data.

Let’s not give up on the attempt to provide all of the logic that drives a status bit on one rung. If for no other reason, providing all of the logic that drives a status bit on one rung typically makes determining why the bit is on or off immediately obvious.

For our purposes, let’s say that we will only reference a given status bit with one OTE instruction in a given program. Most will agree that this is good practice.

Let’s consider Z1 again and ignore the down side of loosing the status on a processor mode change. If there is a problem with Z1, you can review the logic immediately without searching through the program. Some status bits will have more involved logic than Z1. If there are status bits used in the logic controlling another status bit, some searching could be necessary to diagnose a problem. If the rules are applied, you at least will only have to look in one place to find the logic for each of the other status bits.

Now let’s consider the STE instruction. The STE instruction can be thought of as an OTE instruction that will survive a processor mode switch. It should be applied using the same rules mentioned above for the OTE instruction. Only reference a given status in one STE instruction in a program.

Very often it is useful to trigger an event based on the leading edge of a signal or the trailing edge of a signal. The STE instruction actually has three signals embedded in it. STE is a user defined instruction. It has data and logic. Let’s say you declare a tag called STATUS and set its data type to STE. Let’s say you reference STATUS in an STE instruction using the rules mentioned. Then STATUS.PT is on when the rung in conditions are true and is off otherwise. This is just like the OTE instruction behaves. The difference is that if STATUS.PT is true when a processor mode change is made, it will also be true after switching back to Run Mode. STATUS.PT survives a processor mode switch. Another signal embedded in the STE instruction is denoted by STATUS.LE given our example. STATUS.LE is on for the first scan that the STATUS.PT is true. The last signal embedded in the STE instruction is denoted by STATUS.TE given our example. It is on the first scan STATUS.PT is off. PT stands for point. LE stands for leading edge. TE stands for trailing edge.

Consider the following example using the STE instruction:

{
XIC SW1 STE CARRIER_ENTERING

XIC SW2 STE CARRIER_LEAVING

BST XIC CARRIER_ENTERING.LE NXB XIC CARRIER_PRESENT.PT BND XIO CARRIER_LEAVING.TE STE CARRIER_PRESENT
}
***SEE PDF FILE FOR LADDER EXAMPLES***


CARRIER_ENTERING.PT, CARRIER_ENTERING.LE, CARRIER_ENTERING.TE, CARRIER_LEAVING.PT, CARRIER_LEAVING.LE, CARRIER_LEAVING.TE, CARRIER_PRESENT.PT, CARRIER_PRESENT.LE, CARRIER_PRESENT.TE are all concisely defined in these three rungs of logic.

The code reads fairly well. If SW1 is on, then the carrier is entering. If SW2 is on, then the carrier is leaving. If the carrier has entered and has not left, then it is present.

A further refinement would be to say: if the leading edge of the carrier entering occurred and the trailing edge of the carrier leaving has not occurred, then the carrier is present. One could argue that the leading and trailing edge refinement is un-necessary. Depending on the situation it is un-necessary. There are situations where it is useful.

In some cases, CARRIER_ENTERING, CARRIER_LEAVING and CARRIER_PRESENT are defined by more complicated logic than what’s shown here. The conditions in front of the STE instructions for these status points can be as complicated or as simple as necessary.

However complicated the logic that drives it, having immediate access to CARRIER_ENTERING.LE would be useful if the customer decides that a data transaction is needed when the carrier is entering. You immediately know of a trigger that can drive the transaction. See the example below.

{
XIC CARRIER_ENTERING.LE MOV Last_Label1[0,1] InComingLoadbar
}
***SEE PDF FILE FOR LADDER EXAMPLES***


Granted, the data transaction shown here is simple. The point is that you immediately know of a trigger to use. You would also know of a trigger to use if a FIFO push was needed when the carrier is leaving – CARRIER_LEAVING.TE or CARRIER_LEAVING.LE depending on the situation.

Note that in this example, CARRIER_ENTERING.LE essentially mirrors CARRIER_PRESENT.LE. This will not necessarily always be the case. It depends on the logic behind the status points.

Now let’s look at accomplishing the same thing without the STE instruction.

Consider the following code:

{
XIC SW1 BST OTL CARRIER_ENTERING_BIT NXB ONS CARRIER_ENTERING_BIT_LE_osm OTE CARRIER_ENTERING_BIT_LE BND

XIO SW1 BST OTU CARRIER_ENTERING_BIT NXB ONS CARRIER_ENTERING_BIT_TE_osm OTE CARRIER_ENTERING_BIT_TE BND

XIC SW2 BST OTL CARRIER_LEAVING_BIT NXB ONS CARRIER_LEAVING_BIT_LE_osm OTE CARRIER_LEAVING_BIT_LE BND

XIO SW2 BST OTU CARRIER_LEAVING_BIT NXB ONS CARRIER_LEAVING_BIT_TE_osm OTE CARRIER_LEAVING_BIT_TE BND

XIC CARRIER_ENTERING_BIT_LE BST OTL CARRIER_PRESENT_BIT NXB ONS CARRIER_PRESENT_BIT_LE_osm OTE CARRIER_PRESENT_BIT_LE BND

XIC CARRIER_LEAVING_BIT_TE BST OTU CARRIER_PRESENT_BIT NXB ONS CARRIER_PRESENT_BIT_TE_osm OTE CARRIER_PRESENT_BIT_TE BND
}
***SEE PDF FILE FOR LADDER EXAMPLES***

This code is a concise equivalent to the proceeding STE code example – nothing extra or missing. It seems that the STE code easier to read. The STE code is certainly easier to code.
 
Any constructive comments or questions would be welcome. I'm interested in gauging the reception I'll get, in general, if I use this in future applications.
 

Similar Topics

Hello all, I have a couple 1734-AENTR/C modules (revision 6.012) that are connected to a 1756-L73S (Revision 32.011). I have checked the...
Replies
4
Views
2,803
Hi all, I definitely know this is common problem and there are many threads about it and I did read them several time using "search" tool. Also...
Replies
11
Views
16,042
Hello all, We have compactlogix CPU with 1769 SDN scanner. The scanner is connected to two nodes 1734 ADN .Every now and then ADN fails with...
Replies
6
Views
3,594
Some times in running condition of the PLC, the point bus status become solid red and network status blinking green due to that total system...
Replies
1
Views
5,240
Hi All, I´ve been trying for a while but without much luck. I would like the monitor the 4 LEDs on the front of a 1734-AENT(R) module. They are...
Replies
8
Views
6,152
Back
Top Bottom