Multiple OTE in subroutines?

[NetNathan]

well, that's the "trick" ... the ControlLogix and CompactLogix systems don't "scan in sequence" ... specifically, the I/O signals can be transferred

party on ...

How do ControlLogix and CompactLogix scan, if not each rung at a time top to bottom?

I have seen logic that scans in columns instead of rows (which I always thought was wrong)...is this it?

 

[Ron Beaufort]

How do ControlLogix and CompactLogix scan, if not each rung at a time top to bottom?

well, the execution of the ladder logic is basically the way that you described it ...

but ...

it's the transfer of field signals (I/O) that's vastly different from how the PLC-5, SLC-500, and MicroLogix systems handle their I/O ... here are the BASICS for the ControlLogix ...

the input module is configured with an RPI setting (Requested Packet Interval) ... something like 20 milliseconds is a common default value ... each time the RPI elapses, the input module updates the input tags inside the processor with fresh data values ... this transfer of data values can happen at ANY POINT in the processor's execution of the ladder rungs – EVEN PART WAY THROUGH a rung in fact ...

the output module is configured with another (separate) RPI setting (Requested Packet Interval) ... again, something like 20 milliseconds is a common default value ... each time the RPI elapses, the data values of the output tags inside the processor are sent to the output module ... this transfer of data values can happen at ANY POINT in the processor's execution of the ladder rungs ...

(by the way, that's how the output "flicker" effect that I mentioned in an earlier post occurs) ...

going further ...

most ControlLogix input modules have a configuration setting for COS (Change Of State) ... when this feature is enabled (that's the default) it basically means that the input module will update the input data tags with fresh data – without waiting around for the next RPI to occur ... (think: "FAST") ...

besides the RPI, ControlLogix output modules are usually also updated (by default) at the end of every task ... there is also an IOT (Immediate Output Instruction) which can be used to trigger the update of an output module at a specific point in the execution of the ladder logic ... (once again, think: "FAST") ...

 

[CeeDee]

Sounds like the COS (change of state) feature basically overrides/ignores the RPI (requested pack interval) and updates as soon as a state change happens, regardless of the 20msec that is going on ANYways. So much tweak-ability. That's Super-fast!

 

[Davek0974]

Otherwise let each subroutine control a unique bit location 'Subroutine X output ON'. After the last subroutine call place a parallel condition rung. Each parallel branch will have a contact 'Subroutine X is enabled' and another contact 'Subroutine X output ON'. The parallel branches lead to the actual output. This should ease the troubleshooting problem.

this sounds similar to my first option of multiple AND stacks on the single OTE rung, with the addition of the "enabled" contact.

Regarding the compactlogix discussion, is it easier or too simplistic to read it as being processed as one complete rung at a time, that to me would give the flashing lamp result. I know there are immediate outputs but I have not got to them yet

Very interesting stuff.

 

[beethoven_ii]

I came across someone else's code where they used a single bool throughout the whole program as a sort of rung tidy or continuation bit. Although I would never generally use multiple OTE's for the same bit I quite liked their idea and do make use of it myself these days. If you have too much logic to fit neatly on one rung without causing the code to snake then dividing it into several rungs with the first rung ending with your continuation bit and the others starting & ending with it keeps your code neat and very easy to read.

 

[nehpets]

+1 for beethoven's reply, this is exactly as I program, nothing gets my goat more than having to either scroll across the page or navigate a long snake of logic to find the outcome of a rung of code. I always try to keep my logic within my laptop window view by implementing a continuation bit, it may cause quite a few extra rungs, but it's easier and quicker to troubleshoot. IMHO

Steve

 

[Davek0974]

Yes, I do use extenders, luckily in this program there are only two snakes so it's not too bad without them.

My issue this time would be the opposit - not too wide but too high, several extended parallel branches, easier to read than a snake though as there is only the contact stack and the OTE in any one rung.

 

[Ron Beaufort]

Regarding the compactlogix discussion,

if you're referring to the BASIC material that I posted above, I'm afraid that you missed a very important part ... what I described is for the CONTROL-Logix platform ... the COMPACT-Logix has a different (and actually more complex) method of handling its input and output signals ... I didn't describe that one ...

note: since the CONTROL-Logix and the COMPACT-Logix platforms are both programmed using RSLogix5000/Studio5000 software, many (most?) people think that they function the same way "under the hood" ... that is a MIS-conception ...

is it easier or too simplistic to read it as being processed as one complete rung at a time

for MOST situations, you could look at it that way ... in other words, just pretend that the ControlLogix and CompactLogix (asynchronous scan) systems work just like the older (synchronous scan) systems – and get on with your life ...

the concepts that I'm describing are for troubleshooting and debugging "butt-kicker" situations where you finally have to give up and surrender – and call in someone else to help get the job done ... the question then becomes: "What did the guru know – that I didn't know?" ... (by the way, that question invariably occurs to your bo$$ as the guru drives off into the sunset) ...

Very interesting stuff.

yep ... I'd say so ...

TIP: don't lose any sleep over this ... you've got enough to worry about right now with just the "plain vanilla" scan sequence that the PLC-5, SLC-500, and MicroLogix systems use ... just remember that sooner or later you'll run into a ControlLogix or CompactLogix system where things just "do NOT make sense" ... well, this type of "nuts-and-bolts" material is quite often the piece of the puzzle that's driving you crazy ...

 

[Davek0974]

Thanks Ron, I'm definitely not loosing sleep on it, or even reading much further into it, as you said, I'm still cutting my teeth on the SLC and hopefully soon Micrologix units and RSLogix500, it's enough to be getting on with

There's a whole mountain outside of my current situation to be conquered, other languages too, the SigmaTek PLC's that I'm replacing are programmed in English, I had a look once when they were being repaired a few years ago, and it's very much like a Basic application programming language - plenty of if-then-else etc instructions, outputs and inputs just had names, no addresses, so it was something like "If inputX then outputY else OutputZ" Not sure what it was called though, irrelevant here as the plc's were junk and have a habit of losing programming even though they have EPROMs and a battery!

 

[Paullys50]

Another perspective.

We use OTL to activate our code, this way we can repeat it as we want. I find it quite user friendly. This is on our Compact/ControlLogix systems. Some clairty...

We have a pretty structured code, so everything is programmed using step engines and device activations are organized according to the device type. To compliment this we have AOIs that handle all of our device activations and we have faceplates in our HMIs that reflect functionality. The AOIs actually have the OTE used to drive the output.

This also aligns with our design practices as we use grafcet documents to engineer the programs before we actually program the PLC. This allows us to look at a step in grafcet, see what the device activations are, and translate it directly to step activations in our code. It's almost a 1-1 translation (exception being complex conditions). Makes it very easy to audit the engineerd desgin against the written code. I can write my grafcet program definition, hand it to a rookie engineer and they can program 90% of what I need without really having to understand it all. Frees up my time to do higher level stuff.

The program OTL is simply a "Request to activate"
The AOI processes this request, and if true will activate the OTE used to control the output.
The AOI resets the "Request to activate".

Example:

Program Code:

                               Req_to_Activate

--+--EQU-+------------------------(L)---

  | Step |

  |  10  |

  +------+   



AOI Code:



   Req_to_Activate                 Device_Output

-----||--------------------------+--( )-------------+

                                 |                  | 

                                 | Req_to_Activate  | 

                                 +---(U)------------+     

So if I need the device activated in a step, I just add the OTL, if I don't need it in a step, I remove the OTL, the AOI resets it automatically.

From a trouble shooting perspective, look at the HMI to see what program is running, and the step number in reference. Go to the rung that has the step equal to the one in question, review the devices being activated by the OTL on that rung.

 

[Davek0974]

@ The OP.

In simple terms Buffer your I/O and avoid all these issues.

Buffer your I/O and someday someone other than you troubleshooting or making changes will thank you instead of curse you.

Do a forum search for Buffering I/O. IMHO it's stupid not to buffer I/O.

Just looked this up, i have already done this, I refer to it as I/O mapping and it's the first subroutine in my program.