Parameter exchange between PLC and primary controls

Remote and local parametrization of the primary controls of the FPC+ is already possible via the supplied software, but some internal parameters of the cabinet au-tomation PLC cannot be changed from their default values without separate software and the source code of the application. This is not a convenient situation from the clients’ perspective if they want to change the default values, so as a part of this thesis the data communication between the primary controls and the automation PLC is improved to support parameter exchange between the devices exploiting the SDO protocol of CANopen.

5.1. Parameter exchange between PLC and primary controls 41 As the primary controls of the converter and the automation PLC use the CANopen fieldbus for data communications, they support the SDO communication as ex-plained in Section 3.1.2. The interface for the SDO communications of the FPC+

primary controls is well documented in an internal document [47] and the CANopen object dictionary object is already created, but the implementation is missing from the automation PLC application. The interface follows the CANopen standard, and as the PLC’s Intel Atom processor is based on Intel x86 processor architecture, they both use little-endian bit representation [34, p. 93][48, p. 7]. Little-endian repre-sentation means that the least significant byte of a word is stored first in the lowest memory address and the following bytes are stored into the memory in order of increasing significance. Knowing the byte order of both ends of the communication link is essential for programming purposes, but does not concern the customer. The byte order being the same in both ends simplifies the programming work, as bit rotation functions are not required.

Beckhoff’s ADS (Automation Device Specification) interface can be used directly to transfer SDO messages between connected devices. Two library functions are readily available in TwinCAT 2 programming environment to perform read and write operations, which makes the software implementation easier. They are called ADSREAD and ADSWRITE, and their function block diagrams are presented in Figure 5.1. [51]

Figure 5.1 TwinCAT PLC Control’s own ADSREAD and ADSWRITE function blocks for inter-device message exchange. Function block inputs on the left side of each block, and outputs on the right side. [51]

5.1. Parameter exchange between PLC and primary controls 42 As can be noted, both functions are very similar. They take address information of the destination device, CANopen object dictionary indices, function triggers and other supplementary information as inputs, and give information about the status of the current message as an output. Reading one user defined parameter from the primary controls requires three ADSWRITE function calls and one ADSREAD function call. The first two write function calls set the desired parameter group identification and parameter identification, respectively. The third write function call then executes the reading command. Finally, with the last read function call, the value of the parameter is read to the reserved variable set in the Destination input of the function block. Writing a parameter to the controls is possible in similar fashion with four ADSWRITE function calls, but such functionality is not needed in this case. [47] However, if planned for the future, the basic implementation is ready and can be used for this purpose with minor modifications.

The PLC automatically reads the user parameters from the primary controls during every power-up, and stores them in an array, from which they are then individually accessed and assigned to their respective PLC parameter. After the whole user parameter list has been downloaded without errors, a variable indicating a successful download is set true, and the program is no longer executed. The control software has a functionality that detects when the user changes a parameter, and sets a bit in the main status word to 1. The bit retains this value until no more changing parameters are detected during a set time period, and returns to 0 afterwards. The PLC application is programmed to detect this falling edge of the bit, and to start reading the parameter list again to update the changed user parameters.

Suitable timing had to be tested for the read cycle. The function block cannot read the user parameters with the speed of the PLC task cycle time, which is 1 ms. Reading the parameter successfully takes more time. Too fast cycle results in some parameters to be skipped and sometimes wrong values to be read to wrong parameter indices. A pacemaker functionality is added to call the function block periodically, and the timing is adjusted until no errors occurred during long test peri-ods of subsequent reads. For testing purposes all parameter values are set matching their indices, and an automatic testing function is added to repeatedly read the parameter array and to check that every parameter index and its value matches, and formatting the array to zeros in between every read. Around 50 ms read cycle proved to be reliable, resulting in zero wrong values in over ten thousand subsequent read cycles. Zero tolerance for read errors is set as a design premise as reading a

5.2. Power module cooling fan condition monitoring 43