1. Ingeniería

 Basic Functions for Modular
___________________
Preface
Machines
Overview of the functionality
1
___________________
of modular machines
SIMOTION
Motion Control
Basic Functions for Modular
Machines
Function Manual
Synchronizing SIMOTION
devices with a higher-level
bus cycle clock
2
___________
Setting the communication
addresses via the user
program
3
___________
Activating and deactivating
components and technology
objects
4
Changing the active
configuration or the active
kernel
5
___________
A
___________________
Appendix
02/2012
Legal information
Legal information
Warning notice system
This manual contains notices you have to observe in order to ensure your personal safety, as well as to prevent
damage to property. The notices referring to your personal safety are highlighted in the manual by a safety alert
symbol, notices referring only to property damage have no safety alert symbol. These notices shown below are
graded according to the degree of danger.
DANGER
indicates that death or severe personal injury will result if proper precautions are not taken.
WARNING
indicates that death or severe personal injury may result if proper precautions are not taken.
CAUTION
with a safety alert symbol, indicates that minor personal injury can result if proper precautions are not taken.
CAUTION
without a safety alert symbol, indicates that property damage can result if proper precautions are not taken.
NOTICE
indicates that an unintended result or situation can occur if the relevant information is not taken into account.
If more than one degree of danger is present, the warning notice representing the highest degree of danger will
be used. A notice warning of injury to persons with a safety alert symbol may also include a warning relating to
property damage.
Qualified Personnel
The product/system described in this documentation may be operated only by personnel qualified for the specific
task in accordance with the relevant documentation, in particular its warning notices and safety instructions.
Qualified personnel are those who, based on their training and experience, are capable of identifying risks and
avoiding potential hazards when working with these products/systems.
Proper use of Siemens products
Note the following:
WARNING
Siemens products may only be used for the applications described in the catalog and in the relevant technical
documentation. If products and components from other manufacturers are used, these must be recommended
or approved by Siemens. Proper transport, storage, installation, assembly, commissioning, operation and
maintenance are required to ensure that the products operate safely and without any problems. The permissible
ambient conditions must be complied with. The information in the relevant documentation must be observed.
Trademarks
All names identified by ® are registered trademarks of Siemens AG. The remaining trademarks in this publication
may be trademarks whose use by third parties for their own purposes could violate the rights of the owner.
Disclaimer of Liability
We have reviewed the contents of this publication to ensure consistency with the hardware and software
described. Since variance cannot be precluded entirely, we cannot guarantee full consistency. However, the
information in this publication is reviewed regularly and any necessary corrections are included in subsequent
editions.
Siemens AG
Industry Sector
Postfach 48 48
90026 NÜRNBERG
GERMANY
Copyright © Siemens AG 2012.
All rights reserved
Preface
Preface
This document is part of the SIMOTION System and Function Descriptions documentation
package.
Scope of validity
This document is valid for SIMOTION SCOUT - the engineering system of the product range
SIMOTION - in product level V4.2 in connection with:
● A SIMOTION device with the following versions of the SIMOTION Kernel:
– V4.3
– V4.2
– V4.1
– V4.0
– V3.2
● The relevant version of the following SIMOTION Technology Packages, depending on the
kernel:
– Cam
– Path (kernel V4.1 and higher)
– Cam_ext
– TControl
The descriptions for the PROFINET communication refer to PROFINET standard V2.2. For
details please see Compatibility List SW
(http://support.automation.siemens.com/WW/view/de/18857317).
Basic Functions for Modular Machines
Function Manual, 02/2012
3
Preface
Sections in this manual
The following is a list of sections included in this manual along with a description of the
information presented in each section.
● Overview of the functionality of modular machines in the SIMOTION system (Section 1)
This section provides an overview of the functionalities for modular machines that are
automated using SIMOTION and PROFIBUS DP or PROFINET IO.
● Synchronizing SIMOTION devices with a higher-level bus cycle clock (Section 2)
This section describes the synchronization of a SIMOTION device and its PROFIBUS DP
interfaces with a higher-level bus cycle clock.
● Setting the communication addresses via the user program (Section 3)
This section describes the options for changing the communication addresses for
PROFIBUS DP, PROFINET IO, and Ethernet via the user program.
● Activating and deactivating components and technology objects (Section 4)
This section describes how to activate or deactivate DP slaves (in PROFIBUS), IO
devices (in PROFINET), or technology objects in the user program.
● Changing the active configuration or the active kernel (Section 5)
This section describes how to perform a controlled change of configurations or the
SIMOTION Kernel via a user program.
● Index
Keyword index for locating information.
SIMOTION Documentation
An overview of the SIMOTION documentation can be found in a separate list of references.
This documentation is included as electronic documentation in the scope of delivery of
SIMOTION SCOUT. It comprises 10 documentation packages.
The following documentation packages are available for SIMOTION V4.3:
● SIMOTION Engineering System
● SIMOTION System and Function Descriptions
● SIMOTION Service and Diagnostics
● SIMOTION IT
● SIMOTION Programming
● SIMOTION Programming - References
● SIMOTION C
● SIMOTION P
● SIMOTION D
● SIMOTION Supplementary Documentation
Basic Functions for Modular Machines
4
Function Manual, 02/2012
Preface
Hotline and Internet addresses
Additional information
Click the following link to find information on the the following topics:
● Ordering documentation/overview of documentation
● Additional links to download documents
● Using documentation online (find and search in manuals/information)
http://www.siemens.com/motioncontrol/docu
Please send any questions about the technical documentation (e.g. suggestions for
improvement, corrections) to the following e-mail address:
[email protected]
My Documentation Manager
Click the following link for information on how to compile documentation individually on the
basis of Siemens content and how to adapt this for the purpose of your own machine
documentation:
http://www.siemens.com/mdm
Training
Click the following link for information on SITRAIN - Siemens training courses for automation
products, systems and solutions:
http://www.siemens.com/sitrain
FAQs
Frequently Asked Questions can be found in SIMOTION Utilities & Applications, which are
included in the scope of delivery of SIMOTION SCOUT, and in the Service&Support pages
in Product Support:
http://support.automation.siemens.com
Technical support
Country-specific telephone numbers for technical support are provided on the Internet under
Contact:
http://www.siemens.com/automation/service&support
Basic Functions for Modular Machines
Function Manual, 02/2012
5
Preface
Basic Functions for Modular Machines
6
Function Manual, 02/2012
Table of contents
Preface ...................................................................................................................................................... 3
1
2
3
4
Overview of the functionality of modular machines .................................................................................. 11
1.1
Synchronizing SIMOTION devices with a higher-level bus cycle clock.......................................11
1.2
1.2.1
1.2.2
Changing communication addresses via the user program ........................................................12
Application examples for setting the communication address.....................................................13
User program for changing the communication address.............................................................16
1.3
1.3.1
1.3.2
1.3.3
Operating only parts of a configured maximum configuration .....................................................17
Fundamental procedures .............................................................................................................17
User program ...............................................................................................................................18
System behavior ..........................................................................................................................18
1.4
1.4.1
1.4.2
1.4.3
1.4.4
Activating the configuration or the SIMOTION kernel..................................................................19
Activating the configuration..........................................................................................................19
Activating the SIMOTION kernel..................................................................................................20
Selecting and activating a configuration using an initial configuration.........................................20
Procedure.....................................................................................................................................21
Synchronizing SIMOTION devices with a higher-level bus cycle clock .................................................... 23
2.1
2.1.1
2.1.2
General information about synchronizing a SIMOTION device with the bus cycle clock ............23
Cycle clock generation and synchronization in PROFIBUS DP ..................................................24
Cycle clock generation and synchronization in PROFINET IO....................................................26
2.2
Synchronizing a SIMOTION device without an isochronous DP master interface ......................30
2.3
Synchronization of a SIMOTION device with an isochronous DP master interface ....................33
2.4
Behavior in the STOP and RUN operating modes ......................................................................39
Setting the communication addresses via the user program.................................................................... 41
3.1
3.1.1
3.1.2
Setting the PROFIBUS address...................................................................................................42
System functions..........................................................................................................................42
System behavior ..........................................................................................................................44
3.2
Topology detection in PROFINET IO...........................................................................................45
3.3
3.3.1
3.3.2
Setting the device name (NameOfStation) of an IO device on PROFINET IO............................47
System functions..........................................................................................................................48
System behavior ..........................................................................................................................49
3.4
Setting the IP address (on Ethernet) ...........................................................................................50
Activating and deactivating components and technology objects............................................................. 53
4.1
4.1.1
4.1.1.1
4.1.1.2
4.1.1.3
4.1.2
Activating and deactivating nodes on the PROFIBUS or PROFINET IO ....................................53
System functions for activating and deactivating bus nodes .......................................................54
Status diagram for the functions _activateDpSlave and _deactivateDpSlave .............................57
Asynchronous call for the functions _activateDpSlave and _deactivateDpSlave ........................58
Synchronous call for the functions _activateDpSlave and _deactivateDpSlave..........................61
Querying the activation state and status of the nodes (DP slaves or IO devices).......................62
Basic Functions for Modular Machines
Function Manual, 02/2012
7
Table of contents
5
4.1.2.1
4.1.2.2
4.1.2.3
4.1.3
Querying the activation state of the DP slaves and IO devices using system functions ............ 62
Querying the status of the DP slaves and IO devices using system functions........................... 63
Monitoring the status of the DP slaves and IO devices in the engineering system .................... 64
Converting a PROFIBUS address or device number for PROFINET IO into the logical
diagnostics address and vice versa ............................................................................................ 64
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
Option handling for ET200S without reserve modules ............................................................... 65
Principle of operation of option handling without reserve modules............................................. 65
Prerequisites for option handling without reserve modules ........................................................ 66
Example of use without reserve modules ................................................................................... 66
Assigning parameters for option handling without reserve modules .......................................... 67
Controlling and monitoring options ............................................................................................. 69
4.3
Activating and deactivating SINAMICS components .................................................................. 71
4.4
4.4.1
4.4.1.1
4.4.1.2
4.4.1.3
4.4.2
4.4.3
4.4.3.1
4.4.3.2
Activating and deactivating technology objects .......................................................................... 74
System functions for activating and deactivating technology objects......................................... 75
Status diagram for the functions _activateTo and _deactivateTo ............................................... 75
Asynchronous call for the functions _activateTo and _deactivateTo .......................................... 77
Synchronous call for the functions _activateTo and _deactivateTo ............................................ 79
Activating or deactivating technology objects in the engineering system................................... 81
Querying the activation state of technology objects ................................................................... 81
Querying the activation state of technology objects using system functions.............................. 82
Monitoring the activation state of technology objects in the engineering system ....................... 82
4.5
4.5.1
4.5.2
Procedure for deactivating and activating components .............................................................. 83
Deactivating components............................................................................................................ 83
Activating components ................................................................................................................ 84
Changing the active configuration or the active kernel............................................................................. 85
5.1
5.1.1
5.1.2
Activating a configuration ............................................................................................................ 85
Special considerations when a CX32/CX32-2 controller extension is connected ...................... 87
Example for the activation of a configuration .............................................................................. 88
5.2
5.2.1
5.2.2
5.2.3
Activating a kernel....................................................................................................................... 90
Activating a kernel....................................................................................................................... 90
Example programs for activating a kernel................................................................................... 92
Status diagram for activating a kernel......................................................................................... 95
5.3
5.3.1
5.3.2
5.3.3
Selecting and activating a configuration using an initial configuration........................................ 96
Selecting and activating a configuration using an initial configuration........................................ 96
Status diagram for what happens when a SIMOTION device is switched on depending on
whether or not the SelfAdaptingConfiguration functionality is active .......................................... 99
Example program for an initial configuration............................................................................. 100
5.4
Reading the activation state of configurations .......................................................................... 101
5.5
Retaining retentive data in the event of a configuration change............................................... 102
5.6
5.6.1
5.6.2
5.6.3
5.6.4
5.6.5
5.6.6
Procedure for creating the card images of configurations ........................................................ 104
Preparing the memory card of the SIMOTION device .............................................................. 105
Creating the work directories on the PC/PG ............................................................................. 105
Saving the configuration files in the work directories on the PC/PG ........................................ 109
Creating the compressed configuration files............................................................................. 111
Saving the kernel in the work directory on the PC/PG.............................................................. 112
Creating the card images of the configurations ........................................................................ 113
Basic Functions for Modular Machines
8
Function Manual, 02/2012
Table of contents
A
Appendix................................................................................................................................................ 115
A.1
Command line application u7mkcnfx.exe ..................................................................................115
A.2
A.2.1
A.2.2
A.2.3
A.2.4
A.2.5
A.2.6
Creating the card images for the configuration server by means of SCOUT scripting..............118
Creating the script folder in the SCOUT project ........................................................................119
Creating the work directories on the PC/PG..............................................................................120
Saving the configuration files in the work directories on the PC/PG .........................................121
Creating the compressed configuration files..............................................................................122
Creating the card images of the configurations .........................................................................124
Script to call up the individual scripts to create the card image.................................................125
A.3
Loading the card image to the target device by means of SCOUT scripting.............................126
A.4
Storing configuration files for SIMOTION D4xx devices up to kernel version V4.1.4................128
Index...................................................................................................................................................... 131
Basic Functions for Modular Machines
Function Manual, 02/2012
9
Table of contents
Basic Functions for Modular Machines
10
Function Manual, 02/2012
1
Overview of the functionality of modular machines
This section provides an overview of which functionalities are offered by the SIMOTION MC
system to enable the creation of modular machines with SINAMICS drives, PROFIBUS DP,
and PROFINET IO.
The SIMOTION system offers several ways of designing a machine on a modular basis and
optimizing the rated conditions:
● The targeted and automated creation of a SIMOTION project in the SIMOTION SCOUT
engineering system, for example by:
– Using ready-made and tested modules such as library components, for example
– Automating the configuration and parameter assignment of machine components
(e.g. the drives or the components) in scripting.
This procedure is clearly described in the online help section of the SCOUT engineering
system and will not be explained in further detail here.
● Changing the configuration during user program runtime. This is done via system
functions provided by the SIMOTION kernel. An engineering system is not required.
This procedure is described in detail in this document.
The procedure for distributed synchronous operation, which can apply to the entire
project, is described in the function manual titled SIMOTION Motion Control Technology
Objects Synchronous Operation, Cam.
1.1
Synchronizing SIMOTION devices with a higher-level bus cycle
clock
SIMOTION devices provide several communication interfaces to which distributed I/O,
for example, or other SIMOTION devices can be connected. This enables the synchronous
running of axes that are controlled and regulated via the various SIMOTION devices
(distributed synchronous operation). For this, the devices must be interconnected via an
isochronous communication network (PROFIBUS DP or PROFINET IO) and synchronized
with a common bus cycle clock.
6,027,21B
0DVWHU
6,027,21B
6ODYH
0DVWHU
'HILQHVWKHF\FOHFORFNIRUWKHV\VWHP
Figure 1-1
'ULYH
VODYH
Sample configuration for synchronizing a SIMOTION device with an isochronous master
Basic Functions for Modular Machines
Function Manual, 02/2012
11
Overview of the functionality of modular machines
1.2 Changing communication addresses via the user program
The SIMOTION_1 device delivers a bus cycle clock to the connected subnet via an
isochronous communication interface that has been configured as a DP master (in
PROFIBUS DP) or as a sync master (in PROFINET IO).
The SIMOTION_2 device should be synchronized with this higher-level bus cycle clock. For
this reason, the communication interface reached by the bus cycle clock in the SIMOTION_1
device must be configured as a DP slave (in PROFIBUS DP) or as a sync slave (in
PROFINET IO). General information about synchronizing a SIMOTION device with the bus
cycle clock (Page 23) gives an overview of cycle clock generation and synchronization in
PROFIBUS DP and PROFINET IO.
Isochronous DP master interfaces in the SIMOTION_2 device can be synchronized with the
higher-level bus cycle clock and the cycle clock delivered to lower-level drives. The
synchronization behavior of the SIMOTION_2 device depends on whether or not the
PROFIBUS DP interfaces have been configured as isochronous DP masters:
● No further isochronous DP master interface available: The synchronization of the device
(with the internal cycle clocks) occurs automatically when the higher-level bus cycle clock
has been recognized at the corresponding slave interface. See Synchronizing a
SIMOTION device without an isochronous DP master interface (Page 30)
● At least one isochronous DP master interface is available (for example, in SIMOTION
D4xx). Synchronization of the isochronous DP master interfaces is controlled by the user
and occurs when the user calls up a system function. Synchronization of the device
varies, depending on whether the higher-level bus cycle clock is fed in via a PROFIBUS
DP interface or a PROFINET IO interface. See Synchronization of a SIMOTION device
with an isochronous DP master interface (Page 33)
1.2
Changing communication addresses via the user program
Nodes are clearly identified within a communication network by means of, for example
● The PROFIBUS address of the interface in PROFIBUS DP
● The device name (NameOfStation) in PROFINET IO
● The IP address of the interface on Ethernet
These communication addresses are set during configuration with the help of the SIMOTION
SCOUT engineering software. They can be changed later by a user program and the
requirements customized at each respective destination.
Some application examples for this functionality are described in the following.
Basic Functions for Modular Machines
12
Function Manual, 02/2012
Overview of the functionality of modular machines
1.2 Changing communication addresses via the user program
1.2.1
Application examples for setting the communication address
Base machine with several modules
A machine consists of a base machine (base_machine) with several machine modules
(module_1 to module_n). The base machine and all modules are controlled via separate
SIMOTION devices. These are interconnected via a communication network. This is shown
schematically:
● In the PROFIBUS DP example: A base machine with several identical modules, which
communicate via PROFIBUS DP
● In the PROFINET IO example: A base machine with several identical modules, which
communicate via PROFINET IO
The same SIMOTION project (i.e. the same SIMOTION devices, drives, technology objects,
user programs) is loaded on all machine modules. The user program of each module
determines the necessary communication address and sets it up.
Note
As an alternative to changing the communication address of the machine module, you can
also activate different configurations (Activating the configuration (Page 19)).
Basic Functions for Modular Machines
Function Manual, 02/2012
13
Overview of the functionality of modular machines
1.2 Changing communication addresses via the user program
Example of communication via PROFIBUS DP
EDVHBPDFKLQH
6,027,21B
'3
23+0,
'3
PDVWHU
GSBVODYHB
GSBVODYHB
GSBVODYHB
PRGXOHB
6,027,21B
'3
VODYH
'3
PDVWHU
GSBVODYHB
GSBVODYHB
PRGXOHB
6,027,21B
'3
VODYH
'3
PDVWHU
GSBVODYHB
GSBVODYHB
'3
PDVWHU
GSBVODYHB
Figure 1-2
GSBVODYHB
PRGXOHB
6,027,21B
'3
VODYH
GSBVODYHB
GSBVODYHB
GSBVODYHB
Base machine with several identical modules (communication via PROFIBUS DP)
Basic Functions for Modular Machines
14
Function Manual, 02/2012
Overview of the functionality of modular machines
1.2 Changing communication addresses via the user program
Example of communication via PROFINET IO
EDVHBPDFKLQH
6,027,21B
SRUW
SRUW
SRUW
SRUW
23+0,
'3
PDVWHU
GSBVODYHB
GSBVODYHB
PRGXOHB
6,027,21B
SRUW
SRUW
SRUW
SRUW
GHYLFHB
GHYLFHB
GHYLFHB
'3
PDVWHU
GSBVODYHB
PRGXOHB
6,027,21B
SRUW
SRUW
SRUW
SRUW
GHYLFHB
GHYLFHB
GHYLFHB
'3
PDVWHU
GSBVODYHB
Figure 1-3
GSBVODYHB
PRGXOHB
6,027,21B
SRUW
GSBVODYHB
SRUW
SRUW
SRUW
GHYLFHB
GHYLFHB
GHYLFHB
'3
PDVWHU
GSBVODYHB
GSBVODYHB
Base machine with several identical modules (communication via PROFINET IO)
Replacing a module on the base machine
The user connects a replacement module to the base machine. A standard project with a
preset communication address is loaded on the replacement module. The user program of
each module determines the necessary communication address and sets it up.
Basic Functions for Modular Machines
Function Manual, 02/2012
15
Overview of the functionality of modular machines
1.2 Changing communication addresses via the user program
Operating a module on several base machines
A module (with dedicated SIMOTION control) is alternately connected to different base
machines (e.g. a transport vehicle travels to different assembly sites and connects there). At
each base machine, the module is to be integrated in the respective communication network
and contact established with the higher-level control.
A standard project with a preset communication address is loaded on the module. The
communication address valid for the network of the respective base machine is set by the
user program of the module according to the specifications.
1.2.2
User program for changing the communication address
The user program checks which communication address is to be set for the respective
network, e.g. by:
● Reading in and evaluating a slot coding
● Evaluating a program variable (which can be changed, for example, by a user input on
the HMI device)
The determined communication address then sets the user program. System functions are
provided for this purpose, for example:
● To change the PROFIBUS address of a DP slave (see Setting the PROFIBUS address
(Page 42)):
– _getActiveDpSlaveAddress
– _setDpSlaveAddress
– _activateDpSlaveAddress
● To change the device name (NameOfStation) of an IO device on PROFINET IO (see
Setting the device name (NameOfStation) of an IO device on PROFINET IO (Page 47)):
– _getActiveNameOfStation
– _setNameOfStation
– _activateNameOfStation
● To change the IP address of an Ethernet node (see Setting the IP address (on Ethernet)
(Page 50)):
– _getIpConfig
– _setIpConfig
Basic Functions for Modular Machines
16
Function Manual, 02/2012
Overview of the functionality of modular machines
1.3 Operating only parts of a configured maximum configuration
1.3
Operating only parts of a configured maximum configuration
Here, for example, a machine consists of a base machine with several machine modules or
several axes. The user configures and programs the base machine with all possible machine
modules and axes (maximum configuration). The real machine differs from the configured
maximum configuration, e.g.:
● Not all configured machine modules or axes are available (actual structure differs from
configured structure)
● Not all machine modules or axes are required in an operation phase.
SIMOTION provides system functions for the following purposes:
● The distributed I/O on PROFIBUS DP or PROFINET IO (e.g. drives or other DP slaves or
IO devices) can be activated or deactivated. In addition, the current state of individual or
all DP slaves or IO devices can be queried.
● Technology objects (e.g. axes assigned to drives that are not required) can be activated
or deactivated.
The computational load of the SIMOTION device can be reduced through specific use of
these system functions; the computing capability can be concentrated on the drives or
technology objects which are currently required. No bus fault is signaled, even if bus nodes
are not available.
Note
Licenses are required for all axes of the maximum configuration.
1.3.1
Fundamental procedures
As an example, different procedures are described for a machine during ramp-up or during
production.
● During ramp-up, the user program determines the actual structure of the distributed I/O
(e.g. drives, other DP slaves) of the machine. Here, the system function calls
_getStateOfAllDpSlaves and evaluates its return value.
All configured distributed I/O are activated, by default. The user program now deactivates
the DP slaves that are not available and the technology objects assigned to the drives.
● During a defined production phase, certain plant units (e.g. machine modules, including
drives and axes) are required, while others are not. In accordance with the relevant
operator specifications, the user program deactivates plant units which are no longer
required (along with the assigned technology objects) and activates the newly added
ones.
Basic Functions for Modular Machines
Function Manual, 02/2012
17
Overview of the functionality of modular machines
1.3 Operating only parts of a configured maximum configuration
1.3.2
User program
You can use the following SIMOTION system functionalities in the user program:
● System functions are provided (see Activating and deactivating nodes on the PROFIBUS
or PROFINET IO (Page 53)) to activate or deactivate a bus node (DP slaves or IO
devices) and to query its status; for example:
– _activateDpSlave
– _deactivateDpSlave
– _getStateOfAllDpSlaves or _getStateOfAllDPStations
● Use the parameters of a SINAMICS drive (see Activating and deactivating SINAMICS
components (Page 71)) to activate or deactivate the drive and to query its status.
● System functions are provided (see Activating and deactivating technology objects
(Page 74)) to activate or deactivate a technology object and to query its status;
for example:
– _activateTo
– _deactivateTo
– _getStateOfTo
1.3.3
System behavior
The cycle time calculated from the configuration for exchanging data with all distributed I/O
on the PROFIBUS DP remains unchanged.
However, a deactivation of the distributed I/O still results in the following advantages:
● The data volume on the PROFIBUS DP to be transferred cyclically is reduced, and the
time required within a system cycle clock for communication decreases. The time saved
is available for other services on the PROFIBUS (e.g. acyclic services for operator control
and monitoring or diagnostics)
● Deactivated technology objects hardly require any computing time. The time saved is
available for user tasks
● Alarms of these I/O (e.g. _SC_DIAGNOSTIC_INTERRUPT,
_SC_STATION_DISCONNECTED, _SC_STATION_RECONNECTED) are suppressed
and no longer evaluated.
Basic Functions for Modular Machines
18
Function Manual, 02/2012
Overview of the functionality of modular machines
1.4 Activating the configuration or the SIMOTION kernel
1.4
Activating the configuration or the SIMOTION kernel
The "configuration server" functionality integrated in SIMOTION permits configurations on
the memory card to be added to the SIMOTION device. For example, the following
applications can be implemented:
● A configuration adapted for each task (e.g. device configuration, technology objects, user
program) can be added (see Activating the configuration (Page 19)):
– By coupling different machine modules (e.g. in different production phases), the
required configuration can be automatically determined (using connector coding,
for example); this configuration can then be added
– The memory and computing capability of the SIMOTION device are only used for the
configured functionalities
– Cycle times and cycle clocks (e.g. DP cycle clock, position control cycle clock, IPO
cycle clock) can be optimized for each requirement.
● The configurations (e.g. of the user programs) or the SIMOTION kernel can be updated
using the user program:
The user transfers the new configurations and, if necessary, the SIMOTION kernel to the
memory card of the SIMOTION device and starts updating via the user program (see
Activating the configuration (Page 19) and Activating the SIMOTION kernel (Page 20))
● Automatic recognition of the required configuration and its activation during the ramp-up
of a SIMOTION device (SelfAdaptingConfiguration) is possible (see Selecting and
activating a configuration using an initial configuration (Page 20)).
1.4.1
Activating the configuration
Various machine modules (e.g. DP slaves) are alternately connected to a SIMOTION device
(base machine). The data for each arrangement (base machine with connected machine
module) is stored as its own configuration on the memory card of the SIMOTION device.
In the example (see figure), a transport device with a SIMOTION control transports a
workpiece to various machining stations. The following sequences can be observed here:
1. Drawing a blank from the store and transporting it to the machining station
2. Machining the blank
3. Unloading the semi-finished part at the packing station.
5HPRYH
Figure 1-4
0DFKLQH
3DFN
Sequences of an automation task
Basic Functions for Modular Machines
Function Manual, 02/2012
19
Overview of the functionality of modular machines
1.4 Activating the configuration or the SIMOTION kernel
For each machining step, the associated optimized configuration is stored on the memory
card of the transport device. After coupling to a machining station, the transport device
identifies this, e.g. by evaluating a connector coding, and loads the required configuration
using the _activateConfiguration system function. It then completes all work at the station
and moves to the next one.
See also Activating a configuration (Page 85).
1.4.2
Activating the SIMOTION kernel
You can also exchange the active kernel of the SIMOTION device using the user program
and, for example, carry out an update to a new version without having to change the memory
card of the device. In this regard, you must replace all configurations (configuration data) of
the SIMOTION device.
The SIMOTION kernel and the associated configurations (configuration data) are stored on
the memory card.
Using the _activateConfiguration system function you can ensure that a new kernel and a
configuration are loaded and activated in the user program. The activating configuration can
be specified explicitly or determined automatically using an initial configuration.
See also Activating a kernel (Page 90).
1.4.3
Selecting and activating a configuration using an initial configuration
A SIMOTION device (machine module) is connected to a different SIMOTION device (base
machine). After POWER ON, the machine module ramps up, identifies its position at the
base machine (e.g. using a connector coding), and automatically loads the required
configuration.
For this, the data of all configurations is saved to the memory card of the machine module;
the machine module can then pick up this data on the base machine. The initial configuration
also stored there will be loaded automatically after POWER ON. This identifies the required
configuration (e.g. by using a connector coding) and loads it using the _activateConfiguration
system function.
See also Selecting and activating a configuration using an initial configuration (Page 96).
Basic Functions for Modular Machines
20
Function Manual, 02/2012
Overview of the functionality of modular machines
1.4 Activating the configuration or the SIMOTION kernel
1.4.4
Procedure
All configurations required for a SIMOTION device (and possibly the SIMOTION kernel to be
added) must be stored on the memory card of the SIMOTION device in a prescribed data
format. The following section gives a summary of how to create the required data.
1. Configure and program each required configuration as a unique device in the engineering
system (e.g. SIMOTION SCOUT).
2. Create the files required for the file system on the memory card of the SIMOTION device.
3. Transfer this card image to the associated memory card.
This process is described in detail in Procedure for creating the card images of
configurations (Page 104).
Basic Functions for Modular Machines
Function Manual, 02/2012
21
Overview of the functionality of modular machines
1.4 Activating the configuration or the SIMOTION kernel
Basic Functions for Modular Machines
22
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level
bus cycle clock
2.1
2
General information about synchronizing a SIMOTION device with
the bus cycle clock
SIMOTION devices provide a range of interfaces for connecting to PROFIBUS DP or
PROFINET IO. The devices and their applications (e.g. in ServoSynchronousTask or
IPOSynchronousTask) can be operated isochronously to the bus cycle clocks occurring on
the interfaces.
The table below provides an overview of the number and type of PROFIBUS DP and
PROFINET IO interfaces of the various SIMOTION devices.
Table 2- 1
Isochronous PROFIBUS DP and PROFINET IO interfaces of SIMOTION devices
SIMOTION device PROFIBUS DP interfaces
PROFINET IO interfaces
D410 DP
0 interfaces
•
1 external interface
•
1 internal master interface for SINAMICS
Integrated
•
0 external interfaces
•
1 internal master interface for SINAMICS
Integrated
•
2 external interfaces
•
1 internal master interface for SINAMICS
Integrated
D425
D435
D445
D445-1
•
2 external interfaces
•
1 internal master interface for SINAMICS
Integrated
D425-2 DP/PN
D435-2 DP/PN
D445-2 DP/PN
D455-2 DP/PN
•
2 external interfaces
•
1 internal master interface for SINAMICS
Integrated
C230-2
C240
2 external interfaces
0 interfaces
C240 PN
2 external interfaces
1 interface
P320
0 interfaces
1 interface
P350
2 external interfaces
1 interface with connected MCI
PN board
D410 PN
D410-2
1 interface
1 interface
1 interface with connected CBE30
1 interface
The interfaces can be operated as either slave or master.
The following provides a description of cycle clock generation and the various
synchronization mechanisms.
Basic Functions for Modular Machines
Function Manual, 02/2012
23
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.1 General information about synchronizing a SIMOTION device with the bus cycle clock
2.1.1
Cycle clock generation and synchronization in PROFIBUS DP
Clock generation in PROFIBUS DP
It is necessary to distinguish between the following cases for clock generation in PROFIBUS
DP:
● Precisely one PROFIBUS DP interface is configured as DP slave and is operated
isochronously:
In this case, this interface supplies the basic cycle clock for the SIMOTION device.
– If a DP cycle is available at this interface, the SIMOTION device must be synchronized
with this cycle clock. The synchronization behavior depends on whether the
PROFIBUS DP interfaces of the SIMOTION device have been configured as the
isochronous DP master. See the following section, "Synchronization in PROFIBUS
DP".
– If no DP cycle clock is available at this interface (e.g. if the associated DP master
fails), a replacement cycle clock of the same size is generated.
● In all other cases (e.g. if no PROFIBUS DP interface has been configured as DP slave, or
the interface configured as DP slave is not operated isochronously), the following shall
apply:
The basic cycle clock is derived from an internal cycle clock which is determined during
configuration (configured basic cycle clock).
The figure below displays the cycle clock generating principle in PROFIBUS DP.
6,027,21GHYLFH
alternatively, configured
basic clock cycle
3//
%DVLFFORFN
F\FOH
6,027,21NHUQHO
&ORFNF\FOHV
6HUYR,32,32
'3
'3PDVWHU
'3,QWHJUDWHG
'3PDVWHU
7'3
7'3,17
7'3VODYH
'3
'3VODYH
7'3
Higher-level bus cycle clock
6,1$0,&6,QWHJUDWHG
'3VODYH
'3PDVWHU
Figure 2-1
'3VODYH
Cycle clock generation in a SIMOTION device in PROFIBUS DP
Basic Functions for Modular Machines
24
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.1 General information about synchronizing a SIMOTION device with the bus cycle clock
Synchronization in PROFIBUS DP
If the DP slave interface is operated isochronously, the SIMOTION device must be
synchronized with the higher-level bus cycle clock. The synchronization behavior depends
on whether the PROFIBUS DP interfaces of the SIMOTION device have been configured as
the isochronous DP master:
● None of the PROFIBUS DP interfaces have been configured as isochronous DP master
for the lower-level drives:
The device is automatically synchronized with the higher-level bus cycle clock.
After successful synchronization, the cycle clocks of the device (e.g. Servo, IPO, IPO2)
and the programs running in the SynchronousTasks are both synchronous with the
higher-level bus cycle clock.
See: Synchronization of a SIMOTION device without isochronous DP master interface
(Page 30).
● At least one of the PROFIBUS DP interfaces is configured as isochronous DP master for
lower-level drives:
Users must themselves activate synchronization of the device with the higher-level bus
cycle clock using the _synchronizeDpInterfaces system function (user-controlled
synchronization). The user can thereby determine the time of synchronization and take
suitable precautions, such as deactivating affected DP slaves, to avoid system failures
caused by the synchronization process.
Only after successful synchronization are the device cycle clocks (e.g. Servo, IPO, IPO2),
the programs running in SynchronousTasks, and also the isochronous DP master
interfaces all synchronous with the higher-level bus cycle clock.
See: Synchronization of a SIMOTION device with isochronous DP master interface
(Page 33).
NOTICE
A phase jump occurs during synchronization of an isochronous DP master interface with a
higher-level bus cycle clock. This can lead to failures in the connected DP slaves
(e.g. SINAMICS drives).
You should, therefore, deactivate the DP slaves concerned and the technology objects
assigned to them before synchronizing drives that are already in operation. Once
synchronization has been successfully completed, you can reactivate the DP slaves
concerned and their assigned technology objects. See Activating and deactivating
components and technology objects (Page 53).
Note
In SIMOTION D4xx devices, the interface "DP Integrated" is always configured as the
isochronous DP master interface.
Therefore, if these devices are connected to a higher-level isochronous master, they must
always be synchronized.
Basic Functions for Modular Machines
Function Manual, 02/2012
25
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.1 General information about synchronizing a SIMOTION device with the bus cycle clock
NOTICE
Note that if SINAMICS drives with Safety Integrated are connected to the isochronous DP
master interface of a SIMOTION device and the actuation is performed via PROFIsafe:
A safety error in the drive which cannot be acknowledged can be triggered during the
synchronization of the SIMOTION device with the higher-level bus cycle clock. This error
occurs if the phase jump caused by the synchronization occurs while the safety functionality
in the drive is booting up.
Therefore, the synchronization must not be performed until after Safety Integrated in the
drive is ready. In order to achieve this, use the user-controlled synchronization, see
synchronization of a SIMOTION device with isochronous DP master interface (Page 33).
Wait with the call of the system function _synchronizeDPInterfaces as long as:
1. Until the drives have powered up (system variable cyclicInterface of the axis = ACTIVE).
And
2. Until Safety Integrated in the drives is ready (additional 250 ms = 10 * MAX (p9500)).
2.1.2
Cycle clock generation and synchronization in PROFINET IO
Clock generation in PROFINET IO
The following applies for clock generation in PROFINET IO:
If a PROFINET IO interface is available, the base cycle clock of a SIMOTION device is
supplied by this interface providing the interface has been configured as follows:
1. The synchronization type has been set as sync master or sync slave.
2. IRT with the"High Performance" option has been set as the real-time class.
In this configuration, the basic cycle clock is the send cycle clock set at the associated sync
domain.
Basic Functions for Modular Machines
26
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.1 General information about synchronizing a SIMOTION device with the bus cycle clock
It is necessary to distinguish between the following cases:
● The PROFINET IO interface is configured as a Sync-Master:
This interface provides the cycle clock for the SIMOTION device including its isochronous
PROFIBUS DP interfaces. Synchronization with a higher-level bus cycle clock is not
necessary.
● The PROFINET IO interface is configured as a Sync-Slave:
In this case, this interface supplies the basic cycle clock for the SIMOTION device.
– If a cycle clock is available at this interface, the SIMOTION device automatically
synchronizes itself with this cycle clock.
If PROFIBUS DP interfaces of the SIMOTION device have been configured as
isochronous DP master, their synchronization must be initiated by the user himself.
See the following section, "Synchronization in PROFINET IO".
– If no cycle clock is available at this interface (e.g. if the associated sync master fails),
a replacement cycle clock of the same size is generated.
Note
Only a single cycle clock source is permitted on a SIMOTION device. For this reason:
If a SIMOTION device contains a PROFINET IO interface, a PROFIBUS DP interface can no
longer be operated as an isochronous DP slave.
Basic Functions for Modular Machines
Function Manual, 02/2012
27
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.1 General information about synchronizing a SIMOTION device with the bus cycle clock
The following figure shows cycle clock generation in PROFINET IO:
3//
%DVLFFORFNF\FOH
6,027,21
NHUQHO
&ORFNF\FOHV
6HUYR
,32,32
731
352),1(7,2
6\QFVODYH
,57+LJK3HUIRUPDQFH
'3
'3PDVWHU
'3
'3PDVWHU
'3,QWHJUDWHG
'3PDVWHU
7'3
7'3
7'3,17
6,1$0,&6,QWHJUDWHG
'3VODYH
+LJKHUOHYHO
EXVF\FOHFORFN
352),1(7,2
GHYLFH
Figure 2-2
'3VODYH
'3VODYH
Cycle clock generation in a SIMOTION device in PROFINET IO
Basic Functions for Modular Machines
28
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.1 General information about synchronizing a SIMOTION device with the bus cycle clock
Synchronization in PROFINET IO
If the PROFINET IO interface has been configured as a Sync-Slave, the SIMOTION device
must be synchronized with the higher-level bus cycle clock. The synchronization behavior
depends on whether the PROFIBUS DP interfaces of the SIMOTION device have been
configured as isochronous DP master:
● None of the PROFIBUS DP interfaces have been configured as isochronous DP master
for the lower-level drives:
The device is automatically synchronized with the higher-level bus cycle clock.
After successful synchronization, the cycle clocks of the device (e.g. Servo, IPO, IPO2)
and the programs running in the SynchronousTasks are both synchronous with the
higher-level bus cycle clock.
See Synchronizing a SIMOTION device without an isochronous DP master interface
(Page 30).
● At least one of the PROFIBUS DP interfaces is configured as isochronous DP master for
lower-level drives:
Synchronization of the device and the isochronous DP master interfaces is different:
– The device (not including the DP master interfaces) is automatically synchronized with
the higher-level bus cycle clock.
After successful synchronization, the cycle clocks of the device (e.g. Servo, IPO,
IPO2) and the programs running in the SynchronousTasks are both synchronous with
the higher-level bus cycle clock.
– Synchronization of the isochronous DP master interfaces with the higher-level bus
cycle clock must be activated by users themselves using the
_synchronizeDpInterfaces system function. The user can thereby determine the time
of synchronization and take suitable precautions, such as deactivating affected DP
slaves, to avoid system failures caused by the synchronization process.
Only after successful synchronization has been completed are the isochronous DP
master interfaces synchronous with the higher-level bus cycle clock.
See Synchronizing a SIMOTION device with an isochronous DP master interface
(Page 33).
NOTICE
A phase jump occurs during synchronization of an isochronous DP master interface with a
higher-level bus cycle clock. This can lead to failures in the connected DP slaves
(e.g. SINAMICS drives).
You should, therefore, deactivate the DP slaves concerned and the technology objects
assigned to them before synchronizing drives that are already in operation. Once
synchronization has been successfully completed, you can reactivate the DP slaves
concerned and their assigned technology objects. See Activating and deactivating
components and technology objects (Page 53).
Basic Functions for Modular Machines
Function Manual, 02/2012
29
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.2 Synchronizing a SIMOTION device without an isochronous DP master interface
Note
In SIMOTION D4xx devices, the interface "DP Integrated" is always configured as the
isochronous DP master interface.
Therefore, if these devices are connected to a higher-level isochronous master, they must
always be synchronized.
NOTICE
Note that if SINAMICS drives with Safety Integrated are connected to the isochronous DP
master interface of a SIMOTION device and the actuation is performed via PROFIsafe:
A safety error in the drive which cannot be acknowledged can be triggered during the
synchronization of the SIMOTION device with the higher-level bus cycle clock. This error
occurs if the phase jump caused by the synchronization occurs while the safety functionality
in the drive is booting up.
Therefore, the synchronization must not be performed until after Safety Integrated in the
drive is ready. In order to achieve this, use the user-controlled synchronization, see
synchronization of a SIMOTION device with isochronous DP master interface (Page 33).
Wait with the call of the system function _synchronizeDPInterfaces as long as:
1. Until the drives have powered up (system variable cyclicInterface of the axis = ACTIVE).
And
2. Until Safety Integrated in the drives is ready (additional 250 ms = 10 * MAX (p9500)).
2.2
Synchronizing a SIMOTION device without an isochronous DP
master interface
Prerequisites
1. None of the PROFIBUS interfaces in the SIMOTION device have been configured as an
isochronous DP master for lower-level drives:
This is the case e.g. in SIMOTION C230-2, C240 or P350 devices if no lower-level
isochronous drives are connected via PROFIBUS DP.
2. An interface receives a higher-level bus cycle clock and is configured accordingly, i.e. as
DP slave in PROFIBUS DP or as sync slave in PROFINET IO.
Basic Functions for Modular Machines
30
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.2 Synchronizing a SIMOTION device without an isochronous DP master interface
Example configuration
The following example configuration is used:
6,027,21B
0DVWHU
LVRFKURQRXV
6,027,21B
6ODYH
'3PDVWHU
QRWLVRFKURQRXV
,2
'3VODYH
352),%86VXEQHW
Figure 2-3
Example configuration for synchronizing a SIMOTION device with the higher-level bus cycle clock without an
isochronous DP master interface
Synchronization sequence
As soon as a higher-level bus cycle clock is available at the corresponding interface (DP
slave in PROFIBUS DP, sync slave in PROFINET IO) of the SIMOTION_2 device, the
interface automatically synchronizes itself with the defined bus cycle clock.
Note
Only a single cycle clock source is permitted on a SIMOTION device. For this reason:
If a SIMOTION device contains a PROFINET IO interface, a PROFIBUS DP interface can no
longer be operated as an isochronous DP slave.
After successful synchronization, the device cycle clocks (e.g. Servo, IPO, IPO2) and the
programs running in the SynchronousTasks are both synchronized with the received bus
cycle clock.
Should the bus cycle clock fail, a replacement cycle clock will be generated with the same
cycle time.
The current synchronization state is shown in the stateOfDpSlaveSynchronization system
variable. You can, for example, evaluate the synchronization state in the user program so
that in the event of a synchronization failure, execution of program sections that assume
synchronization would be prevented.
Basic Functions for Modular Machines
Function Manual, 02/2012
31
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.2 Synchronizing a SIMOTION device without an isochronous DP master interface
In addition, you can activate the alarms for initiating the PeripheralFaultTask. To do this, call
up the _enableDpInterfaceSynchronizationMode system function using the parameter
dpInterfaceSyncMode = SLAVE_ALARMMESSAGES_1:
● The _SC_DP_SLAVE_SYNCHRONIZED ( = 209) and
_SC_DP_SLAVE_NOT_SYNCHRONIZED ( = 210) events then initiate the
PeripheralFaultTask and can be queried in their TaskStartInfo (TSI#InterruptId).
● The modeOfDpInterfaceSynchronization system variable is set to
SLAVE_ALARMMESSAGES_1.
See also the status diagram in the figure below.
The syntax of this system function is described in detail in the "System Functions/Variables
Devices" List Manual (reference list) and in the online help (see index).
NOTICE
If the alarms for initiating the PeripheralFaultTask are activated, they must be activated in
the execution system and an appropriate program assigned. Otherwise the SIMOTION
device enters the STOP operating mode when this event occurs.
Status diagram
For a SIMOTION device without an isochronous DP master interface, the status diagram in
the figure below describes:
● Both synchronization states
● The values of the corresponding system variables
● The state transitions and the associated initiated alarms (TDI#InterruptId), provided they
are activated.
6,027,21GHYLFHDV\QFKURQRXV
6\VWHPYDULDEOHVWDWH2I'S6ODYH6\QFKURQL]DWLRQ '3B6/$9(B127B6<1&+521,=('
+LJKHUOHYHOEXVF\FOHFORFNGHWHFWHG
76,,QWHUUXSW,G B6&B'3B6/$9(B6<1&+521,=('
)DLOXUHRIKLJKHUOHYHOEXVF\FOHFORFN
76,,QWHUUXSW,G B6&B'3B6/$9(B127B6<1&+521,=('
6,027,21GHYLFHV\QFKURQRXV
6\VWHPYDULDEOHVWDWH2I'S6ODYH6\QFKURQL]DWLRQ '3B6/$9(B6<1&+521,=('
Figure 2-4
Status diagram for synchronization of a SIMOTION device without an isochronous DP master interface
Basic Functions for Modular Machines
32
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.3 Synchronization of a SIMOTION device with an isochronous DP master interface
2.3
Synchronization of a SIMOTION device with an isochronous DP
master interface
Prerequisites
1. At least one PROFIBUS interface in the SIMOTION device has been configured as an
isochronous DP master.
This prerequisite is always met with SIMOTION D4xx devices; the interface "DP
Integrated" is always configured as an isochronous DP master interface.
2. An interface receives a higher-level bus cycle clock and is configured accordingly, i.e. as
a DP slave in PROFIBUS DP or as a sync slave in PROFIBUS IO.
3. The same bus cycle clock must be configured for all isochronously operated interfaces.
Example configuration
The following figures show example configurations for synchronization of a SIMOTION
device which has an isochronous DP master interface with a higher-level bus cycle clock.
The synchronization behavior depends on whether a PROFIBUS DP subnet or a PROFINET
IO subnet supplies the higher-level bus cycle clock.
6,027,21B
'3PDVWHU
LVRFKURQRXV
6,027,21B
'3VODYH
'HILQHVWKHF\FOHFORFNIRUWKHV\VWHP
'3PDVWHU
LVRFKURQRXV
'ULYH
'3VODYH
352),%86'3VXEQHW
352),%86'3VXEQHW
Figure 2-5
Example configuration for synchronization of a SIMOTION device which has an isochronous DP master
interface with a higher-level PROFIBUS DP cycle clock
Basic Functions for Modular Machines
Function Manual, 02/2012
33
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.3 Synchronization of a SIMOTION device with an isochronous DP master interface
6,027,21B
352),1(7,2
V\QFPDVWHU
6,027,21B
352),1(7,2
V\QFVODYH
'HILQHVWKHF\FOHFORFNIRUWKHV\VWHP
'3PDVWHU
LVRFKURQRXV
'ULYH
'3VODYH
352),1(7,2VXEQHW
352),%86'3VXEQHW
Figure 2-6
Sample configuration for synchronization of a SIMOTION device which has an isochronous DP master
interface with a higher-level PROFINET IO cycle clock
Synchronization sequence
Following a configured/programmed system startup, the SIMOTION_2 device with the
interface configured as an isochronous DP master (with drives as DP slaves) is to be
synchronized with the higher-level bus cycle clock determined by the SIMOTION_1 device.
The interface which receives the higher-level bus cycle clock (DP slave in PROFIBUS DP,
sync slave in PROFINET IO) automatically synchronizes itself with the defined bus cycle
clock.
Synchronization of the isochronous DP master interface on the SIMOTION_2 device with the
higher-level bus cycle clock must be activated by users themselves using a system function.
The user can thereby determine the time of synchronization and take suitable precautions,
such as deactivating affected DP slaves, to avoid system failures caused by the
synchronization process. See following sections: "Procedure for automatic synchronization"
and "Procedure for user-controlled synchronization".
Preferably, synchronization should be started while the SIMOTION devices are ramping up
(in the StartupTask), before the drives start to move.
Only after successful synchronization has been completed are the isochronous DP master
interfaces synchronous with the higher-level bus cycle clock.
For synchronization of the internal cycle clocks of the SIMOTION device and the programs
running in the SynchronousTasks, see section: "Synchronization of the cycle clocks of the
SIMOTION device".
Basic Functions for Modular Machines
34
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.3 Synchronization of a SIMOTION device with an isochronous DP master interface
Synchronization of the cycle clocks of the SIMOTION device
The following differences apply as regards synchronization of the SIMOTION device - which
features internal cycle clocks (e.g. Servo, IPO, IPO2) - with the programs running in the
SynchronousTasks:
● In PROFIBUS DP:
Synchronization of the SIMOTION device and synchronization of the isochronous DP
master interface run at the same time.
Therefore, the following applies to both the device cycle clocks (e.g. Servo, IPO, IPO2)
and the programs running in SynchronousTasks: Only after successful synchronization of
the isochronous DP master interfaces are they synchronous with the higher-level bus
cycle clock (see also Cycle clock generation and synchronization in PROFIBUS DP
(Page 24)).
● For PROFINET IO:
Synchronization of the SIMOTION device with the higher-level bus cycle clock is
automatic.
Therefore, the following applies to both the device cycle clocks (e.g. Servo, IPO, IPO2)
and the programs running in SynchronousTasks: They are already synchronous with the
received bus cycle clock once successful automatic synchronization of the interface
receiving the higher-level bus cycle clock is complete (see also Cycle clock generation
and synchronization in PROFINET IO (Page 26)).
Basic Functions for Modular Machines
Function Manual, 02/2012
35
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.3 Synchronization of a SIMOTION device with an isochronous DP master interface
Procedure for automatic synchronization
So that the interface configured as an isochronous DP master in the SIMOTION_2 device
automatically synchronizes itself with the higher-level bus cycle clock, you should proceed as
follows:
1. If drives (e.g. SINAMICS drives) are already in operation:
Deactivate the DP slaves concerned and their assigned technology objects (see
Activating and deactivating components and technology objects (Page 53)).
2. Start the automatic synchronization. To do this, call the
_enableDpInterfaceSynchronizationMode system function using the parameter
dpInterfaceSyncMode = AUTOMATIC_INTERFACE_SYNCHRONIZATION.
– The modeOfDpInterfaceSynchronization system variable will be set to
AUTOMATIC_INTERFACE_SYNCHRONIZATION.
– If a higher-level bus cycle clock is recognized at the corresponding interface, the
interface configured as an isochronous DP master will be automatically synchronized.
You can find out about the current synchronization state using the
stateOfDpInterfaceSynchronization system variable.
– The alarm for initiating the PeripheralFaultTask on loss of synchronization is activated.
The syntax of this system function is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see
index).
3. Once synchronization has been successfully completed, activate the DP slaves which
you previously deactivated and their assigned technology objects (see Activating and
deactivating components and technology objects (Page 53)).
The synchronized state continues to apply unless it is disrupted, e.g. if the constant bus
cycle clock should fail.
The event _SC_DP_SYNCHRONIZATION_LOST ( = 208) initiates the
PeripheralFaultTask and can be queried in the associated TaskStartInfo
(TSI#InterruptId).
NOTICE
If the alarms for initiating the PeripheralFaultTask are activated, they must be activated in
the execution system and an appropriate program assigned. Otherwise the SIMOTION
device enters the STOP operating mode when this event occurs.
Note
Preferably, automatic synchronization should be started while the SIMOTION devices are
ramping up (in the StartupTask), before the drives start to move.
Basic Functions for Modular Machines
36
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.3 Synchronization of a SIMOTION device with an isochronous DP master interface
Procedure for user-controlled synchronization
In order to synchronize the interfaces configured as isochronous DP masters in the
SIMOTION_2 device with the higher-level bus cycle clock, you should proceed as follows:
1. First, you must activate the corresponding alarms for initiating the PeripheralFaultTask.
To do this, call up the _enableDpInterfaceSynchronizationMode system function using the
parameter dpInterfaceSyncMode = MASTER_SLAVE_ALARMMESSAGES_1.
– The events _SC_DP_CLOCK_DETECTED ( = 207) and
_SC_DP_SYNCHRONIZATION_LOST ( = 208) then initiate the PeripheralFaultTask
and can be queried in their TaskStartInfo (TSI#InterruptId).
– The modeOfDpInterfaceSynchronization system variable is set to
MASTER_SLAVE_ALARMMESSAGES_1.
The syntax of this system function is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see
index).
2. If a higher-level bus cycle clock is recognized at the corresponding interface (this event is
signaled by TSI#InterruptId = _SC_DP_CLOCK_DETECTED ( = 207)), synchronization
can be carried out:
– Deactivate all DP slaves and assigned technology objects that are connected to the
isochronous DP master interfaces and in which faults could occur during a phase jump
(e.g. SINAMICS drives) (see Activating and deactivating components and technology
objects (Page 53)).
– Call the _synchronizeDpInterfaces system function.
You can find out about the current synchronization state using the
stateOfDpInterfaceSynchronization system variable.
– Once synchronization has been successfully completed, activate the DP slaves which
you previously deactivated and their assigned technology objects (see Activating and
deactivating components and technology objects (Page 53)).
The synchronized state continues to apply unless it is disrupted, e.g. if the constant bus
cycle clock should fail.
The syntax of this system function is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see
index).
NOTICE
If the alarms for initiating the PeripheralFaultTask are activated, they must be activated in
the execution system and an appropriate program assigned. Otherwise the SIMOTION
device enters the STOP operating mode when this event occurs.
Status diagram of user-controlled synchronization
The status diagram in the figure below describes the fundamental procedure for
synchronizing isochronous DP master interfaces in a SIMOTION device with a higher-level
bus cycle clock.
Basic Functions for Modular Machines
Function Manual, 02/2012
37
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.3 Synchronization of a SIMOTION device with an isochronous DP master interface
,1,7
5XQWKURXJKDWHDFK6723581WUDQVLWLRQ
4XHU\RIWKHV\VWHPYDULDEOH
VWDWH2I'S,QWHUIDFH6\QFKURQL]DWLRQ
7UDQVLWLRQWRWKHPRGHLQDFFRUGDQFHZLWKWKHV\VWHPYDULDEOHVWDWH2I'S,QWHUIDFH6\QFKURQL]DWLRQ
:$,7B)25B'3B&/2&.
6\VWHPYDULDEOH
VWDWH2I'S,QWHUIDFH6\QFKURQL]DWLRQ :$,7B)25B'3B&/2&.
&RQVWDQWEXVF\FOHGHWHFWHG76,,QWHUUXSW,G B6&B'3B&/2&.B'(7(&7('
'3B&/2&.B'(7(&7('
6\VWHPYDULDEOH
VWDWH2I'S,QWHUIDFH6\QFKURQL]DWLRQ '3B&/2&.B'(7(&7('
8VHUFDQGHDFWLYDWHVODYHV
&DOORIV\VWHPIXQFWLRQBV\QFKURQL]H'S,QWHUIDFHV
5HWXUQYDOXH 5HWXUQYDOXH ))))[[[
'3B,17(5)$&(6B6<1&+521,=('
6\VWHPYDULDEOH
VWDWH2I'S,QWHUIDFH6\QFKURQL]DWLRQ
'3B,17(5)$&(6B6<1&+521,=('
8VHUFDQDFWLYDWHVODYHV
6\QFKURQL]DWLRQORVW76,,QWHUUXSW,G B6&B'3B6<1&+521,=$7,21B/267
Figure 2-7
Status diagram for user-controlled synchronization of an isochronous DP master interface with a higher-level
bus cycle clock
Basic Functions for Modular Machines
38
Function Manual, 02/2012
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.4 Behavior in the STOP and RUN operating modes
2.4
Behavior in the STOP and RUN operating modes
The SIMOTION device exhibits the following behavior in the operating modes and in
transition between them. Observe this information when configuring/programming
synchronization variants in accordance with Synchronizing a SIMOTION device without an
isochronous DP master interface (Page 30) and Synchronization of a SIMOTION device with
an isochronous DP master interface (Page 33).
Behavior in the STOP operating mode
If the interfaces of a SIMOTION device are not consecutively synchronized, the input cycle
clock is monitored and a signal generated that leads to the _SC_DP_CLOCK_DETECTED
event in the RUN operating mode.
If the interfaces are consecutively synchronized, the synchronicity and the input cycle clock
are monitored. If the input cycle clock fails, a signal will be generated that results in the
_SC_DP_SYNCHRONIZATION_LOST event in the RUN operating mode.
The state of the DP slaves does not change. An activated slave remains activated and a
deactivated slave remains deactivated.
Behavior during the transition from STOP operating mode to RUN operating mode
The system variables are updated.
Processing of the user program will be delayed until (for example) any internal processing of
the system functions _activateDpSlave, _deactivateDpSlave, or _getStateOfDpSlave (see
Activating and deactivating nodes on the PROFIBUS or PROFINET IO (Page 53)) which is
still running has been completed. There is no separate time monitoring.
Behavior in the RUN operating mode
In the RUN operating mode, the events result in the PeripheralFaultTask being started with
the associated TSI#InterruptId. System functions can be called up in the user program or in
the PeripheralFaultTask.
The user can use the stateOfDpInterfaceSynchronization system variable and the
_getStateOfDpSlave system function to determine the current system state and restart its
application.
Behavior during the transition from RUN operating mode to STOP operating mode
The transition can be made at any time. It is possible that slaves may have been started
already or even deactivated. Interfaces can be synchronous or asynchronous.
All called system functions end in a defined state:
● The _synchronizeDpInterfaces system function will be cancelled.
● The system functions _activateDpSlave, _deactivateDpSlave, and _getStateOfDpSlave
will undergo further internal processing.
Basic Functions for Modular Machines
Function Manual, 02/2012
39
Synchronizing SIMOTION devices with a higher-level bus cycle clock
2.4 Behavior in the STOP and RUN operating modes
Basic Functions for Modular Machines
40
Function Manual, 02/2012
Setting the communication addresses via the user
program
3
Nodes are clearly identified within a communication network by means of, for example
● The PROFIBUS address of the interface in PROFIBUS DP
● The device name (NameOfStation) in PROFINET IO
● The IP address of the interface on Ethernet
These communication addresses are set during configuration with the help of the
engineering software (e.g. SIMOTION SCOUT). They can be changed later by a user
program and customized according to requirements.
The address to be set can be determined in the user program in various ways, e.g.:
● Reading in and evaluating a slot coding
● Evaluating a program variable (which can be changed, for example, by a user input on
the HMI device)
NOTICE
In a communication network where PROFIsafe is also used, communication addresses
may not be changed in the user program.
Note
You will find additional information on PROFIBUS and PROFINET in the SIMOTION
Communication System Manual.
Basic Functions for Modular Machines
Function Manual, 02/2012
41
Setting the communication addresses via the user program
3.1 Setting the PROFIBUS address
3.1
Setting the PROFIBUS address
Using system functions, the user program can set and activate the required address (node
number) for the SIMOTION device on PROFIBUS DP. The activation results in a restart of
SIMOTION.
It is only possible to change the address at the interface when this is set to the DP slave
operating mode.
NOTICE
After changing the configured address, it is no longer possible to route via this interface into
other devices or interfaces (see "Routing in the communication network" in the section titled
System behavior (Page 44)).
If it must still be possible to route via this interface into other devices or interfaces, the
Activating a configuration (Page 85) functionality should be used instead.
3.1.1
System functions
● _getActiveDpSlaveAddress
This function is used to determine the active DP address (node number) of a DP interface
on a SIMOTION device.
● _setDpSlaveAddress
This function is used to set a new DP address (node number) for a DP interface on a
SIMOTION device.
● _activateDpSlaveAddress
This function is used to activate the DP address (node number) for a DP interface on a
SIMOTION device.
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
Example for reading, setting, and activating the DP slave address
// Variable declaration
VAR
// Diagnostics address of the PROFIBUS interface
logAddrDpAdapter : DINT := 1023;
// PROFIBUS address of the local slot
locDpSlaveAddress : SINT := 4;
// Variables for the return values
retDpSlaveAddress : structRetDpSlaveAddress;
locRetVal : DINT;
neededSetDpAddress : DINT := 0;
END_VAR
// Read active DP slave address
Basic Functions for Modular Machines
42
Function Manual, 02/2012
Setting the communication addresses via the user program
3.1 Setting the PROFIBUS address
Example for reading, setting, and activating the DP slave address
retDpSlaveAddress := _getActiveDpSlaveAddress (
logicalAddressCommunicationAdapter := logAddrDpAdapter
// Diagnostics address of the PROFIBUS interface
);
IF (0 = retDpSlaveAddress.functionResult) THEN
// Check if new DP slave address is necessary
IF (retDpSlaveAddress.dpSlaveAddress <> locDpSlaveAddress) THEN
// Need to set new DP slave address
neededSetDpAddress := 1;
ELSE
; //User-defined error response
END_IF;
END_IF;
IF (1 = neededSetDpAddress) THEN
// Set new DP slave address
locRetVal := _setDpSlaveAddress (
logicalAddressCommunicationAdapter := logAddrDpAdapter,
// Diagnostics address of the PROFIBUS interface
dpSlaveAddress := locDpSlaveAddress
// PROFIBUS address of the local slot
);
IF (0 = locRetVal) THEN
locRetVal := _activateDpSlaveAddress (
logicalAddressCommunicationAdapter := logAddrDpAdapter
// Diagnostics address of the PROFIBUS interface
);
ELSE
; // User-defined error response
END_IF;
END_IF;
Basic Functions for Modular Machines
Function Manual, 02/2012
43
Setting the communication addresses via the user program
3.1 Setting the PROFIBUS address
3.1.2
System behavior
Configuring the DP slave interface
The following should be noted when configuring the SIMOTION device interface that has
been configured as a DP slave:
The configured quantity structure of the data to be exchanged must be identical in both the
DP slave and the higher-level DP master.
Only then can the interface function as a DP slave to the higher-level DP master.
Routing in the communication network
The specific routing information is stored in each device corresponding to the communication
addresses configured there. When the address is changed, the appropriate routing
information no longer remains in the device.
6,027,21B
'3
6&287
23+0,
'3
PDVWHU
GULYHB
'3VODYH
GULYHB
'3VODYH
6,027,21B
'3
VODYH
'3
PDVWHU
GULYHB
'3VODYH
Figure 3-1
GULYHB
'3VODYH
Example: Routing in the communication network
In SIMOTION_10, the DP slave address of the DP2 interface is changed in the user
program. Routing from the OP or SCOUT via SIMOTION_1 (DP2/DP1) to SIMOTION_10
(DP2/DP1) and to the drives (drive_11, drive_12, etc.) is then no longer possible. No further
control, loading, or monitoring actions are possible from the SCOUT.
Communication networks with PROFIsafe
In a communication network where PROFIsafe is also used, communication addresses may
not be changed in the user program.
Basic Functions for Modular Machines
44
Function Manual, 02/2012
Setting the communication addresses via the user program
3.2 Topology detection in PROFINET IO
3.2
Topology detection in PROFINET IO
In PROFINET IO, one port belonging to a node is connected to exactly one port belonging to
another node. A SIMOTION device cyclically identifies the connected neighbors for all the
local ports, regardless of the configured transfer procedure.
Note
No topology detection is possible in PROFIBUS DP due to the other existing bus topology.
The result for each local port can be read out using the _getPnInterfacePortNeighbour
system function. As a result, you receive the following data on the connected neighbor node,
which allows for clear identification of this node:
● The device name (NameOfStation), unique within the project, of the connected
PROFINET IO node
● The number of the connected port (value range 1 to 255)
● The number of the slot (identification of the PROFINET IO interface) containing the
connected port (value range 0 to 65,535)
Exceptions:
● If no PROFINET IO node is connected to the local port, you receive the following return
values:
– As a device name: An empty string
– And as a number for the port and the slot: 16#FFFFFFFF in each case
● If the connected PROFINET IO node only contains a single PROFINET IO interface,
16#FFFFFFFF will be returned as the number of the slot.
● If the connected PROFINET IO node has not yet been assigned a device name
(NameOfStation) which is unique within the project, the return value for the device name
will comprise:
– PROFINET IO node is not a SIMOTION device: The hardware address (MAC
address) will be returned. The MAC address will be shown in the usual notation
xx:xx:xx:xx:xx:xx, where x is a hexadecimal number [0 to 9, A to F].
– PROFINET IO node is a SIMOTION device: A character string containing the device
type and the MAC address hexadecimal numbers will be returned, e.g. SIMOTION-D08-00-06-73-6C-E6.
The syntax of this system function is described in detail in the List Manual (reference list) of
the SIMOTION devices and in the online help (see index).
For information about the syntax of the device name (NameOfStation), see Setting the
device name (NameOfStation) of an IO device on PROFINET IO (Page 47).
The figure below displays an example for a topology in PROFINET IO. Topology detection is
carried out on the SIMOTION devices for various ports using the
_getPnInterfacePortNeighbour system function. The result is given in the table.
Basic Functions for Modular Machines
Function Manual, 02/2012
45
Setting the communication addresses via the user program
3.2 Topology detection in PROFINET IO
6ZLWFK
1DPH2I6WDWLRQ
SQVZLWFKQ
,QWHUIDFH
6ORW1XPEHU
3RUW
3RUW
3RUW
3RUW
3RUW
3RUW
3RUW
3RUW
6,027,21B
1DPH2I6WDWLRQ
GHYLFHQ
Figure 3-2
,QWHUIDFH
6ORW1XPEHU
3RUW
3RUW
3RUW
3RUW
3RUW
6,027,21B
1DPH2I6WDWLRQ
GHYLFHQ
3RUW
3RUW
3RUW
3RUW
3RUW
3RUW
3RUW
6,027,21B
1DPH2I6WDWLRQ
GHYLFHQ
Example of a topology in PROFINET IO
Table 3- 1
Topology detection (call up of the function _getPnInterfacePortNeighbour) for the
topology example in the previous figure
Topology detection at
device (port)
Result of the topology detection (components of the return value)
nameOfStation
pnPortNumber
pnSlotNumber
SIMOTION_1 (Port 1)
''
-1
-1
SIMOTION_1 (Port 4)
'pn-switch.n1'
1
0
SIMOTION_2 (Port 1)
'pn-switch.n1'
2
1
SIMOTION_2 (Port 4)
'device.n3'
3
-1
SIMOTION_3 (Port 1)
''
-1
-1
SIMOTION_3 (Port 3)
'device.n2'
4
-1
Basic Functions for Modular Machines
46
Function Manual, 02/2012
Setting the communication addresses via the user program
3.3 Setting the device name (NameOfStation) of an IO device on PROFINET IO
3.3
Setting the device name (NameOfStation) of an IO device on
PROFINET IO
The user program can change and activate the device name (NameOfStation) for the
SIMOTION device on the PROFINET IO using system functions. The activation results in a
restart of SIMOTION.
NOTICE
After changing the configured device name (NameOfStation), the following should be
noted:
• It is no longer possible to route via this interface into other devices or interfaces (see
Routing in the communication network in the section titled System behavior (Page 44)).
• Controller-controller data exchange broadcast is no longer possible.
If these functionalities are still required, follow Activating a configuration (Page 85) instead.
Syntax of the device name (NameOfStation)
The device name (NameOfStation) must adhere to the following conventions:
● Permissible length: 1 to 127 characters
● Organization using periods "." is permissible in several labels; length of a single label: 1 to
63 characters
● Characters permitted within a label:
– Letters "A" to "Z" and "a" to "z".
– Numbers "0" to "9" (not at the beginning of the label)
– Special character hyphen "-" (not at the beginning or end of a label)
– Other special characters (such as umlauts, blank spaces, brackets, underscores) are
not permitted.
● The following designations are not permitted for device names:
– Identifiers that start with "port-xyz-" (x, y, z = 0 … 9),
– Identifiers of the form n.n.n.n (n = 0 … 999).
NOTICE
Device names which do not satisfy the general rules for identifiers (i.e. containing hyphens
or periods) must be enclosed in double inverted commas (", ASCII code 22) for use in
SIMOTION SCOUT (e.g. in the programming languages).
Basic Functions for Modular Machines
Function Manual, 02/2012
47
Setting the communication addresses via the user program
3.3 Setting the device name (NameOfStation) of an IO device on PROFINET IO
3.3.1
System functions
● _getActiveNameOfStation
You can use this function to determine the active device name (NameOfStation) of a
PROFINET IO interface on the SIMOTION device.
If the PROFINET IO interface has not yet been assigned a device name (NameOfStation)
which is unique within the project, a character string containing the device type and the
MAC address hexadecimal numbers will be returned, e.g. SIMOTION-D-08-00-06-73-6CE6.
● _setNameOfStation
You can use this function to set a new device name (NameOfStation) for a PROFINET IO
interface on the SIMOTION device.
● _activateNameOfStation
You can use this function to activate the device name (NameOfStation) of a PROFINET
IO interface on the SIMOTION device.
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
Example for reading, setting, and activating the device name
(NameOfStation), synchronous call
// Program assigned to a MotionTask
// Variable declaration
VAR
// Diagnostics address of the PROFINET IO interface
logAddrPnAdapter : DINT := 1023;
// Device name of the PROFINET IO interface
locNameOfStation : STRING[240];
// Variables for the return values
retNameOfStation : StructRetDeviceNameOfStation;
locRetVal : DINT;
neededSetNameOfStation : DINT := 0;
locCommandId : CommandIdType;
END_VAR
// Read active device name
retNameOfStation := _getActiveNameOfStation (
logicalAddressPnInterface := logAddrPnAdapter,
// Diagnostics address of the PROFINET IO interface
requestMode := REQUEST_TRUE,
// Function will be executed
commandId := locCommandId,
nextCommand := WHEN_COMMAND_DONE
// Synchronous call; wait until the function has terminated
);
IF (0 = retNameOfStation.functionResult) THEN
// Check if new device name is necessary
IF (retNameOfStation.nameOfStation <> locNameOfStation) THEN
Basic Functions for Modular Machines
48
Function Manual, 02/2012
Setting the communication addresses via the user program
3.3 Setting the device name (NameOfStation) of an IO device on PROFINET IO
Example for reading, setting, and activating the device name
(NameOfStation), synchronous call
// Need to create a new device name
neededSetNameOfStation := 1;
ELSE
; // User-defined error response
END_IF;
END_IF;
IF (1 = neededSetNameOfStation) THEN
// Set new device name
locRetVal := _setNameOfStation (
logicalAddressPnInterface := logAddrPnAdapter,
// Diagnostics address of the PROFINET IO interface
nameOfStation := locNameOfStation,
// Device name of the PROFINET IO interface
requestMode := REQUEST_TRUE,
// Function will be executed
commandId := locCommandId,
nextCommand := WHEN_COMMAND_DONE
// Synchronous call
);
IF (0 = locRetVal) THEN
locRetVal := _activateNameOfStation (
logicalAddressPnInterface := logAddrPnAdapter
// Diagnostics address of the PROFIBUS interface
);
ELSE
; // User-defined error response
END_IF;
END_IF;
3.3.2
System behavior
Configuring the PROFINET IO interface
The following should be noted when configuring the PROFINET IO interface of the
SIMOTION device (IO device): The configured quantity structure of the data to be
exchanged must be identical in both the IO device and the higher-level IO controller.
Only then can this interface function as an IO device to the higher-level IO controller.
Routing in the communication network
The specific routing information is stored in each device corresponding to the communication
addresses configured there. After the device name (NameOfStation) has been changed, no
further appropriate routing information remains in the device.
Basic Functions for Modular Machines
Function Manual, 02/2012
49
Setting the communication addresses via the user program
3.4 Setting the IP address (on Ethernet)
Data exchange broadcast
Controller-controller data exchange broadcast is no longer possible. The data exchange
broadcast partner can no longer be found after the device name (NameOfStation) has been
changed.
Communication networks with PROFIsafe
In a communication network where PROFIsafe is also used, the device names
(NameOfStation) may not be changed in the user program.
3.4
Setting the IP address (on Ethernet)
The IP configurations (IP address, subnet mask, gateway address) can be read in, set, or
changed using the system functions _setIpConfig and _getIpConfig. SIMOTION remains in
the RUN operating mode.
System functions
● _getIpConfig
You can use this function to determine the IP configuration of an Ethernet interface; you
can specify the interface by inputting the corresponding enumeration value (IE_01,
IE_02).
● _setIpConfig
You can use this function to set the IP configuration of an Ethernet interface; you can
specify the interface by inputting the corresponding enumeration value (IE_01, IE_02).
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
Note
The factory settings of the IP configurations (e.g. default IP address) vary from one
SIMOTION device to the next. Please check the relevant value in the Commissioning and
Hardware Installation Manual or in the Operating Instructions of the respective SIMOTION
device.
Basic Functions for Modular Machines
50
Function Manual, 02/2012
Setting the communication addresses via the user program
3.4 Setting the IP address (on Ethernet)
The following example demonstrates the setting of an IP address.
Example for setting the IP address
// Variable declaration
VAR
ipRead : ARRAY [1..2] OF StructRetIpConfig;
setIpAddress : ARRAY [0..5] OF USINT;
setIpSubnet : ARRAY [0..5] OF USINT;
setIpGateway : ARRAY [0..5] OF USINT;
retUdint : UDINT;
retActivateConf : StructRetConfiguration;
(* IP address of the configuration will be read from the input with
address 0. *)
ip_conf_id AT %IB0 : USINT;
END_VAR
// Read the current data of the Ethernet interfaces
ipRead[1] := _getIpConfig (
ethernetInterface:= IE_01 );
ipRead[2] := _getIpConfig (
ethernetInterface:= IE_02
);
// Change of the Ethernet interface IE_01.
// Check whether a change is necessary.
IF ( ip_conf_id <> ipRead[1].ipAddress[3] ) THEN
// Make the data to be changed available
setIpAddress := ipRead[1].ipAddress;
setIpAddress[3] := ip_conf_id;
setIpSubnet := ipRead[1].subnetMask;
setIpGateway := ipRead[1].gatewayAddress;
(* Check whether the two Ethernet interfaces are different after the
subnet masks have been changed: *)
IF ( ipRead[2].subnetMask <> setIpSubnet ) THEN
// Set the data of the Ethernet interface IE_01
retUdint := _setIpConfig (
ethernetInterface := IE_01,
ipAddress := setIpAddress,
subnetMask := setIpSubnet,
gatewayAddress := setIpGateway
);
ELSE
; // No change, error response.
// Change interface IE_02 too, if necessary.
END_IF;
END_IF;
Basic Functions for Modular Machines
Function Manual, 02/2012
51
Setting the communication addresses via the user program
3.4 Setting the IP address (on Ethernet)
Basic Functions for Modular Machines
52
Function Manual, 02/2012
Activating and deactivating components and
technology objects
4
This section describes how PROFIBUS DP slaves and technology objects are activated and
deactivated.
4.1
Activating and deactivating nodes on the PROFIBUS or PROFINET
IO
The user has configured and programmed a maximum configuration. The user program
deactivates bus nodes that are not available or not required in order to achieve the following:
● The cyclic load (data exchange) between the DP master and the DP slaves (PROFIBUS)
or the controller and the IO device (PROFINET IO) is reduced.
● The processing of alarms is suppressed for deactivated nodes.
● No bus fault is signaled for PROFIBUS or PROFINET IO nodes which are not available.
● DP slaves (drives) re-synchronize with the DP cycle clock.
The user program can also activate further nodes that are required, for example, in another
production phase.
NOTICE
If the DP slave or the IO device is integrated in PROFIsafe communication (e.g. SINAMICS
with SINAMICS Safety Integrated Extended Functions): Deactivation of a bus node will
result in PROFIsafe errors with corresponding responses in the failsafe control (F-CPU). If
necessary, the control will shut down all other PROFIsafe nodes.
System functions
● _activateDpSlave (Page 54)
● _deactivateDpSlave (Page 54)
● _getStateOfSingleDpSlave (Page 63)
● _getStateOfAllDpSlaves (Page 63)
● _getStateOfAllDPStations (Page 63)
● _getStateOfDpSlave (Page 62)
● _getLogDiagnosticAddressFromDpStationAddress (Page 64)
● _getDpStationAddressFromLogDiagnosticAddress (Page 64)
● _getGeoAddressFromLogAddress (Page 64)
Basic Functions for Modular Machines
Function Manual, 02/2012
53
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
NOTICE
Technology objects are often assigned to the distributed I/O (DP slave, IO device);
therefore, please note the information in Procedure for deactivating and activating
components (Page 83).
4.1.1
System functions for activating and deactivating bus nodes
The example below shows a machine design consisting of a central unit and several
machine modules, each with several drives that communicate over PROFIBUS. This
example can also be applied to PROFINET IO in comparable form.
● Central unit (SIMOTION_1)
The PROFIBUS DP1 interface for the central unit is configured as a DP master for the
subnet dp_subnet_1. Machine modules 10 and 20 are connected to this subnet.
● Machine module 10 (SIMOTION_10)
The PROFIBUS DP2 interface for the machine module is configured as a DP slave for
the subnet dp_subnet_1.
The PROFIBUS DP1 interface for the machine module is configured as a DP master for
the subnet dp_subnet_10. The drives are connected as DP slaves to this subnet.
● Machine module 20 (SIMOTION_20)
The PROFIBUS DP2 interface for the machine module is configured as a DP slave for
the subnet dp_subnet_1.
The PROFIBUS DP1 interface for the machine module is configured as a DP master for
the subnet dp_subnet_20. The drives are connected as DP slaves to this subnet.
System functions
You can use the _deactivateDpSlave and _activateDpSlave system functions to execute the
following actions during operation:
● In the user program of the central unit: Activate or deactivate the machine modules 10
and 20.
● In the user program of the individual machine modules: Activate or deactivate the
respective drives.
You can specify the node to be deactivated or activated (DP slave or IO device) using the
logical diagnostics address for its interface; this address is unique across the project. The
functions can be used on all DP slaves or IO devices (e.g. drives, ET 200, DP standard
slaves, other stations).
Basic Functions for Modular Machines
54
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
Please also note the information relating to the status diagram (Page 57), asynchronous
calls (Page 58) and synchronous calls (Page 61).
Functions (Page 64) are available for converting a PROFIBUS address or device number for
PROFINET IO into the logical diagnostics address and vice versa.
NOTICE
The technology objects assigned to the nodes (e.g. the axes assigned to the drives) must
be activated and deactivated separately (see Activating and deactivating technology
objects (Page 74)).
Observe the correct order (see Procedure for deactivating and activating components
(Page 83)).
Basic Functions for Modular Machines
Function Manual, 02/2012
55
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
Example structure of a modular machine
&HQWUDOPRWLRQFRQWURO
6,027,21B
'3
'3
PDVWHU
23+0,
6&287
GSBVXEQHWB
'ULYH
'3VODYH
'ULYH
'3VODYH
'3DGGUHVV
ORJLFDODGGUHVV
0DFKLQHPRGXOH
6,027,21B
'3
VODYH
'3
PDVWHU
GSBVXEQHWB
'ULYH
'3VODYH
'ULYH
'3VODYH
0DFKLQHPRGXOH
6,027,21B
'3
VODYH
'3DGGUHVV
ORJLFDODGGUHVV
'3
PDVWHU
GSBVXEQHWB
GSBVXEQHWB
Figure 4-1
GSBVXEQHWB
'ULYH
'3VODYH
'ULYH
'3VODYH
'3DGGUHVV
ORJLFDODGGUHVV
Example of a modular machine with differentiation between DP address and logical diagnostics address
Basic Functions for Modular Machines
56
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
4.1.1.1
Status diagram for the functions _activateDpSlave and _deactivateDpSlave
The figure below shows the states of the system functions _activateDpSlave and
_deactivateDpSlave.
The functions can be called asynchronously and synchronously.
● With an asynchronous call (parameter nextCommand := IMMEDIATELY), the user
program is continued immediately after the start of the system function.
You must regularly query the state of the function to be able to determine when a
command has been executed in full.
The asynchronous call is required in cyclic tasks to ensure that their time monitoring
function does not start.
● With a synchronous call (parameter nextCommand : =WHEN_COMMAND_DONE), the
user program waits until the system function has been completed. The return value
directly indicates whether the function call was successful.
The synchronous call is recommended for MotionTasks.
To execute the function (e.g. activation or deactivation of a DP slave or I/O device), start this
with parameter reqActDeactGetStateMode := REQUEST_TRUE.
Start the status query of the function with parameter reqActDeactGetStateMode :=
REQUEST_FALSE. Use the same command ID as for the first call.
NOTICE
To correctly complete the function with an asynchronous call, you must call the function
with the parameter reqActDeactGetStateMode := REQUEST_FALSE as often as necessary
until you obtain 16#0000_000x as the return value or an error message.
You can execute the function only once at the same time for each bus node.
Basic Functions for Modular Machines
Function Manual, 02/2012
57
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
)RUV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B758(
)RUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B)$/6(
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B)$/6(
5HWXUQYDOXH B
5HWXUQYDOXH B[RU))))B[[[[
5HDG\LGOH
6\QFKURQRXVRUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B758(
5HWXUQYDOXH B
IRUDV\QFKURQRXVFDOORQO\
5XQQLQJ
2QO\IRUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B)$/6(
)RUV\QFKURQRXVRUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B758(
5HWXUQYDOXH B
5HWXUQYDOXH ))))B&
)XQFWLRQDOUHDG\VWDUWHG
5(48(67B758(QRWSHUPLWWHG
Return values:
16#0000_0001
// Activation successful, station recovery alarm is issued
16#0000_0002
// Deactivation successful, station failure alarm is issued
16#0000_0005
// Station already activated, station recovery alarm is not issued
16#0000_0006
// Station already deactivated, station failure alarm is not issued
16#0000_7000
// Function not active, initial call required with REQUEST_TRUE
16#0000_7001
// Function started (only for asynchronous call)
16#0000_7002
// Function active
16#FFFF_xxxx
// Function terminated with error
Figure 4-2
4.1.1.2
Status diagram of the system functions _activateDpSlave and _deactivateDpSlave
Asynchronous call for the functions _activateDpSlave and _deactivateDpSlave
The asynchronous call of the functions is required in cyclic tasks to ensure that the time
monitoring function for the task does not start.
With an asynchronous call, the user program is continued immediately after the start of the
system function. You must query the state of the function regularly to determine whether it
has been completed without errors.
Basic Functions for Modular Machines
58
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
Proceed as follows for the asynchronous call:
1. Call the following parameters to start the system function:
– reqActDeactGetStateMode := REQUEST_TRUE,
– nextCommand := IMMEDIATELY.
2. Check the return value.
– The return values 16#0000_0001, 16#0000_0002, 16#0000_0005, and 16#0000_0006
indicate that the function has been completed without errors.
– The return value 16#0000_7001 indicates that the function has been started
successfully, but has not yet been completed.
– A return value < 0 indicates that the function has been terminated with errors. You can
program error routines, depending on the return value.
3. For the state query and to check whether the system function has been completed, call
these again, but with the following parameters:
– reqActDeactGetStateMode := REQUEST_FALSE.
– nextCommand := IMMEDIATELY.
4. Check the return value:
– Return value 16#0000_7002 indicates that the function is still running.
Repeat step 3.
– A return value < 0 indicates that the function has been terminated with errors. You can
program error routines, depending on the return value.
– The return values 16#0000_0001, 6#0000_0002, 16#0000_0005, and 16#0000_0006
indicate that the function has been completed without errors.
The example program below shows the asynchronous call of the _activateDpSlave function
in the BackgroundTask.
Example program for the asynchronous call for the _activateDpSlave
function
INTERFACE
PROGRAM backGround;
VAR_GLOBAL
bgrRequestActivate
bgrResultActivate
bgrLogAddrDpSlave
bgrReqActDeactMode
bgrDpAlarmMode
bgrNextCommand
END_VAR
END_INTERFACE
:
:
:
:
:
:
DINT := 0;
DINT := 0;
DINT := 16#FFFF_FFFF;
enumReqActDeactGetStateMode := REQUEST_TRUE;
enumDeviceDpAlarmMode := SET_DP_ALARM;
enumNextCommandMode := IMMEDIATELY;
IMPLEMENTATION
PROGRAM backGround // Assigned to the BackgroundTask
VAR
retVal : DINT;
Basic Functions for Modular Machines
Function Manual, 02/2012
59
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
Example program for the asynchronous call for the _activateDpSlave
function
END_VAR
// ... Further instructions
IF ( 0 <> bgrRequestActivate ) THEN
retVal := _activateDpSlave (
logicalAddressOfDpStation := bgrLogAddrDpSlave,
reqActDeactGetStateMode := bgrReqActDeactMode,
dpAlarmMode := bgrDpAlarmMode,
nextCommand := bgrNextCommand );
CASE retVal OF
16#0000_0001: bgrRequestActivate := 0;
// Node successfully activated.
16#0000_0005: bgrRequestActivate := 0;
// Node was already activated, no alarm.
16#0000_7001: bgrReqActDeactMode := REQUEST_FALSE;
// Function started successfully
16#0000_7002: ; // Function running.
ELSE // Troubleshooting
bgrRequestActivate := 0;
END_CASE;
IF ( 0 = bgrRequestActivate ) THEN
// Function completed, prepare next call.
bgrReqActDeactMode := REQUEST_TRUE;
bgrResultActivate := retVal;
END_IF;
END_IF;
// ... Further instructions
END_PROGRAM
END_IMPLEMENTATION
Basic Functions for Modular Machines
60
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
4.1.1.3
Synchronous call for the functions _activateDpSlave and _deactivateDpSlave
The synchronous call is recommended for MotionTasks.
With a synchronous call, the user program waits until the system function has been
completed. The return value directly indicates whether the function call was successful.
Proceed as follows for the synchronous call:
1. Call the following parameters to start the system function:
– reqActDeactGetStateMode = REQUEST_TRUE,
– nextCommand = WHEN_COMMAND_DONE.
2. Check the return value:
– A return value < 0 indicates that the function has been terminated with errors. You can
program error routines, depending on the return value.
– The return values 16#0000_0001, 16#0000_0002, 16#0000_0005, and 16#0000_0006
indicate that the function has been completed without errors.
The example program below shows the synchronous call of the _activateDpSlave function in
a MotionTask.
Example program for the synchronous call for the _activateDpSlave function
INTERFACE
PROGRAM motion_1;
VAR_GLOBAL
motion_1_RequestActivate : DINT := 0;
motion_1_ResultActivate : DINT := 0;
motion_1_LogAddrDpSlave : DINT := 16#FFFF_FFFF;
END_VAR
END_INTERFACE
IMPLEMENTATION
PROGRAM motion_1 // Assigned to a MotionTask
VAR
retVal : DINT := 0;
END_VAR
// ... Further instructions
IF ( 0 <> motion_1_RequestActivate ) THEN
retVal := _activateDpSlave (
logicalAddressOfDpStation := motion_1_LogAddrDpSlave,
reqActDeactGetStateMode := REQUEST_TRUE,
dpAlarmMode := SET_DP_ALARM,
nextCommand := WHEN_COMMAND_DONE );
CASE retVal OF
16#0000_0001: motion_1_RequestActivate := 0;
// Node successfully activated.
16#0000_0005: motion_1_RequestActivate := 0;
Basic Functions for Modular Machines
Function Manual, 02/2012
61
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
Example program for the synchronous call for the _activateDpSlave function
// Node was already activated, no alarm.
ELSE // Troubleshooting
motion_1_RequestActivate := 0;
END_CASE;
IF ( 0 = motion_1_RequestActivate ) THEN
// Function completed.
motion_1_ResultActivate := retVal;
END_IF;
END_IF;
// ... Further instructions
END_PROGRAM
END_IMPLEMENTATION
4.1.2
Querying the activation state and status of the nodes (DP slaves or IO devices)
For the PROFIBUS and PROFINET IO nodes (DP slaves, IO devices) you can:
● Query the activation state using system functions (Page 62)
● Query the status using system functions (Page 63)
● Monitor the status in the engineering system (e.g. SIMOTION SCOUT) (Page 64).
4.1.2.1
Querying the activation state of the DP slaves and IO devices using system functions
System function
The _getStateOfDpSlave system function is used to specifically query the status of the
activation or deactivation procedure of a DP slave or IO device, which is defined via its
logical diagnostics address.
The syntax of this system function is described in detail in the "System Functions/Variables
Devices" List Manual (reference list) and in the online help (see index).
Functions (Page 64) are available for converting a PROFIBUS address or device number for
PROFINET IO into the logical diagnostics address and vice versa.
Status diagram, asynchronous call and synchronous call
As regards the main features, the same information applies as for the _activateDpSlave and
_deactivateDpSlave functions, see:
● Status diagram for the functions _activateDpSlave and _deactivateDpSlave (Page 57)
● Asynchronous call for the functions _activateDpSlave and _deactivateDpSlave (Page 58)
● Synchronous call for the functions _activateDpSlave and _deactivateDpSlave (Page 61)
Basic Functions for Modular Machines
62
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
4.1.2.2
Querying the status of the DP slaves and IO devices using system functions
System functions
The system functions _getStateOfAllDPStations, _getStateOfAllDpSlaves, and
_getStateOfSingleDpSlave can be used to query the status of all or just one DP slave or IO
device in a user program. In addition to the activation status, information on availability is
also provided.
● With the _getStateOfAllDPStations function you obtain:
– For PROFIBUS: the status of all DP slaves configured on a DP master with the logical
diagnostics addresses of their PROFIBUS interfaces. You can specify the DP master
using the logical diagnostics address for its PROFIBUS interface.
– For PROFINET IO: the status of all IO devices that you can reach from a controller
(also via routers), as well as the logical diagnostics addresses for their PROFIBUS
interfaces. You can specify the controller using the logical diagnostics address for its
PROFINET IO interface.
With one call of the function, you obtain the status for a maximum of 10 DP slaves or IO
devices. If more DP slaves and/or I/O devices are available, you will receive the value
16#0000_0001 in the functionResult component of the return value. Following this, keep
calling up the function using the parameter RequestMode := REQUEST_FALSE as often
as is necessary until the functionResult component of the return value contains the value
16#0000_0000. Use the same command ID as for the first call.
● With the _getStateOfAllDpSlaves function you obtain:
– For PROFIBUS: for every legal PROFIBUS address on a DP master, whether a DP
slave is configured for this address and, if necessary, its status. You can specify the
DP master using the logical diagnostics address for its PROFIBUS interface.
This function exists only with PROFIBUS DP.
● With the _getStateOfSingleDpSlave function you obtain:
– For PROFIBUS: the status of an individual DP slave that you can specify using the
logical diagnostics address for its PROFIBUS interface.
– For PROFINET IO: the status of an individual IO device that you can specify using the
logical diagnostics address for its PROFINET IO interface.
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" Parameter Manual (reference list) and in the online help (see
index).
Functions (Page 64) are available for converting a PROFIBUS address or device number for
PROFINET IO into the logical diagnostics address and vice versa.
Basic Functions for Modular Machines
Function Manual, 02/2012
63
Activating and deactivating components and technology objects
4.1 Activating and deactivating nodes on the PROFIBUS or PROFINET IO
Status diagram, asynchronous call and synchronous call
As regards the main features, the same information applies as for the _activateDpSlave and
_deactivateDpSlave functions, see:
● Status diagram for the functions _activateDpSlave and _deactivateDpSlave (Page 57)
● Asynchronous call for the functions _activateDpSlave and _deactivateDpSlave (Page 58)
● Synchronous call for the functions _activateDpSlave and _deactivateDpSlave (Page 61)
4.1.2.3
Monitoring the status of the DP slaves and IO devices in the engineering system
You can also monitor the status of the DP slaves and IO devices in the engineering system
(e.g. SIMOTION SCOUT), when this is connected online with the target system.
Proceed as follows:
1. Select the SIMOTION device in the project navigator.
2. Select the Target Device > Device Diagnostics menu.
3. Select the Slaves tab.
All DP slaves and IO devices connected to the SIMOTION device's subnets and their states
are displayed.
Note
Up to version V3.0 of the SIMOTION kernel, only the statuses of those DP slaves that are
drives are displayed.
4.1.3
Converting a PROFIBUS address or device number for PROFINET IO into the
logical diagnostics address and vice versa
The PROFIBUS address and device number for PROFINET IO are unique in the related
PROFIBUS subnet or PROFINET IO segment, but not across the project. Only the logical
diagnostics addresses are unique across the project.
Using the _getLogDiagnosticAddressFromDpStationAddress function you can convert the
PROFIBUS address for a bus node (or device number for PROFINET IO) into the associated
logical diagnostics address in the user program by specifying the related local interface.
Using the _getDpStationAddressFromLogDiagnosticAddress function you can convert the
logical diagnostics address into the PROFIBUS address for a bus node (or device number
for PROFINET IO), as well as the related local interface, in the user program.
By executing the _getGeoAddressFromLogAddress function you will obtain, in the user
program, the geographical address for a logical diagnostics address across the project
(e.g. bus system, slot number).
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
Basic Functions for Modular Machines
64
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.2 Option handling for ET200S without reserve modules
4.2
Option handling for ET200S without reserve modules
With SIMOTION SCOUT version V4.1 and higher, options can be handled even without
reserve modules if an ET200S is being used.
The following sections are excerpts from the SIMATIC documentation concerned, with
corresponding notes especially for use with SIMOTION.
For more details, please refer to the SIMOTION SCOUT online help.
4.2.1
Principle of operation of option handling without reserve modules
Principle
In the case of option handling without RESERVE modules, the configuration data are
insufficient to compare the preset configuration with the actual configuration. In addition,
information about the existing options is still required. This must be sent via the user data to
the IM151-1. In order to be able to receive the user data, the IM151-1 initially goes formally
into cyclic data exchange after the configuration data have been received. However, direct
I/O access does not yet take place. Output data are rejected, the input data are zero. The
IM151-1 only responds to the output data that you have to connect to a power module (O or
SO). A preset-actual test isn't possible until this option information is available. Only after this
can the I/O devices be operated.
Since the option information is stored retentively in the IM151-1, this intermediate state only
exists during the first commissioning or reconfiguration/retrofitting.
Please note the following:
NOTICE
In this operating mode, the IM151-1 may not be operated as a subscriber (F-data exchange
broadcast) on the PROFIBUS or PROFINET.
● Data record requests to option slots that do not exist induce a fault (80B0).
● If the IM151-1 is operated without configuration or without a CPU (DP master), it supplies
the configuration as it exists. This is relevant for wiring test tools, since the actual slot
numbers, without gaps from 1 to n, are used there for status/control.
● In isochronous operation, the designed configuration generally applies for the time
calculation (Ti, To, Tdp).
● There are no limitations when "packing" digital modules. Theoretically, the module to
which the byte address is assigned in the preset configuration can be missing in the
structure.
Note
The configured slot numbers (slot numbers in data records, and for events such as
diagnostics and interrupts) always apply for slot addressing.
Basic Functions for Modular Machines
Function Manual, 02/2012
65
Activating and deactivating components and technology objects
4.2 Option handling for ET200S without reserve modules
4.2.2
Prerequisites for option handling without reserve modules
Prerequisites
For option handling without RESERVE modules you require:
● Interface module IM151-1 HIGH FEATURE (6ES7151-1BA02-0AB0 and higher)
● Power module PM E-24 ..48 VDC or PM E- 24..48 VDC/24 ..230 VAC
One of these power modules must be included in the configuration at least once.
● For configuring the GSD file SI0380E0.GSx as from 10/2006.
Note
You do not require a GSD file for option handling in STEP 7 as from:
• STEP 7 V5.3 SP 3 with HSP0102
You can find the description for option handling in the STEP 7 Online Help or SIMOTION
SCOUT.
4.2.3
Example of use without reserve modules
Configuration variants
Below is an example of the use of option handling without RESERVE modules.
Note: A "0" in the control interface means that this slot number is deactivated in the
configuration and thus does not exist.
Basic Functions for Modular Machines
66
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.2 Option handling for ET200S without reserve modules
',
'2
'2
'2
'2
%XVFRQQHFWLRQ
',
',
30('&9
'2
'2
'2
'2
30('&9
','&9
','&9
$,8
3ODQQHG
PD[LPXP
FRQILJXUDWLRQ
RIWKH
(76
,067$1'$5'
%DVLF
FRQILJXUDWLRQ
&RQWUROLQWHUIDFH3,4ฬ
)HHGEDFNLQWHUIDFH3,,
2SWLRQ
&RQILJXUHGVORWQXPEHU
30('&9
','&9
','&9
$,8
30('&9
',
',
',
%XVFRQQHFWLRQ
,0+)
3UHSDUDWLRQ
ZLWKRXW
5(6(59(
PRGXOHVDQG
SUHZLULQJ
%DVLF
FRQILJXUDWLRQ
2SWLRQ
<RXPXVW
FRQILJXUHWKLV
VHWXS+:
&RQILJ
&20352),
%86
<RXPXVW
LQVWDOODQG
ZLUHWKLV
VHWXS
6HQVRUVDFWXDWRUV
Figure 4-3
4.2.4
Example for use without RESERVE modules
Assigning parameters for option handling without reserve modules
Introduction
You configure option handling without RESERVE modules as described below.
Basic Functions for Modular Machines
Function Manual, 02/2012
67
Activating and deactivating components and technology objects
4.2 Option handling for ET200S without reserve modules
Procedure
1. Drag a PM-E 24..48 VDC or PM-E 24..48 VDC/24..230 VAC power module with one of
the following entries into the configuration table:
– ...O (option handling) or
– ...SO (status byte + option handling)
Note
You may only enter the power module with the ending ...O or ...SO once in the ET 200S
configuration!
2. Assign parameters to the interface module as follows:
Interface module
IM151-1 HIGH
FEATURE
Parameter
Option handling,
general
(6ES7151-1BA02- Option handling:
0AB0 and higher) With/without
RESERVE
modules
Setting
Description
Enable
Option handling is activated for
the entire ET 200S.
Without RESERVE
modules
Selects option handling without
RESERVE modules
Note
If "Operation for set < > actual installation" is blocked for parameter assignment, the ET
200S does not start up if a module is missing or if an incorrect module is plugged in. The
diagnostic "No module" or "Incorrect module" is signaled.
If the IM151-1 does not start up in this state, the SF LED lights up at the IM151-1 and at the
deactivated electronic module of the ET 200S.
Note
In the case of option handling without RESERVE modules, incorrect filling in of the control
interface can result in too many plugged modules with a slot number greater than 63 are
reported from the point of view of the interface module. Since there is only room for 63
modules in the diagnostics message (module status), the highest-value bit is set in the
"Identifier-related diagnostics" in this case. This produces the following results:
- The SF LED on the IM lights up
- Bit 3 in status byte 1 of the diagnostics message is set (external diagnosis exists)
- The "Slot 64 faulty" error message is indicated in STEP7.
Basic Functions for Modular Machines
68
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.2 Option handling for ET200S without reserve modules
Behavior during the first start-up
In the case of option handling without RESERVE modules, the IM151-1 always goes into
cyclic data exchange during the first start-up. However, the I/O device input/output is not
activated until valid information about the options is available from the module. No fault is
indicated externally in this state (BF LED does not light up). The input/output of the I/O
devices is not active in this state. Evaluate the data of the feedback interface in order to
assess this state.
Behavior during a warm restart
Valid information about the options is stored retentively in the IM151-1. During the warm
restart, the IM151-1goes into cyclic data exchange and the input/output of the I/O devices is
activated immediately. If the configuration has changed since the last startup (e.g. incorrect
module plugged in or information about options is incorrect), the input/output of the I/O
devices will remain deactivated until the real configuration matches the configured one
again.
4.2.5
Controlling and monitoring options
Introduction
You can use the control interface (PIQ) and feedback interface (PII) to control and monitor
options by means of the user program.
Recommendation: Before working with the ET 200S optional enhancements, check whether
all the required electronic modules are plugged in using the feedback interface (refer to the
table below). The contents of the feedback interface have to agree with the specifications of
the control interface.
Note
For consistent access to the control and feedback interface, create an I/O variable of BYTE
data type and array length 8 in SIMOTION SCOUT. This procedure is comparable with the
SFC 14/15 for SIMATIC S7.
Principle
The control and feedback interface is located in the input and output process image of the
PM-E 24..48 VDC or PM-E 24..48 VDC/24..230 VAC power modules. It can only be
accessed if entries ending in ...O or ...SO for that power module were selected in the
configuration software.
One bit is available for each ET 200S electronic module slot:
● Control interface: Slots 1 to 63
● Feedback interface: Slots 1 to 63
Basic Functions for Modular Machines
Function Manual, 02/2012
69
Activating and deactivating components and technology objects
4.2 Option handling for ET200S without reserve modules
(%$%[
(%$%[
(%$%[
(%$%[
(%$%[
(%$%[
(%$%[
(%$%[
Figure 4-4
Control (PIQ) and feedback interface (PII)
Control interface PIQ (AB x to AB x+7):
You must inform the IM151-1 via the control interface about which modules actually exist
and which slots have been left out. The IM151-1 cannot evaluate the configuration until it has
received this information.
Table 4- 1
Control interface
Slot
Value of the bit
Reaction
0
0
Content of the bitspur is not relevant
1
Bitspur is valid
1 to 63
0
Slot does not exist in the actual configuration
1
Slot exists in the actual configuration
Feedback interface PII (EB x to EB x+7):
The feedback interface (8 bytes) tells you which module is actually located on which slot.
Table 4- 2
Feedback interface
Slot
Value of the bit
0
0
Option handling is inactive
1
Option handling is active
0
Slot belongs to an option that does not exist or the module
status is not OK
1
Slot exists and is OK
1 to 63
Reaction
If the feedback result of the feedback interface is identical with the specification of the control
interface, the configuration is correct.
Basic Functions for Modular Machines
70
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.3 Activating and deactivating SINAMICS components
Procedure
In order to start testing the options, set Bit0=1 in the first byte (AB x).
Proceed as follows in order to ensure the consistency of the 8 bytes:
● Write the first byte (AB x) last (for direct access with T PAB)
or
● First write the complete information of the control interface in the first byte (AB x) with
Bit0=0 and then set Bit0=1 in this byte in the subsequent OB1 cycle.
Note
Whenever any change in the 8 bytes of the control interface takes place, this information is
stored and used, even if non-relevant bits were changed (bits outside the preset
configuration).
4.3
Activating and deactivating SINAMICS components
There is a fundamental difference between how individual components are activated and
deactivated within a SINAMICS S120 multi-axis group and the corresponding procedures
for, say, I/O components. This is due to the specific architecture involved.
Drives, I/O components in the SINAMICS S120 series, and their control instances are
described in a complex parameter object model that is stored in the central control unit.
Entire drives, including their control or individual components, can be activated or
deactivated there. The following parameters are used for this purpose:
● Activate/deactivate drive objects (also on Terminal Modules or Controller Extension
CX32):
– Adjustable parameter p0105 (Activate/deactivate drive object)
– Display parameter r0106 (Drive object active/inactive)
● Activate/deactivate power units:
– Adjustable parameter p0125[PDS] (Activate/deactivate power unit component)
– Display parameter r0126[PDS] (Power unit components active/inactive)
● Activate/deactivate encoders (on motor modules):
– Adjustable parameter p0145[EDS] (Activate/deactivate encoder interface)
– Display parameter r0146[EDS] (Encoder interface active/inactive)
● Activate/deactivate Voltage Sensing Module (on line modules):
– Adjustable parameter p0145[VSM] (Activate/deactivate Voltage Sensing Module)
– Display parameter p0146[VSM] (Voltage Sensing Module active/inactive)
Basic Functions for Modular Machines
Function Manual, 02/2012
71
Activating and deactivating components and technology objects
4.3 Activating and deactivating SINAMICS components
There is a description of these parameters in the SINAMICS S120/S150 List Manual.
NOTICE
Pay attention to the boundary conditions for the individual parameters described in the
SINAMICS S List Manual.
Example of a sub-topology
The figure below shows an example of a sub-topology.
Parameters have been set on a machine for 1 active line module and 2 motor modules. The
related configuration is saved on the CompactFlash Card of the control unit for the
SINAMICS drive (reference topology).
● With the machine switched off, "drive 1" is removed and the DRIVE-CLiQ cable from the
control unit is connected directly to "drive 2" (sub-topology, actual topology).
● On ramping up, the control unit detects a difference between the reference topology and
the actual topology.
● The user program must then execute the following actions:
– Set the drive object (DO) "drive 1" to "deactivate and not available". For this purpose
the program must set the parameter p0105 = 2 in this DO.
– Save all parameters in non-volatile memory on the CompactFlash Card; for this
purpose the program must set the parameter p0977 = 1 in the control unit.
The actual topology is then saved as the reference topology. No further errors are triggered
on ramping up.
Note
You can use the same procedure to deactivate all drive objects on a Controller Extension
CX32 at the same time. For this purpose, set the parameter p0105 = 2 in the drive object
CU_LINK.
Basic Functions for Modular Machines
72
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.3 Activating and deactivating SINAMICS components
,QIHHG
$QWULHE
$QWULHE
$FWLYH
/LQH
0RGXOH
6LQJOH
0RWRU
0RGXOH
6LQJOH
0RWRU
0RGXOH
;
;
;
;
;
;
;
;
;
;
;
;
$FWLYH
,QWHUIDFH
0RGXOH
;
;
;
60&
;
60&
0
0
&8
;
5HIHUHQFH
WRSRORJ\
;
960
&8
,QIHHG
'ULYH
$FWLYH
/LQH
0RGXOH
6LQJOH
0RWRU
0RGXOH
;
;
;
;
5HFRQQHFWHG
;
;
;
;
;
;
$FWLYH
,QWHUIDFH
0RGXOH
;
6XE
WRSRORJ\
;
;
60&
960
0
'5,9(&/L4
(QFRGHU
3RZHU
Figure 4-5
Example of a sub-topology
Basic Functions for Modular Machines
Function Manual, 02/2012
73
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
4.4
Activating and deactivating technology objects
The user has configured and programmed a maximum configuration. Technology objects
which are not required (e.g. those assigned to deactivated DP slaves or IO devices) can be
deactivated without restarting during operation.
The required technology objects (together with the DP slaves or IO devices to which they are
assigned) can also be activated during operation.
This has the following advantages:
● The processor performance is concentrated on the activated technology objects. The
computing time available for the MotionTasks and the BackgroundTask is increased.
● The system cycle clocks do not have to be dimensioned for calculating all the technology
objects present in the maximum configuration, but only for the maximum number of
simultaneously active technology objects. They can then generally be selected with
shorter times: This increases the time resolution and reduces any response times; motion
control is improved.
● A single project is suitable for various machine configurations; changes to the machine
configuration can be made without a restart during operation.
● A default setting can be specified in the project as to which technology objects are active
during the transition to the RUN operating mode.
Note
Licenses are required for all axes of the maximum configuration.
System functions
● _activateTo (Page 75)
● _deactivateTo (Page 75)
● _getStateOfTo (Page 82)
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
NOTICE
Technology objects are often assigned to the distributed I/O (DP slave, IO device);
therefore, please note the information in Procedure for deactivating and activating
components (Page 83).
Basic Functions for Modular Machines
74
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
4.4.1
System functions for activating and deactivating technology objects
System functions
Use the functions _deactivateTo and _activateTo to activate and deactivate the technology
objects during runtime.
The related technology object is transferred in parameter TO_Instance (data type
ANYOBJECT).
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
Please also note the information relating to the status diagram (Page 75), asynchronous
calls (Page 77) and synchronous calls (Page 79).
NOTICE
The temperature channel technology object can only be activated and deactivated in the
engineering system (see Activating or deactivating technology objects in the engineering
system (Page 81)).
4.4.1.1
Status diagram for the functions _activateTo and _deactivateTo
The figure below shows the states of the system functions _activateTo and _deactivateTo. It
also applies to the _getStateOfTo system function (see also Querying the activation state of
technology objects).
The functions can be called asynchronously and synchronously.
● With an asynchronous call (Page 77) (parameter nextCommand := IMMEDIATELY), the
user program is continued immediately after the start of the system function.
You must regularly query the state of the function to be able to determine when a
command has been executed in full.
The asynchronous call is required in cyclic tasks to ensure that their time monitoring
function does not start.
● With a synchronous call (Page 79) (parameter
nextCommand : =WHEN_COMMAND_DONE), the user program waits until the system
function has been completed. The return value directly indicates whether the function call
was successful.
The synchronous call is recommended for MotionTasks.
Use parameter reqActDeactGetStateMode := REQUEST_TRUE to start execution of the
function (e.g. activation or deactivation of a technology object).
Basic Functions for Modular Machines
Function Manual, 02/2012
75
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
Start the status query of the function with parameter reqActDeactGetStateMode :=
REQUEST_FALSE. Use the same command ID as for the first call.
NOTICE
To correctly complete the function on an asynchronous call, you must call the function with
the parameter reqActDeactGetStateMode := REQUEST_FALSE as often as necessary until
you obtain 16#0000_0000 as the return value or an error message.
You can only execute the function once at the same time for each technology object.
)RUV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B758(
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B)$/6(
)RUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B)$/6(
5HWXUQYDOXH B
5HWXUQYDOXH BRU))))B[[[[
5HDG\LGOH
6\QFKURQRXVRUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B758(
5HWXUQYDOXH B
IRUDV\QFKURQRXVFDOORQO\
5XQQLQJ
2QO\IRUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B)$/6(
)RUV\QFKURQRXVRUDV\QFKURQRXVFDOOZLWK
UHT$FW'HDFW*HW6WDWH0RGH 5(48(67B758(
5HWXUQYDOXH B
5HWXUQYDOXH ))))B&
)XQFWLRQDOUHDG\VWDUWHG
5(48(67B758(QRWSHUPLWWHG
Return values
16#0000_0000
// Activation or deactivation successful
16#0000_7000
// Function in ready mode (idle), initial call required with REQUEST_TRUE
16#0000_7001
// Function started (only for asynchronous call)
16#0000_7002
// Function running (only for asynchronous call)
16#FFFF_xxxx
// Function terminated with error
Figure 4-6
Status diagram of the system functions _activateTo and _deactivateTo
Basic Functions for Modular Machines
76
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
4.4.1.2
Asynchronous call for the functions _activateTo and _deactivateTo
The asynchronous call is required in cyclic tasks to ensure that their time monitoring function
does not start.
With an asynchronous call, the user program is continued immediately after the start of the
system function. You must query the state of the function regularly to determine whether it
has been completed without errors.
Proceed as follows for the asynchronous call:
1. Call the following parameters to start the system function:
– reqActDeactGetStateMode := REQUEST_TRUE,
– nextCommand := IMMEDIATELY.
2. Check the return value.
– Return value 16#0000_0000 indicates that the function has been completed without
errors.
Continue with step 5.
– The return value 16#0000_7001 indicates that the function has been started
successfully, but has not yet been completed.
Continue with step 3.
– A return value < 0 indicates that the function has been terminated with errors. You can
program error routines, depending on the return value.
3. For the state query and to check whether the system function has been completed, call
these again, but with the following parameters:
– reqActDeactGetStateMode := REQUEST_FALSE.
– nextCommand := IMMEDIATELY.
– commandId: Use the same command ID as for the first call.
4. Check the return value:
– Return value 16#0000_7002 indicates that the function is still running.
Repeat step 3.
– A return value < 0 indicates that the function has been terminated with errors. You can
program error routines, depending on the return value.
– Return value 16#0000_0000 indicates that the function has been completed without
errors.
5. On error-free completion of the functions _activateTo and _deactivateTo note the
information below.
Basic Functions for Modular Machines
Function Manual, 02/2012
77
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
NOTICE
Note for versions up to and including V4.0 of the SIMOTION kernel:
The activation or deactivation of the technology object is not yet finished on completion
without errors of the functions _activateTo or _deactivateTo.
Therefore, keep calling the _getStateOfTo (Page 82) system function until the
commandIdState component of the return value (data type EnumStateOfTo) has the value
ACTIVE or INACTIVE.
Example program for the asynchronous call for the _activateTo function
INTERFACE
USEPACKAGE Cam;
PROGRAM backGround;
VAR_GLOBAL
bgrRequestActivate
bgrResultActivate
bgrToInstance
bgrReqActDeactMode
bgrCommandId
bgrNextCommand
END_VAR
END_INTERFACE
:
:
:
:
:
:
DINT := 0;
DINT := 0;
posaxis;
enumReqActDeactGetStateMode := REQUEST_TRUE;
CommandIdType;
enumNextCommandMode := IMMEDIATELY;
IMPLEMENTATION
PROGRAM backGround // Assigned to the BackgroundTask
VAR
retVal : DINT := 0;
END_VAR
// ... Further instructions
IF ( 0 <> bgrRequestActivate ) THEN
retVal := _activateTo (
TO_Instance
reqActDeactGetStateMode
commandId
nextCommand
:=
:=
:=
:=
bgrToInstance,
bgrReqActDeactMode,
bgrCommandId,
bgrNextCommand );
CASE retVal OF
16#0000_0000: bgrRequestActivate := 0;
// Node successfully activated.
16#0000_7001: bgrReqActDeactMode := REQUEST_FALSE;
// Function started successfully
16#0000_7002: ; // Function running.
ELSE // Troubleshooting
bgrRequestActivate := 0;
END_CASE;
Basic Functions for Modular Machines
78
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
Example program for the asynchronous call for the _activateTo function
IF ( 0 = bgrRequestActivate ) THEN
// Function completed, prepare next call.
bgrReqActDeactMode := REQUEST_TRUE;
bgrResultActivate := retVal;
END_IF;
END_IF;
// ... Further instructions
END_PROGRAM
END_IMPLEMENTATION
4.4.1.3
Synchronous call for the functions _activateTo and _deactivateTo
The synchronous call is recommended for MotionTasks.
With a synchronous call, the user program waits until the system function has been
completed. The return value directly indicates whether the function call was successful.
Proceed as follows for the synchronous call:
1. Call the following parameters to start the system function:
– reqActDeactGetStateMode = REQUEST_TRUE,
– nextCommand = WHEN_COMMAND_DONE.
2. Check the return value:
– A return value < 0 indicates that the function has been terminated with errors. You can
program error routines, depending on the return value.
– Return value 16#0000_0000 indicates that the function has been completed without
errors.
For the functions _activateTo and _deactivateTo note the information below.
NOTICE
Note for versions up to and including V4.0 of the SIMOTION kernel:
The activation or deactivation of the technology object is not yet finished on completion
without errors of the functions _activateTo or _deactivateTo.
Therefore, keep calling the _getStateOfTo (Page 82) system function until the
commandIdState component of the return value (data type EnumStateOfTo) has the value
ACTIVE or INACTIVE.
Basic Functions for Modular Machines
Function Manual, 02/2012
79
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
Example program for the synchronous call for the _activateTo function
INTERFACE
USEPACKAGE Cam;
PROGRAM motion_1;
VAR_GLOBAL
motion_1_RequestActivate
motion_1_ResultActivate
motion_1_ToInstance
motion_1_CommandId
END_VAR
END_INTERFACE
:
:
:
:
DINT := 0;
DINT := 0;
posaxis;
CommandIdType;
IMPLEMENTATION
PROGRAM motion_1 // Assigned to a MotionTask
VAR
retVal : DINT := 0;
END_VAR
// ... Further instructions
IF ( 0 <> motion_1_RequestActivate ) THEN
retVal := _activateTo (
TO_Instance
:=
reqActDeactGetStateMode :=
commandId
:=
nextCommand
:=
motion_1_ToInstance,
REQUEST_TRUE,
motion_1_CommandId,
WHEN_COMMAND_DONE );
CASE retVal OF
16#0000_0000: motion_1_RequestActivate := 0;
// Node successfully activated.
ELSE // Troubleshooting
motion_1_RequestActivate := 0;
END_CASE;
IF ( 0 = motion_1_RequestActivate ) THEN
// Function completed.
motion_1_ResultActivate := retVal;
END_IF;
END_IF;
// ... Further instructions
END_PROGRAM
END_IMPLEMENTATION
Basic Functions for Modular Machines
80
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
4.4.2
Activating or deactivating technology objects in the engineering system
You can also activate or deactivate technology objects in the engineering system
(e.g. SIMOTION SCOUT). After downloading the project to the target system, these
technology objects are activated or deactivated during ramp-up of the system (default
setting: all technology objects are activated).
NOTICE
You can only make the settings with the engineering system in offline mode. They only take
effect after the project is downloaded to the target system.
1. Make sure that the engineering system (e.g. SIMOTION SCOUT) is in offline mode.
2. Select the SIMOTION device (e.g. D435) in the project navigator.
3. Select the Edit > Object states menu.
A list of all technology objects configured on this SIMOTION device is displayed. The
check box in front of the identifier of each technology object indicates whether it is
activated during the transition from STOP to RUN operating mode.
4. For each technology object, define whether the object is to be activated when the system
is ramped up:
– Activate the check box if the relevant technology object is to be activated (default
setting).
– Deactivate the check box if the relevant technology object is not to be activated.
5. Repeat steps 2 to 4 for all SIMOTION devices.
6. Change to online mode and download the project to the target system.
After the system is ramped up, you can change the activation and deactivation settings by
calling the system functions _activateTo and _deactivateTo (e.g. in the StartupTask).
You can monitor the current state in online mode using the engineering system (see
Querying the activation state of technology objects (Page 81)).
4.4.3
Querying the activation state of technology objects
You can now carry out the following for individual technology objects:
● Query the activation state using system functions (Page 82)
● Monitor the activation state in the engineering system (e.g. SIMOTION SCOUT)
(Page 82).
Basic Functions for Modular Machines
Function Manual, 02/2012
81
Activating and deactivating components and technology objects
4.4 Activating and deactivating technology objects
4.4.3.1
Querying the activation state of technology objects using system functions
System function
The _getStateOfTo system functions can be used to query the status of an individual
technology object in a user program.
The following information is contained in the return value of the function (data type
StructRetGetStateOfTo):
● The state of the function in the functionResult component (data type DINT)
● The activation state of the technology object in the commandIdState component (data
type EnumStateOfTo) (only when component functionResult = 16#0000_0000)
The syntax of these system functions is described in detail in the "System
Functions/Variables Devices" List Manual (reference list) and in the online help (see index).
Status diagram, asynchronous and synchronous call
As regards the main features, the same information applies as for the _activateTo and
_deactivateTo functions, see: .
● Status diagram for the functions _activateTo and _deactivateTo (Page 75)
● Asynchronous call for the functions _activateTo and _deactivateTo (Page 77)
● Synchronous call for the functions _activateTo and _deactivateTo (Page 79)
4.4.3.2
Monitoring the activation state of technology objects in the engineering system
You can monitor the current activation state of the technology objects of a SIMOTION device
in the engineering system (e.g. SIMOTION SCOUT). The engineering system must be in
online mode.
NOTICE
You cannot make any settings for the activation or deactivation of technology objects in
online mode.
1. Make sure that the engineering system (e.g. SIMOTION SCOUT) is in online mode.
2. Select the SIMOTION device (e.g. C240) in the project navigator.
3. Select the Edit > Object states menu.
A list of all technology objects configured on this SIMOTION device is displayed. The
check box in front of the identifier of each technology object indicates the activation state
after the transition to RUN operating mode and the current activation state:
– Check mark in the check box: activation state after the transition to RUN operating
mode (setting in offline mode)
– Color of the check box: current activation state (green = activated).
Basic Functions for Modular Machines
82
Function Manual, 02/2012
Activating and deactivating components and technology objects
4.5 Procedure for deactivating and activating components
4.5
Procedure for deactivating and activating components
The following is a brief summary of the steps that must be performed when deactivating and
activating each component (e.g. machine modules, DP slave with assigned technology
objects):
● Deactivating components (Page 83)
● Activating components (Page 84)
NOTICE
If possible, deactivate technology objects and components first before activating other
technology objects and components. In this way you will avoid level overflows.
4.5.1
Deactivating components
Proceed in this sequence if you want to deactivate technology objects and the distributed I/O
to which they are assigned:
1. Terminate all commands that are present on the technology objects to be deactivated
(e.g. motion, homing).
2. Remove all enables for these technology objects with the specific system function for the
technology object in question, e.g. _disableAxis.
Also remove the enables for dependent technology objects (for axes, e.g. measuring
inputs, output cams, synchronous objects).
3. Deactivate these technology objects individually:
– Observe the correct sequence if technology objects are dependent on one another:
First deactivate all dependent technology objects (e.g. measuring inputs, output cams,
synchronous objects) before deactivating their base technology object (e.g. axis).
– Start the deactivation process with the system function _deactivateTo (Page 75).
– Only up to version V4.0 of the SIMOTION kernel:
After error-free completion of the _deactivateTo system function, keep calling the
_getStateOfTo (Page 82) system function until the commandIdState component of the
return value (data type EnumStateOfTo) has the value INACTIVE.
4. When all technology objects that are assigned to a distributed I/O (e.g. drive) are
deactivated:
– Deactivate the distributed I/O (e.g. drive) with the system function _deactivateDpSlave
(Page 54)
Or
– Deactivate individual drive objects in the SINAMICS S120 drive line-up with parameter
p0105, see Activating and deactivating SINAMICS components (Page 71).
5. If required, remove the component (e.g. machine module).
Basic Functions for Modular Machines
Function Manual, 02/2012
83
Activating and deactivating components and technology objects
4.5 Procedure for deactivating and activating components
4.5.2
Activating components
Proceed in this sequence if you want to activate the distributed I/O and the technology
objects assigned to it:
1. Connect the component (e.g. machine module).
2. Activate the distributed I/O:
– Activate the distributed I/O (e.g. drive) with the system function _activateDpSlave
(Page 54)
Or
– Activate individual drive objects in the SINAMICS S120 drive line-up with parameter
p0105, see Activating and deactivating SINAMICS components (Page 71).
3. Activate the assigned technology objects individually:
– Observe the correct sequence if technology objects are dependent on one another:
First activate the base technology object (e.g. axis) before activating the dependent
technology objects (e.g. measuring inputs, output cams, synchronous objects).
– Start the activation process with the system function _activateTo (Page 75).
– Only up to version V4.0 of the SIMOTION kernel:
After error-free completion of the _activateTo system function, keep calling the
_getStateOfTo (Page 82) system function until the commandIdState component of the
return value (data type EnumStateOfTo) has the value ACTIVE.
4. Set the required enables for these technology objects with the specific system function for
the technology object in question, e.g. _enableAxis.
5. If required, home the axis with the _homing system function.
6. Start further motion commands.
Basic Functions for Modular Machines
84
Function Manual, 02/2012
Changing the active configuration or the active kernel
5
A configuration contains all configuration data for a SIMOTION device (e.g. device
configuration, communications configuration, technology objects, global device variables, I/O
variables, user programs). The active configuration is stored on the SIMOTION device's
memory card and is loaded with each system ramp-up (after POWER ON).
This section describes how you can perform the following actions in the user program:
1. Replace the active configuration by another one whose card image is present on the
memory card. You can explicitly specify the configuration to be activated (see Activating a
configuration (Page 85)) or select it via an initial configuration (see Selecting and
activating a configuration using an initial configuration (Page 96)).
2. Replace the active kernel of the SIMOTION device with another one whose card image is
present on the memory card (see Activating a kernel (Page 90)).
In this way, you can update the configuration and/or the SIMOTION Kernel without replacing
the memory card.
Note
If need be, you may have to update the corresponding firmware of interlinked SINAMICS
drive units.
5.1
Activating a configuration
A configuration contains all configuration data for a SIMOTION device (e.g. device
configuration, communications configuration, technology objects, global device variables, I/O
variables, user programs). The active configuration is stored on the SIMOTION device's
memory card and is loaded with each system ramp-up (after POWER ON).
This section describes how you can replace the active configuration by another one whose
card image is present on the memory card by means of a user program. In this case, the
configuration to be activated is specified explicitly or determined by the user program. In this
way, a configuration adapted for each task can be added:
● The memory and computing capability of the SIMOTION device are only used for the
configured functionalities
● Cycle times and cycle clocks (e.g. DP cycle clock, position control cycle clock, IPO cycle
clock) can be optimized for each requirement.
A typical application case is as follows: On a SIMOTION device (base machine), various
machine modules are connected in turn. The configuration data for each arrangement (base
machine with connected machine module) is stored as its own configuration on the memory
card of the SIMOTION device. After the machine module is connected to the base machine,
the user program identifies the relevant machine module.
Basic Functions for Modular Machines
Function Manual, 02/2012
85
Changing the active configuration or the active kernel
5.1 Activating a configuration
System function
When the _activateConfiguration system function is initiated, the user program loads the
required configuration and restarts the SIMOTION device. Provide the configuration to be
activated in parameter projectDataId (data type UDINT). The hexadecimal number to be
provided corresponds to the last six characters of the relevant file name assigned to the card
image of the respective configuration on the memory card (example: File name =
PR000001.ZIP, projectDataId = 16#000001).
The syntax of this system function is described in detail in the "System Functions/Variables
Devices" List Manual (reference list) and in the online help (see index).
NOTICE
Note when activating a configuration:
• Retentive global device variables are always initialized.
• The values of the following variables of the last active configuration can be preserved:
Retentive unit variables and retentive system variables of the technology objects.
Observe the measures described in Retaining retentive data in the event of a
configuration change (Page 102).
• If the SINAMICS Safety Integrated Functions configuration is used, an acceptance test
is mandatory when the SIMOTION device is restarted (see "SINAMICS S120 Safety
Integrated" Function Manual).
• After restarting the SIMOTION device, check the Activation state of the configuration
(Page 101) with the _getConfigurationData system function.
The activated configuration remains after the SIMOTION device is turned off. After the
device is turned on (POWER ON), they are reloaded.
A detailed description of how the card images of configurations are created is provided in
Section "Procedure for creating the card images of configurations" (Page 104).
NOTICE
If one or more CX32/CX32-2 controller extensions are connected to a SIMOTION
D4x5/D4x5-2, note the following when activating a configuration with the
_activateConfiguration function:
The activated configuration will only take effect on the CX32/CX32-2 controller extension
after the CX32/CX32-2 has been restarted. This restart must be specifically initiated by the
user, as the _activateConfiguration function does not perform a restart automatically.
Note the information in the Section "Special considerations when a CX32/CX32-2 controller
extension is connected" (Page 87).
Basic Functions for Modular Machines
86
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.1 Activating a configuration
5.1.1
Special considerations when a CX32/CX32-2 controller extension is connected
NOTICE
If one or more CX32/CX32-2 controller extensions are connected to a SIMOTION
D4x5/D4x5-2, note the following when activating a configuration with the
_activateConfiguration function:
The activated configuration will only take effect on the CX32/CX32-2 controller extension
after the CX32/CX32-2 has been restarted. This restart must be specifically initiated by the
user, as the _activateConfiguration function does not perform one automatically.
To force the CX32/CX32-2 controller extension to restart, proceed as follows (3 options):
● Power Off/On for the entire system
● Power Off/On of the CX32/CX32-2 controller extension
● Set p0972 = 1 on the CX32/CX32-2 controller extension:
– In the user program: with the _writeDriveParameter function, for example
Or
– In SIMOTION SCOUT: In the expert list for the "Control_Unit" of the CX32/CX32-2
controller extensions
This restarts the CX32/CX32-2 immediately.
DANGER
Ensure the system is in a safe state.
No attempt should be made to access the memory card of the SIMOTION D4x5/D4x5-2.
Basic Functions for Modular Machines
Function Manual, 02/2012
87
Changing the active configuration or the active kernel
5.1 Activating a configuration
5.1.2
Example for the activation of a configuration
Description
In the figure below, a transport device with a SIMOTION control transports a workpiece to
various machining stations. The following sequences can be observed here:
1. Drawing a blank from the store and transporting it to the machining station
2. Machining the blank
3. Unloading the semi-finished part at the packing station.
5HPRYH
Figure 5-1
0DFKLQH
3DFN
Sequences of an automation task
Implementation
For each machining step, the associated optimized configuration is stored on the memory
card of the transport device. After the transport device has been coupled to one of the
machining stations, the relevant machining station is identified by evaluating a connector
coding and the necessary configuration is loaded. The table below shows examples of the
following information for the machining stations shown in the figure above:
● Their connector coding
● The file name of the associated configuration on the memory card of the transport device
and
● The projectDataId associated with the file name, which is required when calling the
_activateConfigurationsystem function
Table 5- 1
Identifying the configuration
Designation of the
machining station
Connector coding
File name of the
configuration
projectDataId
Remove
001
PR000001.ZIP
16#000001
Machine
010
PR000002.ZIP
16#000002
Pack
100
PR000003.ZIP
16#000003
Basic Functions for Modular Machines
88
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.1 Activating a configuration
Example program
The following programming example shows:
● The identification of the required configuration in accordance with the table above
● The activation of the required configuration
Example program for the identification and activation of a required
configuration
// Variable declaration
VAR
retActivateConf : StructRetConfiguration;
plugCode AT %IB0 : BYTE; // Connector coding
configId
: UDINT; // projectDataId of the
// required configuration
END_VAR
// Identify the required configuration
// by evaluating the connector coding
CASE plugCode OF
2#001
: configId := 16#000001; // Remove (PR000001.ZIP)
2#010
: configId := 16#000002; // Machine (PR000002.ZIP)
2#100
: configId := 16#000003; // Pack (PR000003.ZIP)
ELSE
; // ... Error response
END_CASE;
// Activate the required configuration
retActivateConf := _activateConfiguration (
projectData
:= YES,
projectDataId := configId,
timeOut
:= T#5m
// 5 minutes
);
IF ( 0 <> retActivateConf.result ) THEN
// Error response
; // ...
END_IF;
About parameter timeOut
The timeOut parameter specifies the maximum time the SIMOTION device can require after
the restart until the RUN mode is reached. When this time is exceeded, the system performs
the following actions:
1. The system tries to activate the initial configuration (if present), and to select a
configuration through it (see Selecting and activating a configuration using an initial
configuration (Page 96)).
2. In the event of an error, the device switches to the STOP operating mode.
Monitoring is deactivated when timeOut = T#0s.
Basic Functions for Modular Machines
Function Manual, 02/2012
89
Changing the active configuration or the active kernel
5.2 Activating a kernel
NOTICE
Make sure that the selected system cycle clocks are long enough, otherwise a timeout
(internal error) may occur while a configuration is powering up.
5.2
Activating a kernel
5.2.1
Activating a kernel
This section describes how you can exchange the active kernel of the SIMOTION device
using the user program and, for example, carry out an update to a new version without
having to replace the memory card of the device. In this regard, you must replace all
configurations (configuration data) of the SIMOTION device.
To do this, you transfer the card images of the kernel and all necessary configurations to the
INSTALL\SIMOTION\VExxxxxx directory on the SIMOTION device's memory card. In the
directory name VExxxxxx there is a 6-digit hexadecimal number xxxxxx. You specified this
directory name when creating the card images with the /i"VExxxxxx" option. A detailed
description of how the card images of the kernel and configurations are created is provided
in Section "Procedure for creating the card images of configurations (Page 104)".
The required data is saved in the following subdirectories in the VExxxxxx directory:
● INITIAL directory: The card image of an initial configuration (file name INITIAL.ZIP), if
present
● KERNEL directory:
– For the SIMOTION C2xx and P3xx devices:
The card image of the SIMOTION kernel (file name KERNEL.ZIP)
– For the SIMOTION D4xx and D4xx-2 devices:
The card image of the SIMOTION kernel including the firmware for the SINAMICS
Integrated (file name KERNEL.ZIP)
● PACKAGE directory: The card images of the technology objects
● PROJECT directory: The card images for all configurations (file name PRyyyyyy.ZIP,
where yyyyyy is a hexadecimal number that corresponds to the projectDataId)
Note
Select a designation for the VExxxxxx directory from which the version of the
SIMOTION kernel can be clearly identified, e.g. VE004156 for version V4.1 SP5 HF6.
Basic Functions for Modular Machines
90
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.2 Activating a kernel
Figure 5-2
Directory structure on the memory card
System function
To activate the SIMOTION kernel stored on the card, call in the user program the
_activateConfigurationsystem function with the kernel := YES parameter. In the kernelId
parameter, specify the last six characters of the directory name on the memory card
(example: Directory name = VE004156, kernelId = 16#004156).
The syntax of this system function is described in detail in the "System Functions/Variables
Devices" List Manual (reference list) and in the online help (see index).
Specify the configuration to be activated in the projectData and projectDataId parameters:
● projectData := NO: The projectDataId parameter will be ignored; the initial configuration
will be activated. In this initial configuration, the required configuration will be determined,
for example, by evaluating a connector coding, and loaded by calling the
_activateConfiguration system function again.
See "Example without details of a configuration to be activated" in "Examples for
activating a kernel" (Page 92).
For information on the initial configuration, see Selecting and activating a configuration
using an initial configuration (Page 96).
● projectData := YES: The configuration specified in the projectDataId (UDINT data type)
parameter will be activated. The hexadecimal number to be transferred corresponds to
the last six characters of the relevant file name of the configuration on the memory card
(for example, File name = PR000001.ZIP, projectDataId = 16#000001).
See "Example with details of a configuration to be activated" in "Examples for activating a
kernel" (Page 92).
NOTICE
When activating a kernel and the associated configuration, please note:
• Retentive global device variables are always initialized.
• The values of the following variables of the last active configuration can be preserved:
Retentive unit variables and retentive system variables of the technology objects.
Observe the measures described in "Retaining retentive data in the event of a
configuration change" (Page 102).
• If the SINAMICS Safety Integrated Functions configuration is used, an acceptance test
is mandatory when the SIMOTION device is restarted (see "SINAMICS S120 Safety
Integrated" Function Manual).
• After restarting the SIMOTION device, check the Activation state of the kernel and the
configuration (Page 101) with the _getConfigurationData system function.
Basic Functions for Modular Machines
Function Manual, 02/2012
91
Changing the active configuration or the active kernel
5.2 Activating a kernel
The chronological sequence of the activation of a kernel and the required configuration is
described in the Status diagram (Page 95).
The activated kernel and the activated configuration are retained after the SIMOTION device
is turned off. After the device is turned on (POWER ON), they are reloaded.
5.2.2
Example programs for activating a kernel
The following two examples for activating a kernel make a distinction between two scenarios:
● The configuration to be activated is not specified (see "Example without details of a
configuration to be activated")
● The configuration to be activated is specified (see "Example with details of a configuration
to be activated").
Basic Functions for Modular Machines
92
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.2 Activating a kernel
Example without details of a configuration to be activated
The following example shows the activation of a kernel without details of a configuration to
be activated.
After activating the kernel and restarting the system, the initial configuration will be loaded. In
this initial configuration, the required configuration will be determined, for example, by
evaluating a connector coding, and activated by calling the _activateConfiguration system
function again.
For information on the initial configuration, see "Selecting and activating a configuration
using an initial configuration" (Page 96).
Example for activating a kernel without details of a configuration to be
activated
// Variable declaration
VAR
retActivateConf : StructRetConfiguration;
newKernelId : UDINT;
// kernelId of the
// kernel to be loaded
END_VAR
newKernelId := 16#004156;
// Corresponds to directory
// VE004156
// Activate the required configuration
retActivateConf := _activateConfiguration(
projectData
:= NO,
// Mandatory parameters
projectDataId
:= UDINT#MAX,
// 16#FFFF_FFFF
kernel
:= YES,
kernelId
:= newKernelId,
timeOut
:= T#5m
// 5 minutes
);
IF ( 0 <> retActivateConf.result ) THEN
// Error response
; // ...
END_IF;
The timeOut parameter is described in detail in Section "Example of the activation of a
configuration" (Page 88). The time should be at least five minutes for the activation of a
kernel.
Basic Functions for Modular Machines
Function Manual, 02/2012
93
Changing the active configuration or the active kernel
5.2 Activating a kernel
Example with details of a configuration to be activated
The following example shows the activation of a kernel with details of a configuration to be
activated.
After activating the kernel and restarting the system, the configuration specified in the
projectDataId parameter will be loaded.
Example for activating a kernel with details of a configuration to be
activated
// Variable declaration
VAR
retActivateConf : StructRetConfiguration;
newKernelId : UDINT; // kernelId of the
// kernel to be loaded
configId
: UDINT; // projectDataId of the
// required configuration
END_VAR
newKernelId := 16#004156; //
//
configId
:= 16#000001; //
//
Corresponds to directory
VE004156
Corresponds to file
PR000001.ZIP
// Activate the required configuration
retActivateConf := _activateConfiguration (
projectData := YES,
projectDataId := configId,
kernel := YES,
kernelId := newKernelId,
timeOut := T#5m // 5 minutes
);
IF ( 0 <> retActivateConf.result ) THEN
// Error response
; // ...
END_IF;
The timeOut parameter is described in detail in Section "Example of the activation of a
configuration" (Page 88). The time should be at least five minutes for the activation of a
kernel.
Basic Functions for Modular Machines
94
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.2 Activating a kernel
5.2.3
Status diagram for activating a kernel
The figure below shows the chronological sequence for the activation of a kernel depending
on the projectData parameter (specification of a configuration to be activated).
1RUHTXHVWIRUNHUQHODFWLYDWLRQ
6WDUWBDFWLYDWH&RQILJXUDWLRQ
3DUDPHWHUNHUQHO <(6
ದ /RDG NHUQHO
ದ 5HVWDUW
$FWLYDWLRQRIWKHNHUQHO
.HUQHODFWLYDWLRQ2.
$1'
3DUDPHWHUSURMHFW'DWD <(6
.HUQHODFWLYDWLRQ2.
$1'
3DUDPHWHUSURMHFW'DWD 12
ದ /RDG LQLWLDO FRQILJXUDWLRQ
ದ 5HVWDUW
ದ /RDG UHTXLUHG FRQILJXUDWLRQ
ದ 5HVWDUW
$FWLYDWLRQRIWKHLQLWLDOFRQILJXUDWLRQ2.
ದ 'HWHUPLQH UHTXLUHG FRQILJXUDWLRQ
ದ 6WDUW BDFWLYDWH&RQILJXUDWLRQ
ದ /RDG UHTXLUHG FRQILJXUDWLRQ
ದ 5HVWDUW
$FWLYDWLRQRIWKHUHTXLUHGFRQILJXUDWLRQ
&RQILJXUDWLRQDFWLYDWLRQ2.
$FWLYDWLRQRIWKHLQLWLDOFRQILJXUDWLRQ
&RQILJXUDWLRQDFWLYDWLRQQRW2.
ದ /RDG LQLWLDO FRQILJXUDWLRQ
ದ 5HVWDUW
Figure 5-3
Status diagram for activating a kernel depending on the projectData parameter
Basic Functions for Modular Machines
Function Manual, 02/2012
95
Changing the active configuration or the active kernel
5.3 Selecting and activating a configuration using an initial configuration
5.3
Selecting and activating a configuration using an initial configuration
5.3.1
Selecting and activating a configuration using an initial configuration
Loading an initial configuration during ramp-up (after POWER ON) of a SIMOTION device
ensures that it can be integrated failure-free into a running communication network of
another device after switch-on.
For example, a SIMOTION device (machine module) is connected to a different SIMOTION
device (base machine). After POWER ON, the machine module ramps up, identifies its
position at the base machine (e.g. using a connector coding), and automatically loads the
required configuration.
The card images for all configurations that the SIMOTION device (machine module) can
transfer to the base machine is stored on its memory card. The initial configuration also
stored there will be loaded automatically after POWER ON. This identifies (e.g. using a
connector coding) the required configuration and loads it.
NOTICE
Note the following restrictions on configuring the initial configuration:
1. The interface to the base machine must be configured with a communication address
(e.g. PROFIBUS address or IP address) that is not used in the associated
communication network of the base machine.
This does not disturb communication in this network.
2. There must be no retentive data (e.g. retentive unit variables) in the user program. You
can check this with Reference data > Code attributes.
The retentive unit variables of the last activated configuration thereby remain intact.
3. No instances of technology objects may be configured.
This prevents retentive instance data of the technology objects. The retentive system
variables of the technology objects of the last active configuration remain intact.
4. No drives should be configured.
This reduces the loading time for the initial configuration.
The card image of the initial configuration (file name INITIAL.ZIP) is located in the INITIAL
subdirectory of the relevant kernel version (e.g. INSTALL\SIMOTION\VE004156). A detailed
description of how the card images of the initial configuration and the configurations to be
activated are created is provided in "Procedure for creating the card images of
configurations" (Page 104).
Basic Functions for Modular Machines
96
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.3 Selecting and activating a configuration using an initial configuration
SelfAdaptingConfiguration functionality
The initial configuration will be started automatically during ramp-up of the SIMOTION device
if the SelfAdaptingConfiguration functionality has been activated on its memory card. This
will be the case if the following actions have been performed:
● The /a"ON" option was also specified when creating the card images of the configurations
(Page 113) with the u7mkcnfx.exe program (/m"MAKE_STORE" option).
● In the last user program to run (before POWER OFF), the
_setModeSelfAdaptingConfiguration system function was called with the mode := ON
parameter.
This makes a corresponding entry on the memory card, which causes the initial configuration
to be loaded after POWER ON.
You can disable the SelfAdaptingConfiguration functionality by calling the
_setModeSelfAdaptingConfiguration system function with the mode := OFF parameter. This
makes a corresponding entry on the memory card, which causes the last active configuration
to be loaded after POWER ON.
The syntax of this system function is described in detail in the "System Functions/Variables
Devices" List Manual (reference list) and in the online help (see index).
Note
The activation and the deactivation of the SelfAdaptingConfiguration functionality only take
effect the next time the SIMOTION device is switched on (POWER ON).
NOTICE
In a communication network (PROFIBUS subnet or PROFINET or Ethernet segment), only
one SIMOTION device may be started concurrently with the SelfAdaptingConfiguration
functionality.
The existence of several nodes with the same communication addresses in a
communication network causes a fault.
Basic Functions for Modular Machines
Function Manual, 02/2012
97
Changing the active configuration or the active kernel
5.3 Selecting and activating a configuration using an initial configuration
NOTICE
When activating a configuration through an initial configuration, please note:
• Retentive global device variables are always initialized.
• The values of the following variables of the last active configuration can be preserved:
Retentive unit variables and retentive system variables of the technology objects.
Please note in this regard:
– The restrictions for the initial configuration given in the Notice information at the start
of this section
– The measures for the configuration to be activated described in "Retaining retentive
data in the event of a configuration change" (Page 102)
NOTICE
If one or more CX32 controller extensions are connected to a SIMOTION D4x5, please
note the following when activating a configuration with the _activateConfiguration function:
The activated configuration will only take effect on the CX32 controller extension after the
CX32 has been restarted. This restart must be specifically initiated by the user, as the
_activateConfiguration function does not perform a restart automatically.
Note the information in the section titled "Special considerations when a CX32 controller
extension is connected" (Page 87).
Basic Functions for Modular Machines
98
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.3 Selecting and activating a configuration using an initial configuration
5.3.2
Status diagram for what happens when a SIMOTION device is switched on
depending on whether or not the SelfAdaptingConfiguration functionality is
active
32:(521
6HOI$GDSWLQJ&RQILJXUDWLRQ21
ದ /RDG LQLWLDO FRQILJXUDWLRQ WR 5$0 GLVN
6HOI$GDSWLQJ&RQILJXUDWLRQ2))
ದ /RDG ODVW DFWLYH FRQILJXUDWLRQ
5811,1*B,1,7,$/B&21),*85$7,21
ದ ,GHQWLI\ PDFKLQH PRGXOH
ದ 'HWHUPLQH UHTXLUHG FRQILJXUDWLRQ
ದ $FWLYDWH UHTXLUHG FRQILJXUDWLRQ E\
FDOOLQJBDFWLYDWH&RQILJXUDWLRQ
5HTXLUHGFRQILJXUDWLRQVDPHDVODVWDFWLYH
FRQILJXUDWLRQ
5HTXLUHGFRQILJXUDWLRQGLIIHUHQWIURPODVW
DFWLYHFRQILJXUDWLRQ
ದ 5HVWDUW
ದ /RDG ODVW DFWLYH FRQILJXUDWLRQ
ದ 6DYH UHTXLUHG FRQILJXUDWLRQ DV DFWLYH
ದ 5HVWDUW
ದ /RDG UHTXLUHG FRQILJXUDWLRQ
5811,1*B/$67B/2$'('B&21),*85$7,21
Figure 5-4
5811,1*B5(48(67('B,'(17,),('B&21),*85$7,21
Status diagram for what happens when a SIMOTION device is switched on depending on whether or not the
SelfAdaptingConfiguration functionality is active
When the device is switched on (POWER ON), the SIMOTION performs a one-off run
through the status diagram:
● If the SelfAdaptingConfiguration functionality is activated, the initial configuration will be
loaded.
The initial configuration identifies the position of the machine module on the base
machine, determines the required configuration, and activates it using the
_activateConfiguration system function.
The system function checks whether the configuration to be activated is identical to the
most recently active configuration:
– Identical: After the device restart, the most recently active configuration will be loaded.
– Not identical: The required configuration will be saved as the active configuration and
will be loaded after a device restart.
● If the SelfAdaptingConfiguration functionality is deactivated, the most recently active
configuration will be loaded.
Basic Functions for Modular Machines
Function Manual, 02/2012
99
Changing the active configuration or the active kernel
5.3 Selecting and activating a configuration using an initial configuration
5.3.3
Example program for an initial configuration
The following example program shows the determination and activation of a configuration in
the initial configuration:
Example for activating a configuration in an initial configuration
// Variable declaration
VAR
ipRead
: ARRAY [1..2] OF StructRetIpConfig;
setIpAddress
: ARRAY [0..5] OF USINT;
setIpSubnet
: ARRAY [0..5] OF USINT;
setIpGateway
: ARRAY [0..5] OF USINT;
retUdint
: UDINT;
retActivateConf : StructRetConfiguration;
// IP address and projectDataId of the configuration are
// read from output with address 0.
ip_conf_id AT %IB0 : USINT;
END_VAR
// Read the current data of the Ethernet interfaces
ipRead[1] := _getIpConfig (
ethernetInterface:= IE_01);
ipRead[2] := _getIpConfig (
ethernetInterface:= IE_02);
// Change of the Ethernet interface IE_01.
// Check whether a change is necessary.
IF ( ip_conf_id <> ipRead[1].ipAddress[3] ) THEN
// Make available the data to be changed
setIpAddress
:= ipRead[1].ipAddress;
setIpAddress[3] := ip_conf_id;
setIpSubnet
:= ipRead[1].subnetMask;
setIpGateway
:= ipRead[1].gatewayAddress;
// Check whether, following the change, the subnet masks
// of the two Ethernet interfaces are different:
IF ( ipRead[2].subnetMask <> setIpSubnet ) THEN
// Set the data of the Ethernet interface IE_01
retUdint := _setIpConfig (
ethernetInterface := IE_01,
ipAddress
:= setIpAddress,
subnetMask
:= setIpSubnet,
gatewayAddress
:= setIpGateway
);
// Activate the required configuration
retActivateConf := _activateConfiguration(
projectData
:= YES,
projectDataId := ip_conf_id,
timeOut
:= T#1m // 1 minute
);
ELSE
; // No change, error response,
// change interface IE_02 too, if necessary.
END_IF;
END_IF
Basic Functions for Modular Machines
100
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.4 Reading the activation state of configurations
5.4
Reading the activation state of configurations
You can use the _getConfigurationData function to query the status of the last two calls of
the _activateConfigurationsystem function.
The syntax of this system function is described in detail in the "System Functions/Variables
Devices" List Manual (reference list) and in the online help (see index).
A description of some input parameters follows:
● You specify in the configurationInfoId parameter (EnumConfigurationInfoId data type), the
configuration whose status you want to query:
– ACTUAL_ACTIVATED: The status of the currently active configuration (last call of the
_activateConfiguration function) will be queried.
– PREVIOUS_ACTIVATED: The status of the previously active configuration (next to
last call of the _activateConfiguration function) will be queried.
● In the requestMode parameter (EnumReqSysFunctMode data type), you specify whether
the actual function (query of the configuration state) is to be executed or whether the
status of the command is to be queried.
– REQUEST_TRUE: The function (query of the configuration state) will be executed.
– REQUEST_FALSE: The query of the status of the command will be executed
(required for asynchronous call)
The same principles illustrated by the Status diagram for the functions _activateTo and
_deactivateTo (Page 75) and _getStateOfTo, apply.
● You specify in the nextCommand parameter (EnumNextCommandMode data type) when
the next command is to be executed:
– IMMEDIATELY: Immediately (asynchronous call - required for cyclic tasks)
See "Asynchronous call for the functions _activateTo and _deactivateTo" (Page 77).
– WHEN_COMMAND_DONE: After the completion of the command (synchronous call recommended for MotionTasks).
See "Synchronous call for the functions _activateTo and _deactivateTo" (Page 79).
The return value (StructRetGetConfigurationData data type) shows
● In the functionResult component (DINT data type), the general result of the function call
● In the configuration component (StructDeviceConfigurationData data type):
– The general status of the _activateConfiguration function
– The value of the timeOut parameter
And for each functionality to be activated (configuration, technology object, drive, kernel)
– Its activation status
– The activation request placed in _activateConfiguration
– The ID of the functionality to be loaded (e.g. the projectDataId of the configuration)
The example program below shows the status query for a configuration with a synchronous
call.
Basic Functions for Modular Machines
Function Manual, 02/2012
101
Changing the active configuration or the active kernel
5.5 Retaining retentive data in the event of a configuration change
Example program for the _getConfigurationData (synchronous call) function
// Variable declaration
VAR
configurationInfoId
: EnumConfigurationInfoId;
locRequest
: EnumReqSysFunctMode;
nextCommand
: EnumNextCommandMode;
locCommandId
: CommandIdType;
retConfigurationInfo
: StructRetGetConfigurationData;
END_VAR
// Provide the parameter data
configurationInfoId := PREVIOUS_ACTIVATED;
locRequest
:= REQUEST_TRUE; // Start request
nextCommand
:= WHEN_COMMAND_DONE; // Synchronous call
locCommandId
:= _getCommandId ();
// Query status
retConfigurationInfo := _getConfigurationData (
configurationInfoId := configurationInfoId,
requestMode
:= locRequest,
commandId
:= locCommandId,
nextCommand
:= nextCommand
);
// Check and evaluate result
If ( 0 <> retConfigurationInfo.functionResult ) THEN
; // ... Error response
ELSE
; // ... Evaluate the structure
//
retConfigurationInfo.configuration
END_IF;
5.5
Retaining retentive data in the event of a configuration change
The following section describes which measures you must adopt so that the following
retentive data is retained during a change of configuration:
● Retentive unit variables
● Retentive system variables of the technology objects (e.g. absolute encoder adjustment)
NOTICE
Note when activating a configuration:
• Retentive global device variables are always initialized.
• Without the described measures, retentive unit variables and retentive system variables
of the technology objects are also initialized.
Basic Functions for Modular Machines
102
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.5 Retaining retentive data in the event of a configuration change
Measures for retaining retentive unit variables
Proceed as follows to ensure the values of retentive unit variables are retained (not
initialized) during a configuration change:
1. Declare the retentive unit variables in a separate unit with the same identifier and the
same object address in all configurations.
2. Ensure that an identical data structure is used in all configurations within this unit particularly because of HMI device access.
3. Use several declaration blocks in the unit, if necessary.
The retentive unit variables thus receive the same version code in all configurations.
If the retentive unit variables in the most recently activated configuration and the
configuration to be activated have the same version code, they are not initialized.
Note
When activating a configuration using an initial configuration, please also note the
restrictions for the initial configuration given in Selecting and activating a configuration using
an initial configuration (Page 96) (in the Notice information).
NOTICE
If you do not observe the above procedure, the retentive unit variables will be initialized
when a different configuration is activated.
Also ensure the following setting is made for the download: The initialization of retentive
variables must be disabled (Options > Settings menu, Download tab).
Alternatively, unit variables even with functions _exportUnitDataSet and _importUnitDataSet
can be exported, saved and imported again.
Measures for retaining the retentive system variables of technology objects
Proceed as follows to ensure the retentive system variables of technology objects are
retained (not initialized) during a configuration change.
Configure the SIMOTION devices and the technology objects in the following manner in all
configurations:
1. Set the system variable of the SIMOTION device
_configurationManagement.preserveToRetainData := YES in offline.
2. Assign identical identifiers and object addresses for the same technology objects.
This prevents the retentive system variables of a technology object from being initialized
when the following conditions are met in the last configuration activated and the
configuration to be activated:
1. Identifier and object address of the technology object are identical.
2. The structure of the retentive system variables of the technology object is the same.
Basic Functions for Modular Machines
Function Manual, 02/2012
103
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
Note
When activating a configuration using an initial configuration, please also note the
restrictions for the initial configuration given in Selecting and activating a configuration using
an initial configuration (Page 96) (in the Notice information).
NOTICE
If you do not observe the above procedure, the retentive system variables of a technology
object will be initialized when a different configuration is activated.
The _configurationManagement.preserveToRetainData system variable can only be
changed in offline mode and takes effect after the configuration has been activated or
downloaded. It cannot be changed in online mode or in a user program.
The setting for the download for the initialization of retentive variables (Options > Settings
menu, Download tab) has no effect.
5.6
Procedure for creating the card images of configurations
The individual steps of how to create the card images of the configurations and the
associated kernel are described in the following.
1. Preparing the memory card of the SIMOTION device (Page 105)
2. Creating the work directories on the PC/PG (Page 105)
3. Saving the configuration files in the work directories on the PC/PG (Page 109)
4. Creating the compressed configuration files (Page 111)
5. Saving the kernel in the work directory on the PC/PG (Page 112)
6. Creating the card images of the configurations (Page 113)
Note
The following steps can also be automated by means of SCOUT scripting. Appropriate
scripts are shown in the appendix in "Creating the card images for configuration servers by
means of SCOUT scripting" (Page 118).
Basic Functions for Modular Machines
104
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
5.6.1
Preparing the memory card of the SIMOTION device
Check the following:
1. The memory card is formatted with the FAT16 file system.
2. The SIMOTION kernel for the associated SIMOTION device is present on the card.
5.6.2
Creating the work directories on the PC/PG
You must create the required work directories in the file directory of the PC/PG on which the
SIMOTION SCOUT engineering software is installed.
The directory structures for the following applications are described in the following:
1. Activation of a kernel (e.g. update to a new version) with several associated
configurations
2. Activation of several kernels (e.g. various firmware versions) each with several
associated configurations
Directory structure for a kernel with several associated configurations
You want to activate, for example, a new kernel with three configurations and create the
required card images. The following is a detailed description of how to create the required
work directories on the PC/PG.
You require a work directory for storing all the generated data (e.g. D:\modular_machine). In
this directory you require three further directories each with specific subdirectories for each
individual configuration:
● One directory (e.g. download) for storing the uncompressed (executable) configuration
files.
In this directory, you require a subdirectory with the DExxxxxx designation for each
configuration, where xxxxxx is a hexadecimal number. With this number, you specify the
associated configuration for the call of the _activateConfiguration (Page 85) system
function.
● One directory (e.g. zip) for storing the compressed configuration files.
In this directory too, you require a subdirectory with the DExxxxxx designation for each
configuration, where xxxxxx is a hexadecimal number. With this number, you specify the
associated configuration for the call of the _activateConfiguration (Page 85) system
function.
● One directory (e.g. cardfiles) for storing the card images.
You must duplicate the directory structure on the memory card in this directory. This is
described in Section "Activation of a kernel" (Page 90).
Basic Functions for Modular Machines
Function Manual, 02/2012
105
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
You create these directories with the corresponding subdirectories with the command line
application u7mkcnfx.exe as follows:
1. In the Windows Explorer, create a directory that you want to use to store all generated
files (e.g. D:\modular_machine).
2. Create a batch file (e.g. make_dirs.bat).
Basic Functions for Modular Machines
106
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
3. Edit this batch file. Write a command line to start the u7mkcnfx.exe application with the
following options:
– /m"Mode" option: /m"MAKE_DIRS".
– /l"Load Path" option: Specification of the complete path for the directory for storing the
uncompressed configuration files (e.g. /l"d:\modular_machine\download").
– /s"Source Path" option: Specification of the complete path for the directory for storing
the compressed configuration files (e.g. /s"d:\modular_machine\zip").
– /d"Destination Path" option: Specification of the complete path for the directory for
storing the card images (e.g. /d"d:\modular_machine\cardfiles").
– /i"Identifier" option: Specification of the identifier for the version of the SIMOTION
kernel in the form VEyyyyyy, where yyyyyy is a hexadecimal number
(e.g. /i"VE004156"). With this number you specify the kernel version for the call of the
_activateConfiguration system function (see Activating a kernel (Page 90)).
– /n"Number of Projects" option: Specification of the number of configurations for which
the subdirectories are to be created.
Example:
rem make_dirs.bat Create work directories
rem The command must be written in a command line
u7mkcnfx /m"MAKE_DIRS"
/l"d:\modular_machine\download"
/s"d:\modular_machine\zip"
/d"d:\modular_machine\cardfiles"
/i"VE004156" /n"3"
pause
The syntax of the command line application u7mkcnfx.exe is described in the appendix in
Command line application u7mkcnfx.exe (Page 115).
4. Execute the batch file.
The directories for the uncompressed and compressed configuration files as well as the
directory for the card images are created. The following is also created:
– In the directories for the uncompressed and compressed configuration files (e.g.
download), the following subdirectories:
DE000001, DE000002,
etc.: Consecutively numbered directories for the files of the
associated configuration, in accordance with the number of configurations. The
identifier of these directories (DExxxxxx), corresponds to xxxxxx of a hexadecimal
number with which you identify the respective configuration when calling the
_activateConfiguration system function (see Activating a configuration (Page 85)).
INITIAL:
KERNEL:
Directory for the files of the initial configuration
Directory for storing the kernel
– In the directory for the card images (e.g. cardfiles), the following
INSTALL\SIMOTION subdirectory containing a subdirectory with the identifier
specified with the /i"Identifier" option (e.g. VE004156).
Basic Functions for Modular Machines
Function Manual, 02/2012
107
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
Further directories, not specified here, are created within these subdirectories.
The figure below shows an example of the directory structure for three configurations
identified by means of 16#000001, 16#000002, and 16#000003.
Figure 5-5
Directory structure for one kernel with three configurations
Note
The steps described in this section can also be automated by means of SCOUT scripting. A
corresponding script is shown in the appendix under "Creating the work directories on the
PC/PG" (Page 120).
Directory structure for several kernel versions with the respective associated configurations
If you want to create the card images for several kernel versions with their respective
associated configurations, proceed as follows:
1. Create the work directories (e.g. download, zip, cardfiles) as described above.
2. Create the new directories corresponding to the number of kernel versions and assign
them unique names (e.g. VE004153 and VE004156).
3. Copy of move the download and zip directories to the directories that you have just
created (e.g. VE004153 and VE004156).
4. In the cardfiles\INSTALL\SIMOTION directory, copy the VEyyyyyy directory (e.g. VE004156)
corresponding to the number of kernel versions. Assign unique names to the copies in
the form of VEyyyyyy, where yyyyyy is a hexadecimal number (e.g. VE004153).
Basic Functions for Modular Machines
108
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
The following figure shows the resulting directory structure:
Figure 5-6
5.6.3
Directory structure for two kernels each with three configurations
Saving the configuration files in the work directories on the PC/PG
This section describes how you can save different configurations for a kernel (e.g. for a
kernel update) in the work directories on the PC/PG.
Requirements
You have created a project in the SIMOTION SCOUT engineering system in which the
required configurations are configured as dedicated devices (with technology objects,
programs, etc.).
This project has been compiled without errors.
If an initial configuration (Page 96) is required, it must also be configured as a dedicated
device.
NOTICE
All SIMOTION devices must be configured with the same version of the SIMOTION kernel.
Basic Functions for Modular Machines
Function Manual, 02/2012
109
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
Procedure
This description applies to:
● All SIMOTION C2xx, P3xx and D4xx-2 devices, regardless of the SIMOTION kernel
version
● The SIMOTION D4xx device, as of SIMOTION kernel version V4.1.5 (V4.1 SP5)
Note
For the procedure with SIMOTION D4xx devices up to version V4.1.4 (V4.1 SP4) of the
SIMOTION kernel: See the appendix, "Storing configuration files for SIMOTION D4xx
devices up to kernel version V4.1.4 (Page 128)".
To store the configuration files in the work directories on the PC/PG:
1. Select the appropriate device in the project navigator.
2. Select (alternatively):
– The Edit > Load to file system menu or
– The Load to file system context menu
3. In the window, select: Save normally.
4. Click the Select target button to select the directory.
5. Select the directory for the uncompressed configuration files (e.g.
D:\modular_machine\download).
In this directory, select the DExxxxxx folder with which you can identify the configuration by
the hexadecimal number in the file name (xxxxxx), and confirm with OK.
The device with all technology objects and programs is compiled and saved in the
specified directory in the USER subdirectory.
6. Repeat steps 1 to 5 for all devices, other than the device that represents the initial
configuration.
Save the configuration files of the initial configuration in the INITIAL directory.
Note
The steps described in this section can also be automated by means of SCOUT scripting. A
corresponding script is shown in the appendix at "Storing the configuration files in the file
system" (Page 121).
Basic Functions for Modular Machines
110
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
5.6.4
Creating the compressed configuration files
Proceed as follows to compress the configuration files
1. Create a batch file (e.g. make_zip.bat).
2. Edit this batch file. Write a command line for each configuration to start the
u7mkcnfx.exeapplication with the following options:
– /m"Mode" option: /m"MAKE_ZIP"
– /s"Source Path" option: Specification of the complete path in which the uncompressed
files of the respective configuration are stored
(e.g. /s"d:\modular_machine\download\DE000001").
– /d"Destination Path" option: Specification of the complete path for the directory for
storing the compressed configuration files (e.g. /d"d:\modular_machine\zip").
– /i"Identifier" option: Specification of the subdirectory in which the compressed files of
the respective configuration are stored. This name is identical to the name of the
corresponding subdirectory for the uncompressed files (e.g. /i"DE000001").
You use the hexadecimal number in the name to specify the configuration for the call
of the _activateConfiguration system function (see Activating a configuration
(Page 85)).
You create the compressed files of the initial configuration with the /i"INITIAL" option.
Example:
rem make_zip.bat Compress configuration files
rem The command must be written in a command line
u7mkcnfx /m"MAKE_ZIP"
/s"d:\modular_machine\download\DE000001"
/d"d:\modular_machine\zip" /i"DE000001"
u7mkcnfx /m"MAKE_ZIP"
/s"d:\modular_machine\download\DE000002"
/d"d:\modular_machine\zip" /i"DE000002"
u7mkcnfx /m"MAKE_ZIP"
/s"d:\modular_machine\download\DE000003"
/d"d:\modular_machine\zip" /i"DE000003"
rem Compress files of the initial configuration
u7mkcnfx /m"MAKE_ZIP"
/s"d:\modular_machine\download\initial"
/d"d:\modular_machine\zip" /i"INITIAL"
pause
Basic Functions for Modular Machines
Function Manual, 02/2012
111
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
The syntax of the command line application u7mkcnfx.exeis described in the appendix in
Command line application u7mkcnfx.exe (Page 115).
3. Execute the batch file.
The compressed files are created in the specified directories (the PROJECT.ZIP file in each
PROJECTsubdirectory).
Note
The steps described in this section can also be automated by means of SCOUT scripting. A
corresponding script is shown in the appendix in "Creating the compressed configuration
files" (Page 122).
5.6.5
Saving the kernel in the work directory on the PC/PG
You can obtain the kernel (firmware) suitable for the stored configurations in two ways:
● As of version V4.1 of the SIMOTION Kernel, directly from a SIMOTION device that is
connected via Ethernet to the PC/PG:
You can download the kernel from the device with the SIMOTION IT DIAG function
package contained in the kernel, which enables direct diagnostics of the SIMOTION
device via an HTML standard browser.
To do this, call the Manage Config standard page and also the Device update tab.
Activate the FW checkbox.
The procedure is described in the "SIMOTION IT Diagnostics and Configuration"
Diagnostics Manual.
You are provided with a ZIP archive (file name name.zip) that contains the KERNEL.ZIP
file.
SIMOTION P3xx devices do not support kernel download.
● Irrespective of the version of the SIMOTION Kernel as download from the SIMOTION
Service and Support pages on the Internet:
http://support.automation.siemens.com/WW/view/en/10805436
Rename the ZIP archive that you have downloaded to KERNEL.ZIP.
The KERNEL:ZIP file contains the SIMOTION Kernel of the respective device as well as the
SINAMICS Integrated firmware for the SIMOTION D4xx and D4xx-2 devices.
Proceed as follows:
1. Open the directory for the compressed configuration files (e.g. D:\modular_machine\zip).
2. Copy the KERNEL.ZIP file to the KERNEL\PROJECT subdirectory.
Basic Functions for Modular Machines
112
Function Manual, 02/2012
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
5.6.6
Creating the card images of the configurations
Requirement
A read/write device for the memory card is connected to the PC.
Proceed as follows to create the card images and copy them to the memory card
1. Create a batch file (e.g. make_store.bat).
2. Edit this batch file. Write a command line to start the u7mkcnfx.exe application with the
following options:
– /m"Mode" option:/m"MAKE_STORE".
– /s"Source Path" option: Specification of the complete path for the directory for storing
the compressed configuration files (e.g. /d"d:\modular_machine\zip").
– /d"Destination Path" option: Specification of the complete path for the directory for
storing the card images (e.g. /d"d:\modular_machine\cardfiles").
– /a"ModeSelfAdaptingConfiguration" option: Specification of whether the initial
configuration, in which the appropriate configuration is selected, should be
automatically loaded after POWER ON (see Selecting and activating a configuration
using an initial configuration (Page 96)):
/a"ON":
The initial configuration is started after each POWER ON.
/a"OFF":
The initial configuration is not started after POWER ON.
/i"Identifier" option: Specification of the identifier for the version of the SIMOTION
kernel (as described in Creating the work directories on the PC/PG (Page 105)). The
identifier has the form VEyyyyyy, where yyyyyyis a hexadecimal number
(e.g. /i"VE004156"). With this number you specify the kernel version for the call of the
_activateConfiguration system function (see Activating a kernel (Page 90)).
Example:
rem make_store.bat Create card images
rem The command must be written in a command line
u7mkcnfx /m"MAKE_STORE" /s"d:\modular_machine\zip"
/d"d:\modular_machine\cardfiles"
/a"ON" /i"VE004156"
pause
The syntax of the command line application u7mkcnfx.exe is described in the appendix in
Command line application u7mkcnfx.exe (Page 115).
Basic Functions for Modular Machines
Function Manual, 02/2012
113
Changing the active configuration or the active kernel
5.6 Procedure for creating the card images of configurations
1. Execute the batch file.
The card images are created in the \INSTALL\SIMOTION\VEyyyyyysubdirectory of the
directory specified for the card images (e.g. D:\modular_machine\cardfiles):
– The PROJECTsubdirectory contains the card images of the configurations in the form
PRxxxxxx.ZIP, where xxxxxxis the hexadecimal number which was defined in the
DExxxxxxidentifier when the compressed files were created (see Creating the
compressed configuration files (Page 111)).
– The INITIALsubdirectory contains the card image of the initial configuration
INITIAL.ZIP.
– The PACKAGEsubdirectory contains the card image of the technology packages.
– The KERNELsubdirectory contains the card image of the SIMOTION kernel KERNEL.ZIP.
A BOOT.INI file is also created in the specified directory
(e.g. D:\modular_machine\cardfiles).
2. Copy the following from the directory of the card images
(e.g. D:\modular_machine\cardfiles) to the memory card's root directory:
– The INSTALLdirectory with all subdirectories and files
– The BOOT.INI file
Overwrite any files and directories that exist.
Note
The steps described in this section can also be automated by means of SCOUT scripting. A
corresponding script is shown in the appendix in "Creating the card images of the
configurations" (Page 124).
Basic Functions for Modular Machines
114
Function Manual, 02/2012
A
Appendix
A.1
Command line application u7mkcnfx.exe
Command line application for Windows, with which the card images of the configurations and
the SIMOTION kernel are created in several steps (/m"Mode" option).
Options
The following options are available:
/m"Mode"
Specification of the functional principle of the command line application.
/m"MAKE_DIRS"
Creating the work directories
The following additional options must be specified:
• /s"Source Path"
• /d"Destination Path"
• /i"Identifier"
The following options can be specified:
• /l"Load Path"
• /n"Number of projects"
For application information and an example, see Section Creating the
work directories on the PC/PG (Page 105) and Creating the work
directories on the PC/PG (Page 120) in the appendix.
/m"MAKE_ZIP"
Compressing individual configurations
The following additional options must be specified:
• /s"Source Path"
• /d"Destination Path"
• /i"Identifier"
For application information and an example, see the section titled
Creating the compressed configuration files (Page 111) and Creating
the compressed configuration files (Page 122) in the appendix.
/m"MAKE_ZIP_ALL"
Compressing all configurations
The following additional options must be specified:
• /s"Source Path"
• /d"Destination Path"
Basic Functions for Modular Machines
Function Manual, 02/2012
115
Appendix
A.1 Command line application u7mkcnfx.exe
/m"MAKE_STORE"
Creating card images
The following additional options must be specified:
• /s"Source Path"
• /d"Destination Path"
• /a"Mode Self Adapting Configuration"
• /i"Identifier"
For application information and an example, see Section Creating the
card images of the configurations (Page 113) and Creating the card
images of the configurations (Page 113) in the appendix.
/m"MAKE_STORE_AR Archiving card images
CHIVE"
The following additional options must be specified:
• /s"Source Path"
• /d"Destination Path"
• /i"Identifier"
For application information and an example, see Creating the card
images of the configurations (Page 124) in the appendix.
/s"Source Path"
Specification of the complete path for the source directory
● For options /m"MAKE_DIRS" and /m"MAKE_STORE"
Specification of the complete path for the directory for storing the compressed
configuration files (e.g. /s"d:\modular_machine\zip").
● For option /m"MAKE_STORE_ARCHIVE"
Specification of the complete path for the directory for storing the card images
(e.g. /s"d:\modular_machine\cardfiles").
● For option /m"MAKE_ZIP"
Specification of the complete path in which the uncompressed files of the respective
configuration are stored (e.g. /s"d:\modular_machine\download\DE000001").
● For option /m"MAKE_ZIP_ALL"
Specification of the complete path for the directory for storing the uncompressed
configuration files (e.g. /s"d:\modular_machine\download").
Basic Functions for Modular Machines
116
Function Manual, 02/2012
Appendix
A.1 Command line application u7mkcnfx.exe
/d"Destination Path"
Specification of the complete path for the source directory
● For options /m"MAKE_DIRS" and /m"MAKE_STORE"
Specification of the complete path for the directory for storing the card images
(e.g. /d"d:\modular_machine\cardfiles").
● For option /m"MAKE_STORE_ARCHIVE"
Specification of the complete path for the directory for storing the card images (e.g.
/d"d:\modular_machine\cfes").
● For options /m"MAKE_ZIP" and /m"MAKE_ZIP_ALL"
Specification of the complete path for the directory for storing the compressed
configuration files (e.g. /d"d:\modular_machine\zip").
/l"Load Path"
Optional, only for option /m"MAKE_DIRS"
Specification of the complete path for the directory for storing the uncompressed
configuration files (e.g. /l"d:\modular_machine\download").
/i"Identifier"
Only for options m/"MAKE_DIRS", /m"MAKE_STORE" and m/"MAKE_ZIP
● For options /m"MAKE_DIRS", /m"MAKE_STORE" and /m"MAKE_STORE_ARCHIVE"
Specification of the identifier for the version of the SIMOTION kernel. The identifier has
the form VEyyyyyy, where yyyyyyis a hexadecimal number (e.g. /i"VE004156"). With this
number you specify the kernel version for the call of the _activateConfiguration system
function (see Activating a kernel (Page 90)).
● For option /m"MAKE_ZIP"
Specification of the subdirectory in which the compressed files of the respective
configuration are stored. This name is identical to the name of the corresponding
subdirectory for the uncompressed files (e.g. /i"DE000001").
You use the hexadecimal number in the name to specify the configuration for the call of
the _activateConfiguration system function (see Activating a configuration (Page 85)).
You create the compressed files of the initial configuration with the /i"INITIAL" option.
Basic Functions for Modular Machines
Function Manual, 02/2012
117
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
/a"Mode Self Adapting Configuration"
Only for option /m"MAKE_STORE"
Specification of whether the initial configuration, in which the appropriate configuration is
selected, should be automatically loaded after POWER ON (see Selecting and activating a
configuration using an initial configuration (Page 96)).
/a"ON" The initial configuration is started after each POWER ON.
/a"OFF" The initial configuration is not started after POWER ON.
/n"Number of projects"
Only for option /m"MAKE_DIRS"
Specification of the number of subdirectories to be created for the individual configurations.
For /n"3", for example, three subdirectories DE000001, DE000002and DE000003are created.
These configurations are identified by the hexadecimal numbers 16#00001, 16#00002 and
16#00003.
A.2
Creating the card images for the configuration server by means of
SCOUT scripting
This function is available in SIMOTION kernel as of version V4.1.
The steps for creating the card images of configurations (as described in Procedure for
creating the card images of configurations (Page 104)) can be largely automated by means
of SCOUT scripting.
After you have set up the folder for the scripts (Creating the script folder in the SCOUT
project (Page 119)), create the individual scripts for the following tasks:
● Creating the work directories on the PC/PG (Page 120)
● Saving the configuration files in the work directories on the PC/PG (Page 121)
● Creating the compressed configuration files (Page 122)
● Creating the card images of the configurations (Page 124)
Script to call up the individual scripts to create the card image (Page 125) in the appendix
defines another script which calls up the ones specified above.
Basic Functions for Modular Machines
118
Function Manual, 02/2012
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
A.2.1
Creating the script folder in the SCOUT project
First, you must set up the folder in the engineering system (e.g. SIMOTION SCOUT) in
which the scripts will be stored.
Proceed as follows:
1. Select the project in the project navigator.
2. Select the Expert > Insert script folder context menu.
The SCRIPTS folder is created in the project. The scripts defined in the following sections
are stored in this folder.
Proceed as follows to create a script in this folder:
1. Select the folder.
2. Select the Insert new object > Script context menu.
3. Specify the name.
4. Confirm with OK.
Basic Functions for Modular Machines
Function Manual, 02/2012
119
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
A.2.2
Creating the work directories on the PC/PG
The following script "createDirsModMach" deletes any directories present in the
d:\modular_machine directory and also sets up the required directories there (see also
Creating the work directories on the PC/PG (Page 105)).
' createDirsModMach
App.LogActive = True
APP.LogMode = 1
Set objFso = CreateObject("Scripting.FileSystemObject")
basePath = "d:\modular_machine"
App.PrintToLog "remove dirs ...\cardfiles ..." _
& "\download ...\zip ...\cfes"
If (objFso.FolderExists(basePath)) Then
App.PrintToLog "delete folder basePath"
call objFso.deleteFolder(basePath)
End If
If not (objFso.FolderExists(basePath)) Then
App.PrintToLog "create basePath ...\modMach"
Call objFso.createFolder(basePath)
End If
createPath = basePath & "\cardfiles"
App.PrintToLog "path: " & createPath
If not (objFso.FolderExists(createPath)) Then
App.PrintToLog "create folder ...\cardfiles"
Call objFso.createFolder(createPath)
End If
createPath = basePath & "\cfes"
App.PrintToLog "path: " & createPath
If not (objFso.FolderExists(createPath)) Then
App.PrintToLog "create folder ...\cfes"
Call objFso.createFolder(createPath)
End If
createPath = basePath & "\download"
App.PrintToLog "path: " & createPath
If not (objFso.FolderExists(createPath)) Then
App.PrintToLog "create folder ...\download"
Call objFso.createFolder(createPath)
End If
Basic Functions for Modular Machines
120
Function Manual, 02/2012
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
createPath = basePath & "\zip"
App.PrintToLog "path: " & createPath
If not (objFso.FolderExists(createPath)) Then
App.PrintToLog "create folder ...\zip"
Call objFso.createFolder(createPath)
End If
createPath = basePath & "\export"
App.PrintToLog "path: " & createPath
If not (objFso.FolderExists(createPath)) Then
App.PrintToLog "create folder ...\export"
Call objFso.createFolder(createPath)
End If
App.LogActive = False
A.2.3
Saving the configuration files in the work directories on the PC/PG
The following script "downl" stores the configuration files of the configured device in the
download directory (see also Storing the configuration files in the file system (Page 109)).
' downl
' download project-data into filesystem of hd
App.LogActive = True
APP.LogMode = 1
'App.PrintToLog "update project"
basePath = "d:\modular_machine"
App.PrintToLog "download into filesystem"
'APP.Time 1
App.PrintToLog "D435_1"
downloadPath = basePath & "\download\1"
call PROJ.Devices("D435_1").DownloadFileSystem _
( downloadPath, "overwrite" ) ', FALSE )
App.PrintToLog "D435_2"
downloadPath = basePath & "\download\2"
call PROJ.Devices("D435_2").DownloadFileSystem _
( downloadPath, "overwrite" ) ', FALSE )
App.PrintToLog "D435_3"
downloadPath = basePath & "\download\3"
call PROJ.Devices("D435_3").DownloadFileSystem _
( downloadPath, "overwrite" ) ', FALSE )
Basic Functions for Modular Machines
Function Manual, 02/2012
121
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
App.PrintToLog "D435_initial"
downloadPath = basePath & "\download\initial"
call PROJ.Devices("D435_initial").DownloadFileSystem _
( downloadPath, "overwrite" ) ', FALSE )
App.PrintToLog "end script download"
App.LogActive = False
A.2.4
Creating the compressed configuration files
The following script "makezip" compresses the configuration files present in the download
directory and stores them in the zip directory (see also Creating the compressed
configuration files (Page 111)).
' makezip
Dim WshShell, oExec', script
Set WshShell = CreateObject("WScript.Shell")
basePath = "d:\modular_machine"
App.LogActive = True
App.PrintToLog "make_zip 1"
App.LogActive = false
sourcePath = basePath & "\download\1"
destinationPath = basePath & "\zip"
Set oExec = WshShell.Exec _
("C:\Program Files\siemens\step7\s7bin\u7mkcnfx " _
& " /m""MAKE_ZIP""" _
& " /s""" & sourcePath & """" _
& " /d""" & destinationPath & """" _
& " /i""DE000001""")
'
needed !!! for waiting end execute zip
Do While oExec.Status = 0
APP.time 1
Loop
App.LogActive = True
App.PrintToLog "make_zip 2"
App.LogActive = false
sourcePath = basePath & "\download\2"
destinationPath = basePath & "\zip"
Set oExec = WshShell.Exec _
("C:\Program Files\siemens\step7\s7bin\u7mkcnfx " _
Basic Functions for Modular Machines
122
Function Manual, 02/2012
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
&
&
&
&
'
"
"
"
"
/m""MAKE_ZIP""" _
/s""" & sourcePath & """" _
/d""" & destinationPath & """" _
/i""DE000002""")
needed !!! for waiting end execute zip
do While oExec.Status = 0
APP.Time 1
loop
App.LogActive = True
App.PrintToLog "make_zip 3"
App.LogActive = false
'
sourcePath = basePath & "\download\3"
destinationPath = basePath & "\zip"
App.LogActive = false
Set oExec = WshShell.Exec _
("C:\Program Files\siemens\step7\s7bin\u7mkcnfx " _
& " /m""MAKE_ZIP""" _
& " /s""" & sourcePath & """" _
& " /d""" & destinationPath & """" _
& " /i""DE000003""")
'
needed !!! for waiting end execute zip
do While oExec.Status = 0
APP.Time 1
loop
App.LogActive = True
App.PrintToLog "make_zip initial"
App.LogActive = false
sourcePath = basePath & "\download\initial"
destinationPath = basePath & "\zip"
Set oExec = WshShell.Exec _
("C:\Program Files\siemens\step7\s7bin\u7mkcnfx " _
& " /m""MAKE_ZIP""" _
& " /s""" & sourcePath & """" _
& " /d""" & destinationPath & """" _
& " /i""INITIAL""")
'
needed !!! for waiting end execute zip
do While oExec.Status = 0
APP.Time 0.1
loop
Basic Functions for Modular Machines
Function Manual, 02/2012
123
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
A.2.5
Creating the card images of the configurations
The following script "makestore" creates the corresponding card images from the
compressed configuration files in the zip directory and stores them in the cardfiles
directory. These card images are then archived in the cfes directory (see also Creating the
card images of the configurations (Page 113)).
' makestore
Dim WshShell, oExec', script
Set WshShell = CreateObject("WScript.Shell")
basePath = "d:\modular_machine"
App.LogActive = True
App.PrintToLog "make_store"
App.LogActive = false
sourcePath = basePath & "\zip"
destinationPath = basePath & "\cardfiles"
Set oExec = WshShell.Exec _
("C:\Program Files\siemens\step7\s7bin\u7mkcnfx " _
& " /m""MAKE_STORE""" _
& " /s""" & sourcePath & """" _
& " /d""" & destinationPath & """" _
& " /i""VE000041""" _
& " /a""ON""")
'
needed !!! for waiting end execute zip
do While oExec.Status = 0
countTime = countTime + 1
loop
App.LogActive = True
App.PrintToLog "make_archive"
App.LogActive = false
sourcePath = basePath & "\cardfiles"
destinationPath = basePath & "\cfes"
Set oExec = WshShell.Exec _
("C:\Program Files\siemens\step7\s7bin\u7mkcnfx " _
& " /m""MAKE_STORE_ARCHIVE""" _
& " /s""" & sourcePath & """" _
& " /d""" & destinationPath & """" _
& " /i""ARCH0041""")
'
needed !!! for waiting end execute zip
do While oExec.Status = 0
APP.Time 1
Basic Functions for Modular Machines
124
Function Manual, 02/2012
Appendix
A.2 Creating the card images for the configuration server by means of SCOUT scripting
loop
App.LogActive = True
App.PrintToLog "ende make_archive"
App.LogActive = false
The card images in the cardfiles directory and the BOOT.INI file can then be transferred to
the memory card of the SIMOTION device via a read/write device connected to the PG/PC
(Creating the card images of the configurations (Page 113)).
The archived card images in the cfes directory as well as the BOOT.INI file can be
transferred directly to the corresponding SIMOTION device. Corresponding scripts are
shown in the appendix under Loading the card image to the target device by means of
SCOUT scripting (Page 126).
A.2.6
Script to call up the individual scripts to create the card image
The individual scripts mentioned above are executed by a central script. In this, only the
actions that run in the engineering system are summarized (no target required). This is
possible by means of the syntax listed below:
'
allToDo
WBScript.addCode(Scripts("createFoldersModMach").code)
WBScript.addCode(Scripts("downl").code)
WBScript.addCode(Scripts("makezip").code)
WBScript.addCode(Scripts("makestore").code)
Basic Functions for Modular Machines
Function Manual, 02/2012
125
Appendix
A.3 Loading the card image to the target device by means of SCOUT scripting
A.3
Loading the card image to the target device by means of SCOUT
scripting
This function is available in SIMOTION kernel version V4.1 and higher.
The following scripts show examples of how an archived card image stored in the subfolder
of the d:\modular_machine\cfes directory can be transferred to the corresponding target
device.
For other target devices, the scripts are to be changed accordingly.
After loading the card images, the SIMOTION devices must be restarted in order for the card
images to become effective as the active configuration.
Setting up an online connection to the target device
The following script "online" sets up an online connection to the SIMOTION device with the
identifier "D435_1."
' online
' connection to device "D435_1"
App.LogActive = True
PROJ.Devices("D435_1").EnableOnline = TRUE
PROJ.Online = true
Basic Functions for Modular Machines
126
Function Manual, 02/2012
Appendix
A.3 Loading the card image to the target device by means of SCOUT scripting
Loading the card image to the target device
The following script "dwldtarg" loads the archived card image of the configuration into the
SIMOTION device with the identifier "D435_1."
' dwldtarg
' enable log activities
App.LogActive = True
App.PrintToLog "begin download into filesystem of target"
basePath = "d:\modular_machine"
bootIniPath = basePath _
& "\cfes\INSTALL\SIMOTION\BOOT.INI"
archivePath = basePath _
& "\cfes\INSTALL\SIMOTION\ARCH0041.ZIP"
call PROJ.Devices _
("D435_initial").DownloadConfigServerData( _
bootIniPath, _
archivePath )
App.PrintToLog "end download into filesystem of target"
' disable log activities
App.LogActive = False
Ending the online connection to the target device
The following script "online" breaks the online connection to the SIMOTION device with the
identifier "D435_1."
' offline
PROJ.Devices("D435_1").EnableOnline = false
PROJ.Online = false
Basic Functions for Modular Machines
Function Manual, 02/2012
127
Appendix
A.4 Storing configuration files for SIMOTION D4xx devices up to kernel version V4.1.4
A.4
Storing configuration files for SIMOTION D4xx devices up to kernel
version V4.1.4
Requirements
1. You have created a project in the SIMOTION SCOUT engineering system in which the
required configurations are configured as dedicated devices with technology objects,
programs, etc.
2. This project has been compiled without errors.
3. If an initial configuration (Page 96) is required, it must also be configured as a dedicated
device.
4. The following options are deactivated (Options > Settings menu Download tab) in the
SIMOTION SCOUT engineering system:
– Compile all programs before loading
5. The PC with the SIMOTION SCOUT engineering system is connected to the SIMOTION
device (e.g. via PROFIBUS).
6. The PC is included in the network of the SIMOTION device (e.g. with NetPro).
7. A read/write device for the memory card is connected to the PC.
Basic Functions for Modular Machines
128
Function Manual, 02/2012
Appendix
A.4 Storing configuration files for SIMOTION D4xx devices up to kernel version V4.1.4
Procedure
1. Insert the memory card in the SIMOTION device and switch it on.
2. Execute the following steps in succession in the SIMOTION SCOUT engineering system:
– Select the appropriate device in the project navigator.
– Select the Edit > Open object menu to open the HW configuration of the device.
– In the HW Config program, select the Target system > Load to module menu to load
the hardware configuration to the device.
Then exit the HW Config program.
The appropriate device is still selected in the project navigator of the SIMOTION
SCOUT engineering system.
– In the SIMOTION SCOUT engineering system, select the Project > Connect to target
system menu.
– Select the Target system > Load > Load CPU / drive unit to target device menu to
load the configuration data to the device.
– Select the Target system > Copy RAM to ROM menu to store this data on the memory
card.
– Select the SINAMICS_Integrated element below the respective device in the project
navigator.
– Select the Target system > Load > Load CPU / drive unit to target device menu to
load the drive data to the device.
– Select the Target system > Copy RAM to ROM menu to store this data on the memory
card.
– Select the Project > Disconnect from target system menu.
3. Switch off the SIMOTION device and remove the memory card.
4. In the Windows Explorer in the directory for uncompressed configuration files
(e.g. D:\modular_machine\download), select the DExxxxxxfolder whose hexadecimal
number you want to use to identify the configuration in the file name (xxxxxx).
5. Copy the configuration files from the memory card to the selected directory:
– Insert the memory card into a card reader on your PC.
– Copy the USER directory from the memory card (e.g. B:\USER) to the selected directory
DExxxxxx. Overwrite any existing USER directory.
6. Repeat steps 1 to 5 for all devices, other than the device that represents the initial
configuration.
Proceed as described above for the initial configuration, but copy the USER directory from
the memory card (e.g. B:\USER) to the INITIAL directory.
Basic Functions for Modular Machines
Function Manual, 02/2012
129
Appendix
A.4 Storing configuration files for SIMOTION D4xx devices up to kernel version V4.1.4
Basic Functions for Modular Machines
130
Function Manual, 02/2012
Index
_
_activateDpSlave, 54
Asynchronous call, 58
Status diagram, 57
Synchronous call, 61
_activateDpSlaveAddress, 42
_activateNameOfStation, 48
_activateTo, 75
Asynchronous call, 77
Status diagram, 75
Synchronous call, 79
_deactivateDpSlave, 54
Asynchronous call, 58
Status diagram, 57
Synchronous call, 61
_deactivateTo, 75
Asynchronous call, 77
Status diagram, 75
Synchronous call, 79
_enableDpInterfaceSynchronizationMode, 32
Automatic synchronization, 36
User-controlled synchronization, 37
_getActiveDpSlaveAddress, 42
_getActiveNameOfStation, 48
_getConfigurationData, 101
_getDpStationAddressFromLogDiagnosticAddress, 64
_getGeoAddressFromLogAddress, 64
_getIpConfig, 50
_getLogDiagnosticAddressFromDpStationAddress, 64
_getStateOfAllDpSlaves, 63
_getStateOfAllDpStations, 63
_getStateOfDpSlave, 62
_getStateOfSingleDpSlave, 63
_getStateOfTo, 82
Asynchronous call, 82
Status diagram, 82
Synchronous call, 82
_setDpSlaveAddress, 42
_setIpConfig, 50
_setModeSelfAdaptingConfiguration, 97
_setNameOfStation, 48
_synchronizeDpInterfaces, 37
A
Activating
Component, 84
Configuration, 85
DP slave, 53
Initial configuration, 96
IO device, 53
Kernel, 90
SINAMICS component, 71
Technology object, 74
Activation state
Configuration, 101
DP slave, 62
IO device, 62
Technology object, 82
Address
Converting the diagnostics address, 64
Converting the PROFIBUS address, 64
Setting the IP address, 50
Setting the PROFIBUS address, 42
Asynchronous call
_activateDpSlave, 58
_activateTo, 77
_deactivateDpSlave, 58
_deactivateTo, 77
_getStateOfTo, 82
C
Card image
Creating with batch file, 104
Creating with SCOUT scripting, 118
Loading with SCOUT scripting, 126
Changing
IP Address, 50
NameOfStation (PROFINET IO), 47
PROFIBUS address, 42
Component
Activating, 84
Deactivating, 83
Configuration
Activating, 85
Activation state, 101
Card image, 104, 118, 126
Definition, 85
Basic Functions for Modular Machines
Function Manual, 02/2012
131
Index
Configuration change, 85
Retaining retentive data, 102
Control interface, 70
Cycle clock generation, 24, 26
PROFIBUS DP, 24
PROFINET IO, 26
Activating and deactivating components and
technology objects, 53
Changing the active configuration or the active
kernel, 85
Overview of the functionality of modular machines
in the SIMOTION system, 11
Setting the communication addresses via the user
program, 41
Synchronizing SIMOTION devices with a higherlevel bus cycle clock, 23
D
Deactivating
Component, 83
DP slave, 53
IO device, 53
SINAMICS component, 71
Technology object, 74
DP slave
Activating, 53
Activation state, 62
Deactivating, 53
Setting the PROFIBUS address, 42
F
Feedback interface, 70
I
Initial configuration
Activating, 96
Status diagram, 99
IO device
Activating, 53
Activation state, 62
Deactivating, 53
IP address
Setting, 50
K
Kernel
Activating, 90
Activating, status diagram, 95
M
modeOfDpInterfaceSynchronization, 32
Automatic synchronization, 36
User-controlled synchronization, 37
Modular machines
O
Option handling
parameter assignment, 67
Prerequisites, 66
P
PII, 70
PIQ, 70
PROFIBUS DP
Converting the address,
Cycle clock generation, 24
Interfaces, 23
Setting the address, 42
Synchronization, 25
PROFINET IO
Converting the device number, 64
Cycle clock generation, 26
Interfaces, 23
Setting NameOfStation, 47
Synchronization, 29
Topology detection, 45
R
References, 4
Retentive data
Retaining during a configuration change, 102
S
Scripting, 118, 126
SIMOTION device behavior
RUN operating mode, 39
RUN/STOP transition, 39
STOP operating mode, 39
STOP/RUN transition, 39
SINAMICS
Basic Functions for Modular Machines
132
Function Manual, 02/2012
Index
Activating components, 71
Deactivating components, 71
Sub-topology, 72
stateOfDpInterfaceSynchronization, 36, 37
stateOfDpSlaveSynchronization, 31
Status diagram
_activateDpSlave, 57
_activateTo, 75
_deactivateDpSlave, 57
_deactivateTo, 75
_getStateOfTo, 82
Initial configuration, 99
Kernel activation, 95
Synchronization of a device
for PROFINET IO, 29
In PROFIBUS DP, 25
With isochronous DP master, 33
Without isochronous DP master, 30
Synchronization with an isochronous DP master
Automatic, 36
Example configuration, 33
Prerequisites, 33
Procedure, 36, 37
Sequence, 34
SIMOTION device, 35
Status diagram, 37
User-controlled, 37
Synchronization without an isochronous DP master
Example configuration, 31
Prerequisites, 30
Sequence, 31
Status diagram, 32
Synchronous call
_activateDpSlave, 61
_activateTo, 79
_deactivateDpSlave, 61
_deactivateTo, 79
_getStateOfTo, 82
U
u7mkcnfx.exe, 115
Automatic loading of initial configuration, 97
Compress configuration files, 111
Create card images, 113
Creating directories, 106
T
Technology object
Activating, 74
Activation state, 81
Deactivating, 74
Topology
SINAMICS drive, 72
Sub-topology, 72
Basic Functions for Modular Machines
Function Manual, 02/2012
133
Index
Basic Functions for Modular Machines
134
Function Manual, 02/2012