the performance is considered to be very small compared to the other parts.
3.5.1 System 1: Beckhoff PROFIBUS
Figure 3.7 shows the schematic setup for the Beckhoff PROFIBUS approach. It
is to mention that Beckhoff uses their proprietary ADS protocol to communicate
between the OPC server and the card driver, which was therefore outlined in this
figure [20]. The maximum update rate of TwinCat OPC Server is 2 milliseconds,
the cycle time of the variable i/o task is 1 ms.
Figure 3.7: Schematic setup of Beckhoff PROFIBUS approach
3.5.2 System 2: MMS
The MMS approach is depicted in Figure 3.8. In contrary to the PROFIBUS
solution there is no need for an additional communication device connected to
CEX bus as the Ethernet port is located in the processor module itself, using its
resources. Unfortunately, the maximum update rate of the AC800M OPC Server
is limited to 50 milliseconds, which is a comparatively high value compared to the
cycle time of other system parts.

3.5.3 System 3: Woodhead PROFIBUS
In contrary to Beckhoff’s solution, Woodhead implements a more direct access path
for the OPC server. Its maximum update rate is 1 millisecond. The GSD-file of
the SST-PBMS-PCI card had to be slightly modified in order to be importable by
Control Builder M. Furthermore, there exists a trick how to simplify bulk setup of
OPC tag names. More information on the latter as well as a working GSD-file is
enclosed with the CD-ROM in the appendix.

Chapter 4
Evaluation
In this chapter we describe the evaluations performed on the test system. In order
to implement the different tests, we needed to program both controllers with appropriate code, which presumed the know-how for two quite different application
development systems and engineering tools (see [30], [31], [32] and [33]).
4.1 Test Systems
As described in the preceding chapter, we evaluated three different test system
variants. While the AC160 side physically stayed the same for all tests, the AC800
connection was tested with the following approaches:
• PROFIBUS connection with Beckhoff’s card and server
• Standard MMS connection using an Ethernet card
• PROFIBUS connection with Woodhead’s card and server
Due to reasons explained in the next chapter, all main tests were performed with
Kepware’s LinkMaster OPC bridging software.
4.2 Basic Idea
The basic idea behind all tests is the definition of a complementary set of receiving
and sending variables to each of the two controllers. During each controller program
cycle all receiving variables are read from the bus/network and all sending variables
are written. On the other side of the bus/network, the OPC server makes the
variables available. The OPC bridging software, acting as an OPC client to the
servers, links the two corresponding variables by reading the values from one server
and writing them to the other.

4.2.1 Short Circuit
To explore the behavior of one side or to isolate problems, we also performed test
with a “short circuit” configuration. That is, the bridging software is not configured
to link the variables from one OPC server to the other, but right back to other
variables on the same server.

4.3 Variables
This section informs about the type and quantity of variables used to test the
connection.
4.3.1 Data Types
According to the requirements, only 32-bit floating point and boolean values have
to be processed. Since the booleans are packed into integer values, the problem
modifies to the transport of 32-bit floating point and 32-bit integer values.
4.3.2 Packaging of Booleans
The are various reasons to pack booleans into integer values instead of processing
them one by one:

Figure 4.3: Data types in different sections with PROFIBUS
• The smallest possible PROFIBUS module size provided by both cards is one
byte. If processing booleans one by one, 7 bit would get “lost” for every value,
which reduces performance.
• In MMS telegrams, one single boolean requires 3 bytes space whereas one
integer containing up to 32 booleans uses only 6 bytes [17].
• A smaller number of variables improves the performance of the OPC connections.
• One can save a lot of configuration effort for the bridging software.
• AC800M supports transparent packaging of the booleans into PROFIBUS
modules, that is, it is not even necessary to manually pack them into integers.
• AC160 offers a program code element to pack/unpack booleans into/from
integers.
Since the size of one variable in an AF100 DSP is limited to 32 bit, we intended to
pack this amount of booleans into an integer value. However, the packaging program
code element offered in AC160 treats the last bit as a sign flag not compatible to the
transparent mapping of the AC800M. Instead of implementing additional program
code we therefore decided to set this last bit aside and pack only 31 bits into one
integer value.
4.3.3 Quantity
In order to learn more about the behavior of the concerned parts, we performed six
main tests with different amounts of variables:
• The first four Tests 0 to 3 are intended to get an overview on the behavior
of the configurations. They are designed such that they can run with all test
system variations, that is, the amount of data does not exceed 488 bytes in