PLC Benchmarking

I could see where that could be a problem.

It would still be interesting to see how big a penalty indexing into an array costs. I would think everyone has a bitwise AND. If you were to add:

j = i AND F

Then use j as the index into an 8-element array. It keeps the data quantity down just still requires a variable index. I don't have anything as ***y as an L85E around here but I might try that tonight with an L71.

Keith
 
I just ran an adjusted code:



300 ms cycle time in a 1214C, without monitoring.
I use a DI to start/stop the sequence and capture cycle time with standard blocks and record min and max cycle time.


Is there any difference if you look OB1 block's cycle time located to temp area?
 
Tested on a Beckhoff CX5140:


MathTest: 4.2 ms
BubbleSort: 11.2 ms


These results were found using a single core. I was able to get MathTest down to around 2 ms by splitting the loop across multiple cores. Not sure if that counts??? :unsure:
 
Originally posted by kolyur:

I was able to get MathTest down to around 2 ms by splitting the loop across multiple cores. Not sure if that counts???

Absolutely that counts. If the performance is available to be used, I say use it. As long as you tell us what it takes to get there, its fair game.

Keith
 
Here are some results running the tests on an AB 1756-L71 with V28 firmware (if that matters).

I ran the Math Test in five different flavors:

1) No arrays with Main ladder calling ST routine with for/next: 278 msec
2) No arrays with Main ladder and JMP/LBL inline: 273 msec
3) No array with Main ST inline: 280 msec
4) 8-element arrays with indexing in Main ST inline: 460 msec
5) No array with Main ST inline including AND to limit index: 375 msec

Test #3 is the most direct representation of what Archie started with. It is a single structured text routine under one program in the continuous task with the for/next loop in it.

Test #3 was the most surprising to me as it has the longest scan time of tests 1-3. But it is close enough to #1 and #2 that it could just be odd scan variation.

Test #4 is what I was talking about a few posts back but I used 7 as my mask instead of 15.

Test #5 is the same as Test #3 except I include the program line with the AND to see how much of the scan time difference is due to indexing into the arrays and how much is due to the added line of code being executed. That line is:

j := i AND 7;

The bubble sort copied right out of the original post is running at 1360 msec.

Keith
 
After seeing the differences in indexing arrays and ANDing, I think the test should be revised:

Math Test stays the same:
Code:
FOR i:=0 TO 99999 DO
	DINTResult:=(Real1*Real2);
END_FOR;

Indexing Test
Code:
FOR j:=0 TO 9999 DO
  FOR i:=0 TO 9 DO
	DINT1[I]:=DINT2[I];  'Arrays of 10 elements
  END FOR;
END_FOR;

Bitwise Operation
Code:
FOR i:=0 TO 99999 DO
	DINTResult:=i AND 2730; '* Every other bit for 12 bits
END_FOR;
 
You removed the indexing from the math test, is that what you want ?
Just loop through the same DINTResult:=(Real1*Real2) 100000 times ?
You said "math test stays the same", so it confuses me.
 
You removed the indexing from the math test, is that what you want ?
Just loop through the same DINTResult:=(Real1*Real2) 100000 times ?
You said "math test stays the same", so it confuses me.
Yes. The indexing was removed because as I started testing different PLCs I found that many could not handle the large arrays. My original goal was to have the same test that could be run on all or most PLCs. As I got further into testing and getting feedback from others, the test code had to be tweaked to stick to the original goal.

My statement in my last post should have been "Math test stays the same as the last iteration." My last suggested revisions are to isolate math, indexing, and bitwise operations.
 
OK, now I have perfoprmed the 3 tests from post #39 on a Siemens S7 151-8 CPU.
This is a low-end PLC (but still pretty good IMO).
I made 3 variants for each test.
One with access from FC to TEMP variables.
One with access from FC to global DB variables.
One with access from FB to instance-DB variables.
The results only varied a little. Access to TEMPs and instance-DBs were indistinguable. Access to global DB data was slightly longer.

Also a comment: The "bitwise" test is not a boolean logic test, but more math test on words rather than bits.
A Siemens S7 CPU is optimised for boolean logic, whereas most other PLCs execute bit logic same as complete words. So it is a bit unfair to Siemens S7 not to highlight that it is significantly faster for boolean logic.

Here are the results:

Math test: 430 .. 468 ms.
Index test: 609 .. 818 ms.
Bitwise test: 307 .. 323 ms.


I dont think I will repeat the test for the 315-2PN/DP. Just assume that it will be 30-50% faster.

I had to do some type conversions in code since S7 Classic do not do that implicitly (which I find much better than "helping" by doing it automatically).
So
DINTResult:=i AND 2730 ;
became
DINTResult:= DWORD_TO_DINT(DINT_TO_DWORD(i) & DINT_TO_DWORD(2730)) ;
It does not affect the code generation or execution times.

Here is the STEP7 Classic project for anyone interested how I did it:
 
Originally posted by JesperMP:

A Siemens S7 CPU is optimised for boolean logic, whereas most other PLCs execute bit logic same as complete words. So it is a bit unfair to Siemens S7 not to highlight that it is significantly faster for boolean logic.

Come up with some tests and post them. There is apparently no shortage of individuals that will run them. Also, the scan time range you are seeing kind of surprises me. I was seeing variations of 3-5 msec in any given run on the L71 i was running. The index test results you show seem to indicate a 20-30% variation in scan time. any idea what is causing that? I wouldn't have thought that would happen to that degree.

My results this morning are:

Index test: 136 msec
Bitwise AND Test: 154 msec

Just for giggles I also ran an empty FOR/NEXT loop and that comes up at 56 msec.

Keith
 
My variations are 1-2 ms max. The differences I posted were between addressing TEMPs or IDB data versus global DB data.

Suggestion boolean logic:
Code:
FOR i:=0 TO 99999 DO
	boolvar_1 := (boolvar_2 AND boolvar_3) OR (boolvar_4 AND boolvar_5)  ; // logic --(=)
        IF (boolvar_6 AND boolvar_7) THEN
            boolvar_10 := TRUE ; // logic --(S)
        END_IF ;
        IF (boolvar_8 OR boolvar_9) THEN
            boolvar_10 := FALSE ; // logic --(R)
        END_IF ;
END_FOR;
 
Originally posted by JepserMP:

The results only varied a little. Access to TEMPs and instance-DBs were indistinguable. Access to global DB data was slightly longer.

You and I have somewhat different views on the quantity inferred by "slightly".

The logic posted above is running at 103 msec in the L71. What are you seeing?

Full disclosure. I used 1 and 0 instead of TRUE and FALSE. I don't remember in the S7 if those are keywords or you need to set them up as tags. In the AB stuff those are not recognized as keywords. If they are tags, let me know and I will run the test that way.

Keith
 
Last edited:

Similar Topics

Hello, I have an automation direct d2 262 plc and C-more HMI EA9T6CL-R. I need to prepare a program, scheduled to be performed on a future date. I...
Replies
1
Views
31
Hello, I'm trying to delve a little into rs-485 communications for a couple projects of mine. Until now I've been using a delta vfd and a delta...
Replies
2
Views
47
Greetings All, I recently decided to start freelancing in Controls and Automation part time, most of my experience has been with Rockwell...
Replies
2
Views
95
I am having a problem communicating my PLC with Drive via Modbus connection. I start by opening the port and there is no problem, but then when I...
Replies
5
Views
64
I have worked on small projects using AB Micrologix but now we want to take a photo, process it online, and sort based on returned variables...
Replies
1
Views
92
Back
Top Bottom