PC based PLCs and Ethernet based fieldbus: the new standard
platform for future VLT instrument control
Mario J. Kiekebusch 1a, Christian Lucuix a, Toomas M. Erm a, Gianluca Chiozzi a, Michele
Zamparelli a, Lothar Kern a, Roland Brast a, Werther Pirani a, Roland Reiss a, Dan Popovic a, Jens
Knudstrup a, Michel Duchateau a, Stefan Sandrock a, Nicola Di Lieto a
a
European Southern Observatory, Karl-Schwarzschild-Strasse 2, D-85748 Garching bei München.
ABSTRACT
ESO is currently in the final phase of the standardization process for PC-based Programmable Logical Controllers
(PLCs) as the new platform for the development of control systems for future VLT/VLTI instruments. The standard
solution used until now consists of a Local Control Unit (LCU), a VME-based system having a CPU and commercial and
proprietary boards. This system includes several layers of software and many thousands of lines of code developed and
maintained in house. LCUs have been used for several years as the interface to control instrument functions but now are
being replaced by commercial off-the-shelf (COTS) systems based on BECKHOFF Embedded PCs and the EtherCAT
fieldbus. ESO is working on the completion of the software framework that enables a seamless integration into the VLT
control system in order to be ready to support upcoming instruments like ESPRESSO and ERIS, that will be the first
fully VLT compliant instruments using the new standard.
The technology evaluation and standardization process has been a long and combined effort of various engineering
disciplines like electronics, control and software, working together to define a solution that meets the requirements and
minimizes the impact on the observatory operations and maintenance.
This paper presents the challenges of the standardization process and the steps involved in such a change. It provides a
technical overview of how industrial standards like EtherCAT, OPC-UA, PLCOpen MC and TwinCAT can be used to
replace LCU features in various areas like software engineering and programming languages, motion control, time
synchronization and astronomical tracking.
Keywords: Instrument Control, PLC, EtherCAT, COTS, OPC-UA
1. INTRODUCTION
Motivations
The VLT control system has been successfully used to operate astronomical instruments for almost 15 years. A
fundamental part of the VLT control system is the LCU, the component which is the interface between the high-level
software and the hardware. The LCU contains commercial and custom boards connected through a VME local bus. The
core of the LCU is the MVME6100 CPU board with a Freescale PowerPC processor running VxWorks and several
layers of software developed and maintained in house. The LCU is a general purpose real-time system that is very
flexible and versatile, but often too complex and costly for typical instrument applications1.
Based on the obsolescence issues of this platform and the increasing complexity of control systems for new VLT
instruments, it has been decided some years ago to evaluate COTS products as a replacement for the LCU. Using COTS
is a worldwide trend which shall bring the following benefits:
•
•
•
•
1
Reduction of development and maintenance costs which are now transferred to the industry.
Improve quality by using well proven solutions.
Facilitate obsolescence management (standard interfaces supported by industry).
Reduction of instrument costs by replacing over dimensioned VME systems by properly dimensioned industry
components.
mkiekebu@eso.org; phone +49 89 32006-0; fax: +49 89 320 2362.
Software and Cyberinfrastructure for Astronomy III, edited by Gianluca Chiozzi, Nicole M. Radziwill,
Proc. of SPIE Vol. 9152, 915207 · © 2014 SPIE · CCC code: 0277-786X/14/$18
doi: 10.1117/12.2056648
Proc. of SPIE Vol. 9152 915207-1
However COTS might also have some drawbacks that need to be considered:
•
•
•
•
Industry is driving the requirements and not the needs of the astronomical instruments.
Shorter life cycles
High license costs
Less flexibility to adapt to specifics requirements.
COTS hardware and software has been used since the beginning of the VLT but always with a combination of a
significant custom development.
Standardization Roadmap
We are currently close to completing the standardization process for the new control platform. The first steps towards the
standardization started in 2009 after the experience gained with the technology evaluations of the E-ELT project. During
that year, we began with the design and implementation of an extension of the VLT instrumentation software framework.
The purpose was to provide new ways of implementing the control of instrument functions based on industry standards1.
In 2010, the first version of the new software (so-called Fieldbus (FB) Extension) was validated in operational
conditions thanks to the collaboration with Laboratoire d'Astrophysique de Grenoble (LAOG)2. This agreement enabled
an early verification and test of the new technology seamlessly integrated into the control system of a VLTI visitor
instrument (PIONIER) in La Silla Paranal Observatory. The instrument has been used since then as part of the normal
operations of the VLT Interferometer.
The first official version of the FB Extension was released only in 2011 as part of the VLT Software release 2011. This
version contained the core software and an initial set of software drivers for controlling typical instrument functions such
as lamps, shutters and stepper motors. The same year some further evaluations were carried out to investigate the
capabilities of PLCs to replace more complex motion control and time synchronization functionalities. This investigation
confirmed the feasibility of using PLC solutions for the implementation of most of the functional requirements needed
by instruments in the area of motion control and time synchronization.
In 2012, the Directorate of Engineering established a technical board to evaluate PLCs technology as a standard
development platform for control systems at ESO. The technical board was composed of members from various
directorates, divisions and departments within ESO and a member from CERN. The main conclusion of the technical
board was the suggestion to adopt PLCs as a new development platform for new VLT projects3.
At the same time, some ESO instruments projects started to integrate PLCs as part of their control systems for auxiliary
tasks like cabinet temperature control systems (MUSE, GALACSI), the cryogenic controller (GRAVITY, MATISSE)
and the control of digital devices (GRAAL, 4LGSF).
Beginning of 2013, the PRIMA project used PLCs for the polarization studies at VLTI. It was possible to integrate this
technology with the existing system in a very short time. In 2013 and during the Final Design Review (FDR) of the
ESPRESSO instrument, ESO accepted the proposal from the consortium to use PLCs as the replacement of VME-based
LCUs for their instrument control system. The same year, the ERIS team drafted the adoption of PLCs for the same
purpose. These two instruments are the first ones that will be fully based on PLCs for their respective control systems.
In June 2013, an internal project was started in the scope of the ESO Technology Development programme whose goal
was to finalize the evaluation of the new technology, complete the development of software devices for ESPRESSO and
ERIS and provide training for ESO staff and consortia. This project is still on-going and it will be finalized with the
organization of an Instrument Control System seminar in October 2014. This seminar will be used to introduce the new
technology to the instrument developers from ESO partner institutes.
Technology Acceptance
Big technological changes do not occur too often in the lifetime of large astronomical projects due to the operational
constraints and the associated costs.
Proc. of SPIE Vol. 9152 915207-2
The standardization process has been a long and combined effort of various engineering disciplines, like electronics,
control and software, working together to define a solution that meets the requirements and minimizes the impact on the
observatory operations and maintenance. This process has not been exempt from issues especially associated with the
initial acceptance of the technology.
As it is well known, the resistance to technological changes in organizations might become an obstacle for its
acceptance, especially if the change is affecting the balance and distribution of roles. In our case, this was not an
exception. The acceptance of the new technology has been a slow process. The idea of using PLCs as such was not
controversial and it was generally accepted by all engineers. However the selection of the type and brand of the PLC has
been more difficult than expected basically for the following reasons:
•
The natural tendency is to prefer keeping what is well-known and familiar rather than to accept innovations.
•
The term PLC is misleading since modern PLCs are not just programmable logical controller as they used to be
in the past. Today they are machines providing more flexibility in programming, larger memory capacity, and
more features and functions in general. Some new terms have emerged to classify modern PLCs like the
Programmable Automation Controller (PAC), term introduced by the market research firm ARC in 20014. A
PAC would be equivalent to Industrial PC + PLC solution. However the name is not as important as
understanding the types of applications for which each one is suited best.
•
Traditional PLCs have been used since the beginning of the VLT for very specifics tasks which were mainly
related to logical control and later on extended to the area of safety applications. Their implementation and
maintenance was historically under the responsibility of electronic engineers due to their origins as a
replacement for relay logic.
•
Traditional PLCs have a reputation of reliable devices, while in general PCs running windows do not. Engineers
with large experience with traditional PLCs did have some doubts about the robustness and capabilities of these
more compact and PC based PLCs.
•
Technological changes are in general difficult; engineers have many different ideas about how to solve a
particular problem. The focus shall not be in the technology itself but in the problem to be resolved.
The way to sort out our differences in the selection of the final solution has been to work together on the evaluation of
the technology. This has fostered the communication and interaction among the engineers leading to its gradual
acceptance. A successful validation, first in the laboratory and later on in operational conditions, was the key element
that eased its acceptance across the organization.
2. TECHNOLOGY
There is a variety of controllers and fieldbuses available nowadays in the market. They all provide similar functionalities
making it more difficult to decide which technology is the most appropriate to replace the VME-based LCUs. Before
selecting the PLC brand and type, we started defining the international standards that we wanted to be supported. The list
has been prepared taking into consideration the E-ELT development standards and some of the most common industry
standards. We did not want specific vendor solutions that could lock us into a determined architecture. The support of
standards will allow a possible replacement of the hardware without major impact on the control system.
International Standards
EtherCAT (fieldbus): EtherCAT is an open real-time industrial Ethernet protocol originally developed by BECKHOFF
and now maintained and promoted by the EtherCAT Technology Group (ETG)8, a global organization with headquarters
in Germany. Our main motivation to use EtherCAT is the high real-time performance of this Ethernet based fieldbus
achieved using standard network interfaces. Although this is not particularly relevant for most of the tasks within the
domain of instrument control, it gives a significant comparative strength which can be relevant for more specific and
demanding applications.
IEC 61131-3 (programming): IEC 61131 is an international and widely used standard in automation. The part three of
this standard describes the PLC programming languages. It defines a set of graphical and textual PLC programming
Proc. of SPIE Vol. 9152 915207-3
languages. From the supported languages, we have selected Structured Text (ST) as the standard PLC language for
writing the low level control of instrument devices.
PLCOpen MC (motion control): PLCOpen is a worldwide association whose mission it is to resolve topics and define
standards in the area of industrial control7. One of the standards promoted by PLCOpen is the Motion Control (MC)
which defines a set of hardware independent and reusable components including basic function blocks for motion
control, axes synchronization and homing procedures among other specifications.
OPC-Unified Architecture (communication protocol): OPC-Unified Architecture (UA) is the latest generation OPC
specification released by the OPC Foundation in February 20099. Its elaboration started in 2003 as a collaboration
between several industry leaders working together to elaborate an open standard for information exchange, not only
between automation and process control components but also vertically to the enterprise applications. OPC-UA is not a
replacement of the old OPC specifications, but is rather a unification of the old specifications adding the interoperability
standards and multiplatform support. An important constraint of our system is the integration to our VLT control system
based on Linux machines for the deployment of high-level coordination tasks. OPC-UA provides the means of
connecting servers and clients of different platforms in a seamless fashion.
IEEE 1588 (time protocol): The IEEE 1588 Precision Time Protocol (PTP) is Ethernet-based time synchronization
system designed to achieve sub-microsecond accuracies. The standard describes a master-slave architecture for clock
distribution. This protocol has been declared as the baseline solution for time synchronization for the E-ELT project and
it is also considered as the future replacement of the existing VLT time bus system.
Automation Controller
The upfront selection of the standards and the evaluation in different areas of control lead us to the proposal for the new
ESO standard development platform for instrument control. The selection was made after testing hardware alternatives
from vendors where we had previous experience within ESO projects. The proposal is an Embedded PC from
BECKHOFF New Automation Technology.
An Embedded PC is a compact DIN rail PC from the CX series which
can be complemented with various I/O modules5. An Embedded PC
comes with the software TwinCAT (The Windows Control and
Automation Technology). TwinCAT is not only the EtherCAT master
implementation but is also the responsible for transforming a PC-based
system into a real-time controller5.
a.
Our current standard will be to use TwinCAT 3.1, which is currently the
latest version that provides additional and very interesting features.
Embedded PC
Figure 1: Picture of an Embedded PC (source:
BECKHOFF website).
The selection of I/O modules will depend on the applications. As part of the standardization process, a set of
recommended configurations will be defined in order to support instrument developers in the selection of components.
The justification of the selected solution is based on the following:
•
Support for IEEE1588: EtherCAT/TwinCAT supports the connection to the IEEE 1588 time network through the
gateway terminal (EL6688) that bridges the internal time synchronization with an external time reference.
•
High-level Programming Languages: With the latest version of TwinCAT (version 3.1) it is possible to develop
PLC code not only with the traditional standard languages specified in IEC61131-3, but also in C/C++ and
MatLab/Simulik. This is a major advantage towards the replacement of the VME LCUs, making it possible to
implement more advanced, high performance applications, beyond what is covered by traditional and simple PLC
logic. This may also make it possible to re-use part of our VLTSW code base or some of the astronomical and
mathematical libraries that are currently used on the VME platform.
Proc. of SPIE Vol. 9152 915207-4
•
PLCopen Standards: The TwinCAT software supports standards defined by PLCopen. One of these standards is
the Motion Control (MC) which allows replacing our VLT motor library by an off-the-shelf motion control solution,
avoiding the costs of implementing and maintaining our own libraries.
•
Multi-Core Support: The Embedded PC is basically a “normal PC”, typically based on the Intel CPU chipset.
Quad-core Embedded PCs are already available and computational power is expected to continue to increase in the
future. The option of multi-core systems facilitates the implementation of more advanced real-time applications.
•
Interoperability: EtherCAT can interoperate with other Ethernet based fieldbuses through switches. This means
that other fieldbus solutions can co-exist if an EtherCAT segment is located on one switch port, and any other
Ethernet-based communication, such as normal TCP/IP traffic, is located on a different port to avoid interference
with the EtherCAT operation.
•
User Friendliness: From our experience, using TwinCAT is relatively straightforward. This is an important aspect
to be considered, especially considering the end users, where this technology facilitates a faster and better
integration of the control system. A demonstration of this is the PIONIER instrument, where the consortium spent
very little time implementing the control system using this technology.
Although Embedded PCs are the selected technology for replacing the LCU for instrument control, the usage of
traditional PLCs will continue as before for safety related applications and for the implementation of standalone systems
like Cryogenic Control. At ESO, these two types of PLCs (PC based and traditional) are intended for different types of
applications.
3. EVALUATION
In order to verify the feasibility of EtherCAT and BECKHOFF solutions to replace the capabilities of the VME-based
LCUs, we have carried out evaluations in different areas of instrument control. The main results of those evaluations are
reported hereafter.
3.1 Motion Control
The technology evaluation of motion control started in 2010 with the integration of the first steppers motors. With the
expertise gained during that year, we were able to start a more serious evaluation the year after where we tested the
implementation of first non-tracking motion control devices using Embedded PC CX1030 controllers. A set of system
requirements has been defined which are mainly based on the functionalities provided currently in the LCU by our
custom made CAN Remote Motion Controller (CAN-RMC)10.
The suggested motion control solution is:
•
TwinCAT NC PTP: this is axis positioning software which includes the implementation of the PLCopen MC
library and the engineering interface for testing and integrating motor axis without the need of the PLC
applications.
•
DC motion controller: terminal EL7342 is 2-channel DC controller with integrated TTL encoder interface
capable to drive motors up to 3.5A. The integrated encoder interface only 16 bits resolution limiting
considerably its usage for more demanding applications. The velocity controller in hardware (terminal) can
only be used when using the internal encoder interface.
•
Stepper motion controller: terminal EL7041 is a two phase stepper controller with an integrated TTL encoder
interface. This controller has a maximum of 5A output current.
•
Encoder interface: terminal EL5101 is an incremental encoder interface with differential inputs (RS485).
The above components provide similar features as the CAN-RMC except for the DC controller where the maximum
output current is only 3.5A. Nevertheless around 95% of instruments delivered to Paranal use motors with an output of
Proc. of SPIE Vol. 9152 915207-5
less than 2A therefore this limitation of the BECKHOFF DC controller is not an issue6. Another difference is that they
do not provide a tacho input which is replaced by a velocity feedback derived from the encoder.
Evaluation
The tests performed so far to evaluate the motion control can be split into the following categories.
Basic motion control
During the last years, we have acquired significant experience controlling small motors (mainly steppers). We have
developed the PLC motion library that implements the interface with the high-level instrumentation software via OPCUA1. This library simplifies the implementation of instrument motorized functions by instrument developers following
the philosophy of the VLT Instrumentation Framework.
The usage and configuration of motion control terminals is rather simple, in particular, when the positioning accuracy is
not an issue. The TwinCAT eXtended Automation Engineering (XAE) provide an integrated environment with graphical
tools that facilitate the configuration, control and validation of the motor response.
Repeatability
Our colleagues from ESPRESSO Consortium are integrating PLCs and the software libraries provided by ESO. They
have tested some motion control capabilities like the reproducibility of the positioning. They have used a MICOS LS-65
motor and Embedded PC CX1030 for the tests. The test consisted in moving repeatedly to a specific position, after doing
the switch detection during the initialization of the motor.
The results of the tests have been measured with a micrometer and they indicate a mean precision of 2.4 microns when
moving the motor at 0.2 mm/s during the initialization. This precision is independent of the motion velocity. This
precision satisfies by far the repeatability requirements needed by the instrument.
High Resolution Encoder
We have made tests with two motors having high resolution encoders: ERIS Derotator and GALACSI Field Selector.
Figure 2: ERIS Derotator setup (left), GALACSI Field Selector setup (right)
The very preliminary performance tests with the ERIS derotator confirm that the system largely meets the position
accuracy requirements which are currently defined to be 0.02 degrees. The motor is a PI M062.DG stage having an
encoder resolution of more than 6.5 million counts. The tests have been performed without the motor load which
certainly affects the results but the final load of this motor is not significant so results should not be too different.
Additionally and in order to test the limits of the BECKHOFF DC controller, we have tried to drive the field selector
device from GALACSI, the adaptive optics module of the MUSE instrument. For this test, as well as for the ERIS test,
we have used the differential encoder interface terminal EL5101-0010. We succeeded to control the motor smoothly
only after receiving the support from BECKHOFF. However the performance achieved has been significantly worse than
our custom motion controller CAN-RMC controlling the same motor. There are few reasons affecting the results:
Proc. of SPIE Vol. 9152 915207-6
•
CAN-RMC uses the motor tacho signal instead of the encoder as input. Even with this setup, the tuning of the
motor was rather tricky due the characteristics of the motor.
•
The field selector assembly is not well balanced making very difficult to control it.
•
The velocity controller runs in the PLC within the NC task and not in hardware as a consequence of using an
external encoder interface.
After the experience trying to improve the performance of this DC motor, we discovered some documentation issues and
some limitations of the DC motion controller. The motion control documentation is not sufficiently clear with respect to
the various hardware configurations that could be found in a motion control setup. It has been difficult to obtain support
for how to configure correctly the DC controller in order to achieve better motor performance. We will soon evaluate
another EtherCAT DC motion controller available on the market from the Swiss company maxon. According to the
specifications, the maxon DC controllers deliver better performance than the terminal EL7342 from BECKHOFF.
However, its integration with the TwinCAT system remains to be verified.
Scalability
We are currently preparing the tests to measure the scalability of the motion control solution. We have prepared a setup
including one PLC and ten axes (stepper and DC motors) that will be controlled simultaneously to verify the behavior of
the system (CPU load, reliability, etc.) under these conditions. Unfortunately the tests were not finalized in time to report
the results here.
3.2 Time Synchronization
Time synchronization is required for the implementation of astronomical tracking devices such as derotators and ADCs.
Those devices shall correct continuously the position of motorized functions according to the sidereal time and the
position of the telescope. For achieving this, the access to the Universal Time Coordinate (UTC) provided by the VLT
Time Reference System (TRS) is required.
There are two basic time synchronization requirements that the new platform shall fulfill in order to replace some of the
most relevant capabilities provided by the TIM board of the LCU:
•
•
Integration with IEEE1588, the baseline time synchronization system for the E-ELT that will replace in the
future the custom time bus solution of the VLT.
Hardware synchronization better than 100µs. This requirement comes from infrared instruments where it is
necessary to synchronize the telescope chopping with the detector readout, and in some cases with the
positioning of an internal piezo mirror.
Distributed Clocks
EtherCAT provides an internal time synchronization mechanism named Distributed Clocks. This mechanism enables
synchronized operation of local clocks in the EtherCAT devices (master and slaves). The first terminal with support of
distributed clock in the EtherCAT segment acts as the timing reference for the whole network. Clocks of all other
terminals are synchronized with this reference time with a nominal accuracy of less than 100 ns, under direct control of
the master which is responsible for managing the exchange of the timing information5. The distributed clocks support an
external synchronization interface for the IEEE 1588 protocol through the terminal EL6688.
Oversampling
In some cases, the PLC cycle time is a limiting factor, for instance when a digital signal has to be toggled at high
frequencies, e.g. 10 kHz. BECKHOFF has a solution for this and it is called oversampling. Oversampling is a special
type of signal sampling that is used for refining the time resolution of a signal based on the oversample factor5. The
sampling is done in hardware (terminal) by dividing the PLC cycle in smaller intervals (up to 1000 interval for digital
signals and up to 100 intervals for analog signals). This feature enables the implementation of hardware synchronization
required by VLT infrared instruments.
Proc. of SPIE Vol. 9152 915207-7
00,s sample timi
5
1
6
/
samples
cydetime
Figure 3: BECKHOFF Oversampling (source: BECKHOFF website).
Evaluation
The evaluation of the time synchronization consisted of a set of functional tests aimed at verifying in the laboratory
whether the features of the system satisfy the requirements. These tests are described hereafter.
Oversampling Verification
This test was meant to prove the oversampling capabilities of digital output terminal ES2262. A test PLC program has
been implemented to write a pulse train of the entire oversampling period at each PLC cycle. This information is
transferred by the EtherCAT master to the terminal and then, at each terminal cycle, the signals are activated in the
digital output module according to the information written in the previous PLC cycle. The EL2262 terminal was
configured as follows: maximum oversampling factor that allows up to 500 kHz frequency and bytes as operation mode.
The start time of the hardware trigger has to be used to compute the time, at least, one cycle in advance in order to be
able to keep the synchronization with respect to the absolute time. The result of the test demonstrated that the
oversampling mechanism works. We could achieve up to 0.5 MHz frequencies when using the maximum oversampling
capabilities. The results look stable over time and no abnormal behavior was observed during the tests. Figure 4 shows
the output of two digital signals from the two ES2262 digital outputs with a period of 2µs marked by the two vertical
lines.
8OOmU
HOLD
2.0 us
-a
B
B =10 U
500ns Trig: DI
B=1 U
Figure 4: Oscilloscope view of the pulse train generated with oversampling.
DC Synchronization
The tests consisted in switching On/Off two digital signals located in different terminals and segments of the EtherCAT
network for internal and external synchronization. The EtherCAT network used for the test is depicted in Figure 5.
Proc. of SPIE Vol. 9152 915207-8
ibd [Block] EtherCatNetwork [ EtherCatNetwork_Electrical V
backplane
connection
ir
sbus : Ethernet TypeS- Bus _IB
ebinOut : Ethernet TypeS -Bus_ 13
[ eth2 : Ethernet TypeRJ45F_IB
: Beckholf CX7030-0111
I
1 eth1 : Ethernet TypeRJ45F_IB
: Beckhoff EN1110
description = Basic CPU module
I
ethOut : Ethernet TypeRJ45F_IB
description = EtherCat extension
I
I
Twisted pair
connection
ebinOut : Ethernet TypeS- Bus _IB
ebinOut : Ethernet TypeS- Bus _IB
I
ebinOut : Ethernet TypeS- Bus _IB
I
I
: Beckhoff ES2262
: Beckhoff ES2262
1
d : Beckhoff EN1100
I
description = DO with oversampling
description = DO with oversampling
description = EtherCAT- Coupler
ethin : Ethernet TypeRJ45F_IB
channels = 2
channels = 2
ethOut : Ethernet TypeRJ45F_IB
ebinOut : Ethernet TypeS- Bus _IB
timRefin : Ethernet TypeRJ45F1B
: Beckhoff EL6688
description = IEEE1588 external interface
Figure 5: EtherCAT distributed clocks network test setup.
The external synchronization is referred to the connection to a IEEE 1588 network through the terminal EL6688 while
the internal synchronization uses only the internal time reference. It is important to note that the distributed clock time is
not adjusted automatically by TwinCAT when the external reference is used. The EL6688 terminal provides the
computation of the internal and external time at the cycle time which can be read by the application in order to adjust the
distributed clock time accordingly.
In order to simplify this task, we have implemented a function block (FB_DcAbsoluteTime) in ST language that converts
the distributd clocks time to absolute UTC time.
Time Offset = Internal DC time – External time + Leap time
Absolute Time (UTC) = DC time – Time Offset
Input
DC time
Output
FB_DcAbsoluteTime
UTC
The results of these tests showed a very good synchronization which was consistent with the nominal precision
specification from BECKHOFF.
Proc. of SPIE Vol. 9152 915207-9
Table 2: Time synchronization results.
Signals
Synchronization Method
Precision
Two signals from the same terminal
Distributed Clocks
< 10 nsec
Two signals from the same terminal
External time reference
< 10 nsec
Two signals from different terminals and from
different segments
Distributed Clocks
< 10 nsec
Two signals from contiguous terminals (same
segment)
External time reference
< 200 nsec
Two signals from different terminals and each
terminal located in different segments.
External time reference
< 1 µs
Time Synchronization with present Time Bus System
This test consisted in measuring the hardware synchronization of two TTL signals: one generated in the LCU using the
actual time bus system and the other one using the module ES2262 with oversampling support. Both systems were
connected to a common time source, see Figure 6. This hardware setup resembles the future VLT Time Reference
System (TRS) where the two time systems will coexist.
PTP IEEE 1588
VLT- Instruments with
E -ELT
Technology
Beckhoff PLC
Timing Measurement
GPS-
Central Time Standard
Meinberg M900
!IT
I
0
Serial
Time Server
Time Bus
Distribution Box
Fiber
LCU with
Time Interface Module
Figure 6: Hardware synchronization setup.
Figure 7 shows the results of the tests. The level of synchronization of the two systems is very good, reaching 1µs delay,
in the worst case, between the activation of the two signals. To activate the signals, we have prepared a small PLC
program (ST) and in C for the LCU to trigger the signal at a given absolute time.
It is important to note that synchronization between the PLC and the type source have been also measured independently
against the reference signal of the Meinberg device (1 PPS) showing consistent results.
Proc. of SPIE Vol. 9152 915207-10
it
Tek
Acq Complete M Pos: 1200ns
SAVE /REC
Tek
it
Acq Complete M Pos: 1200ns
SAVE /REC
Action
Action
S.a'de. All
2* -
CH1
PRINT
PRINT
Button
Button
Select
2iriv,
CH2 50.0V
24
Select
Folder
Folder
About
Save All
About
Save All
M 25.Ons
i-H2 f 10,i
25-Feb-14 13:42
4,0i ii i02kHa
i=H2 Furry
M 250ns
i-H2:' 1rH
25-Feb-li 13:43
4, i i ti ti u 2 k H a
Figure 7: Hardware synchronization results, best (left) and worst (right) cases.
3.3 High-level Languages
TwinCAT enables the usage of high-level languages like C++ and Simulink to develop applications for the PLC
environment. This is an important feature for us because11 :
•
Enables the re-use of existing and previously tested software components.
•
Simplifies the development under the new PLC platform by using a well known programming language. Most
of our developers are experienced C/C++ developers.
•
Enables the implementation of more advanced applications requiring higher order of performance.
Evaluation
We have tested successfully the integration of C++ and Simulink into the PLC environment.
Tracking Device
The tracking device prototype is a PLC application consisting in two TwinCAT modules, one written in ST and the other
one in C++. These two modules implement the tracking control of an instrument derotator device. The part in ST does
the control of the motor using the MC function blocks and it uses the C++ module to compute the corrections of motion
based on sidereal time and the position of the telescope. The interface between the two modules is done trough the
mapping of inputs and outputs.
Standard Telescope Axis Controller (ESTAC)
We managed to deploy and run a simplified version of ESTAC on a PLC and we have tested it controlling two different
DC motors. ESTAC is a Simulink based controller which is used to control the main telescope axes11.
3.4 Software Engineering
The adoption of the new standard would suggest that the same methods and processes successfully applied for quality
control on the LCU are also applied to the PLCs. The suitability and relevance of software engineering techniques for the
PLC environment is currently being investigated.
The key factors in this investigation are:
a) The availability of third party commercial (or free) quality control tools.
b) The richness of the available development environment (including most predominantly the presence of an application
programming interface).
c) The adoption of open standards by the vendor, foremost for data formats.
d) The supported operating system being the same of the rest of the control system
Proc. of SPIE Vol. 9152 915207-11
While the situation for points (a) and (d) is disappointing, BECKHOFF has been fairly receptive to the popular demand
for more support of software engineering activities and for (b) and (c) our expectations are fulfilled or are expected to be
in the medium term.
ESO will receive and integrate contributions from external ESO partners, and therefore it has the interest to spot
deviation from architectural and notational standards early on. Initial efforts are concentrated on easing the maintenance,
by measuring the adoption of naming conventions for variable, data types, function blocks when using the ST
Programming Language (IEC 61131-3). Likewise, simple metrics have been introduced (see Figure 8) for size, amount
of documentation, or usage of the desired communication interface (OPC-UA).
The most critical item has been recognized to be version control, most notably the capability to reliably identify the
version of an application running in the operational environment, and match it with the revision control system in use
throughout the project. This has required the establishment of simple conventions and the usage of a dedicated utility to
deploy the application on the target (the automated, on-the-fly modification of a constant containing the version number
keeps human error out of the loop).
Further efforts will continue to investigate the automated deployment of the PLC code from a high level integration or
system test at instrument level.
ESO TC3 Lamp Library
ESO TC3 Lakeshore Driver
TC3 Generic SerialPortDriver
TC3 Comm
onLibrary
TC3 IODevLibrary
TC3 MoñonLrbrary
TC 3 LDLS Library
Solution
Name
1
2
3
Title
Author
Last Changed
sics2
pesics2.sln
vbaldini
pesplc1
14 Ntay 2014
sglcl
pesplci_solution.sln
icoretti
pesplcl
26 Mar 2014
TESTProject.sln
invalid
invalid
testProject
Viol.
SLOC
MAIN
./
Vars.
OPC Vars.
POUs
313
0
20
161
0
59
1
1
9
3
10
0
4
2
4 CCC TC3
CCC TC3.sln
icoretti
ESO TC3 Cabinet Cooling Controller Driver
25 Mar 2014
351
0
23
5
5 Common
Common TC3.sln
dpopovic
ESO TC3 Common Library
16 Apr 2014
18
0
12
0
3
6 Cooling
Cooling TC3.sln
dpopovic
ESO TC3 PLC based Cabinet Cooling Control
3 Mar 2014
130
0
20
4
2
5
7 IODev
8
Lakeshore TC3
9 Lamo
IODev_TC3.sln
icoretti
TC3 IODev Library
25 Mar 2014
395
1
45
12
Lakeshore TC3.sln
icoretti
ESO TC3 Lakeshore Driver
25 Mar 2014
339
0
23
5
2
Lamp TC3.sln
dpopovic
ESO TC3 Lamp Library
16 Apr 2014
291
0
29
4
2
3
10
Motor
Motor Solution.sln
mkiekebu
invalid
26 Aug 2013
811
0
95
4
11
Motor
Motor TC3.sln
dpopovic
ESO TC3 Motion Library
9 Ivlay 2014
1572
0
193
4
3
RS_Comm TC3.sln
icoretti
TC3 Generic Serial Port Driver
25 Mar 2014
341
0
36
4
2
Shutter TC3.sln
dpopovic
ESO TC3 Shutter Library
9 May 2014
292
0
32
8
3
Timer.sln
dpopovic
ESO TC3 Timer Library
17 Mar 2014
116
0
56
4
3
12 RS Comm TC3
13
Shutter
14 Timer
Violations Report
testProject
Element
myLovelyFunction
Type
Category
Message
FUNCTION NAME
naming convention
should start with F_
2 plutoStructure
STRUCT NAME
naming convention
should start with T
3 test
FUNCTION BLOCK NAME
naming convention
should start with FB_
1
Figure 8: Example of automated naming conventions/metrics inspection for PLC code.
Proc. of SPIE Vol. 9152 915207-12
4. CONCLUSIONS
Throughout this paper we have presented the results of the technology evaluation that is leading to a new hardware
standard for future VLT instruments. The new standard uses PC based PLCs and EtherCAT as a fieldbus.
The selection and verification of the technology has been a long process which started in 2009 and is coming to an end
with the formal ESO standardization process. Besides the status of the formal process, many instruments are already
using the new standard for auxiliary control tasks. Moreover instruments like ESPRESSO and ERIS will use exclusively
the new technology for their respective control systems.
The use of COTS brings significant cost savings but also means less flexibility and control. We have experienced some
issues when we tried to understand better the implementation and behavior of the COTS DC motion controller. The way
to mitigate this is selecting solutions where it is possible to reuse the internal know-how and the domain expertise and
where it is possible to adapt the solutions to specific ESO requirements.
Based on our experience so far and on the features provided by the proposed solution, we can say that BECKHOFF
Embedded PCs and EtherCAT are today an adequate replacement for the LCUs for controlling instrument functions.
Nevertheless, the evolution of the technology has to be followed closely since it might easily migrate to follow industry
trends which might not be necessary in line with the requirements of future instruments.
REFERENCES
[1] Kiekebusch, M., Chiozzi, G., Knudstrup, J., Popovic, D., Zins, G., "Evolution of the VLT instrument control
system toward industry standards" Proc. SPIE 7740 (2010).
[2] Berger, J.-P., “PIONIER: a visitor instrument for the VLTI" Proc. SPIE 7734 (2010).
[3] Technology Board, “Evaluation of PLC Technology as a Standard Control System Development Platform at
ESO”, ESO internal document, GEN-TRE-ESO-73000-5788.
[4] Payne, J., “PLC vs. PAC”, Control Engineering Magazine, http://www.controleng.com/
[5] http://www.beckhoff.de
[6] Knudstrup, J. T., "PLC Based Motion Control Technical Report," ESO internal document, (2012).
[7] http://www.plcopen.org
[8] http://www.ethercat.org/default.htm
[9] https://opcfoundation.org/
[10] Popovic, D., Brast, R., Di Lieto, N., Kiekebusch, M., Knudstrup, J., Lucuix, C., “Motion control solution for
new PLC-based standard development platform for VLT instrument control systems” Proc. SPIE 9152 (2014).
[11] Kiekebusch, M., Di Lieto, N., Sandrock, S., Popovic, D., Chiozzi, G., “MathWorks Simulink and C++
integration to the new VLT PLC-based standard development platform for instrument control systems” Proc.
SPIE 9152 (2014).
Proc. of SPIE Vol. 9152 915207-13