Status Point Energize (STE) 2

[RichardE1]

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 Richard.edington@gmail.com with questions, comments or for more information.

 

[RichardE1]

The pdf version did not get attached to the original post. Here it is.

 

[Skogsgurra]

First time visitor. We don't know you and we do not know if you are presenting a new idea. Or if you just reformulate old best practice methods. Or if you are trying to sell something.

Perhaps you should make a short and snappy summary where you concentrate on the problem and how STE helps.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[RichardE1]

It would be difficult to sell something that has already been given away.

I wrote the STE instruction and found it useful.

I would like to know if other people find it useful.

If you like, try the instruction. If not don't.

 

[RichardE1]

100 % recycled posting....What does this mean?

If you've seen this content before, please tell me where so I can review it.

 

[RichardE1]

This instruction is only posiable due to features provided fairly recently in PLCs. Specifically, the ability to provide logic for when a rung in condition is false in a user defined instruction. Review the STE instruction to see what I'm talking about.

 

[RichardE1]

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.

 

[Skogsgurra]

OK. I don't do much ladder. Use 'Logic' programming and Finite State Machines myself. So I am afraid I have never run into the kind of problem you describe. If the problem is what happens when you switch between run and stop mode, then it is mostly about how you initialize the system - sometimes how you do not initialize it and if non-volatile memory is available or not. Available in all systems these days.

I think that anyone 'under the gun' prefers not to find code that requires extra thinking in the system he is troubleshooting. Keep it simple has always proven best.

Not that your STE doesn't simplify (reduce) number of terms/rungs in the program, but it needs to be tested, included in the documentation and taught to everyone that will have to work with the system. Quite a task.

I am sorry if I sound old fashioned and somewhat reserved re the STE. The reason is that I have met many bright ideas that have been implemented from a purely theoretical point of view and that I have been that guy 'under the gun' when things go wrong. Having unknown, undocumented blocks or functions and no one that knows what it is about doesn't exactly help in such situations.

The '100 % recycled' thing is an attempt to be PC, witty, original in a place where it doesn't cause much problems (i.e. not in a program) and I think that it is obvious what it means. Or did you think it was a comment to your work? It is not.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[RichardE1]

To Skogsgurra comment,

The situation I describe can't be initialized programatically. The point is that there is a carrier between two switches. Before the processor mode switch the system correctly denoted a carrier present because SW1 was made and SW2 was not made yet. After the mode switch, there is no input to the system that can correctly denote a carrier between the two switches when using an OTE instruction as mentioned. The status will be lost.

I consider understanding the instruction to be simple in the extreme. Convincing others is not simple at all. Based on testing and running machinery with it, I know the instruction works. As you seemed to admit, the instruction simplifies coding and reduces the amount of code.

I completely understand your point of view. So far, I'm the only person that seems to find the instructon benificial.

I figure that there is at least one person out there that finds wading through volumes of rediculously low level code a waste of time. Of course, I'm primarily talking about the latch and unlatch instructions.

I have no idea what the forum lingo means.

 

[RichardE1]

This version is more to the point, has more examples and less philisophical ramblings.

See attached 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.

The STE instruction makes use of fairly recent functionality provide in some PLC programming languages. Specifically, the ability to define logic for the rung in false condition in a user defined instruction. See the STE implementation for full details and the associated logic.

The logic behind STE is as follows:

In the Logic routine of the STE Add-On Instruction:

{
BST XIO PT OTE LE NXB OTL PT NXB OTU TE NXB OTU STATUS_TE BND
}

***SEE PDF FILE FOR LADDER EXAMPLES***


In the EnableInFalse Routine of the STE Add-On Instruction:

{
BST OTU LE NXB OTU PT NXB XIO STATUS_TE OTE TE NXB OTL STATUS_TE BND
}
***SEE PDF FILE FOR LADDER EXAMPLES***


That’s basically it. Define PT, LE, TE as outputs. Define STATUS_TE as an internal variable.

To try the STE instruction using RSLogix 5000, download the STE.zip file. Extract STE.L5X and import it into RSLogix 5000 as an Add-On Instruction – right click on “Add-On Instruction” and click “Import Add-On Instruction”. STE will appear as an instruction under Add-on in the instruction pallet. You can copy the text versions of the logic examples above to rungs in the program – double click on a new rung and paste the text in the box provided. After pasting the logic, if you right click on “CARRIER_PRESENT”, for instance, in the STE instruction; you can click Add “CARRIER_PRESENT” to define it as a STE tag in the program. After you’ve added all of the tags to the program, you should be able to download and run if you have a processor or emulator at your disposal.

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 the best that’s available so far. I’ve done quite a bit of testing to make sure the instruction performs as indicated. The instruction has been used extensively to control machinery. Please contact Richard Edington at Richard.edington@gmail.com with questions, comments or for more information.