SLC compute scan time

I think they are simply interpreting the test each time the compute block is execute. You have raised a very good point. It would be better yet to implement the compute block in ladder.

The CPT is implemented in A-B PLCs in ladder only, even in Logix5000 systems which can also use Function Block, Structured Text, and Sequential Function Chart programming languages. (In Structured Text you can simply make the assignment Destination := Expression.

The expression you can put into a CPT instruction can be as complex as you want, I've seen some horrendous expressions !

On one job I worked on, the client spec. gave the calculation for a specific part of the process, and I decided not to break it up for speed, but to enter it into a CPT expression exactly as written in the spec.

That was a lifesaver for me, because when the CPT incorrectly calculated the result and compromised the product, i simply did a PrtScrn of the instruction and handed it to the client for checking. A few minutes later, the client's engineer returned with the news that the expression was wrong in the spec., and they had to admit the error was on their part.

I would advocate the use of CPT for any calculation that needs more than 4 or 5 "standard" instructions, it is so much clearer to the observer what the math is doing.

I would also question the need to perform the calculations every scan? In the case I quoted above, the CPT was executed once every 1.5 hours, so the speed of execution was not an issue.

2012-01-23_221535.jpg 2012-01-23_221620.jpg 2012-01-23_221652.jpg
 
Now that optimizing the expression is out of the way lets explain why a CPT might be better if several operations were being performed.

The statement in the manual could be worded better that for single operator computations the CPT instruction is slower and takes more words
For example
ADD A B C will execute faster than CPT C A B

However that is not always true for multiple operator computations.

If I wanted to add A+B+C+D and store the results in E then I could program

CPT E A+B+C+D

or

BST ADD A B E NXB ADD E C E NXB ADD E D E BND

You can see that the number of instructions programmed for the CPT is less. That doesn't mean it will be more efficient, but if you look at the second rung you will notice that there are three intermediate results that have to be stored in memory and then fetched back from memory. Those memory stores and fetches take time. And that is what makes the second rung less efficient.

For something simple like A+B+C+D the difference between the two methods is probably negligible, but for a more complex statement the CPT instruction can beat the performance of individual math instructions because it doesn't require the storage and recall of intermediate results.

Hope that helps.
 
For something simple like A+B+C+D the difference between the two methods is probably negligible, but for a more complex statement the CPT instruction can beat the performance of individual math instructions because it doesn't require the storage and recall of intermediate results.

The CPT still has to store and recall intermediate results in a complex expression, think of BODMAS and parentheses, but these will be O/S stack operations rather than user instructions, and consequently faster.

I suppose it would be possible to set up some comparison code, but I guess the effort wouldn't reveal much except that "standard" maths instructions execute faster than the equivalent CPT, but at some (variable?) point of complexity (probably quite low), and in some circumstance of math function usage, the CPT might be be faster. There would just be too many permutations to consider to make it a worthwhile test.

I still say, unless you need the speed (very rare), the CPT is a nicer instruction to use than a set of daisy-chained maths instructions. I certainly wouldn't use CPT to replace a single math instruction like D = A/B, but I might if I wanted D = (A/B)*C
 
For many operations intermediate results can stay in one of the processor's registers. If the compiler didn't optimize for that I would be very disappointed in it. Even if a stack push is required stack operation are a lot faster. But that kind of detail isn't necessary to convey to the OP that the time for intermediate result storage from discrete instructions will eventually make a string of discrete instructions less efficient.

Many years ago I wrote a program to compare a computation in ST to a computation in ladder and ran the computation over a period of several hours. The ST code was considerably faster than the ladder. I expect that had I been comparing a CPT ladder to the same thing in discrete instructions in ladder the CPT would have also won out.

I agree that CPT has a nicer presentation than a bunch of branched math instructions. It makes the purpose of complex expressions much easier to follow. However every once in a while I find that I want to preserve an intermediate result for use in troubleshooting or be able to observe the values of the source data right on the rung. When that is the case I use individual math instructions and don't worry about the penalty from the intermediate result storage. That is something Gary might want to consider. If he thinks that at some future time it might be nice to see what N7:0 and T4:0.ACC are while online looking at the rung without toggling to the data tables then he should use two discrete instructions.
 
A very good point, TConnolly, there is always the "what's in view" to consider, and it's always going to be a judgement call ...

Anyway, horses for courses, and all that, and i guess there will always be arguments (nay, discussions) about what's best. IMHO the best solution is always the one that best fits the application, after all, that's what the code was written for....

I'll summarise for the both of us if I may.

"The CPT can be used to enter a whole expression in one instruction, and can replace multiple instructions to achieve the same computation.
Sometimes the CPT is better than the individual instructions, sometimes it isn't.
Sometimes the CPT may hide intermediate values that might be of interest when troubleshooting.
You (the programmer) will have to determine what best fits your application"

Hope that covers it.....🍻
 
If the compute block is being interpreted from text then the compute block will be slow, slower than ladder. Saving temporaries in registers doesn't apply. If the compute block is complied it would probably be faster than ladder. Interpreting text is slow because the lexical scanning and parsing must be done each time.

I would bet that the compute block is scanned each time and the text is converted to ladder internally or at least uses the same ladder code blocks.
 
Now that optimizing the expression is out of the way lets explain why a CPT might be better if several operations were being performed.

The statement in the manual could be worded better that for single operator computations the CPT instruction is slower and takes more words
For example
ADD A B C will execute faster than CPT C A B

However that is not always true for multiple operator computations.

If I wanted to add A+B+C+D and store the results in E then I could program

CPT E A+B+C+D

or

BST ADD A B E NXB ADD E C E NXB ADD E D E BND

You can see that the number of instructions programmed for the CPT is less. That doesn't mean it will be more efficient, but if you look at the second rung you will notice that there are three intermediate results that have to be stored in memory and then fetched back from memory. Those memory stores and fetches take time. And that is what makes the second rung less efficient.

For something simple like A+B+C+D the difference between the two methods is probably negligible, but for a more complex statement the CPT instruction can beat the performance of individual math instructions because it doesn't require the storage and recall of intermediate results.

Hope that helps.

If using a Logix platform, I would also consider putting the math instructions in series thus eliminating the 2-BST, 1-NXB, 1-BND instructions. How much scan time is saved?? Who knows? Rockwell doesn't break down those implied instructions in their scan time manual.
 
If using a Logix platform, I would also consider putting the math instructions in series thus eliminating the 2-BST, 1-NXB, 1-BND instructions. How much scan time is saved?? Who knows? Rockwell doesn't break down those implied instructions in their scan time manual.
I don't think it makes much difference but I would also put the math instructions in series. This is safe. To put them in an output branch may be slower depending on how smart the compiler is. If the compiler is smart then it knows that the match blocks can't change the true/false state of the rung and may simply execute everything in line any way. It would be a good test to verify this.

BTW, I don't think the BST, NXB and BND instruction really do that much. I think of the BST, NXB and BND as the Rockwell version of parentheses.

BST is (
NXB is ) OR ( // NXB is an OR instruction too.
BND is )

Parentheses control the order of execution but also can provide labels to jump to.
 
In a CLX I usually skip branching when it is not necessary. The OP is using a SLC 5/04 so he doesn't have that option.

I think that all BST, NXB, BND do is push and pop logical results to/from a stack. Execution time is minimal, but they are extra instructions.
 
I don't think it makes much difference but I would also put the math instructions in series. This is safe. To put them in an output branch may be slower depending on how smart the compiler is. If the compiler is smart then it knows that the match blocks can't change the true/false state of the rung and may simply execute everything in line any way. It would be a good test to verify this.

BTW, I don't think the BST, NXB and BND instruction really do that much. I think of the BST, NXB and BND as the Rockwell version of parentheses.

BST is (
NXB is ) OR ( // NXB is an OR instruction too.
BND is )

Parentheses control the order of execution but also can provide labels to jump to.
You may be right about the Logix and SLC500 family where the software compiles the code but because of the interpreter method of logic scanning in the PLC-5, the BST, NXB, and BND were interpreted as instructions just like XIO, XIC, OTL, etc.

That may have been changed in a compiled form that is downloaded to the controller.
 

Similar Topics

How can i get (N7:31 * 6 / 5) to work in compute instruction? This is very annoying. I know i am missing something?? Please help. Thanks, Ven
Replies
6
Views
2,242
I’m attempting to send a temperature from a SLC-5/02 to an EZiMarquee display. The vendor said to use a MSG instruction to send the data to the...
Replies
1
Views
95
Hello all. I have a few SLCs in my plant and of late we've seen a weird issue: The system will be running normally and then randomly the outputs...
Replies
2
Views
104
I am working on setting up a Prosoft Datalogger model PLX51-DLplus-232. This unit will be collecting data from a SLC 5/05 on the DB9 port set to...
Replies
3
Views
105
I have a redundant ControlLogix being set up. This program reads a value from a remote site which happens to be SLC PLC. Rockwell mentions SLC...
Replies
2
Views
96
Back
Top Bottom