PLC Benchmarking

OK, I have redone LDs tests on a Siemens IM151-8.
Results:
1: //indexed multiply with non-zero data - 1680ms
2: //non indexed multiply with non-zero data - 430ms
3: //some trig functions - 1770ms
4: //non indexed multiply with non-zero data, more calcs, for loop smaller - 280ms
5: //non indexed divide with non-zero data - 560ms
6: //non indexed multiply with zero data - 440ms
7: //Boolean logic - 310ms
8: //Bitwise operation - 300ms
9: //bubble sort - fails to finish within 6000ms (maximum cycle time for IM151-8)

edit: btw, the arrays were too big for the available memory, so I reduced them by a factor 10 and extrapolated the results accordingly.
 
Last edited:
Originally posted by L D[AR2,P#0.0]:

3: // some trig functions - 13.5ms
#rData1 := 0.1;
#rData2 := 0.2;
FOR #diIndex := 0 TO 99999 DO
#diResult := REAL_TO_DINT(TAN(#rData1) * TAN(#rData2));
END_FOR;

That doesn't make any sense. This test is running faster than the multiplying of two reals case. Is it possible that since the values of #rData1 and #rData2 are being explicitly set just prior to entry into the FOR loop that the compiler is optimizing the result of the TAN function to a constant?

Keith
 
LD's tests done with a Siemens S7-1512SP (optimized block access)
Results:
1: //indexed multiply with non-zero data - 434ms
2: //non indexed multiply with non-zero data - 557ms
3: //some trig functions - 498ms
4: //non indexed multiply with non-zero data, more calcs, for loop smaller - 455ms
5: //non indexed divide with non-zero data - 540ms
6: //non indexed multiply with zero data - 320ms
7: //Boolean logic - 54ms
8: //Bitwise operation - 51ms
9: //bubble sort - 1250ms

Again, due to the memory requirements I had to reduce the array sizes and extrapolate the results.

edit: I think that Kamenges is right, that in test 3 (and possibly some of the other tests) the TIA compiler detects that the variable doesnt get changed, so that it is a de-facto constant, and thus optimises the code by substituting the calculation by a simple value assignment of the result of the formula.

edit again: That could mean that the tests should be reviewed and possibly changed to avoid that from happening. Otherwise the test results are skewed.
 
Last edited:
By the way, trig functions are not friendly to the L71. I ran the math test with the real multiply replaced with TAN(REAL1). This is less than half as intense as the test L D[AR2,P#0.0] ran on the S7-1517. The scan time came in at 1860 msec.

X to the power of Y was a bigger hit. In the math test I replaced (Real1 * Real2) with (Real1 ** Real2), which in AB-speak is Real11^Real2. That took 3805 msec.

Keith
 
LD's tests done with a Siemens S7-1512SP (non-optimized block access)
Results:
1: //indexed multiply with non-zero data - 785ms (*)
2: //non indexed multiply with non-zero data - 523ms
3: //some trig functions - 588ms
4: //non indexed multiply with non-zero data, more calcs, for loop smaller - 460ms
5: //non indexed divide with non-zero data - 555ms
6: //non indexed multiply with zero data - 322ms
7: //Boolean logic - 119ms (**)
8: //Bitwise operation - 63ms
9: //bubble sort - 2200ms (*)

*: One can see that when there is access from the code to global DB, there is a penalty when the DB is non-optimized.
**: Even if only TEMP memory of the block is used, non-optimized costs a penalty for boolean code.
 
Test Re-do

1769-L24ER vr 31
Using Archies File

MathTest = 313ms
Bubble Sort = 1.57sec
IndexTest = 147ms
BitwiseTest = 167ms

Not Calling Routine. Using it as MAIN
 
Last edited:
LD's tests done with a Omron NJ101-9000
Results:
1: //indexed multiply with non-zero data - 100ms
2: //non indexed multiply with non-zero data - 84ms
3: //some trig functions - 225ms
4: //non indexed multiply with non-zero data, more calcs, for loop smaller - 80ms
5: //non indexed divide with non-zero data - 103ms
6: //non indexed multiply with zero data - 31ms
7: //Boolean logic - 8ms
8: //Bitwise operation - 11ms
9: //bubble sort - 82ms
 
The trig functions return a lower test time due to the the magnitude of the numbers involved - the smaller the number the less time a floating point multiply takes.


I modified case 3 so that the tans would return 100.0 and 1000.0 so it would be comparable with case 2 and now it does take longer to execute.



Code:
    3:  // some trig functions - 15.0ms
        #rData1 := LREAL_TO_REAL(ATAN(100.0));
        #rData2 := LREAL_TO_REAL(ATAN(1000.0));
        #diResult := REAL_TO_DINT(TAN(#rData1) * TAN(#rData2));
        FOR #diIndex := 0 TO 99999 DO
            #diResult := REAL_TO_DINT(TAN(#rData1) * TAN(#rData2));
        END_FOR;
 
The trig functions return a lower test time due to the the magnitude of the numbers involved - the smaller the number the less time a floating point multiply takes.
Even so, it is odd that doing trig functions before multiplying, is executing faster than just multiplying.
One should think that adding the extra trig instructions should take longer time.

I wonder if it makes a difference if you change rData1 and rData2 from TEMP to STAT or to global DB.
 
Originally posted by L D[AR2,P#0.0]:

The trig functions return a lower test time due to the the magnitude of the numbers involved - the smaller the number the less time a floating point multiply takes.

It's not the multiplies. It is the trig functions. There are two "typical" ways to handle trig functions in a CPU. One is interpolation into a look-up table. At a minimum that will require two indexed data accesses with multiple subtractions and divides (assuming linear interpolation). The other method is to approximate the value with a power series which is even more processor intensive. So the fact that ANY operation including a trig function can complete faster than a similar operation without a trig function seem really odd.

Keith
 
I did some tests on an L85E using firmware 28 and 32. I was surprised to find a difference:

v28
MathTest 7.5
IndexTest 3.7
BitWiseTest 2.6
BubbeSort 83


v32
MathTest 9.5
IndexTest 3.5
BitWiseTest 2.4
BubbeSort 77
 
LD's tests done with a Siemens S7-1515SP Open Controller (optimized block access)

This is not the latest version. As far as I know, the latest version essentially has 4 cores instead of 2 cores. It is still only 1 core for the Open Controller PLC. It is the Windows side that gets bumped from 1 to 3 cores. So the test results should be valid even for the newest version.

Also of note, the 1515SP should be approximately equivalent to an S7-1516.

I am not going to repeat the test with non-optimized block access.

Results:
1: //indexed multiply with non-zero data - 28ms
2: //non indexed multiply with non-zero data - 27ms
3: //some trig functions - 24ms
4: //non indexed multiply with non-zero data, more calcs, for loop smaller - 27ms
5: //non indexed divide with non-zero data - 27ms
6: //non indexed multiply with zero data - 14ms
7: //Boolean logic - 1ms
8: //Bitwise operation - 1ms
9: //bubble sort - 51ms
 
I did non-optimized anyway

LD's tests done with a Siemens S7-1515SP Open Controller (non-optimized block access)

Results:
1: //indexed multiply with non-zero data - 76ms
2: //non indexed multiply with non-zero data - 27ms
3: //some trig functions - 25ms
4: //non indexed multiply with non-zero data, more calcs, for loop smaller - 27ms
5: //non indexed divide with non-zero data - 29ms
6: //non indexed multiply with zero data - 25ms
7: //Boolean logic - 12ms
8: //Bitwise operation - 11ms
9: //bubble sort - 246ms
 

Similar Topics

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
26
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
67
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
47
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
85
Hi, I have a 1500 that controls a station with diferents warehouses, but i also have a 1200 that controls one of those warehouses, i have been...
Replies
9
Views
208
Back
Top Bottom