RSLogix5000 structural text correlation with PLC scan

Hi this is my first time posting in this forum, so apologies if it isn't in accordance to forum rules.

Query 1
Does the structural text in RSLogix5000 run within one scan cycle?

Correct me if I am wrong, but from my understanding the PLC goes through scan cycles whereby it reads inputs, runs program and updates outputs. So I'd assume structural text is part of the program. So any rung that already has been cycled through shouldn't be able to affect the program before the structural text finishes.

Query 2
Another confusion I have is regarding the tasks. I know the tasks run in the sequence you schedule it, but can a short task run multiple times before a longer task finishes? So in the attached example can program2 (given its shorter) run multiple times before main program finishes?

I am not very experienced hence my questions might sound trivial, but any help is greatly appreciated.

A1: Yes, that's correct.

A2: I'm going to approach this thinking you mean "programs within tasks" instead of "tasks" themselves because of the attached image. Since the programs are both members of the continuous task, they will execute in serial fashion, regardless of time consumed by either.

welcome to the forum ...

Does the structural text in RSLogix5000 run within one scan cycle?

Click to expand...

in general terms, yes ...

the PLC goes through scan cycles whereby it reads inputs, runs program and updates outputs.

Click to expand...

no - it's not that simple ... your statement is USUALLY correct for MOST PLCs – but it is NOT correct for the ControlLogix/CompactLogix system that you've pictured ... the ControlLogix/CompactLogix systems are ASYNCHRONOUS – which means that the field inputs and the field outputs can be updated at ANY point during the processor's execution of the code/instructions ...

So I'd assume structural text is part of the program. So any rung that already has been cycled through shouldn't be able to affect the program before the structural text finishes.

Click to expand...

we'll have more success answering that question AFTER you've studied some of the definitions mentioned below ...

Another confusion I have is regarding the tasks. I know the tasks run in the sequence you schedule it,

Click to expand...

I think that you're confusing the term/idea of a TASK with the term/idea of a PROGRAM ...

here's a VERY basic explanation ...

(1) a TASK is a "scheduler" ... it doesn't really do anything by itself – it just tells other things (the PROGRAMS) when to execute ...

(2) a PROGRAM is just a "container" ... it doesn't really do anything by itself – it just holds/contains other things (the ROUTINES) ...

(3) a ROUTINE is where the real action takes place ... the routines contain the "code" which can be set up as Relay Ladder Logic, Structured Text, Function Block Diagrams, or Sequential Function charts ...

TIP: based on what you've posted so far, and on the questions that you're asking, I'd strongly suggest that you start out with Relay Ladder Logic – before you tackle Structured Text ...

can a short task run multiple times before a longer task finishes?

Click to expand...

technically, the answer is "yes" – but I strongly suspect that you're confusing the terms/ideas of TASKS and ROUTINES ... (in other words, there's more to it than you probably suspect) ...

So in the attached example can program2 (given its shorter) run multiple times before main program finishes?

Click to expand...

in simplest terms, no ...

suggestion: read throught the material in the following link – particularly Chapter 2 ... I really think that will help you get a handle on all of this ... then come back with any specific questions that you have ...

http://literature.rockwellautomation.com/idc/groups/literature/documents/qs/1756-qs001_-en-p.pdf

big question for you ... do you have any software and hardware to practice on - or are you trying to simply study this material from a book - or through videos, etc. ? ... you REALLY need something to work with in order to make much progress ... this is sort of like learning to play a piano - it's hard to learn without having an actual piano available to bang on ...

I hope that this helps ... good luck with it ...

reading are available as below,

http://literature.rockwellautomation.com/idc/groups/literature/documents/wp/logix-wp003_-en-p.pdf


http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm005_-en-p.pdf

another reading,

http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm007_-en-p.pdf

Thanks for the insight everyone =)

Ron I do have both Compact and Control to test on. It is tricky to tell the sequence as they run almost instantaneously.

However, I did get most of the answers I was looking for. Can you tell me if any of the following interpretations are wrong?

1. Short periodic tasks can run multiple times by interrupting any longer, lower priority task.
2. Task scheduling determine the sequence in which the programs will be executed.
3. Each program runs the primary routine, which can be used to jump to subroutines.
4. Structured text runs sequentially when called in the primary routine.
5. The ladders themselves run left to right and from top to bottom. Rungs do not run in parallel.
6. Whenever the code/instruction updates an output, it is reflected instantly.

I have used structural text before, I just wanted to clarify the timing for my own knowledge. The reason why I am using structural is because I need a lot of conditional statements, which is a pain in ladder logic.

Thanks for your detailed explanation!

You're mostly correct.

2. Task scheduling determine the sequence in which the programs will be executed.

Click to expand...

Not quite - task scheduling does not control the order the programs are executed within the task. This is handled by the program scheduler for each task - which you set up by right clicking on the task and selecting task scheduler. Task scheduling merely tells each task when to execute itself. When it executes, the programs will be run in the order determined by the program scheduler.

3. Each program runs the primary routine, which can be used to jump to subroutines.

Click to expand...

Correct - although for semantics sake - it's correctly called the Main Routine

4. Structured text runs sequentially when called in the primary routine.

Click to expand...

Correct - although as with ladder logic, a routine can use JMP and LBL instructions to return to a previous point in the routine, or to skip to a later point in the routine. This capability should be used very, very sparingly - but it is possible.

5. The ladders themselves run left to right and from top to bottom. Rungs do not run in parallel

Click to expand...

Correct for Allen-Bradley PLC's, and most other PLC's - but not all. Some Schnieder and Modicon PLC's run from top to bottom, and then left to right.

6. Whenever the code/instruction updates an output, it is reflected instantly.

Click to expand...

This depends on whether you mean "the state of the bit within the PLC code" or "the physical, hardware output on the PLC".

If a bit is set to 1 or 0 with an OTE, OTL, OTU, or anything else, it will immediately change state in the PLC code. So if the next rung examines that output, it's state for the purposes of evaluating the logic of that rung, will reflect what it was set to on the previous rung.

The physical outputs are a different story. On most PLC's, the outputs are updated once, at the end of the scan. The sequence is "Read Inputs>Execute Logic>Update Outputs". So though the state of the PLC tag is instantaneously updated, the physical output itself doesn't turn on until the last rung has been scanned and executed. However, on ControlLogix and CompactLogix PLC's, the inputs and outputs are updated asynchronously - that is to say, they are updated at a rate entirely independent of the PLC program. This rate is set on each card as you add it to the hardware configuration - typically digital I/O updates every 20ms, and analog I/O every 80ms (from memory, those are the defaults). This happens completely separately to the logic execution, so the same input could be true on rung 4 and false on rung 5. Likewise, you can never know when your output will actually turn on in relation to the position the logic will be in. Unless - you use an IOT (Immediate Output) instruction, which forces the hardware to immediately update the output image to turn that output on. There are very few reasons to do this - it's generally only used in very high speed applications as far as I'm aware.

Hope that helps!

Thanks ASF, you pretty much cleared all my confusion. Much appreciated !

The scheduling bit I meant the same thing, but I ignorantly referred to it as 'task scheduling'. My bad

So then the RPI (requested packet interval) parameter in many modules, essentially dictates when the input image follows the hardware input and the output image changes the hardware output.

Do I need to close the thread or change thread status to resolved, in this forum?

Salman S. said:

So then the RPI (requested packet interval) parameter in many modules, essentially dictates when the input image follows the hardware input and the output image changes the hardware output.

Click to expand...

That's correct. No need to mark as resolved, we don't have that functionality here

Do I need to close the thread or change thread status to resolved, in this forum?

Click to expand...

no - please don't even try that ... "closing threads" is for computer forums (not that there's anything wrong with that) ... we'll probably be grinding away on this thread (off and on) for years to come ... if you'll hang around here for a while, you'll find that every "answer" generates several new "questions" ...

So then the RPI (requested packet interval) parameter in many modules, essentially dictates when the input image follows the hardware input and the output image changes the hardware output.

Click to expand...

yes, but there's a little more to it ... by default, the ONE/ZERO status of the OUTPUT bits are written to the OUTPUT FIELD DEVICES at the end of every TASK ... this is in addition to the RPI update of the OUTPUTS ...

so ...

in simplest terms, the ControlLogix outputs are usually processed a lot more often (faster) than just the RPI setting would indicate ...

also - by default, with ControlLogix (not with CompactLogix) most INPUT modules have CHANGE OF STATE enabled ... that means that if the INPUT MODULE sees a change in an ON or OFF status of a field device, then the module will automatically update the input bit's ONE/ZERO status EVEN PART WAY THROUGH THE EXECUTION OF A RUNG ...

so ...

in simplest terms, the ControlLogix inputs are usually processed a lot faster than just the RPI setting would indicate ...

things get even more complicated if you're dealing with updating ANALOG INPUT signals ... if you're interested in that topic, I suggest that you start out by reading through this link:

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

TIP: the best way to get a handle on how the logic within the rungs gets executed, is to double-click a rung number until the TEXT WINDOW opens up ... (set it for ASCII for easiest reading) ...

(and a special thanks to ASF) ...

and another tip ...

The reason why I am using structural is because I need a lot of conditional statements, which is a pain in ladder logic.

Click to expand...

please consider this idea before you go too far along these lines ... MOST applications being controlled by PLCs have to be maintained/repaired - which invariably involves some amount of TROUBLESHOOTING ...

where I come from, many (most?) of the troubleshooters have names like Gomer and Goober ... these guys are NOT dumb - but they do tend to have a much better chance of interpreting Ladder Logic than they do of reading Structured Text ...

there are some (more than a few) companies/customers who will dictate in their project specifications that you are NOT allowed to use anything other than good-old-fashioned Ladder Logic for the programming code ...

so ...

even if it's not specifically "forbidden" for you to use Structured Text, you might want to check with the customer's maintenance manager to see what programming approach would make it easier for his guys to keep the machinery running ... I frequently hear horror stories of programmers who are not awarded additional work - by a customer whose maintenance workers curse the code that they've been saddled with ...

Ron Beaufort said:

... by default, the ONE/ZERO status of the OUTPUT bits are written to the OUTPUT FIELD DEVICES at the end of every TASK ... this is in addition to the RPI update of the OUTPUTS ...

so ...

in simplest terms, the ControlLogix outputs are usually processed a lot more often (faster) than just the RPI setting would indicate ...

also - by default, with ControlLogix (not with CompactLogix) most INPUT modules have CHANGE OF STATE enabled ... that means that if the INPUT MODULE sees a change in an ON or OFF status of a field device, then the module will automatically update the input bit's ONE/ZERO status EVEN PART WAY THROUGH THE EXECUTION OF A RUNG ...

so ...

in simplest terms, the ControlLogix inputs are usually processed a lot faster than just the RPI setting would indicate ...

Click to expand...

Huh...you learn something new every day! Just to clarify - you mention that the inputs are updated instantly on ControlLogix (by default) but NOT CompactLogix - but with regard to the outputs updating at the end of each task, you mentioned Control Logix but didn't specifically say whether it applies or not to the CompactLogix - does the CompactLogix also update outputs at the completion of each task?

Hey Ron thanks for your detailed input, once more.

yes, but there's a little more to it ... by default, the ONE/ZERO status of the OUTPUT bits are written to the OUTPUT FIELD DEVICES at the end of every TASK ... this is in addition to the RPI update of the OUTPUTS ...

Click to expand...

Are you implying that there is asynchronous communication between the processor and module at the end of each task? I was under the impression backplane comms are fixed with respect to the RPI. Wouldn't this introduce collisions? Unless, at the end of each task the RPI is halted momentarily.

Following your statement, it would suggest that a very high RPI would have no effect on output update rate, given the task has a shorter execution time.

By any chance is the option "Disable automatic output processing. . . " referring to updating output at the end of each task?

where I come from, many (most?) of the troubleshooters have names like Gomer and Goober ... these guys are NOT dumb - but they do tend to have a much better chance of interpreting Ladder Logic than they do of reading Structured Text ...

Click to expand...

Thanks for sharing your experience. I wasn't aware that structural text is a taboo of sorts.

I like how you edited your stance on computer forums

Salman S. said:

Are you implying that there is asynchronous communication between the processor and module at the end of each task?

Click to expand...

Yes, that is correct, and in most cases can be ignored. However, it does introduce an "extra" exchange of data, that, in most cases, isn't entirely necessary.

Also be aware that the I/O update in CompactLogix (not ControlLogix) is a hidden "Task" that is assigned a fixed priority level of 6. This means that the I/O update can be interrupted by a task configured with priority levels 1...5. You need to choose task priorities carefully to avoid I/O "problems". The document "compact_system.pdf" explains this in some detail from page 99.

Salman S. said:

Following your statement, it would suggest that a very high RPI would have no effect on output update rate, given the task has a shorter execution time.

Click to expand...

It depends what you mean by "high RPI". Since RPI is "...Interval", to me high RPI reads as "high interval", or slow update...

Salman S. said:

By any chance is the option "Disable automatic output processing. . . " referring to updating output at the end of each task?

Click to expand...

Yes, but you might also consider the use of IOT instructions in your interrupting tasks if you want fresh output data sent to specific modules as fast as possible. IOT instructions override the RPI of connected output modules.

Also be aware that the I/O update in CompactLogix (not ControlLogix) is a hidden "Task" that is assigned a fixed priority level of 6

Click to expand...

Makes sense, if I consider it a separate task. Might I ask how the ControlLogix updates though?

It depends what you mean by "high RPI".

Click to expand...

I meant long intervals between I/O updates. So if a shorter task updates the output every time, assigning a high RPI doesn't achieve much.

Yes, but you might also consider the use of IOT instructions

Click to expand...

I will look into that, thanks