Structured Text

[Ron Beaufort]

at this point, I think that I've answered Peter's question:

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

but there's more to the story ...

look back at Example F – and suppose that Paul leaves the "problem" NON-retentive code there ... but ... suppose that Paul deletes the "unused" JSR rung shown in Example D ... in that case the fan would have the RETENTIVE operation that Paul desires ...

in simplest terms, in an Allen-Bradley ControlLogix or CompactLogix system, PRESCAN will not "find" a file which has absolutely nothing to "call" it into operation ... it doesn't matter that the "calling" mechanism is made "false" (as with an AFI) – but as long as the mechanism exists, PRESCAN will operate on the file ...

now for the PLC-5 platform (preview: this is slightly different) ...

in simplest terms, in an Allen-Bradley PLC-5 system, prescan WILL indeed "find" a file even if it has absolutely nothing to "call" it into operation ... specifically, if Paul had completely deleted the "unused" JSR rung in a PLC-5 program, then the fan still would NOT have regained the desired RETENTIVE operation ...

hopefully this will be helpful to someone who passes this way in the future ...

DISCLAIMER: I'm swamped with work right now – and have written this in "fits and starts" – mostly when I should have been sleeping ... I apologize for the inevitable typographical errors – and any other similar mistakes ...

 

[Manglemender]

Ron,

Thanks for taking the time to explain. It is clear what you meant with your original statement about understanding the the difference between := and [:=].

I can see where Jesper was coming from in that "Result := Logic" isn't comparable to "Logic = OTL Result" in ladder because the the latter will never unlatch if "Logic" is false.

Once again, thanks for taking the time to explain.

Nick

 

[Ron Beaufort]

you're welcome ...

yes, I certainly see Jesper's point too ... the basic idea that I was trying to get across is that:

(a) in Ladder Logic there is a retentive way - and there is a non-retentive way to control bit/boxes ...

(b) in Structured Text there is a retentive way - and there is a non-retentive way to control bit/boxes ...

I agree that there's no way to precisely correlate the two programming methods with each other – but we've got to have SOME frame of reference when we move from one method to the other ...

the biggest issue that I've seen lately is that more and more programmers nowadays seem to be making conversions from one programming method to the other – but they often overlook the concepts of retentive and non-retentive operations when they do that ...

so ...

they can get their programs to work perfectly in normal day-to-day operations – but when a "Go-To-Run" situation arises, sometimes the failure to consider these "retentive" concepts can lead to disturbing surprises ...

hopefully these latest examples that I've given will make things easier to understand ...

 

[dbh6]

Hey Everyone

So i got a chance to go over this pdf http://literature.rockwellautomation...m007_-en-p.pdf
which is AB's structured text language, however on page 11 at the tip on the bottom of the page i came across something that i'am trying to grasp what it means, below is what i don't understand,


"I/O module data updates asynchronously to the execution of logic. If you reference an input multiple times in your logic, the input could change state between separate references. If you need the input to have the same state for each reference, buffer the input value and reference that buffer tag"

Ok i'am aware of the asynchronous nature of the logix 5000 processors however im trying to understand what it means when "If you need the input to have the same state for each reference, buffer the input value and reference that buffer tag".

if some one has the time please explain this as with an example if possible thanks.

 

[Ron Beaufort]

see if this helps ...

Edit to Rob.Hill (below) ...

Posted this from my phone - cant see all the screen - so I hope it makes sense!

yes, it makes perfect sense ...

.

 

[Rob.Hill]

Their wording could be more clear...
Basically at the start of the scan copy inputs to a defined set of internal registers. Then in the rest of your program, instead of referencing the physical inputs (which are liable to change) - reference your copy of the inputs as these wont change until the start of the next scan.

Posted this from my phone - cant see all the screen - so I hope it makes sense!

 

[JOLTRON]

Maybe I am over simplifying but it looks like,

In Siemens:
Memory locations are defined as "Retentive" during configuration. Where you select your range of M bytes (300 series) or check the boxes for what DB bits/bytes etc...(1200 series).

In AB:
Memory locations are defined as "Retentive" based on the instruction used that writes to it.

Retentive being defined as "The memory address / location returns to the state it was in before the processor left RUN mode (either by power loss or switching state from RUN to STOP to RUN again)".

 

[dbh6]

ok so correct me if im wrong as i think this will solidify my doubts on the nature of the asynchronous scan. If we are dealing with internal bits/registers, the way they execute in the scan is left to right, top to bottom and for any memory bit or register to update it would have to wait till the next scan before it gets a chance to update, so in essence the execution of the scan is like a the slc type plc for AB. Now the difference for logix platform plc's comes when you are dealing with the Local inputs coming in such that if you are referencing them in your logic, depending at what instance you use them in the logic, the status of your input could change mid way through your scan, which can cause unexpected results because your logic may want to execute that specific input at its current state not when its changing because of the asynchronous nature of the input updating. So in conclusion a workaround or solution to that is to buffer that input to a internal memory location which is really just mapping that local input to an internal location in memory. By doing that then we won't have to worry about the input status changing mid way through the scan because that internal memory that we mapped from the local input only updates at the beginning of the scan so the status of that mapped input will stay exactly the same for that scan unless of course something in your logic changes it.

So let me know if thats right once again, thank you all for your help.

 

[jstolaruk]

Its not limited to Local inputs, could be fieldbus or other data not in the rack.

 

[dbh6]

@ jstolaruk ok say its not limited to only local inputs, is what i stated in the above message true such that if we use the buffer mapping we avoid the local inputs, fieldbus, analog or other data not in the rack from updating midway through the scan?????

 

[jstolaruk]

Yep, thats a very popular way of handling it. Update psuedo input images in memory at the beginning of program, the program updates psuedo output images, then copies those output images to the real I/O at the end of your program.

 

[dbh6]

come to think of it usually when i write my programs i actually did map my IO to internal memory locaitons at the beginning of the scan before calling program routines, well at least now i know why its good to do that.

 

[Lancie1]

I think that RSLogix5000 situation is downright funny. To get all those bells and whistles, you have to do some extra work that is not required by the older software!

 

[The Plc Kid]

I think that RSLogix5000 situation is downright funny. To get all those bells and whistles, you have to do some extra work that is not required by the older software!

Yep compared to the features and functions of 5 and 500 much is left to be desired IMHO.

A lot of the functions are there bet they are add on apps or seperte tools. Talking with product managers at tech ed last year they are trying to get all the seperate apps to be part of the logix enviroment and install as one and not seperate tools.

 

[dfreerks]

Hey Everyone
"I/O module data updates asynchronously to the execution of logic. If you reference an input multiple times in your logic, the input could change state between separate references. If you need the input to have the same state for each reference, buffer the input value and reference that buffer tag"
.

Why not just use a periodic task with priority 1-6? Just make sure you allow enough time for I/O processing.