Sie sind auf Seite 1von 78

Standard documentation for chassis construction systems

Section 12.1 Robotics - General Component


Standard
Electrics
BP V2.0

Robot system - General Component


(A01_PLC)

KUKA robot with KRC4 controller

Created: A. Ermer, S. Rüdiger


Date of creation: 28.01.2013
Last change: 2/18/2016
Version: 1.10
Language: English
Other languages: No other languages are currently available

The "German" version is always valid!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 1 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Table of contents section 12.1


Table of contents section 12.1 ................................................................................................................. 2
Change history: ........................................................................................................................................ 4
12.1.1 General ............................................................................................................................. 5
12.1.1.1 Purpose ............................................................................................................................. 5
12.1.1.2 Motion commands ............................................................................................................ 6
12.1.1.3 Load data determination ................................................................................................... 6
12.1.1.4 Teaching the Adjustment Offset ....................................................................................... 7
12.1.1.5 Tool and Base data ........................................................................................................... 7
12.1.1.6 Energy supply ................................................................................................................... 7
12.1.1.7 Language .......................................................................................................................... 7
12.1.1.8 Documentation .................................................................................................................. 8
12.1.1.9 Data Integrity..................................................................................................................... 8
12.1.1.10 BMW Standard Application files ....................................................................................... 8
12.1.1.11 Copying of programs/files ................................................................................................. 8
12.1.1.12 Passwords ........................................................................................................................ 8
12.1.1.13 Acceptance ....................................................................................................................... 8
12.1.1.14 Assignment of the activities ............................................................................................ 10
12.1.2 Process data (I/O area) ................................................................................................... 12
12.1.3 Safe Robots, Safe Operation ......................................................................................... 13
12.1.3.1 General Information ........................................................................................................ 13
12.1.3.2 Functions ........................................................................................................................ 13
12.1.3.2.1 Cell area ....................................................................................................................... 14
12.1.3.2.2 Monitoring Spaces ........................................................................................................ 14
12.1.3.2.3 Safe tools ..................................................................................................................... 14
12.1.3.2.4 Axis, Spatial and Cartesian speeds and safe operational stopping ............................. 16
12.1.3.2.5 Brake test ..................................................................................................................... 16
12.1.3.2.6 Reference switch (mastering test) ................................................................................ 17
12.1.3.2.7 Stopping distances ....................................................................................................... 17
12.1.3.3 Default settings ............................................................................................................... 17
12.1.3.4 Applicable documents ..................................................................................................... 22
12.1.4 Program, general ............................................................................................................ 23
12.1.4.1 Program structure ........................................................................................................... 23
12.1.4.2 Storage structure ............................................................................................................ 24
12.1.4.3 Assignment table of program numbers ........................................................................... 25
12.1.4.4 Test of the program sequence ........................................................................................ 26
12.1.5 Program, Detail............................................................................................................... 27
12.1.5.1 Program: CELL .............................................................................................................. 27
12.1.5.2 Application programs ...................................................................................................... 28
12.1.5.3 Organization program ..................................................................................................... 29
12.1.5.4 Maintenance program ..................................................................................................... 30
12.1.5.5 Application-specific programs ......................................................................................... 30
12.1.5.6 Service programs ............................................................................................................ 30
12.1.5.7 Abort programs ............................................................................................................... 30
12.1.5.8 Standard programs ......................................................................................................... 31
MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 2 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.6 Variables and data lists ................................................................................................... 32


12.1.6.1 Kuka-system-data list: $config.dat .................................................................................. 32
12.1.6.2 Location-specific data list: A01_plc_User.dat ................................................................. 32
12.1.6.3 Application-specific data list: Axx_yyy_User.dat ............................................................ 32
12.1.6.4 Application-specific position data list: Axx_yyy_global.dat ............................................. 32
12.1.7 Home position ................................................................................................................ 33
12.1.7.1 Home configuration ......................................................................................................... 33
12.1.8 Initialization concept ...................................................................................................... 34
12.1.9 Jobs ................................................................................................................................ 36
12.1.9.1 Job: Concept: .................................................................................................................. 36
12.1.9.2 Job: Program command ................................................................................................. 37
12.1.9.3 Job: Complex example ................................................................................................... 43
12.1.10 Areas .............................................................................................................................. 45
12.1.10.1 Area: Concept: ................................................................................................................ 45
12.1.10.2 Area: Program command ................................................................................................ 46
12.1.10.3 Area: a complex example ............................................................................................... 51
12.1.11 Collision protection ........................................................................................................ 52
12.1.11.1 Collision protection: Concept: ......................................................................................... 53
12.1.11.2 Collision protection: Program command ......................................................................... 54
12.1.12 User communication ...................................................................................................... 58
12.1.12.1 User communication: Concept: ....................................................................................... 58
12.1.12.2 User communication: Program command ...................................................................... 59
12.1.13 Type number / User number ......................................................................................... 65
12.1.13.1 Sending Type number / User number ........................................................................... 65
12.1.13.2 Send Type number / User number, as first response to a JobRequest request ........... 65
12.1.13.3 Requesting a Type number / User number .................................................................... 66
12.1.13.4 Undefined number range ................................................................................................ 67
12.1.13.5 Example program ........................................................................................................... 67
12.1.14 Abort program ................................................................................................................ 68
12.1.14.1 Program Abort: Concept: ................................................................................................ 68
12.1.14.2 Program Abort: Robot in the Home position: .................................................................. 69
12.1.14.3 Program Abort: Robot not in any Home position: ........................................................... 69
12.1.14.4 Program Abort: Abort programs...................................................................................... 70
12.1.14.5 Program abort: complex example ................................................................................... 71
12.1.15 CheckHome & Rehome .................................................................................................. 73
12.1.15.1 Check home function ...................................................................................................... 73
12.1.15.2 Check home with “Rehome” function ............................................................................. 74
12.1.16 Other functions................................................................................................................ 75
12.1.16.1.1 Stop at process point ............................................................................................... 75
12.1.16.1.2 Controlled Stop ........................................................................................................ 75
12.1.16.1.1 Controlled stop: Program command ........................................................................ 75
12.1.16.2 Locking in the case of multiple querying of the same areas and collision zones ........... 77

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 3 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Change history:

Date Topic Note Name


10.10.2013 Section 12.1.15 New section inserted, stop at process point and Ermer /
controlled stop enhanced Ruediger
21.10.2013 Section 12.1.4 Folder structure overview amended Ermer /
Ruediger
28.10.2013 Section 12.1.2 I/O connection to the master area enhanced Ermer /
Ruediger
28.10.2013 Section 12.1.4.3 "Job Reference" details inserted Ermer /
Ruediger
21.11.2013 Section 12.1.4 Folder structure overview changed again Ermer /
Ruediger
21.11.2013 Section 12.1.5.4 Maintenance program description changed Ermer /
Ruediger
21.02.2014 Section 12.1.13.2 Section Send Type / User number initially after Ermer /
JobRequest request inserted. Ruediger
21.02.2014 Section 12.1.1.11 Assignment of the activities described in more detail Ermer /
Ruediger
21.02.2014 Section 12.1.15.3 Multiple Request commands query described Ermer /
Ruediger
06.06.2014 Section 12.1.4.1 Program structure, description enhanced, sample Ermer /
image changed Ruediger
02.12.2014 Section 12.1.3 Section Safe Robot completely new Ermer /
Ruediger
31.03.2015 Section 12.1.15.2.1 ILF Controlled stop inserted Ermer /
Ruediger
07.08.2015 Section 12 Service programs, Controlled stop Ermer /
Ruediger
16.11.2015 Purpose, More information and detail added Garrett
Data Integrity,
BMW Standard Applica-
tion files
Application programs
11/25/2015 Kap. 12.1.9 Job Request "AnyJob" function added Ermer
Kap 12.1.9 Job Examples
30/01/2016 CheckHome & Rehome Function Check Home with “Re-Homing” Garrett
30/01/2016 English translation errors Garrett
corrected

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 4 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.1 General
The guidelines for erection, handling and programming of the robot specification
"SPEZ_Kap_04_robot _xxxxxx.pdf" are to be adhered to.

The system supplier is obliged to use qualified robot programmers.


The qualification requirements for raw chassis construction are specified in the electrical specifica-
tion for chassis construction systems (MAN_Kap12_01_ROB_Common_General_160218_en.docx)

12.1.1.1 Purpose

The rules, regulations and concepts described in this document are to be observed and ap-
plied to ensure the overall standards and concepts are adhered to.

Not included in the scope of this document are all application-specific requirements, which
are described within the specific "application standard documents".

The System Suppliers and subsequent robot programmers have the responsibility to comply
with all the requirements stated within the BMW standards and forward any questions for
clarification with the responsible BMW robot project “GEL”.

The standard documentation is intended to provide users with instructions, guidelines, ex-
amples, explanations and solutions to all BMW standard robot related issues.

Adherence to the standards is a prerequisite for final acceptance.

Overview When does this document Apply?


This standard document is "dynamic" - As It is the intention that all robot programmers
such it is continually updated / adjusted / code developers working for or on behalf of
edited for improvements. Periodic updates BMW adhere to this standard.
are released to the BMW server. System
Suppliers are responsible for making sure
they are working with the most up to date
version, and for communicating important
information to any relevant personal.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 5 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.1.2 Motion commands


Exclusively the motion commands PTP, LIN, CIRC and the application-specific motion commands are
released. The new commands (NewMotion) are not approved for project G11/12 and must not be
used!

12.1.1.3 Load data determination


Before programming, a load data determination (mass, center of gravity and moment of inertia) must
be performed for every tool and every part on a real robot.
This does not include small parts that have no significant influence on the motion behavior com-
pared to the load carried by the robot. (small parts with <= 2% of the rated load)
The required software option is contained in the scope of delivery. (Main Menu > Commissioning >
Measurement > Tool > Tool Load Data)

The robot must always (also in the Home positions) be operated with this real-world measured data.
The system supplier must ensure that the robot is never overloaded.

If the load data determination reveals that the robot is overloaded then the BMW technical depart-
ment responsible must be notified immediately.

Note: If incorrect weight data is used at the start of programming the robot the "Absolute accuracy"
function can cause point offsets.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 6 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.1.4 Teaching the Adjustment Offset


On initial commissioning the robot is adjusted by a KUKA Service employee and tool must not be
mounted on the robot flange when this is performed.
After mounting the tools the programmer must perform the "Learn adjustment offset" function for
every tool (incl. all tools docked via the tool changer).
The Part in handling constellation does not need to be separately considered.

Note: It must be ensured that each axis has enough room to move when in the adjustment position
on order to be able to perform a complete adjustment (incl. various different tools). In individual cas-
es it is permissible for axes 1+7 to be adjusted at a different position. Axes 2 to 6 must always be
adjusted at the same position!

12.1.1.5 Tool and Base data


All programs must always be created using the vehicle coordinate system. All Tool values (e.g. robot
spot gun, Handling) are to be adopted as 6-D data from the offline simulation system. All Base val-
ues (e.g. tool plate, external clamps) are to be adopted from the cell measurement data. The proce-
dure is described in the "Guideline_Geosim_OLZP".
128 Tool data records and 128 Base data records are available. The detailed assignment is provided
in the file "LIST_yymmdd_robot_interface_BP_V2.0.xlsx" in the "Tool+Base assignment" folder.
This assignment must be adhered to.

12.1.1.6 Energy supply


The robot is delivered with default energy supply settings. The optimum settings must be deter-
mined in advance using a simulation system. The energy supply settings must be made using the
data determined in the simulation before starting programming. The system supplier is obliged to
optimize the settings to ensure a maximum service life. Collisions and exceeding of the bending
radius must be ruled out. Only standard fastening elements (unmodified) may be used. The setting
and optimization of the energy supply is subjected to an acceptance procedure by the robot suppli-
er. A successful and correctly documented energy optimization acceptance is one of the prerequi-
sites for achieving final acceptance of the system.

12.1.1.7 Language
All text entries (descriptions/comments etc.) must be provided in the native language of the relevant
factory. (China in English)
Every user program must contain a program header with the following information, which must be
kept up to date until handover.
 Program description
 Company name
 Author name
 Creation date
 Change history

For better comprehension, Comments are to be inserted at important places in the program.
Caution: When external editors are used, ANSI format must be set!
No umlauts may be used!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 7 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.1.8 Documentation
All data is to be documented in the RobotWorkbook (robot documentation).

12.1.1.9 Data Integrity


The robot programmer is responsible for ensuring data integrity until the time of handover. The data
backup of the robot system is usually executed in the form of an archive. This ensures that the sys-
tem can be fully restored after a data loss!
The data must be backed up via the network according to the currently valid archiving concept. For
commissioning, or in the case of a fault, a temporary backup or restore of the system can be per-
formed via USB or KUKAWorkVisual.
The Line builder/SE partner/programmer must ensure all commissioning software code/comments/
temporary declarations/ no longer used code etc. are removed prior to acceptance. This includes
any programs, temporary copies of routines, additional backups on the robot memory, generated
during the programming phase or commissioning data provided as a part of OLP off line program-
ming.

Attention:
In addition to the user data, an archive also contains Standard data and System data. The robot pro-
grammer is responsible for ensuring that this data cannot be deleted or modified.
Especially after a Standard update, care must be taken to ensure that a complete archive is restored.

12.1.1.10 BMW Standard Application files


The system supplier / Programmer / SE Partner is forbidden from making any changes to the BMW
standard application source code files.

The system supplier / Programmer / SE Partner may not either add or remove any BMW standard
application system files unless permitted to do so by the standard documentation or agreed by the
appropriate BMW robot project “GEL”.

12.1.1.11 Copying of programs/files


The copying of any programs/routines, configurations or parameters etc. from one robot to another
should be avoided. This is to prevent any error within the original data being transferred to other ro-
bots without the knowledge of the user as this could then have detrimental consequences during any
future updates or modifications to the software.
The initial robot backup provided by robot supplier as a part of the first commissioning contains unique
data to that robot therefore, under no circumstances may a complete backup be restored from any
other robot.

12.1.1.12 Passwords
The currently valid passwords can be requested from the Robot System technical department if re-
quired. Passwords may not be changed by the user!

12.1.1.13 Acceptance
Conformance to the standard is a partial prerequisite for acceptance. The standard settings for pa-
rameters and machine data, e.g. for speed, acceleration etc. must not be changed without prior con-
MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 8 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

sultation. Test routines that systematically search the memory image for irregularities are used by
BMW during the acceptance process. If irregularities occur that influence the correct operation of
the robot then the acceptance is retracted and the system supplier must correct all defects.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 9 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.1.14 Assignment of the activities

Assignment of the activities Work is to be carried out by:

Provision of the commissioning data is a basic prerequisite and this System builder
must be provided to the robot supplier before commissioning.
The commissioning files are generated using the "XML Generator"
(project.xml). The basis for this is Derived from the E-Plan.
The commissioning files contain the following location-specific infor-
mation:
 Required applications (IBN.xml)
 Profinet configuration of the robot
 I/O connections and start addresses of the individual partici-
pants
 Long texts
 Current GSDML files
 IP address and computer name for message output

The system builder must check the functionality and plausibility of the
data.

A renewed commissioning due to faulty commissioning files is per-


formed at the cost of the system builder and must be separately or-
dered by the AL from the robot supplier.

Execution of initial commissioning based on a commissioning check- KUKA


list (visual checking of the manipulator, control cabinet and hose
package, checking of the plug connections, initial adjustment, etc.)
Commissioning of KUKA Linear Unit if present.

Installation/Update of the KUKA system software (KSS) to the version KUKA


agreed with the customer.

Installation of the BMW standard application software with the com- KUKA
missioning files provided by the system builder.

On commissioning, all Profinet participants are set to not "always


available".

Mounting of the tools as specified, incl. (manual axes A4, A5, A6 in System builder
zero position)

All participants that are not operated via a tool changer must be set to Programmers
"always available".
Device christening of the individual Profinet participants is to be per-
formed.

Calibrate the robot into the vehicle coordinates network and en- Programmers
ter/check the specified data.

Enter and check the specified tool data Programmers

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 10 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

The correct load data, incl. additional load data must be determined Programmers
for every tool (Tool) See section 12.1.1.3

Execute the Teach Offset function for every tool. Programmers


See section 12.1.1.4

Creation, installation and optimization of the user program, incl. ad- Programmers
herence to the programming standards.

Perform a risk analysis and define any measures necessary System builder

Programming and testing of the safety measures required by the risk Programmers
analysis. See section 12.1.3

Setting and optimization of the media package. Have the media pack- Programmers
age accepted by the robot supplier. See section 12.1.1.6

Documentation as required in the RobotWorkbook. Programmers


See section 12.1.1.8
Ensure data integrity. See section 12.1.1.9 Programmers

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 11 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.2 Process data (I/O area)


The I/O communication to the PLC and the applications occurs via ProfiNet. No other bus systems
are available.

The connection to the PLC consists of a standardized region of 255 bytes. The assignment of the
individual application signals is not defined in advance and is generated according to the E-plan data
on commissioning.

User and System signals (Bytes: 0-63 / Bit 1 -512) > Fixed assignment
Application signals (Bytes: 64-253 / Bit 513-2032) >Assigned
according to E-Plan
System-internal occupied (Bytes: 254-255 / Bit 2033-2048) > Fixed as-
signment

Connection of the applications to the lower level "Master area" consists of a standardized area of
max. 718 Bytes. The assignment of the individual application signals is not defined in advance and
is generated according to the E-plan data on commissioning.

Application signals (Bytes: 256-974 / Bit 2049-7800) > Assigned according


to E-Plan
System-internal occupied (Bytes: 975-1023 / Bit 7801-8192) > Fixed assignment

An area of 8 Bytes (ProfiNet-Safety) is available for the safety signals.

The dynamically assigned signals for the visualization are available under the menu
"Display" -> "BMW" application-specific status window.

Concept: During commissioning, the "XML-Generator" tool is used via "WorkVisual" to load the
required application packets and implement the dynamic I/O assignment, based on the planning
information from the E-Plan.
Note: The E-Plan must correspond to the real system configuration at the time of commissioning,
otherwise the robot commissioner (KUKA) cannot install the correct application package.

A detailed assignment is provided in the file "LIST_yymmdd_robot schnittstelle_BP_V2.0.xlsx"!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 12 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.3 Safe Robots, Safe Operation

12.1.3.1 General Information


All robots in the project are supplied with the "KUKA SafeOperation" option. This is a safety-
analyzed program for axis and space restriction with hardware components.

A fundamental requirement is that all robots must be made safe in accordance with the currently
applicable versions of SPEZ_xxxxxx_SafetyConcept_ChassisConstruction, the EN ISO 10218 stand-
ard and all other relevant standards and documents.
A risk assessment must be performed for every robot.

If protective measures are necessary as a result of the risk assessment then the required safety
parameters (e.g. coordinates of the protected area, geometry of the tool, permissible speed, etc.)
must be entered into the robot controller.
The data, e.g. for protected spaces, can be generated on the real robot or created with an offline
system. The operation and entry of the configuration data for "KUKA SafeOperation" is performed
using the WorkVisual software or directly at the robot system.

In the chassis construction sector, the cyclic brake test must be activated for all axes on all robots.

The protective measures must be checked in the real cell and the correct function ensured. The
protection target according to the risk assessment must be achieved.

All safety data must be documented in the system safety documentation


(FORM_xxxxxxx_8_1_5_v80_SafetyDevies_60204). Only layouts are to be entered into the "Robot-
Workbook".

Note:
The protective measures must be checked again if robot sequence programs are changed where
the robot moves into a protected area (e.g. employee workspace).
Among other examples, a program change is: removal of motion points, modified movement to the
protected area. modification of speed etc.. Such program changes cam change the braking path
angles of the robot and possibly result in the safety target no longer being achieved.

12.1.3.2 Functions
KUKA SafeOperation provides the following functions:

 User-defined cell area


 16 user-defined monitoring spaces (Cartesian / axis-specific)
 16 safe tools with safe TCP and up to 6 spheres
 Safe monitoring of axial, spatial and Cartesian velocities
 Safe operational stop
 Safe inputs and outputs for monitoring and status messages
 Checking of the brakes
 Checking / monitoring of the synchronization
 Configuration via robot controller or in WorkVisual
 Visualization of the spaces/ tools and I/O’s on the programmer hand-held unit.
 Determination of the stopping paths using the KUKA Stopping Path Logging Tool integrat-
ed into the BMW user interface.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 13 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.3.2.1 Cell area


If the risk assessment and/or the SPEZ_xxxxxx_SafetyConcept_ChassisConstruction indicates that
the robot must be designed safe, then the cell region must be defined
The cell region is a permanently defines, constantly active Cartesian workspace design to ensure a
safe working region for the robot.

Note:
Configuration, programming and function tests are to be performed based on the KUKA
KUKA.SafeOperation documentation, the risk assessment and the
SPEZ_xxxxxx_SafetyConcept_ChassisConstruction.

12.1.3.2.2 Monitoring Spaces


Up to 16 monitoring spaces cam be defined using a Cartesian or axis-specific coordinate system,
where the Cartesian variant should always be used whenever possible.

The following configuration options can be set for the monitoring spaces:
 Workspace and protected space
 Space-specific Cartesian velocity inside or outside
 Activation and deactivation via safe inputs
 Violation signals via safe outputs
 Stop on violation of the space borders
 Reference stop in the case of missing adjustment referencing

Note:
Configuration, programming and function tests are to be performed based on the KUKA
KUKA.SafeOperation documentation, the risk assessment and the
SPEZ_xxxxxx_SafetyConcept_ChassisConstruction.
Stopping paths are to be taken into consideration if indicated by the risk assessment and/or the
SPEZ_xxxxxx_SafetyConcept_ChassisConstruction / MAN_xxxxxxx_8_2_Leitfaden_Standardsituationen.
Meaningful names are to be defined for the spaces.

12.1.3.2.3 Safe tools


Up to 16 safe tools are monitored against the borders of the Cartesian monitoring spaces.

A safe tool is basically modeled using the Safe TCP and up to 6 freely configurable spheres When
modeling, care must be taken to ensure that no parts / tool elements protrude outside the sphere
(tool incl. part must be completely enclosed by the spheres).

The safe tools are activated using safe inputs. The actuation and activation of tools is performed
exclusively by the safety PLC.

The "Normal TCP" is to be used as the Safe TCP (e.g. spot gun with fixed sleeve, auxiliary TCP for
the gripper). With a tool combination (e.g. spot gun/ handling) the TCP furthest away from the center
of the flange is to be used as the Safe TCP. When using a tool with only one safe tool model (no
switching of the safe tool) the "Normal TCP" furthest away from the flange is to be used as the Safe
TCP.

With changer tools, in some situations it may be necessary to define multiple safe tools that are
switched over by the safety PLC (according to the optional safety switches at the stations).

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 14 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

As far as possible, as many tools as possible should be combined into a safe tool. This means that
only one tool is to be used if the tool geometries are almost identical.
The tool with the largest geometry, including parts, must be configured as a safe tool.

Note:
The parts in the tool cannot be switched in and out, i.e. the Safe Tool always has parts!!

Multiple tools may only defined in the case of different geometries that cannot be combined for rea-
sons of accessibility (see also following concept diagrams)

If necessary, Safe Tool 15 is to be used for the tool changer without a docked tool.

If accessibility problems occur with the Safe Tool "gripper with docked mobile tool changer/milling
tool" then an additional Safe Tool can be configured by mounting an additional optional safety
switch on the mobile milling tool resting area.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 15 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

A Safe TCP, which is monitored for the configured speed, is defined for every safe tool. The Safe
TCP is not automatically identical to the active TCP of the base system.

12.1.3.2.4 Axis, Spatial and Cartesian speeds and safe operational stop-
ping
If required (as a result of the risk assessment) it can be used according to the KUKA SafeOperation
documentation.

12.1.3.2.5 Brake test


The robot controller uses the brake test to check the holding brakes for correct function and wear.

If persons can be present in the vicinity of a robot that presents a hazard due to its mass and/or tool
load, then a cyclic brake test must be provided.

The brake test must be implemented for every robot used in the chassis construction sector!

Note:
The KUKA Standard Brake Test program must not be used!

The BMW brake test program "Prog251_braketest.src" and the BMW parking position program
"BMWBrakeTestPark.src" are to be created (positions, paths, tool change etc. teaching) or the
equivalent OLP program generated offline must be adjusted.

The brake test is started by the PLC every 24 hours. The call in the automatic sequence is
"Prog251_BrakeTest".

Note:
The brake test is started from Home1. If possible, Home1 should be used as the test position. The
parking position is ideally the transport position and must be chosen so that the robot can collapse
without danger.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 16 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.3.2.6 Reference switch (mastering test)

The mastering test is used to check that the actual position of the robot corresponds with a refer-
ence position. The robot can only be safely monitored with SafeOperation if the mastering test was
successful.

Attention:
This program is only required if the risk assessment resulted in the requirement for SafeOperation
functions.

The reference switch provided in the KUKA scope of delivery must be used.
The reference switch should not be used in conjunction with the KUKA actuating plate (tuning fork)
but rather with the gripper or the gun!
No movable parts such as pins, clamps etc. are to be used, also rounded parts such as electric
shafts are not permitted!

The alternative variant of moving safety switches to and fro above the PLC is not permitted!

Notes:
The KUKA Standard mastering test programs must not be used!

The BMW adjustment referencing program "Prog250_MasterReference" must be created (teach


positions, paths, tool changes etc.) or the equivalent OLP program generated offline must be ad-
justed.

The program starts and ends at Home 1. The robot position must be chosen so that all axes of the
robot (incl. linear axis if present) can be measured.
The call in the automatic sequence is "Prog250_MasterReference".

When using tool changers, referencing is only to be implemented for one tool. The tool used in the
"Home1" position should preferably be used.

12.1.3.2.7 Stopping distances


When the robot is stopped as a result of monitoring by SafeOperation it requires a certain stopping
distance before it comes to a standstill (stopping distance = reaction distance + braking distance).

The decision as to whether the stopping distance must be taken into consideration depends on the
results of the risk assessment. The diagrams from the robot manufacturer's specifications are to be
used for determining the stopping distance in the planning phase.

The "Nachlauf Logging tool" from KUKA can also be used for the actual situation in the fully pro-
grammed cell. In the case of a violation of the protected space this tool records the axis angles at the
time of violation and the time of standstill. This is then used to calculate and output the braking dis-
tance.

12.1.3.3 Default settings


The following visual documentation should help in defining the correct basic settings.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 17 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

On commissioning the cyclic brake test is automatically switched active. The settings remain at the de-
fault values. The PLC starts the brake test cyclically (every 24 hours).

The settings according to the figure below must be made in the Hardware Options.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 18 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

The speeds are preset to default values in the global parameters.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 19 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

The rotatory axis monitoring is set to 100 °/s at the maximum speed T1 (KUKA default 30 °/s)

The reference probe provided in the KUKA must be used for adjustment referencing. The reference
probe must not be damped with the KUKA damping plate (tuning fork) but rather damped with the grip-
per or the gun wherever possible!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 20 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

No movable parts such as pins, clamps etc. are to be used, also rounded parts such as electric shafts are
not permitted

Meaningful names must be used for the monitoring spaces and safe tools (e.g. station or tool numbers).

Safe Tool 15 must be used for the tool changer without tool!

The "Normal TCP" is to be used as the Safe TCP (e.g. spot gun with fixed sleeve, auxiliary TCP for the
gripper). With a tool combination (e.g. spot gun/ handling) the TCP furthest away from the center of the
flange is to be used as the Safe TCP. When using a tool with only one safe tool model (no switching of
the safe tool) the "Normal TCP" furthest away from the flange is to be used as the Safe TCP.

Further configuration is to be performed according to the application.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 21 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.3.4 Applicable documents


Safety concept: SPEZ_xxxxxx_SafetyConcept_ChassisConstruction
MAN_xxxxxx_8_2_Guideline_StandardSituations_D_E
FORM_xxxxxxx_8_1_5_v80_SafetyDevices_60204

OLP method description: PR_xxxxxx_RobKalDat_SafeMove

Documents from KUKA: Specification_QUANTEC/ FORTEC_xxxxx


KST_SafeOperation_xx_de
Docu_StoppingPathMeasurement

Among the applicable standards: DIN_EN_ISO_10218-1


DIN_EN_ISO_10218-2
And the documents listed in the safety concept

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 22 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.4 Program, general

12.1.4.1 Program structure


The program sequence should preferably be as simple as possible. In each cycle, the robot must be
started from the CELL.SRC program via a program number and should return to the CELL program
when finished.

The different program numbers are to be used primarily for restarting the robot in the case of "Start
after fault" The organization program e.g. "Prog001_xxxxx" contains a complete robot sequence
robot. Further program numbers each represent a reduced scope of the organization program, as
illustrated in the following figure.

In exceptional cases and after consultation with/ approval from the respective BMW technical de-
partment it is possible to allow a program to run in an endless loop. In this case the program must
still be started from CELL.

Due to the possibility of being able to implement program aborts with return movement to a home
position, the following program structure is favored.

The robot program starts from Home 1 moves through all sequences directly one after another and
the ends back at Home 1. All other Home positions are only moved to in the case of an error, after
an abort.
The gripper must always be empty at the Home 1 position.

Note: All maintenance programs are always started from Home 1.


See Section: 12.1.5.4 Maintenance programs

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 23 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.4.2 Storage structure

The working folder (R1 directory) of the robot is structured as follows:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 24 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.4.3 Assignment table of program numbers


Job reference:
64 Jobs are available that should always be used in reference to the program numbers. When multiple
tools are used on a robot, in addition to the Job number a User number can be provided by the PLC or
a User number can be requested!

Example: Pick(Job 1) – Place(Job 2) – Spot(Job 3)

Prog001_xxx: Job 1 – 2 – 3
Prog002_xxx: Job 2 – 3
Prog003_xxx: Job 3
Prog062_TipDress: Job 62 (for multiple clamps, call incl. UserNum)
Prog063_TipChange: Job 63 (for multiple clamps, call incl. UserNum)
Prog064_Maintenance: Job 64 (for multiple tools, call incl. UserNum)

Program Program Name:


No.
1 Prog001_xxxxxxxxxxxxxxx
2 Prog002_xxxxxxxxxxxxxxx
3 Prog003_xxxxxxxxxxxxxxx
4 Prog004_xxxxxxxxxxxxxxx
5 Prog005_xxxxxxxxxxxxxxx
.
.
50 Application-specific programs
.
.
.
62 Prog062_TipDress
63 Prog063_TipChange
64 Prog064_Maintenance (maintenance program)
. Not assigned
. Not assigned
. Not assigned
250 Prog250_MasterReference
251 Prog251_BrakeTest
252 Spare
253 Spare
254 Spare
255 Spare

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 25 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.4.4 Test of the program sequence

The programmer must ensure that all programs are tested for function and freedom from collisions.
When using "conditional" program sequences (e.g. IF or SWITCH /CASE commands) all branching
possibilities must be tested and erroneous combinations ruled out. (e.g. by using a default - CASE)
A default error program is available to the user! "Plc_DefaultError()"
More information is provided in Section 0

Example:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 26 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.5 Program, Detail


All new or modified programs must be completely executed, or the modified parts executed, in
manual operation. The same applies to programs created offline.

12.1.5.1 Program: CELL


The automatic sequence can only run when robot has been started via the CELL.SRC program.
Messages and query dialogs appear on the hand-held unit to guide the user to the location in the
program where it is possible to switch to the "automatic Extern" operating mode.
The "Automatic" mode is not permitted in the plant collective and the PLC will not issue a start!

A "CASE" condition for every program number is to be entered into CELL.SRC. Only the call to the
organization program is to be entered into the respective CASE statement.

Cell.SRC
......
......
SWITCH
CASE 1
Prog001_xxxxx() Prog001_xxxxx.SRC
CASE 2
Prog002_xxxxx () ; complete sequence
CASE 3 Pick_part
Prog003_xxxxx () Welding
..... Place_part
ENDSWITCH Prog002_xxxxx.SRC
END
; reduced sequence
Welding
Place_part

END Prog003_xxxxx.SRC

; reduced sequence
Place_part

END

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 27 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.5.2 Application programs


All user programs to be created for BMW AG are to be named according to the described regula-
tions. Deviations are only permitted after consultation with, and the approval of, the technical de-
partments. The fundamental expectation is simple programming and the ability to quickly jump into
the automatic sequence when faults occur.
The program names must contain the subtask, the tool area and the vehicle type. A maximum of 23
characters can be used.
The following structure and the "_" separator must be adhered to:

{Task}_{ToolArea}_{Type}
Example: Spot_ST20FX1_G11

1. Task Abbreviation list for applications


Task Abbreviation Description
Spot Spot welding
Stud Stud welding
Glue Gluing
Pick Picking parts
Drop Placing parts
Arc Arc welding
Clinch Clinching
Flow Flow drill screwing
Rivet Riveting
Nut Nut welding
Fasten Fastening / Screwing
Hem Hemming
Laser Laser welding
Search Searching
Stack Stacking parts
Spray Spraying parts
Fit Best fit
Inline Inline measurement
Check Checking e.g. After gluing
Stamp Stamping
Scan Scanning
Vrtfx Virtual fixture
Dock Docking Tool
Undock Undocking Tool

Description: Subtask
The subtask describes the main activity in each respective program. This can be (e.g.) placing, weld-
ing, machining, gluing etc.

Description: Tool area


All component designations must conform to the BMW plant identification system (AKZ Master
string). (e.g. ST = station, FX = tool/fixture, etc.) 3-digit numeric blocks are reserved for most com-
ponents. The full designation of a tool according to the AKZ Master string is thus defined as follows:
++ST010+FX001
Shortening of the station designation and/or tool area to avoid wasting characters is permitted.
Care must be taken to ensure that every designation is unique. e.g.

Description: Type

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 28 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

3 characters are reserve for the type description. (e.g. G11 or G30). If a program is to be used simul-
taneously for multiple types (e.g. for G11 and G12) the designation of G1x is also permitted. The
type can be omitted if only one type is programmed in the robot and no additional type is integrated
later.

12.1.5.3 Organization program


The organization program Prog001_xxxxx.SRC contains the entire robot sequence. Each of the ad-
ditional programs (e.g. Prog002_xxxxx.SRC, Prog003_xxxxx.SRC, etc.) respectively represent a
reduced scope of the main program.
If the same sequences are to be processed for different types or when other type-dependent se-
quences are required, then this can be implemented with the Job Request / TypReq command.

Motion sequences must never be programmed in organization programs!

After consultation with, and approval from the respective BMW technical department, it is also pos-
sible to choose a different program structure.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 29 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.5.4 Maintenance program


The term "Maintenance program" is defined as a program that is started by the PLC via a program
no.
The standard specifies one Maintenance program (Prog064_Maintenance) that is always started from
Home1 and must always end at Home1.
When using several tools, a user number is also passed when the program is called, which is used to
call the individual maintenance programs via a "Switch/Case" selection.
Note: Program 64 is purely an organization program. The individual maintenance programs must be
stored in the "BMW_Utilities" directory.

A maintenance program incl. a maintenance position must always be implemented for every tool.
When using a tool changer a maintenance position without a docked tool is also to be provided.

Standardized I/Os are available for the PLC handshake.

Cleaning position:
A cleaning program must be created for every robot. This is called by calling the maintenance pro-
gram and passing "User-Nr. 100".
The cleaning position must be chosen to ensure free and non-hazardous access to the system for
the cleaning personnel. This is usually a position above Home1.
The positions must be selected under consideration of various ergonomic factors and these must
be defined in agreement with the respective BMW technical department.
A collision-free execution must be ensured and a collision protection concept must be taken into
consideration if necessary.

12.1.5.5 Application-specific programs


Programs required for a robot application, which can be run in "automatic" operating mode are re-
ferred to as "application-specific programs". Program templates can be found in the R1 directory
under "BMW_Utilities".
Program numbers 50-64 are designated for application-specific programs with job reference. Pro-
gram numbers 62 and 63 are assigned for spot welding, and 64 for the maintenance program.
The program numbers for all other programs must be individually agreed between PLC and robot
programmer, and programmed by the robot programmer in the cell / organization program.
To ensure quick access to the system, a controlled stop must be outputted in the service position.
This can be realized via the ILF PlcCom with Set Output, Wait Input, or via the ILF Controlled Stop
(see also section 12.1.15.2 Command / ILF descriptions).

12.1.5.6 Service programs


"Service programs" are programs that are not started from the PLC. Service programs are only se-
lected and started in the "Manual" operating mode and are not permitted to be used in the automat-
ic sequence.
The required scope and selection of the service position must be selected under consideration of
various ergonomic factors and these must be defined in agreement with the respective BMW tech-
nical department.
Example: Welding gun changing position (without automatic tool changer)

12.1.5.7 Abort programs


The abort function carries a significant risk of collision if used incorrectly.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 30 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Whether or not the Abort concept should be implemented, and the scope of any implementation,
must be clarified with the BMW technical department responsible!

Aborts can be programmed using the "Job Request" and "Area Request" commands.
Note: Abort programs must always end in a Home position and must be created to have an appro-
priately safe speed.

A collision-free execution must be ensured and a collision protection concept must be taken into
consideration if necessary. When using or changing the program, care must be taken to ensure that
all possible program sequences have been properly tested.

Further information on the abort concept is provided in Section Kap. 12.1.14

12.1.5.8 Standard programs


Standard program packages are available for the individual applications and these are installed on
the robot as required. Mandatory programming regulations apply to all applications.
Standard programs must not be changed!

Note: With subsequent software updates, the standard programs can be changed or completely
replaced.
The customer must always be consulted if changes are required.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 31 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.6 Variables and data lists


If user-specific variable are required then the following requirements must be satisfied:

 First check if a suitable variable that can be used already exists.


 The name must be chosen to ensure that a duplicate declaration is impossible.
(e.g. Application-specific variables begin with an application abbreviation "scr_xxxxxx")
 The variable name must thus described the purpose of the variable.
 It must contain the smallest possible number of characters.
 The preferred language for variable names is English
 The name must contain an indicator of the variable
 The readability can be greatly improved through an appropriate use of the separator "_” and
sensible use of upper case and lowercase letters!

12.1.6.1 Kuka-system-data list: $config.dat


The $config.dat is used exclusively for data/variables specified by the Kuka system. (I.e. home posi-
tions, tool data, load data, base data etc.) No other location-specific data is allowed to be stored in
$config.dat.
Attention: When updates are performed all other variables declared in $config.dat are ignored!

12.1.6.2 Location-specific data list: A01_plc_User.dat


All other location-specific data/variables declared by the user must be stored in "A01_plc_User.Dat".

12.1.6.3 Application-specific data list: Axx_yyy_User.dat


A location-specific data list is available for each application the variables are usually predeclared and
must be location-specific adjusted by the user.

12.1.6.4 Application-specific position data list: Axx_yyy_global.dat


A data list for global positioning data is available for each application. All global application-specific
positions (e.g. welding points) must be stored in this data list!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 32 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.7 Home position


Up to 5 different robot home positions (Home 1 to 5) can be used. The Home positions are defined
globally and are thus valid in all programs.

Attention: Changing a Home position can result in collisions in other programs! All affected pro-
grams must be checked after every change.

In general, one can state:


 "Home1" is to be used for the home position without a part.
 The Home positions 2-5 are only used if they are actually needed in the program.
 A corresponding designation is to be configured for every Home position used.
 The correct load data must be used in the program for every Home position.

Linking of the home position with part checks or other similar functionality is not implemented in the
robot program but rather in the PLC.

12.1.7.1 Home configuration


The required number, designation and the position data must be set using a configuration menu.
After successful configuration, the robot system automatically sets the corresponding "Home out-
put" when the robot reaches the position.
The “Restore" function can be used to restore the last valid home position.

Note: The "Home Output" is only set by the system when the configuration is performed via this
menu.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 33 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.8 Initialization concept


By default, all outputs and variables are reset to defined values when a robot "Start CELL" occurs.
This includes the system functions, the application-specific settings and the user-specific scopes.
The basic rule is that all functions used by the programmer (e.g. Areas, User outputs, variables, etc.)
must be reset to defined values within the user program.

However, it must be assumed that an operator will eventually abort execution if a fault occurs and
then restart the robot via "CELL". This situation must be trapped and explicitly handled!

The following initialization programs (Start after fault)are available to the user in the directory
"BMW_Init".

Init_BeforeHome: (InitBeforeHome.src)
Initialization of user scopes, before the robot moves

Init_InHome: (InitInHome.src)
Initialization of user scopes, after the robot has reached the home position

Init_Produktion: (InitProduction.src)
Initialization of user scopes user query, every time before a new PLC program no. is requested!

Note:
The system program "A01_plc_init.src", which is called from within the program "InitProduc-
tion.src", initializes all system outputs to the PLC. This call must not be removed.
If individual functions (e.g. Areas, Jobs, CollZone, user outputs) are still required in the program se-
quence, then the user must always explicitly set these functions again after calling
"A01_plc_init.src"!

Attention:
"InitProduction.src" is immediately executed at the end of a program sequence. If a function (e.g.
Job Done) is set too late at the end of program execution, then the PLC might not receive the corre-
sponding signal (cycle time) because "InitProduction.src" immediately resets the function. The only
solution: Set the function earlier in the program sequence or program a small waiting time if neces-
sary!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 34 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Overview image:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 35 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.9 Jobs
A program usually defines a number of different subtasks to be performed by the robot, i.e. a num-
ber of different jobs to be completed The Job concept synchronizes these subtasks with the PLC
via standardized inputs and outputs. The PLC evaluates these signals for visualization, for preparing
a Start after Fault and for time monitoring.

12.1.9.1 Job: Concept:

The following concept diagram illustrates the use of Job Started, Job Done and JobClearAll.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 36 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.9.2 Job: Program command

The Inline Form for the Job command is designed so that it dynamically changes according to the
settings. The individual data entry possibilities are described on the following pages.
The "Job" standard command (with and without movement) for 64 Jobs is available for program-
ming.
Please also observe the notes on the initialization concept in Section12.1.8

Data entry field 1: Selection of the function

JobStarted:
This function is used to notify the PLC that a Job has been started. The "JobStarted" is not auto-
matically executed on release of the "JobRequest" but is rather programmed at the position in the
user program where the subtask actually begins.

Example: The "Welding" is released in advance and the robot moves to the turntable. The
robot cannot move into the area until the area until the turntable signals "ready". The "Weld-
ing" only starts after the release.

JobDone:
This function is used to notify the PLC that a job has been completed. "JobDone" is usually set after
execution of the last process point. The status of "JobStarted" remains unchanged.

Example: After the last welding point has been completed on the part, the PLC calls "Job-
Done" to signal that this part has been fully processed. If this is followed by a manual inter-
vention and the robot is manually moved to the home position, the PLC can perform further
program preparation.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 37 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

JobRequest:
The PLC is queried to see if the release for a particular job is present. This function is usually only
used in the organization program. It is also possible to request a type number and/or a user number
for the corresponding job request
A JobRequest command can be canceled via the PLC.

The PLC asks whether approval for a certain job has been given. In exceptional cases it is also pos-
sible for the PLC to specify a job No. This is the "AnyJob" function, but it may only be used with the
consent of the relevant control technology.
The JobRequest function is usually only used in the organization program.
It is also possible to request a type number and/or user number for the job request. If "AnyJob" is
used, you should also remember that in certain circumstances there is not a user or type number
available in the PLC for all possible jobs.

Information and restrictions are described in the PLC documentation!

JobRequest commands can be canceled using the PLC.

JobClearAll:
This function is used to inform the PLC that all jobs have been completed. The "Job-interface" is
completely reset. Single jobs cannot be reset. All "JobStarted" and "JobDone" signals retain their
status until everything is deleted by "JobClearAll".
This function has been developed primarily for use in the initialization programs and for last program
step.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 38 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field 2: Motion type selection


Motion positions can be programmed with the "Job_Started", "Job_Done" and Job_Clear functions.
Job_Request is only possible without motion.

After selection of "PTP or LIN" all fields necessary for the respective motion settings are shown.

The position is moved to according to the selection. The "Started-output" is always set in advance,
execution of "Done-output" and "ClearAll" is triggered at the programmed position.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 39 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field 3: Job number

A maximum of 64 jobs are available. Inputs and outputs are mapped to the I/O interface analogous
to the Job numbers.

Data entry field 4: Continue

If the "CONT" switch is set the robot performs "approximate positioning", otherwise a stop in ad-
vance of execution is performed and the robot remains in this position.
The "Done" and "ClearAll" functions are always executed exactly at the specified position, regard-
less of this setting.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 40 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field 5: Description

Up to 40 characters of text can be entered into this field.


Every command used must always be described.

Example: "Welding finished" or "gluing part xx finished"

The entry should be comprehensible and provide additional information for the user.
An entry such as "Job 1 finished" provides no additional information!!!

Data entry field 6: Type number and/or User number

In addition to a Job number request (Job_Request) a Type number and/or a User number can also
be requested from the PLC. This only requires a "tick" to be set in the corresponding field. The pro-
gram execution is stopped until the valid numbers are sent by the PLC. The function is processed in
advance.
A range of 1-255 is defined for both numbers. "0" cannot be selected.
The passed Type number and/or User number are temporarily stored in variables by the system and
can later be read once using the "GetTypNum" and "GetUserNum" functions.

Note: For safety reasons the "GetTypNum" and "GetUserNum" functions only return the valid values
once after these have been requested! Querying again returns a value of "0"!

More information on Type numbers and User numbers: Section 12.1.13

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 41 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field 7: Abort

Implementation of an abort function is not compulsory for every job. This function carries a signifi-
cant risk of collision if used incorrectly. Agreement must be reached with the customer on the ap-
propriate method and scope for implementing the abort concept.

Further information on Aborts: Section 12.1.14

Abort= "NoAbort"
The program abort function is not activated.

Abort= "Home1 … Home5"


The program abort function is activated and an "Abort" can be initiated by the PLC. The PLC does
not initiate an abort the setting has no effect and execution of the program continues as pro-
grammed!
If an abort is initiated the running program is exited and the robot moves directly to the selected
Home position at reduced velocity! After this, a new program no. is requested from the PLC.
Attention: The programming must ensures that the robot can move to the Home position without a
collision.

Abort= "AbortProgXX"
The program abort function is activated and an "Abort" can be initiated by the PLC. The PLC does
not initiate an abort the setting has no effect and execution of the program continues as pro-
grammed!
If an abort is initiated the running program is exited and the selected "Abortprogram" is started. Af-
ter this, a new program no. is requested from the PLC.
Attention: The programming must ensure that the robot can execute the abort program without a
collision.

Note: An abort program is generally executed at reduced speed for system-technical reasons.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 42 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.9.3 Job: Complex example

Job request with type and user number (standard case)


Example: Picking from 3 containers, worker station and drop station.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 43 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Jobrequest "AnyJob" is initially requested without a type and user number.


Example: Picking from 3 containers, worker station and drop station.

Program sequence

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 44 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.10 Areas
Robots usually operate in different areas. Management of these areas is implemented using the
Area concept. Unlike the collision protection concept, areas do not apply across the entire plant but
rather only between specific respective robots. Basically the PLC is the manager of the area and the
robot can only "ask" if an area is free or "notify" when an area can be entered or is free.

Please also observe the notes on the initialization concept in Section12.1.8

12.1.10.1 Area: Concept:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 45 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.10.2 Area: Program command


The Inline Form for the Area command is designed so that it dynamically changes according to the
settings. The individual data entry possibilities are described on the following pages.
The "Area" standard command (with and without movement)) for 32 Area’s is available for pro-
gramming.

Data entry field: Selection of the function

AreaRequest:
This function is used by the PLC to query if an area is free for moving into. The query always occurs
in advance, which means that under certain circumstances the query is processed by the PLC sev-
eral motion steps before reaching the area border. If the area is locked out then the robot stops at
the programmed position and waits until the release is enabled. If the release is already enabled
before reaching the programmed position the robot does not stop but rather only "approximately
positions" the movement.

AreaRelease:
This function is used to inform the PLC that the robot has exited an area of the system. This com-
mand is not processed in advance but is triggered exactly at the programmed position.

Data entry field: Motion type selection


The Area command can be programmed with and without motion positions.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 46 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

On selection of "PTP or LIN" all fields necessary for the respective motion settings are shown. The
position is moved to according to the selection.

The "Request" is always executed in advance and the Release is always executed when triggered at
the programmed position.

Data entry field: Area number

A maximum of 32 areas are available. Outputs and inputs are assigned to the I/O interface, analo-
gous to the Area numbers.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 47 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Continue

If the "CONT" switch is set the robot performs approximate positioning, otherwise a stop in advance
of execution is performed and the robot remains in this position. The "Release" function is always
executed exactly at the specified position, regardless of this setting.

Data entry field: Description

Up to 40 characters of text can be entered into this field.


Every command used must always be described.

Example: "Move to turntable" or "Leave Shuttle"

The entry should be comprehensible and provide additional information for the user.
An entry such as "Query area 1" provides no additional information!!!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 48 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Abort

Implementation of an abort function is not compulsory for every area. This function carries a signifi-
cant risk of collision if used incorrectly. Agreement must be reached with the customer on the ap-
propriate method and scope for implementing the abort concept.

Further information on Aborts: Section 12.1.14

Abort= “NoAbort"
The program abort function is not activated.

Abort= “Home1 … Home5"


The program abort function is activated and an "Abort" can be initiated by the PLC. The PLC does
not initiate an abort the setting has no effect and execution of the program continues as pro-
grammed!
If an abort is initiated the running program is exited and the robot moves directly to the selected
Home position at reduced velocity! After this, a new program no. is requested from the PLC.
Attention: The programming must ensures that the robot can move to the Home position without a
collision.

Abort= “AbortProgXX"
The program abort function is activated and an "Abort" can be initiated by the PLC. The PLC does
not initiate an abort the setting has no effect and execution of the program continues as pro-
grammed!
If an abort is initiated the running program is exited and the selected "Abort Program" is started.
After this, a new program no. is requested from the PLC.
Attention: The programming must ensure that the robot can execute the abort program without a
collision.

Note: An abort program is generally executed at reduced speed for system-technical reasons

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 49 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: ClearAll

The ClearAll function deletes all requests and releases all areas at the same time. This function has
been developed primarily for use in the initialization programs. Basically, the area releases should be
programmed individually at the places where the robot leaves the area.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 50 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.10.3 Area: a complex example

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 51 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.11 Collision protection


In many plants, several robots work simultaneously and sometimes on the same part. The motion
sequences sometimes overlap spatially and this can lead to collisions. The collision protection con-
cept regulates which robot can enter a motion space (collision zone) at which time. The different
collision zones are managed in the PLC and released or locked for the individual robots. Standard-
ized robot commands are available for zones in the range 1-254.

Please also observe the notes on the initialization concept in Section12.1.8

In general, one can state:


 Collision zones apply over the entire system, e.g. a zone number can only be assigned once for
each system!
 Only one robot at a time can be present in each "collision zone".
 The first robot requesting access to a zone receives the release to enter the zone, all other ro-
bots must wait!
 A collision zone can only be released by the robot that occupied the zone!

Note: The motion sequence must still be secured via collision protection even if the robots do not
come into contact because they work at different times. For example, a robot might be operated at
reduced speed for testing!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 52 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.11.1 Collision protection: Concept:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 53 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.11.2 Collision protection: Program command

The Inline Form for the Collision protection: command is designed so that it dynamically changes
according to the settings. The individual data entry possibilities are described on the following pag-
es.
The "CollZone" standard command (with and without movement)) for 1-254 collision zones is
available for programming.

Data entry field: Selection of the function:

CollZone Request:
This function asks the PLC if the robot is allowed to move into an area of the system (collision zone).
The query always occurs in advance. This means that under certain circumstances the query is re-
ceived by the PLC several motion steps before reaching the collision border. If the zone is locked
out then the robot stops at the programmed position and waits until the release is enabled. If the
release is already enabled before reaching the programmed position the robot does not stop but
rather only "approximately positions" the movement.

CollZone Release:
This function is used to inform the PLC that the robot has exited an area of the system (collision
zone). This command is not processed in advance but is triggered exactly at the programmed posi-
tion.
Note: Only the robot occupying a given zone can later release this zone. Releases for non-occupied
zones have no effect!

Data entry field: Motion type selection


The CollZone command can be programmed with and without motion positions

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 54 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

On selection of "PTP or LIN" all fields necessary for the respective motion settings are shown.

The position is moved to according to the selection.


The "Request" is always executed in advance and the Release is always executed when triggered at
the programmed position.

Data entry field: Selection ExtPlc

The command should usually takes effect in the own PLC area. The PLC can also be optionally noti-
fied that the communication is provided for the PLC neighbor area.

PLC= " “ (empty)


The command takes effect in the own PLC area. Default setting:

PLC= “ExtPlc"

In rare situations it is possible that a robot must perform tasks across the plant in 2 different PLC
controller areas. (E.g. a part is picked up in the area of the associated PLC and must be placed in the
area of another PLC). In this case the selection "ExtPlc" can be used to notify the PLC that this
command is to take effect in the other PLC area.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 55 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Collision zone number

A maximum of 1-254 zones are available. No individual inputs and outputs of the I/O interface are
available to the user. The communication is implemented using an 8 bit number and control bits.
The values "0" and "255" are not valid zone numbers and cannot be selected.

Data entry field: Continue

If the "CONT" switch is set the robot performs approximate positioning, otherwise a stop in advance
of execution is performed and the robot remains in this position. The "Release" function is always
executed exactly at the specified position, regardless of this setting.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 56 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: ClearAll:

The ClearAll function releases all collision areas occupied by this robot. This function has been de-
veloped primarily for use in the initialization programs. The collision releases should always be pro-
grammed individually at the places where the robot leaves the area.

Data entry field: Description

Up to 40 characters of text can be entered into this field.


Every command used must always be described.

Example: "K-Zone for 01R02"

The entry should be comprehensible and provide additional information for the user.
An entry such as "Coll zone 1" provides no additional information!!!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 57 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.12 User communication


In many cases it is necessary to synchronize program sequences and exchange information be-
tween the robot and the PLC. The PLC_COM command has been developed in order to support
most of the handshake situations between the PLC and robot. The command is structured in 3 lev-
els. This means that 3 commands can be programmed.
Note: Not all levels need to be used.
The command supports the 512 PLC I/Os, one User Number (8 Bit) and one Type Number (8 Bit).

Level 1 allows one of the PLC outputs to be set or reset.


Level 2 allows waiting for one of the PLC inputs or an action to be triggered.
Level 3 allows one of the PLC outputs to be reset or set.

Example 1:
The robot has reached the maintenance position and signals this to the PLC.

1st command: Set PLC_do_ServicePos / maintenance position reached


2nd command: Wait PLC_di_10 / return message "maintenance done", the robot is allowed to
continue moving
3rd command: Reset PLC_do_ServicePos / leave maintenance position

Example 2:
The robot is to remove different parts from a magazine. The PLC knows the content of the magazine
and specifies the removal sequence.

1st command: Set PLC_do_20 / Request a compartment number


2nd command: UserNum_Request / Request the compartment number
3. command: Reset PLC_do_20 / Reset the request

Please also observe the notes on the initialization concept in Section12.1.8

12.1.12.1 User communication: Concept:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 58 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.12.2 User communication: Program command

The Inline Form for the User Communication command is designed so that it dynamically changes
according to the settings. The individual data entry possibilities are described on the following pag-
es.
The "Plc_Com" standard command (with and without movement)

Data entry field: Selection of the motion type:

The User communication command can be programmed with and without motion positions be . On
selection of "PTP or LIN" all fields necessary for the respective motion settings are shown. The
position is moved to according to the selection.

Data entry field: Selection of the function for the 1st command

The "Set user output" and "Reset user output" actions can be selected.
No selection ("_") means that no function is executed.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 59 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Select a user output for the 1st command

Only the 512 PLC outputs of the standard interface be selected. Other inputs are not supported by
this command.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 60 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Selection of the function for the 2nd command

7 different "actions" can be set for the 2nd command.

Wait_Input=1
The program pointer waits until the specified input reaches the "high" state.

Wait_Input=0
The program pointer waits until the specified input reaches the "low" state.

Request_UserNum
A user number is requested from the PLC via the standardized interface. The program stops at this
selection until the PLC sends a valid User-Num (1-255). The number "0" cannot be used. This user
number can then be used later in the program. (See Section 12.1.13.3)

Send_UserNum
PLC can be sent a user number via the standardized interface. A numeric range of 0-255 is permit-
ted. (see Section 12.1.13.1)

Request_TypNum
A type number is requested from the PLC via the standardized interface. The program stops at this
selection until the PLC sends a valid Type-Num (1-255). The number "0" cannot be used. This type
number can then be used later in the program. (See Section 12.1.13.3)

Send_TypNum
The PLC can be sent a type number via the standardized interface. A numeric range of 0-255 is
permitted. (see Section 12.1.13.1)

No selection ("_") means that no function is executed.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 61 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Assignment of a user input to the 2nd command

Only the 512 PLC inputs of the standard interface can be selected. Other inputs are not supported
by this command.

Data entry field: Send a user number

Selection of "Send_UserNum" and "Typ_UserNum" allows a numerical value from 0-255 to be en-
tered into the data entry field.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 62 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Selection the function of the 3rd commando

The "Reset_Output" and "Set_Output" actions can be selected. No selection ("_") means that no
function is executed.

Data entry field: Assigning a user output to the 3rd command

Only the 512 PLC outputs of the standard interface be selected. Other inputs are not supported by
this command.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 63 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Data entry field: Continue

If the "CONT" switch is set the robot performs the movement with approximate positioning. The
configured actions are performed in advance. If "CONT" is not set the robot remains at the pro-
grammed position. The configured actions are only performed after this.

Data entry field: Description

Up to 40 characters of text can be entered into this field.


Every command used must always be described.

Example: "Camera 1, Start image!"

The entry should be comprehensible and provide additional information for the user.
An entry such as "Set Output 1 and wait for Input1" provides no additional information!!!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 64 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.13 Type number / User number


The "JobRequest" and "PlcCom" commands can be used to exchange an 8 bit Type number or User
number with the PLC.
Type numbers are primarily used for selecting / sending response messages for different vehicle
types (e.g. G11, G12, etc.). The user number can be used as decision-making information (e.g. stor-
age compartment no.) during execution of the program.

Attention: Type numbers and User numbers must always be requested / sent using the specific
commands and functions provided for this purpose. Evaluation of the direct I/O signals is not per-
mitted because they only have the correct status briefly during communication!

12.1.13.1 Sending Type number / User number


A Type number / User number must be sent using the "PlcCom" robot command.
Further information: PlcCom: Section 12.1.12.2

12.1.13.2 Send Type number / User number, as first response to a JobRequest


request

The function has been developed to allow the PLC to check if the robot has actually jumped into the
specified sequence! This can occur when the organization program contains logical errors or (e.g.) if
sequence programs have been incorrectly copied.

Example: Program sequence with 2 types

When a Type number / User number is requested via the JobRequest command, the PLC expects
the same number to be "mirrored back" in the first response after the command! If a different
number is returned the program startup is stopped and corresponding messages are displayed on
the robot control panel and the system PC.
The return mirroring is performed using the "Plc-Com-Command" in the sequence program!

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 65 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Examples: Error message on robot control panel

The checking function in the PLC only works for the first return mirroring of a number after a
"JobRequest-Command incl. TypNum/UserNum-Request" has been programmed!

The function is reset in the following situations:


 After "Start from Cell"
 After "Request program -Nr."
 After a "JobDone" command in the user program
 After successful return mirroring of a number
 After a JobRequest command without a "TypNum/UserNum Request"

12.1.13.3 Requesting a Type number / User number

Type numbers and User numbers must be requested using the “JobRequest" or "PlcCom" robot
commands. If no valid numbers are present in the PLC at the time of the request then the moved
pointer stops at the robot command and generates a message after the expiry of "MaxTime". This
message cannot be acknowledged, the robot program waits until a valid number has been exchanged
and verified.

After a successful request the number is temporarily stored in an internal system variable. This can be
processed further in the user program via the "GetTypNum" or "GetUserNum" functions. If the number
is only required once then it can be used directly via the function, otherwise it can be copied into a
user variable.

Attention: For safety reasons, the functions return the valid values only once these have been re-
quested!! Querying again returns a value of "0"!

Further information:
JobRequest: Section 12.1.9.2
PlcCom: Section12.1.12.2

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 66 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.13.4 Undefined number range


A "Default Case" must be programmed in the user program to deal with the "Passing of an unknown
number" situation. The "plc_defaulterror()" program is to be used for this error case If an error occurs
the cursor remains stuck in the "plc_defaulterror()" program. The following message is output.

If the number is also passed, as shown in the sample program: 12.1.13.5 then it is shown on the dis-
play.

The "Start CELL" manual intervention and checking or possible modification of the user program
would then be necessary.

12.1.13.5 Example program

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 67 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.14 Abort program


In chassis construction systems different program numbers are normally used for starting a robot
after a fault (See Section Program structure12.1.4.1)Error! Reference source not found.
The abort concept was developed to allow implementation of targeted exit jumps out of the "nor-
mal" program execution. An "abort" must always end in a Home position! The renewed jump into
the program sequence is always performed by requesting a new program number.
An abort can only be programmed via the "Job" or "Area" commands. This command only informs
the PLC that the robot is currently at a possible abort position. The abort is triggered exclusively by
the PLC!

In general, the abort must be implemented at suitable positions in the program (e.g. before starting a
job). Aborting a job that has been started is not permitted!

Note: The abort function carries a significant risk of collision if used incorrectly. Care must be taken
to ensure that all possible program sequences have been properly tested. Agreement must be
reached with the customer on the appropriate method and scope for implementing the abort con-
cept.

12.1.14.1 Program Abort: Concept:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 68 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

A distinction is made between 2 different types of abort:

12.1.14.2 Program Abort: Robot in the Home position:


This function was primarily developed for aborts in organization programs. This is implemented us-
ing the command: Job Request / Abort = Home1(2,3,4,5)

If the PLC triggers an abort then a check is made to see if the robot is in a Home position. If yes, the
robot program is aborted at this position and the program pointer in the "CELL" program is set to
the "Request new program number" line. In this case the initialization programs are not not execut-
ed!
Attention: In this application case it must be ensured that the robot is in the specified Home posi-
tion, otherwise the robot would move to the selected Home position using a direct path.

Further information:
Job command in Section 12.1.9.2, Data entry field abort

12.1.14.3 Program Abort: Robot not in any Home position:


This function was primarily developed for aborts at defined positions in user programs. This is im-
plemented using the commands:
Area Request / Abort "AbortProgXX" or "Home1 … Home5"
Job Request / Abort "AbortProgXX" or "Home1 … Home5" (if the robot is not yet at the selected
Home position)

If the PLC triggers an abort then the selected "Abort Program" is started or the robot moves directly
to the specified "Home position". This occurs at a reduced speed. It must be ensure that the abort
program ends at a Home position, otherwise the abort is denied with an error message. The "Start
CELL" manual intervention and checking or possible modification of the user program would then
be necessary.
After a successful abort the program pointer in the "CELL" program is set to the "Request new pro-
gram number" line. In this case the initialization programs are not executed!

Further information:
Job command in Section 12.1.9.2, Data entry field abort
Area command in Section 12.1.10.2, Data entry field abort

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 69 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.14.4 Program Abort: Abort programs

All abort programs must always be designed and tested to exclude the possibility of collisions in all
cases.

Abort programs can only be used in the "Job" and "Area" commands when they have first been
created via the "ModAbortPrograms" menu. Conformance to the naming convention is compulsory!
Since abort programs are not included in the regular sequences and are only used in exceptional
cases, these must be programmed with an appropriate speed.
For an abort, it must be noted that the collision protection and area concept may need to be updat-
ed. The last position must be a home position, otherwise automatic execution of the program can-
not continue.

The required menu us located under:

The program is stored in the directory: R1 /Program / Abort

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 70 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.14.5 Program abort: complex example

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 71 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 72 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.15 CheckHome & Rehome


The “CheckHome” instruction is a designed for use in 2 scenarios. The concept of the instruction is to
check that the robot is in a specified home position prior to a routine executing, if the robot position
doesn’t match the requested home position then an error message to the PLC will be generated.
When the optional parameter “Rehome” is selected then the instruction in addition to the above,
checks the existence of a routine to automatically move the robot between home positions.

Note:
This functionality is only available in version V1.4.0 of A01 and later.

12.1.15.1 Check home function


The instruction is not tied to a position.
The instruction is dynamic and only displays the Home positions that have been programmed.
The instruction should be inserted at the start of process programs and where ever a confirmation of
home position is required.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 73 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.15.2 Check home with “Rehome” function

The “ModHomePrograms” GUI is used for creating “Home to Home” programs similar in concept to the
“Abort Programs”. The “HomeX_to_HomeX” programs are stored inside the “Home Programs” Folder
and MUST be programmed to enable a safe robot path between homes.

It is the responsibility of the line builder to ensure all programs are fully tested prior to handover.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 74 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.16 Other functions

12.1.16.1.1 Stop at process point

The user must be able to stop a process at a particular process point.


An operating image is provided for this in the visualization on the system PC.
This can be accessed via the menu Lines / General / Process Data / Robot Data.

Illustration of the data entry form on the system PC

The operator must enter the Process ID and the associated Application Number. A maximum check-
ing time, specifying the maximum time allowed for finding the process point, must also be set. The
check is automatically ended if not robot has recognized this ID within this time. The check is start-
ed via the Start button.

Note: Poorer cycle times are to be expected while a check is active. This is because every robot
queries the SPS signal ProcessRel before each process point. If process point monitoring is activat-
ed, this signal is not set to "one" until the PLC has confirmed that the next process number output
by the robot is not the number to be checked.

12.1.16.1.2 Controlled Stop


A button for requesting access (blue button) is located at every safety door.
When this is pressed the PLC sets the input signal PLC_di_ControlledStop.
The robot stops its current process at a suitable place and notifies the PLC that the robot is con-
trolled stopped via the PLC_do_ControlledStop output signal. In addition, after a while a message is
displayed in the robot that it has performed a controlled stop.
After all the robots in a system have signaled a controlled stop the safety door is released by the
PLC.

12.1.16.1.1 Controlled stop: Program command

The inline form for the Controlled Stop command is provided for special cases only, where a con-
trolled stop is required, which cannot be covered via the standard commands.

Note: The ILF must be programmed with a Repeat Until loop with waiting time.

An application case is e.g. the ILF at a visual inspection position for adhesive application verification.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 75 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

Implementation example:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 76 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

12.1.16.2 Locking in the case of multiple querying of the same areas and colli-
sion zones
The "Area" and "CollZone" commands can be position-triggered and programmed with approxi-
mate positioning for advance execution. If the same areas are multiply queried and released in suc-
cession then this presents a danger of the corresponding signals overlapping in time and creating
an undefined state in the PLC.

Example:

To prevent this, a lock is implemented in the "Area" and "CollZone" commands.


The Release command signals the number of the area to be release
In the advance execution. The Request command checks if the area queried is already noted
for release. In this case the Request command waits until the Release occurs in the main execution.

Multiple querying and intermediate releases are pointless and the user program must be corrected.
In Automatic operation the following message is generated:

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 77 of 78
Standard documentation for chassis construction systems
Section 12.1 Robotics - General Component
Standard
Electrics
BP V2.0

In T1 or T2 operation, moving the cursor or aborting a program can cause an area to be requested
again. In this case there is no program error but the lock still engages. The following message dia-
log is displayed.

If the dialog is answered with "Yes" then the "previous request query" is canceled and "new request
query" is sent to the PLC!

If acknowledged with "No" the program sequence remains unchanged and the controller continues
to wait for a release from the PLC.

MAN_Kap12_01_ROB_Common_General_160218_en.docx
© All rights reserved by BMW AG, also in the case of patent applications.
All rights of disposal, such as rights of copying and distribution, lie with the BMW Group.

Page 78 of 78

Das könnte Ihnen auch gefallen