Structured Text

Thats not what 'retentive' means.

And this cant be right either:
Ron Beaufort said:
:= is RETENTIVE and basically acts like an Allen-Bradley OTL (Latch) instruction in ladder logic ...
Click to expand...

For achieving OTL and OTE in ST:

// similar to OTL
// if condition is TRUE then var is set to TRUE
IF condition THEN
var := TRUE ;
END_IF ;

// similar to OTE
// if condition is TRUE then var is set to TRUE
// if condition is FALSE then var is set to FALSE
var := condition ;
 
I think that we need to remember that SOME of us are talking about ALLEN_BRADLEY's version of "structured text" (and specifically for RSLogix5000) ...

and SOME of us are talking about some OTHER brand's version of "structured text" ...

I'm off to class right now – but I'll write more as time allows ...

peace ...
 
Hi
While i recognise the examples given are only to try and illustrate, a good programmer will use a start up routine to clear any 'latched' bits or data that needs to be reset on startup....
Also I recognise that all PLC manufacturers twist standards, i prefer to try and use common functions and therefore portable code.

Cheers
 
just for the record - part 1 ...

the figure below shows a series of lab experiments using an Allen-Bradley 1756-L55 ControlLogix processor - Revision 16.20 ...

suppose that the Start_Button is wired as a Normally-Open momentary pushbutton ...

suppose that the Stop_Button is wired as a Normally-Closed momentary pushbutton ...

suppose that the Outputs are all field devices ...

suppose that the processor is in the Run mode – and that the Start_Button has been pressed and released ... all of the outputs will be turned ON ...

suppose that the processor is placed in the Program mode – all of the outputs will be OFF ...

suppose that the processor is then placed back into the Run mode ...

in Example A, the non-retentive construction will cause Output_A to remain OFF ...

in Example B, the retentive construction will cause Output_B to come back ON ...

in Example C, the non-retentive assignments will cause Output_C to remain OFF ...

in Example D, the retentive assignments will cause Output_D to come back ON ...

.

stx_retentive_etc.PNG
 
Last edited:
just for the record - part 2 ...

the figure below shows a series of lab experiments using an Allen-Bradley PLC-5/20E processor – Series E - Revision D.2 ...

suppose that I:000/4 is a Start_Button which is wired as a Normally-Open momentary pushbutton ...

suppose that I:000/5 is a Stop_Button which is wired as a Normally-Closed momentary pushbutton ...

suppose that the processor is in the Run mode – and that the Start_Button has been pressed and released ... all of the output bits will be turned ON (status = 1) ...

suppose that the processor is placed in the Program mode ...

suppose that the processor is then placed back into the Run mode ...

in Example E, the non-retentive construction will cause bit B3/1 to go OFF (status = 0) ...

in Example F, the retentive construction will cause bit B3/2 to remain ON (status = 1) ...

in Example G, the non-retentive assignment will cause bit B3/3 to go OFF (status = 0) ...

in Example H, the retentive assignment will cause bit B3/4 to remain ON (status = 1) ...


.


stx_plc5.PNG
 
Last edited:
My comment pertained to that you likened persistent to OTL, and non-persistent to OTE.
Pretty sure I am right about what I wrote in post #16.

When you say ":= is RETENTIVE and basically acts like an Allen-Bradley OTL (Latch) instruction in ladder logic .." then you dont think about when the conditions are FALSE the := sets the output FALSE. OTL does not set the output FALSE under any conditions.

What you have described in the last two posts is something different. Here you have made examples in Ladder where you assume that you are latching an output via an OTE and by means of a parallel 'keep' bit that are part of the conditions.

I believe your description of how RETAIN in PLC5 and := and [:=] work in Logix works, it is just a puzling concept to me that retentivity is set in code.
I guess that what you explained in posts #20-#21 is what you wanted to explain in post #14.
 
Last edited:
Also I recognise that all PLC manufacturers twist standards, I prefer to try and use common functions and therefore portable code.
Click to expand...
Portable PLC code: what a sweet dream! I don't think it will happen in my lifetime.
 
Greetings JesperMP ...

first let me say that I'm looking at this as a friendly conversation – not as anything even remotely resembling a confrontational debate ...

it's quite possible that we're BOTH "right" – but that we're just not understanding each others' terminology ... please keep in mind that the terms "retentive" and "non-retentive" aren't something that I came up with myself ... these are the terms that Allen-Bradley uses to describe the operation of their programming components ...

please pardon me if I'm wrong, but something in your comments seems to indicate that you might not be fully aware of how Allen-Bradley handles "retentive" and "non-retentive" data - based on a PRESCAN sequence which their processors execute whenever they "Go-To-Run" mode ... if you're interested in this particular topic, you might want to take a look through the first few posts in the following thread:

http://www.plctalk.net/qanda/showthread.php?p=71786&postcount=1

this covers the Allen-Bradley (prescan) method of handling this sort of thing – and compares it side-by-side with the Automation Direct method (which is based on "ranges" of retentive and non-retentive data) ...

I'll write more as time permits – but right now I'm swamped with work ... I've knocked together a ControlLogix program which might be helpful ... if you want to take a look at it, please pay particular attention to the rung comments at the end of Ladder File 4 and at the end of Structured Text File 8 ...

it's important to keep in mind that neither of these two files are scanned/executed by the processor during normal operation (their subroutine calls are disabled) ... but ... the processor does indeed execute both of the files during its PRESCAN sequence – and that's where the "retentive" and "non-retentive" concepts are most important ...

my basic intention was to compare the Ladder Logic instructions with their Structured Text counterparts – in a side-by-side demonstration of how PRESCAN either DOES – or does NOT – affect each component during a processor's "Go-To-Run" situation ...

I believe that the program will adequately show the reality of what happens ...

somewhere along the line I'm sure that we can come up with a mutually acceptable method of describing this reality – in terms which will make sense to the widest possible audience ...

my major reason for tackling this subject in such detail is that more and more of my students are being forced to deal with Structured Text programs in their plants' control systems ... the concepts that I've brought up in this thread seem to be widely misunderstood by many programmers – at least based on what I've seen lately in the programs that my students have been bringing to class for analysis ...

.
 
Ron, I dont find your post confrontational, and I hope you think the same about mine.

I believe everything you wrote about the way AB PLCs retentivity work. I said so already.

It is simply your statement ":= is RETENTIVE and basically acts like an Allen-Bradley OTL (Latch) instruction in ladder logic .." that I disagreed with, and still disagree with.
I dont think I have more to add to what I have already written.
 
I am confused too

JesperMP said:
I believe your description of how RETAIN in PLC5 and := and [:=] work in Logix works, it is just a puzling concept to me that retentivity is set in code.
Click to expand...

The RETAIN attribute specifies if it is going to be stored in retentive memory.

What if a variable is assigned using a [:=] in one place and := in another?

The OTE or OTL issue is another issue, or at least it should be.

I am still working on my ST compiler. Variables that are declared in a RETAIN variable area, VAR RETAIN .. END_VAR will be stored in a flash as the motion controller loses power. Capacitors will provide power for a short time. Other than that RETAIN has no affect on how one assigns to the variable in normal operation.

Rockwell may be different but then they shouldn't call it structured text.
 
more about Structured Text - Retentive and Non-retentive ...

Greetings Peter ...

first let's make sure that we're talking about apples and apples ... specifically, Allen-Bradley has TWO versions of "Structured Text" ...

(1) in the ControlLogix and CompactLogix platforms – with RSLogix5000 software ...

:= is the retentive assignment ...
[:=] is the non-retentive assignment ...

(2) in the PLC-5 platform – with RSLogix5 software ...

:= RETAIN is the retentive assignment ...
:= is the non-retentive assignment ...

The RETAIN attribute specifies if it is going to be stored in retentive memory.
Click to expand...
sorry, but that's not exactly the way it works in Allen-Bradley-Land ...

with Allen-Bradley's method of handling Structured Text for the PLC-5 processor, the RETAIN statement will just keep the bit/box from being written to a ZERO status whenever the processor performs its PRESCAN during a "Go-To-Run" experience ...

specifically, if the := assignment is followed by the RETAIN statement, then the PLC-5 processor will NOT affect the associated bit/box during PRESCAN ... more specifically, if the bit/box is ON (status = 1) while shut down, the bit/box will remain ON (status = 1) when the processor goes back into the Run mode ...

on the other hand, the := assignment (when used by itself) will cause the PLC-5 processor to write a ZERO status into the associated bit/box during PRESCAN ... (notice this is DIFFERENT from the action of the same := assignment when used in a ControlLogix or CompactLogix system) ...

in simplest terms, using the RETAIN statement will allow the PLC-5's bit/box to remain "latched" ON at start-up ... without the RETAIN statement, the bit/box gets reset to ZERO at start-up – so it can NOT stay "latched" ...

now we might not agree with the terminology that Allen-Bradley uses – or the way that they handle "retentive" operations – but that's the way it works ...

side trip: many people refer to a "seal-in" rung construction as a "latch" ... personally I NEVER use that terminology ... the reason is that (with Allen-Bradley systems) a "seal-in" rung can NOT be made retentive ... on the other hand, a rung construction based on the OTL (Latch) instruction CAN be made retentive ...

What if a variable is assigned using a [:=] in one place and := in another?
Click to expand...
an excellent question – with a tricky answer that has unpleasantly surprised more than one unsuspecting programmer ...

since you've mentioned the [:=] assignment, which does not apply to the PLC-5 platform, I'll provide an answer for the ControlLogix and CompactLogix systems ... (the rules are slightly different for the PLC-5 platform) ... it's going to take several steps to nail this all down ...
 
Last edited:
2

suppose that Programmer Paul (not his real name) is writing a program for a ControlLogix system to control a small saw ... Paul is fairly comfortable with Ladder Logic programming – so he writes the "seal-in" rung shown below in Example A ...

the Start_Button has a momentary action – and it's wired Normally-Open ...
the Stop_Button has a momentary action – and it's wired Normally-Closed ...

Paul tests out the system many times – and the start and stop operations work fine ... and ... if the saw happens to be running when the processor is placed in the Program mode, naturally the saw goes OFF ... then when the processor is placed back into the Run mode, the saw does NOT come back on again ... this is precisely what Paul wanted – specifically, a NON-retentive action for the saw ...

now suppose that Paul decides to use Structured Text programming instead of Ladder Logic for his saw program ... he discards/deletes the original "seal-in" rung – and replaces it with what he assumes is the equivalent logic in Structured Text ... this is shown in Example B ...

once again, Paul tests out the system many times – and the start and stop operations work fine ... BUT ... suppose that Paul gets caught up in the "magic of the moment" and neglects to test the "retentive" properties of his new program logic ...

this could be a "lawyer-level" oversight ... because now if the saw happens to be running when the processor is placed in the Program mode - when the processor is placed back into the Run mode, the saw DOES indeed come back ON again ... this is definitely NOT the operation that Paul wanted ... specifically, he now has an unintended RETENTIVE action for the saw ...

moving right along ...

the Structured Text approach shown in Example C would make a better conversion of Paul's original "seal-in" rung ... here he's using a NON-retentive assignment ... now if the saw happens to be running when the processor is placed in the Program mode, when the processor is placed back into the Run mode, the saw does NOT come back on again ... this is giving the same NON-retentive operation as the original "seal-in" rung – which is precisely what Paul expected in the first place ...

now on to the next post for the flip side of the story ...

.

retentive_saw_a.PNG
 
this time suppose that Programmer Paul is writing a program for a ControlLogix system to control a small fan ... he's decided to do this in Structured Text – mainly because it looks similar to the programming languages that he studied in college ...

the Start_Button has a momentary action – and it's wired Normally-Open ...
the Stop_Button has a momentary action – and it's wired Normally-Closed ...

Paul wants the fan to have a RETENTIVE operation ... specifically, if the fan happens to be running when the processor is shut down, then the fan SHOULD start back up again when the processor is placed back into the Run mode ...

first let's take a quick look at Example D ... Paul is using the JSR in the top rung to properly "call" his Structured Text file into operation ... there's nothing wrong with that – it works fine ...

and like many programmers, Paul keeps a "scrapbook" file of unused clippings and samples of code which "might be needed later" ... naturally he intends to come back (someday) and delete this file – which he's calling "STX_Scraps" ... since he doesn't want anything in this particular file to be executed, he uses an AFI (Always False Input) instruction to disable the "calling" rung ...

Example E shows the logic which Paul has written for the fan ... notice that this time around he is using RETENTIVE assignments – correctly and on purpose ...

Paul tests out the system many times – and the start and stop operations work fine ... and ... if the fan happens to be running when the processor is placed in the Program mode, naturally the fan goes OFF ... then when the processor is placed back into the Run mode, the fan DOES indeed come back on again ... this is precisely what Paul wanted – specifically, a RETENTIVE action for the fan ...

now back to Peter's question:

What if a variable is assigned using a [:=] in one place and := in another?
Click to expand...
next suppose that Paul pastes the clipping of code shown in Example F into his STX_Scraps file ... since that particular file will never get called (remember the AFI) then Paul assumes that this little piece of code won't matter ... Paul is wrong ...

here's the trick ... when the processor is placed in the Run mode, the "unused" JSR will send the processor through the "unused" file during its PRESCAN operation ... at that point, the NON-retentive assignment will cause the processor to go write a ZERO into the fan's bit/box ... note that it will write a ZERO status - even though the "unused" code is structured to write a ONE (not a zero) ...

to make a long story short (no, it's too late for that) if Paul doesn't retest his program (after adding that last "unused" scrap of code) then he could be setting himself up for a surprising situation ...

specifically, now if the fan happens to be running when the processor is placed in the Program mode - when the processor is placed back into the Run mode, the fan will NOT come back ON again ... this is definitely NOT the RETENTIVE action for the fan that Paul desired – and fully expected ...

notice that Paul didn't alter the original code shown in Example E ... all he did was render it NON-retentive – by mistakenly including the NON-retentive assignment in the "unused" file ...

so – are we having fun yet? ...

now one more post ...

.

retentive_fan_a.PNG
 

Similar Topics

P
Structured Text String Alterations
Hello, I am using studio 5000 pro and am trying to figure out the structured text. Here's my scenario: An operator scans a barcode, the barcode...
2
Replies
15
Views
238
drbitboy
drbitboy
A
Structured text math data types
I have an expression in a structured text routine of a Logix controller that looks more or less like the following: ResultInteger := Integer1 *...
Replies
13
Views
389
lfe
L
dalporto
Logix - Structured Text - Need a hand
Good evening. I display the step number of a SFC on a display. Sometimes, on a trip, it goes quickly through many steps and I need to prove to...
Replies
1
Views
133
dalporto
dalporto
J
simulation setup using horner OCS using structured text (Cscape)
I am trying to set up a piece of equipment with a Horner HE-X4R. I'd like to use structured text and so far I'm just trying to get a basic On/off...
Replies
0
Views
70
jdk202
J
dalporto
Weird Structured Text execution order
Good morning. I'm doing a rehab and I need to recycle some part of the old code that won't change and that I need. This is a calculation that...
2
Replies
22
Views
1,370
I_Automation
I_Automation
Back
Top Bottom