Mike...
You said...
"...only the instructions in the main body of the program, and called subrutines will be scanned."
It would be more accurate to say...
Each rung in the main program and each rung in any called sub-routine is subject to the
possibility of scanning.
PROGRAM #1
Rung-1 "Hello World!"
Rung-3000 END
How fast will Program #1 run?
How many rungs in Program #1 will in fact be scanned?
Now, how fast will this program run?
PROGRAM #2
Rung-1 "Hello World!"
Rung-2 Go To Rung-3000
Rung-3000 END
How many rungs in Program #2 are in fact scanned?
If, for whatever reason, we really needed to write and rewrite the phrase "Hello World!" as quickly as possible, which program would do it better?
Obviously, Program #2 will blow Program #1 out of the water. Of course, Program #2 doesn't do anything more than write and rewrite "Hello World!".
But the point is made. Both programs are the same size and yet Program #2 leaves Program #1 standing in the dust as far as scan-rate is concerned. This is because of the difference in logic-flow management.
Obviously, we would like to have programs do a little bit more than running around yelling
"Hello World! Hello World! Hello World!..."
So... is there a way to maximize the scan-rate while actually doing something?
PROGRAM #3
Rung-1 If don't need to exercise Module-0 then Go To Rung-1000
- Module-0 code
- Module-0 code
- Module-0 code
Rung-1000 If don't need to exercise Module-1 then Go To Rung-2000
- Module-1 code
- Module-1 code
- Module-1 code
Rung-2000 If don't need to exercise Module-2 then Go To Rung-3000
- Module-2 code
- Module-2 code
- Module-2 code
Rung-3000 END
In this arrangement, the smallest scan-rate would be based on the time required to scan Rung-1, Rung-1000, Rung-2000 and Rung-3000.
That is a 3000 rung program being scanned as if it were only 4 rungs long. The scan-rate advantage is obvious.
Now, the actual coding is a little more complicated than what I have shown.
On "Start-Up", the following conditions are FALSE:
- Don't need to exercise Module-0
- Don't need to exercise Module-1
- Don't need to exercise Module-2
While in a particular module, the program might do something that requires follow-up. For instance, if, while in a particular module, the program starts a timer then, if for no other reason, the program will have to revisit the module on the next scan just to check on the timer (there might be reasons other than timers). In that case, the program reasserts the FALSE status of the "Don't need to exercise Module-X" condition.
If the program goes through a module and at the end of the module there is no internal reason to revisit the module then the "Don't need to exercise Module-X" condition is set to TRUE. In that case, the program hasn't done anything inside the module that requires further attention.
Now, like I said, the code above is very much simplified. There is also code that monitors those external activities that apply to the particular module. So, depending on external activities, the program might determine (at the top-most level) that there is a need to visit a particular module.
So, the program might visit a module because of external conditions or because a previous visit to the module requires a follow-up.
Modularity should be extended all the way down to individual output devices. It might be the case that Module-1 contains some sub-modules; Module-1A, Module-1B, Module-1C,...
Each of those sub-modules is subjected to the same control scheme that exists at the top-level. That is, at the upper-level of Module-1 there is a set of conditions similar to the conditions at the top-most level:
- Don't need to exercise Module-1A
- Don't need to exercise Module-1B
- Don't need to exercise Module-1C
As the program goes deeper and deeper within a particular module, the corresponding "Don't need to exercise..." bits are SET or RESET accordingly.
So, if Module-1 contains 50 sub-modules (Module-1 might be several levels deep), and there is a cause to visit or revisit Module-1, then it might be the case that only 2 or 3 of the sub-modules get visited... or maybe all 50 need to be visited.
The concept is to use only those tools (sections of code) that are needed and only when they are needed.
Depending on the particular application, the scan-rate might vary widely, but each scan will be as short as it can be for the particular set of circumstances. Of course, this scheme has no affect on over-head (over-head time is generally fixed). However, this scheme brings the control process as close to real-time as it can be.