Axesbrain Motion System

Volume 1 AxesBrain Motion System

Motion system

A x e s B r a i n Motion system

AB&T Tecnologie Informatiche  Via dell’About, 2/A • 10015 Ivrea Fax +39 0125 234397 www.bausano.net [email protected]

Legal notice

The information in this document, including URLs and other references to the Internet website, can be changed without prior notification. Unless otherwise indicated, references to companies, organizations, products, persons and events are completely fictitious and unrelated to real companies, organizations, products, persons and events. AB&T Tecnologie Informatiche  is entitled to register, license, apply for copyright or trade marks and affirm its intellectual property rights with regard to all the topics dealt with in this document. Without limiting entitlements under copyright, no part of this document can be reproduced, modified, or transmitted in any form and using any media (electronic, mechanical, photocopy, recording, or other) without the prior express authorization of AB&T Tecnologie Informatiche . Except in the case of written agreements with AB&T Tecnologie Informatiche  the fact of being supplied with this document shall not authorize any party to register, grant licenses, apply for copyright or trade marks or affirm its intellectual property rights with respect to the subjects dealt with herein.

AxesBrain , VisAlgo , ScadaMERCURIO  are registered trade marks AxesBrain, VisAlgo are covered by copyright

ActiveX, DirectX, JScript, Microsoft, Microsoft Press, MS-DOS, Visual Basic, Visual C++, Win32, Win32s, Windows, WDM, Windows NT, Windows 2000 and Windows Me are products or trade marks registered by Microsoft Corporation in the U.S.A. and/or in other Countries. The names of companies and products quoted in this document may be trade marks that have been duly registered by their owners.

Contents

Introduction i Synchronization instructions 7

Indication instructions 8

CHAPTER 1–Motion system - Service instructions 9

Architecture 1 Intructions for integrtation with foreign

Interface devices 2 environments 10

Services (DCOM) 3

Coordinates and anti-collision systems 4 CHAPTER 4 – CNC (AxesBrainISO)-

Plant configuration 5 Architecture 1

Sampling 6 Physical axes link 2

OEM Capability 7 Work plane 3

User interface 8 Motion functions 4

Integration with vision inspection 9 G functions 5

M functions 6

CHAPTER 2–AxesBrainServer services - T functions 7

Basic system functions 1 F, S and O functions 8

Axes and spindles functions 2 Program control instructions 9

Functions for signals 3

Subsystem functions 5 CHAPTER 5 - PLC(AxesBrainAWL) -

Plant indication functions 6 Architecture 1

System configuration functions 7 Types of data and addressing modes 2

Server events 8 Contact instructions 3

Access with AxesBrainBase (DLL library) 9 Timer and counter instructions 4

and AxesBrainCom (OCX library) Mathematical instructions 5

Increment and transfer instructions 6

CHATPER 3 – Automation (AxesBrainL)- Program control instructions 7

Architecture 1 Logic stack instructions 8

Language syntax 2 Boolean instructions 9

Global and local variables 3

Multitasking and anti-collision systems

Mathematical logic instructions 5

Control instructions 6

Motion instrucitons 7

I/O instructions 8

CHAPTER 6 Environment APPENDIX A

(AxesBrainStudio)- Virual axes

Architecture 1 APPENDIX B

Basic applications 2 Ganrty axes

OCX applications 3 APPENDIX C

HTML applications 4 Axis control with handwheel

APPENDIX D

Electronic cams

APPENDIX E

Continuous motion

APPENDIX F

Integration with vision inspection

Introduction

AxesBrain motion system

The AxesBrain system was developed to offer motion control services to user applications, utilizing “DCOM” technology, thus making it possible to provide access to the services not only from the PC in question, but also from PCs networked in LANs and connected over the Internet.

here are essentially two approaches to be taken in order to utilize motion control services, either using the functions directed to axes and spindle resources and I/O signals, or making use of programmed cycles. Axes path and manipulation and processing task cycles or procedures are T defined by means programming languages; in our case we have three languages at our disposal: AxesBrainL, AxesBrainISO and AxesBrainAWL, which the user can adopt depending on the type of application in question. It is also possible to integrate, as a library, functionalities or even processes for the management of work cycles that are tailored to meet specific needs, completely developed by the user.

The motion control services are as follows:

• Direct FUNCTIONS

o commands transmitted to axes and to I/O signals

o acquisition of field values, reading of axes, I/O, transducers, etc.

o programming of modes for trajectories, acquisitions, etc.

• processing and manipulation CYCLES programmed by means of

o AxesBrainL – Proprietary language suitable for describing manipulation cycles for generic automations

o AxesBrainISO – ISO standard language suitable for describing the processing cycles typically associated with milling, boring and turning operations.

o AxesBrainAWL – AWL language to describe PLC cycles

• Special “OEM” FUNCTIONS

• processing and manipulation CYCLES with programming of special “OEM” procedures

AxesBrain is structured as a series of functional modules in such a way as to achieve the maximum flexibility in terms of management of devices, user interface characteristics, and performance features.

AxesBrain is divided as follows:

• “AxesBrainOpenEnviroment” module for driving interface devices; in addition to the management of several ranges of commercial devices, this module was developed in an open architecture system so as to allow the devices to be expanded in accordance with changing requirements of users.

• “AxesBrainServer” basic module, supplier of system services in “DCOM” technology.

• “AxesBrainOpenTemplate” basic classes module to allow the user to develop new performances, both in terms of functions and procedures.

• “AxesBrainBase” interface module for connection with services for applications in Visual Basic or Visual C++

• “AxesBrainCom” interface module for connection with services for HTML user pages or for applications compiled in any of the various programming languages.

• “AxesBrainStudio” user interface environment, this module allows the creation of highly personalized user interfaces.

AxesBrain architecture

64 Axes 32 Spindles 1024 Digital inputs 1024 Digital outputs 128 Analog inputs 128 Analog outputs 128 Counters Images for measurements and 128 Timers recognition

1-Carriers+IP Industrial Pack 2-USB Controller 1-PC Axis Board 1-Frame grabber PCX 200 3-Encoder 2-OEM Encoder + Analog DAC 2-Frame grabber P610 4-Analog DAC 3-OEM 1394 Axis controller 4-OEM Axis controller 5-USB SEB I/O VisAlgo OpenEnviroment access and pilot Driver AxesBrainOpenEviroment - Driving of interface devices

Functions and cycles for AxesBrainOpenTemplate AxesBrainL AxesBrainISO AxesBrainAWL image data processing and Automation CNC PLC - OEM Capability analysis Remote or Programmed motion cycles Local VisAlgo Connection

OEM capabilities Direct commands and Programmed cycles 1 - VisAlgoBase DLL Library Access Functions system resources and instructions access 2 – VisAlgoCom OCX Library access function functions

AxesBrainServer DCOM - Handling system services

Remote or Local Connection

AxesBrainBase DLL Library AxesBrainCom OCX User Cycles Library

Basic Applications

Visual Basic User Applications OCX User HTML User Applications Applications HTML User Applications Visual C++ / Visual C# User Applications

AxesBrainStudio – Applications and User Cycles Container Environment

Figure 1

Chapter 1

Motion system

The motion system is the controller of all the resources and the supervisor of the motion functionalities requested either directly or by way of processing cycles programmed utilizing the three programming languages; in addition, it can integrate, in the form of a library, functionalities and the work cycles management processes, completely developed by the Customer. During the desoign stage, particular attention was devoted to the scalability of the system in terms of devices, functions, plant and user interface.

The requirements of the environment in which a handling system is installed are numerous, ranging from:

• the type of motors:

dc motors, stepper motors, brushless motors, linear motors, etc.

• the motor control system:

analog drives, digital drives, etc.

• the type of electronic devices that make it possible to access the motor drives:

PCAxisBoard, PCFieldBus, PCEncoderBoard, PCAnalogBoard , etc.

• the type of PC bus:

PCI, AT, 104, CompactPCI, etc

• the type of operating system

Windows 98, Windows Me, Windows 2000

The AxesBrain system is designed to introduce the maximum flexibility into the scenario described above, creating a layer denominated AxesBrainOpenEnviroment , which contains a series of modules designed to drive various commercial devices, and a basic class in order to facilitate the development and integration of new devices. This makes it possible also to separate the driver environment from the applications.

A basic requisite of a motion control system is that it must be able to supply its services to a plurality of users, potentially resident on remote PCs; this requirement is filled by the Distributed Component Object Module (DCOM) technology utilized in the implementation of the AxesBrainServer .

Although the system provides a broad band of functionalities, it is impractical to be able to develop responses for the entire range of requirements of a motion system. For this reason, the system was designed in such a way as to create the maximum expandability in terms of performances, which, in this case, can be developed directly by the Customer and which the system is able to integrate in the form of an OEM library, which are supported on a Template of specific classes; this facility in terms of the extension of functional aspects is provided by the AxesBrainOpenTemplate module.

The User Interface is implemented as a Client of the AxesBrainServer module and can be freely developed by the Customer, utilizing any programming language that is compatible with DCOM technology. To increase the efficiency and extend the range of programming languages, two libraries interfacing with the DCOM services of the AxesBrainServer have been developed: the first is a DLL library denominated AxesBrainBase , the second is an OCX technology library denominated AxesBrainCom .

In order to allow the use of several common user interfaces such as editing of programs, plant characterization, plant supervision, monitoring of signals and states, etc., a series of basic applications have been developed, which can be integrated uniformly with the user applications. These basic applications have been included in a context denominated AxesBrainStudio

Architecture

The architecture of AxesBrain is articulated on three levels:

• AxesBrainOpenEnviroment (First Layer FIELD) Manager of motion devices.

• AxesBrainServer (SecondLayer DCOM “Distributed Component Object Model” ) Supplier of motion services

• AxesBrainStudio (Third Layer APPLICATION LAYER) Container of user and basic applications for the management of the functions, handling cycles, and customer applications of the DCOM AxesBrainServer. The third level contains the user applications.

FIRST LAYER

AxesBrainOpenEnviroment FIELDManag – Manager of motion devices

SECOND LAYER

AxesBrainServer DCOM – Supplier of motion services

Remote or Local Connection

THIRD LAYER

AxesBrainStudio APPLICATIONS LAYER – Container of basic and user applications

Interface Devices

Software modules denominated “Drivers” designed to manage devices and located in a library, were developed by starting from a basic class; this open architecture is designed to facilitate both the development of new modules and also the extension of their performance capabilities. Indeed, the expression “OpenEnviroment” emphasises the fact that the system was developed in such a way that additional devices can be easily integrated as new demands emerge. The Drivers are created using Windows Driver Model (WDM) technology in such a way as to remain independent from the Microsoft Windows operating system:

Windows 98 Windows Me (Millenium Edition) Windows 2000 .

The devices currently managed by the AxesBrainOpenEnviroment can be subdivided into ranges as follows:

• “Industrial Pack” range with SBS Carrier for PCI, CompactPCI, PC104 , PCAT

° IP Tews 1, 2 axis encoder ° IP SBS unidig T 4 timers/counters ° IP SBS unidig 48 48 digital I/O’s ° IP SBS 8 DAC 8 analog outputs ° IP SBS 32DAC 32 analog outputs ° IP SBS 16DAC 16 analog inputs

• USB range

° USBController for Encoder and Stepping axes and digital/analog I/O’s ° USBController for digital/analog I/O’s

• PC board range

° Encoder Axes ° Analog outputs ° PC8255 4 Timers + 48 digital TTL I/O’s

• PC AxisBoard range

° (currently in analysis phase)

The Industrial Pack range with SBS Carrier for PCI, CompactPCI, PC104 , PCAT, although the most expensive, offers three very important benefits:

• Compatibility with all PC platforms (PC-AT , PC-104, PCI, CompactPCI).

• Facility to achieve the maximum physical expandability in terms of:

° 64 physical axes ° 32 spindles ° 1024 digital inputs ° 1024 digital outputs ° 128 analog inputs ° 128 analog outputs ° 128 timers ° 128 counters.

The facility for sampling of 100 microseconds for 8 axes (using processors with a clock speed of at least 500 MHz).

The USB range, which is the easiest to use because it can be connected to the PC by way of the USB port (present on almost all modern PCs), is somewhat limited in terms of sampling frequency, which is fixed at 1 millisecond. Expandability is as follows:

° 32 physical axes ° 32 spindles ° 512 digital inputs ° 512 digital outputs ° 64 analog inputs ° 64 analog outputs ° 16 counters.

The PC Board range, although the most economical, presents considerable problems in the context of expansion and compatibility with different types of platforms.

The PC AxisBoard range is currently undergoing analysis.

The AxesBrainOpenEnviroment platform is designed in such a way as to provide scalability of the motion system in terms of devices .

Note: Particular attention is currently being devoted to 1394 FireWire devices.

Motion services supplier (DCOM)

The AxesBrainServer is the supplier of motion services of the resources and acquisition of field data. The server was developed in DCOM architecture for two important reasons: • MULTIUSER - several applications active simultaneously in the request for motion control services

• REMOTE CAPABILITIES - some or all of the applications can be resident on different machines, provided they are connected in a LAN or over the Internet.

Various types of scenario can be implemented: • Work Station (User Interface) + Controller on a single PC

• Work Station (User interface) on one PC + Controller on a second PC

• Controller without User Interface, although when connected to a PC on a network management can be obtained

• Controller with more than one User Interface, e.g. a second User Interface only for unloading / loading tasks.

• Connection from any remote PC in order to perform verification and checking operations

• Remote control of unmanned machines

The AxesBrainServer is designed in order to obtain scalability of the motion system in terms of functionality .

AxesBrain DCOM

Co-ordinates and anti-collision systems

Resources, i.e. the parts that make up a field, consist of the following:

• Axes • Spindles • Digital inputs • Digital outputs • Analog inputs • Analog outputs • Timers • Counters

Axes can operate in various different co-ordinate systems. AxesBrain features three types of co- ordinate systems plus several variations on the theme:

Cartesian System

The axes lie on the three co-ordinates X, Y and Z; this is the normal working unit:

1. X axis of abscissa 2. Y axis of ordinate 3. Z axis of altitude

Polar System

Cylindrical “quill” type system:

Composed of a rotating axis denominated A1 plus a quill axis denominated Y1 Axis C1 with rotary compensation of the angle defined by axis A1.

Cylindrical “traversing” system

Composed of a rotating axis denominated A1 plus a traversing axis denominated X1 Axis C1 with compensation of the angle defined by axis A1

Scara System

System composed of two rotating axes A1 and B1 plus a third rotating axis C1 for compensation of the rotations of A1 and B1.

Pantograph

Type of Scara with mechanical compensation of axis B

as shown in the figure, axis B1 remains mechanically tied to the position with respect to the Cartesian axes. Also this system features a C1 axis for compensation of axes A1 and B1

Virtual axes

For both polar and “SCARA” systems it is necessary to be able to refer to the axes as though they were in a Cartesian co-ordinates system; for this reason we have introduced the concept of virtual axes (Cartesian system) with respect to the physical axes that provide the movements.

VIRUALE ORDINATA = ORDINATE VIRTUAL AXIS QUARTO ASSE = FOURTH AXIS TERZO ASSE = THIRD AXIS SECONDO ASSE = SECOND AXIS PRIMO ASSE = FIRST AXIS VIRTUALE ASCISSA = ABSCISSA VIRTUAL AXIS

Anti-collision system

The axes are therefore grouped in such a way that they can work independently, although they may be operative on a single physical axis, for example a gantry with several arms working on the same supporting axis. In this case the system is able to solve the problem of anti-collision logic by managing momentary stopping of one axis to wait for another axis to move to a safe position.

Axis X arm 1 Axis X arm n

In this case programming is performed using a separate cycle for each arm, otherwise it would be extremely task-intensive to have to calculate motion of the entire system; it is therefore the AxesBrain system with its anti-collision function that controls management of obstacles; the only precaution required is to ensure that the programming of the cycles does not result in conditions of deadlock..

Plant configuration

Axes can be subdivided into several co-ordinate systems, work together or separately, and work on different and concurrent cycles.

Aggregation of the axes is performed dynamically and managed only by the commands or instructions of the programmed cycles; therefore, there may be several systems working together: robot lines, some of which with SCARA geometry, others with POLAR geometry and others still with Cartesian geometry. With this philosophy we can create a machine with integrated feeding systems, the only limit being the maximum number of axes, i.e. 64.

Plant configuration example:

Line with Scara, Polar, Cartesian Robots

Axes Brain

Operator machine with loading procedures performed by a Scara robot and unloading performed by a Cartesian gantry robot

Axes Brain

Operator machine with 3 Cartesian arms articulated on a single gantry

Axes Brain

The co-ordinates systems and configurations enable scalability of the motion system in terms of plant .

Sampling

Axes management calls for a sampling time interval, with the scope of performing cyclic calculations for:

1. Transformation of the SCARA and POLAR co-ordinate systems 2. Interpolation of co-ordinated axes 3. Management of continuous movement of co-ordinated axes (Normal, SPLINE) 4. Control of PID (D2,Ie) for each analog axis

The use of CPU resources for axes management is therefore proportional to the number of axes and calculations to be performed. Point 4 (control of the PID (D2,Ie) with EMBEDDED DSP devices or digital axes) is delegated to the device itself and will therefore not impinge on the sampling utilization time. For sampling purposes, an embedded real-time system has been designed with the Microsoft Windows operating system (Windows 98, Windows Me, Windows 2000), which makes it possible to obtain sampling on machines with minimum clock speed of 500Mhz, of 100 microseconds for 8 axes or 500 microseconds for 32 axes, or 1 millisecond for 64 axes. All times are quoted for analog axes (i.e. worst possible case).

Sampling functional layout

Maximum sampling times

Remaining 70% of sampling time is left 8 axes 100 microsec 35 microsec average time utilized to operating system 32 axes 500 microsec 150 microsec average time utilized 64 axes 1 millisec 300 microsec average time utilized USB controller 1 millisec 20 microsec average time utilized

30% of maximum time of sampling cycle is utilized for

1-Transformation of co-ordinates system SCARA or POLAR systems 2-Axes interpolation 3-Continuous management (Normal, Spline) 4-PID control (D2 ,Ie) of analog axes

A faster sampling frequency improves resolution of the system, not only for the PID (D2,Ie), but also in non-linear trajectories (circular, Spline, virtual axes, etc.), which are calculated in the effective sampling time (in real-time).

OEM Capability

AxesBrainOpenTemplate allows the integration of specific Customer functionalities, making it possible to add new instructions and new work cycles, with the relative commands. These functionalities are integrated as a specific DLL owned by the customer and added to those of the basic system. AxesBrainOpenTemplate features specific classes that serve to integrate Customer functions as DLL files.

OpenOEMDll CloseOEMDll

Basic Classes class COEMCapability Create(…) OnGetStatusOEM( .. ) OnCommandOEM(..) OnReadRunningProcessesOEM(..) Close(..)

class CRegistryOEM Methods: Create(..) ReadRegistry( int iKindRegistry, int iStartElement, int iNumberElements, Variat) WriteRegistry( int iKindRegistry, int iStartElement, int iNumberElements, Variat) Close(..)

class CArrayOEM Create(..) ReadArray(int iKindArray, int iNumArray, iStartElement, iEndElements,Variat) WriteArray(int iKindArray, int iNumArray, iStartElement, iEndElements,Variat) Close(..)

class CProcessOEM Create(..) GetStatusProcess( .. ) CommandProcess(..) GetParametersProcess(..) SetParametersProcess(..) ExecProcess(.. ) KillProcess ( ..) SendProcessCompleted (.. ) SendOrClearSubSystemEventSignal (..) WriteServiceParametersAndContinue (..) WaitSignal (..) WaitServiceParameters (..) Close(..)

class CInstructionOEM Create ExecInstruction( ) KillInstruction( ) SendInstructionCompleted ( ) SendOrClearSubSystemEventSignal (..) WriteServiceParametersAndContinue (..) WaitSignal (..) WaitServiceParameters (..) Close

User interface

AxesBrainStudio is a package of applications that allow the user to interface with the handling system.

The software can be subdivided into basic applications and user applications. The basic applications provide plant control functions, and make it possible to program and edit working and manipulation cycles, monitor controlled resources, configure the plant, perform maintenance, and generally provide all the tools needed by the user to manage the plant or machine in question; user applications, on the other hand, serve to personalize these tools in such a way as to tailor the user interface to match the specific requirements of individual systems.

User applications can be developed with the majority of current programming languages (Visual Basic, Visual C++ , Java, etc.); in addition, they can also be developed in the form of pages of an HTML document.

Applications are grouped together under “Environments”, so that each becomes a “View” or “Page” of the “Environment”, thus facilitating navigation by the user.

“AxesBrainStudio” is designed in such a way as to provide “ scalability ” of the motion system in terms of user interface .

Integration with vision inspection

“AxesBrain” incorporates a method of integration with various applications, either resident on the local PC or in remote sites, a method of integration with external services which, however, remain transparent to the user interface, in such a way as to promote uniformity throughout the entire system.

The integration with applications that use the “VisAlgo” library is of particular interest.

The “VisAlgo” library supplies modules for the analysis of images generated by commercially available frame grabbers.

The functionalities are basically addressed to two types of requirement: recognition for the manipulation of parts, and measurement of components.

Integration is achieved by means of AxesBrainL language instructions, or by means of services request functions. (This method is utilized by OEM modules).

The same method can, in any event, be utilized for any type of programs that develop services which can be utilized by the motion system.

Chapter 2

AxesBrainServer DCOM services or methods

Services, designated also “Methods” are the tools with which users control motion of the machine or production plant.

The AxesBrainServer DCOM methods or services are accessed by means of a set of functions that can be subdivided, in accordance with the functions requested, into the following groups:

• Basic system functions

• Axes and spindle functions

• Functions for signals

• Subsystem functions

• Plant indications functions

• System configuration functions

In turn, the “AxesBrainServer” DCOM transmits events to:

• signal faults

• notify that the service requested has been completed

• request services from connected users

Basic system functions

In order to manage system resources globally with the processing cycles, functions are needed to: acquire the status, activate or deactivate power to axes, cancel work cycles in execution on user applications or programmed with their respective languages

1-GetAxesBrainInformations Reads system data 2-GetSystemStatus Reads system status 3-SystemCommand Transmits a command to supply or disconnect power to the axes, or resets operating requests both for automation cycles and CNC cycles, and for axes commands currently in progress

Axes and spindles functions

In order to manage axes and spindle resources the system is equipped with functions that operate directly on the resources in question by means of their name. In order to launch co-ordinated movements with mutually compatible reference systems and with continuous or SPLINE trajectories, management HANDLES must be opened.

4-ReadAxesRegister Read the value of an axis register 5-WriteAxesRegister Write a registry value to an axis 6-StartAxesBuffer Start buffering of axis data 7-ReadAxesBuffer Read buffered axis data 8-StopAxesBuffer Stops buffering of axis data 9-SendCommandAxes Transmits a command to an axis 10-ChangeOnFlyDinamicParameterAxes Change axis dynamic parameters on the fly 11-OpenHandleAxis Open an axis management HANDLE 12-CommandMotionAxis Command movement on axes 13-CloseHandleAxis Close an axis management HANDLE 14-ChangeDinamicParameterSystem Change system dynamic parameters

Functions for signals

Functions that refer to I/Os by name are provided in order to manage digital and analog I/O resources.

15-ReadIO Read the value of an I/O 16-WriteIO Write the value of an I/O 17-WaitIO Wait for the value of an I/O

Subsystem functions

Functions to manage global system resources with processing and manipulation cycles programmed in AxesBrainL, AxesBrainISO, AxesBrainAWL languages, and OEM Capability, which allows concurrent execution of several activities or cycles, of suitable flexibility for use with generic automation applications.

18-GetSubSystemStatus Read status of a subsystem 19-SubSystemCommand Transmit command to subsystem 20-GetSubSystemRegistry Read subsystem registries 21-SetSubSystemRegistry Write subsystem registries 22-GetSubSystemArray Read subsystem arrays 23-SetSubSystemArray Write subsystem arrays 24-ExecSubSystemProcess Request execution of a process 25-KillSubSystemProcess Suspend and abort execution of a process 26-GetSubSystemRunningProcesses Read processes in execution in subsystem 27-GetSubSystemProcessStatusRegistry Read status registries of a process 28-SetSubSystemProcessStatusRegistry Write status registries of a process 29-GetSubSystemProcessParameters Read parameters of a process 30-SetSubSystemProcessParameters Write parameters of a process 31-ExecSubSystemInstruction Request execution of an instruction 32-KillSubSystemInstruction Suspend and abort execution of an instruction 33-SendOrClearSubSystemEventSignal Used as simple synchronization with the subsystem signalling an event; if the subsystem process was awaiting the event, it is reactivated, otherwise the event is stored in the memory. 34-WriteServiceParametersAndContinue The subsystem process stands by, transmitting a service request; it is the service executor that calls the method: “WriteServiceParametersAndContinue”

Note: OnRequestServiceEvent Requests a service from connected users; once it has terminated the task, the user application required to fill the request must signal, by means of the function “WriteServiceParametersAndContinue” that the operation has been performed.

Service request events are :

WAIT_SERVICE Generic service request WAIT_KEYBOARD_SERVICE Keyboard input request WAIT_VisAlgo_FUNCTION VisAlgo function request WAIT_VisAlgo_PROCEDURE VisAlgo procedure request

Functions for plant indications

When the AxesBrain system detects anomalies, error conditions or indications, it records them in a Log file and signals them by means of a dedicated FIRE; the applications can capture these indications and then display them in graphic form.

35-GetEventsLogFile Read LOGFILE indications 36-DeleteEventsLogFile Delete LOGFILE indications

Note:

OnSystemEvent Event transmitted by the system to signal anomalies

System configuration functions

The configurations of resources, control devices and other system characteristics are registered in “AxesBrain” and managed by a series of dedicated functions make it possible to read, edit or delete this information and add new configuration if required.

37-ReadSystemConfiguration Read system configuration 38-EditSystemConfiguration Write system configuration 39-GetNumberAndNameKindElement Read number and name of a element 40-ReadElementConfiguration Read element configuration of a element 41-EditElementConfiguration Edit, delete or add configuration of a element

Events from the Server

The server transmits, asynchronously, indications to connected users by means of “EVENTS”. Events can be subdivided into three types:

• System fault notification events • Asynchronous requests executed notification events • Request events from Server, to obtain services from Clients

OnSystemEvent Signals anomaly on system OnCompleteCommand Signals completion of asynchronous function (with ID given at time of request) OnRequestServiceEvent Requests a service from the user application in terms of data, which, when retrieved, will be supplied using the relevant write function.

Access with AxesBrainBase (DLL library)

and with AxesBrainCom (OCX library)

To facilitate the interface with user applications, two libraries have been developed for access to the AxesBrainServer DCOM functionalities: an initial DLL library that can be used by applications developed in Visual C++ or Visual Basic, and a second OCX library for all programming languages. To call functions from the AxesBrainBase library (DLL) add the prefix Bs_ to AxesBrainServer DCOM functions. To call functions from the AxesBrainCom library (OCX) add the prefix Cx_ to the AxesBrainServer DCOM functions.

The DCOM technology utilized to create the AxesBrain system, makes it possible for the intrinsic functionalities to be utilized also by applications that operate in the world of the Internet, hence developed with HTML language; the use of the OCX library facilitates this procedure.

AxesBrain AxesBrain Base DCOM AxesBrain AxesBrain Com Com

AxesBrainC AxesBrainC om om

Chapter 3

Automation (AxesBrainL)

AxesBrainL is a proprietary language for the management of generic automation cycles.

Developed on the basis of the SIGLA specification (SIGMA LANGUAGE) by Olivetti in 1976, and one of the world’s first programming languages for special parts assembly machinery, AxesBrainL has been expanded so as to respond to contemporary requirements in terms of integration and flexibility (see “Robot technology at Olivetti: the Sigma System” Olivetti, Milan 1976).

One of the prerogatives of this language, in addition to the simple syntax, is the possibility for multiple programming of individual cycles – an indispensable feature when controlling the assembly and manipulation of parts.

Architecture

The architecture of the automation subsystem is such that the work cycles can be executed in parallel, synchronizing them with events.

Each program incorporates a proprietary area utilized for the allocation of LOCAL variables which, among other functions, are used to store call parameters.

When the program is launched in execution, either by an explicit command, by means of a CALL, or by means of a TSK instruction, the source code is loaded into the memory and automatically pre-compiled; the source code will remain in the memory until an explicit CLOSE command is received or a RESET command is transmitted to the subsystem.

The programs are combined with a proprietary work handler to which all the activities of the cycle will be attached; there can be a virtually unlimited number of handlers, and, using this method, it is possible to obtain extremely flexible plant configurations, as required for robot lines, special multiple head machines, machines with integrated feeding and unloading systems, multipurpose machines, etc..

cycle 1 cycle 2 cycle “n” management management management handler handler handler

Cycle 1 Cycle 2 Cycle “n”

Language syntax

The language syntax is extremely simplified: a three-letter string preceded by a dash “-” constitutes the instruction, a slash “/”is the limiter, separating the instruction parameters, which can be:

1. Direct references to GLOBAL or LOCAL variables

2. Indirect references to GLOBAL variables

3. Numerical expressions with references to GLOBAL or LOCAL variables

4. Mathematical expressions with reference to GLOBAL or LOCAL variables

5. Jump LABELS

6. Names of resources in terms of axes, spindles, inputs and outputs

7. Alphanumeric strings

The parameters are separated by commas.

LABELS for conditional or unconditional jumps are entered before the instruction separator dash “-”.

Comments are preceded by a semicolon “;”

[ label] –XXX/[parameter 1],…[parameter n] [; this is a comment]

Example:

; this is a programming example -SET/G1,0 here -JNE/G1,1,here ; wait until the value of GLOBAL variable G1 is set to 1 ; by another cycle in a parallel process

Mathematical expressions have the following functions:

abs Absolute value of a number acos Cosine arc and And of two numbers asin Sine arc atan Tangential arc atanw Tangent arc of Y, X ceil Rounding up of a decimal number to create an integer cos Cosine cosh Hyperbolic cosine deg Conversion into degrees of an angle expressed in radians exp Exponential floor Rounding down of a decimal number to create an integer logd Decimal logarithm logn Natural logarithm lshift Left shift of a number max Maximum among “n” expressions min Minimum among “n” expressions mod Modulus of two numbers not Boolean negation of a number or Or of two numbers pi π rad Conversion into radians of an angle expressed in degrees rshift Right shift of a number sin Sine sinh Hyperbolic sine sqr Square root tan Tangent tanh Hyperbolic tangent xor exclusive Or between two numbers

The operators in an expression can be:

+ sum - subtraction / division * multiplication ^ elevation ( open parentheses ) close parentheses

Example of mathematical expression

-LET/L1, MAX(SIN(RAD(G1+12),COS(RAD(G1+12*L1/56)) ; the variable LOCAL L1 is loaded with the result of the expression: ; MAX(SIN(RAD(G1+12),COS(RAD(G1+12*L1/56))

Global and local variables

Variables are required in order to perform logical operations and read numerical values.

The AxesBrainL subsystem uses two types of variables:

LOCAL

GLOBAL

When it starts running, each program assumes a number of variables equal to the number configured in the system; these variables are set to zero and placed at the disposal of the instructions of the program in question. The first variables are set with the call parameters of the execution command; the variables remain in the memory for use by interrogation or display operations.

A special case is represented by programs called using the instructions “-CAL” and “-TSK” with parameters; in these cases, the first LOCAL variables are loaded with the call parameters in the same position order. If LOCAL variables are included in the call parameters, they will be assigned with the new value when the called program returns.

Example:

-CAL/,myroutine,L9,12,23,G1+89,L7 when “myroutine” is returned L9 and L7 will have the value defined in the routine, in this case

L9 will be assigned the value 11

L7 will be assigned the value 3

In effect, the code of “myroutine” is as follows:

-LET/L1,11

-LET/L5,3

At the time of execution, the LOCAL “myroutine” variables are:

L1= value of L9 of the calling program

L2= 12

L3= 23

L4= value of variable G1 + 89

L5= value of L7 of calling program

In addition to LOCAL variables, the automation subsystem can use a total of 32767 GLOBAL variables, which are called with the letter G followed by the relative number.

Indirect variables represented by the letter “I” followed by the number, denote that the value being treated is that of the GLOBAL variable, the number of which is that of the LOCAL variable indicated with the letter “I”.

Example:

-LET/L12,100

-LET/I12,120.56

In this case the value 120.56 is loaded into the GLOBAL variable 100; indeed, the value 100 indicating the GLOBAL variable has been loaded into LOCAL variable 12, which is referred to in the instruction “- SET/I12,120.56”.

Multitasking and anti-collision system

An important characteristic in automation is the ability to be able to execute several operations together, whether mutually co-ordinated or not. This requirement dictates the need for a MULTITASK feature.

An activity cycle can be performed with an explicit command or by means of a -TSK instruction; the cycle or program are linked to a proprietary work handler to which all activities of the cycle will be assigned; the number of HANDLERS is virtually unlimited.

A TASK can be deleted by another task or by itself with the instruction –TKM, or when a RESET command is executed on the automation subsystem.

A task can be suspended or reactivated by the instruction -TKM.

It is helpful to view a HANDLER as though it were a channel on which starting operations are executed relative to continuous motion, aggregations of movement, and pause times to await completion of the movements.

With this architecture, we can view the motion system as though it were an appliance with several “Arms” that work together, either co-ordinated or uncoordinated, dynamically aggregating groups of axes.

As an example, we could imagine filling drinking glasses on a tray: in the initial phase there are two “Arms” that fill the glasses separately, the system controls the anti-collision protocol and we therefore have two sets of axes working independently; when the glasses are full, the system co-ordinates the arms and moves them together as would a wine waiter, so that the tray can be transferred to an unloading area.

As noted above, during filling of the glasses the two arms are articulated on the same physical X axis, where, thanks to anti-collision management, it is possible to program two independent filling cycles and then synchronize the two cycles when the respective tasks are completed so that a single tray unloading cycle can be programmed, grouping together the two arms as a single unit.

Mathematical logic instructions

1-LET Enter the value of the expression (LET) in a Variable 2-ADD Add to a Variable the value of the expression (ADDed) 3-SUB Subtract from a Variable the value of the expression (SUBtract) 4-MUL Multiply a Variable by the value of the expression (MULtiply) 5-DIV Divide a Variable by the value of the expression (DIVided) 6-NEG Negate the value of a Variable (NEGation) 7-LBF Set a vector of Variables to the value of the expression (Load BuFfer)

Control Instructions

8-JMP Unconditional jump to a Label ( JuMP) 9-JEQ Jump to a Label if the two expressions are equal (Jump if Equal ) 10-JNE Jump to a Label if the two expressions are different (Jump if Not Equal) 11-JLT Jump to a Label if the value of the first parameter is less than the second (Jump if Less Than) 12-JLE Jump to a Label of the value of the first parameter is less than or equal to the second one (Jump if Less than and Equal) 13-JGT Jump to a Label if the value of the first parameter is greater than the second (Jump if Greater Than) 14-JGE Jump to a Label if the value of the first parameter is greater than or equal to the second ( Jump if Greater than and Equal ) 15-JRN Jump if the value of the parameter is included in the range ( Jump if RaNge) 16-JNR Jump if the value of the parameter is outside the range (Jump if Not Range) 17-JOS Jump if at least one bit of the parameter value is one (Jump Or if bit Set) 18-JOC Jump if at least one bit of the parameter value is zero (Jump Or if bit Clear) 19-JAS Jump if all the bits of the parameter value are one (Jump And if bit Set) 20-JAC Jump if all the bits of the parameter value are zero (Jump And if bit Clear) 21-CAL Call a part program and provide parameters (CALl) 22-RET Return to program caller (RETurn) 23-TSK Execute a work cycle in parallel (TaSK) 24-TKM Suspend, restore and delete a work cycle (TasK Management)

Motion instructions

25-HOM Axis origin (HOMing) 26-MOV Linear interpolated movement of a group of axes (MOVe) 27-MOC Linear interpolated movement of a group of axes with start condition (MOve Conditional) 28-CIR Clockwise circular or elliptical interpolated movement of a group of axes (CIrcular Right) 29-CIL Counter-clockwise circular or elliptical interpolated movement of a group of axes (CIrcular Left) 30-CRR Clockwise circular or elliptical interpolated movement of a group of axes, with known radius (Circular Radius Right) 31-CRL Counter-clockwise circular or elliptical interpolated movement of a group of axes, with known radius (Circular Radius Left) 32-STC Start of continuous motion with definition of path (STart Continuous) 33-HLC Wait for completion of continuous motion (HaLt Continuous) 34-ABC Cancellation of continuous motion (Abort Continuous) 35-CAP Change axes parameters (Change Axis Parameter) 36-HMS Master Slave Management (Handling Master Slave) 37-HEC Cams Management (Handling Electronic Cam) 38-CFR Change axis dynamic parameters (Change Feed Rate) 39-CPL Change position loop (Change Position Loop) 40-PRD Read axis positions (Position ReaD) 41-RAV Read axis parameters (Read Axis Value) 42-RSV Read spindle speed (Read Speed Value) 43-SFP Set speed of feed profile (Set Feed Profile) 44-SPD Set spindle rotation speed (SPeeD) 45-TCH Movement with touch probe sensing (TouCH) 46-TMT Movement with search for analog signal value (Test Movement Transducer) 47-TMS Movement with search for digital sensor value (Test Movement Sensor) 48-TPE Enable touch probe (Touch Probe Enable) 49-SZP Defines the position of a machine zero set (Set Zero Point) 50-LZP Activates a machine zero set (Load Zero Point) 51-PIN Incremental position flag on an axis (Position INcremental) 52-PAB Absolute position flag on an axis (Position ABsolute) 53-ANT Anti-collision management (ANTicollision)

Instructions for input and output signals

54-WDI Wait for a digital input signal to assume a given status (Wait Digital Input) 55-WAI Wait for an analog input signal to assume a given status (Wait Analog Input) 56-TDI Perform a test operation on a digital input signal (Test Digital Input) 57-TAI Perform a test operation on an analog input signal (Test Analog Input) 58-SDO Set or reset a digital output signal (Set Digital Output) 59-SAO Write value of an analog output signal (Set Analog Output) 60-GDI Read value of a digital input signal (Get Digital Input) 61-GAI Read value of an analog input signal (Get Analog Input) 62-WBD Writes a block of digital output signals (Write Buffer Digital output) 63-RBD Reads a block of digital input signals (Read Buffer Digital input)

Synchronization instructions

64-EVS Set synchronization events (EVent Set) 65-EVC Reset synchronization events (EVent Clear) 66-EVW Wait for certain synchronization events (EVent Wait) 67-OCS Open critical session (Open Critical Section) 68-CCS Close critical session (Close Critical Section) 69-SCD Disable AxesBrainL part program scheduling (SCheduler Disable) 70-SCE Enable AxesBrainL part program scheduling (Close Critical Section)

Service instructions

71-FOC Reset contents of file or create file if none exists (File Open Create) 72-FWR Write record to file (File WRite) 73-FRD Read record on file (File ReaD) 74-TIM Seconds timer (TIMe) 75-TMM Milliseconds timer (TiMe Millisecond) 76-SWA Initialize clock (Start WAtch) 77-RWA Read clock (Read WAtch) 78-HWA Stop clock (Halt WAtch) 79-CWA Continue clock (Continue WAtch) 80-KYB Wait for keyboard action (KeYBoard) 81-DRT Continuously display values of axes, global variables, signals (Display Real Time) 82-DIS Display a message line (DISplay) 83-WND Create graphic window (WiNDow) 84-DRW Draw graphic elements (DRaW) 85-HLD Cause system to assume Cycle Stop status (HoLD) 86-TEA Self-teaching (TEAch)

Instructions for integration with foreign environments

87-ARI Request for execution of an instruction for the environment specified in the first parameter and await answer (return executed with function “WriteServiceParametersAndContinue” to AxesBrainL automation subsystem) (Ambient Request Instruction) 88-AES Send events to the environment specified in the first parameter (Ambient Event Set) 89-AEC Reset events from the environment specified in the first parameter (Ambient Event Clear) 90-AEW Wait for an event from the environment specified in the first parameter (wait terminated with the function “SendOrClearSubSystemEventSignal” to the AxesBrainL automation subsystem) ( Ambient Event Wait )

The environments are:

1. “CLIENT” environment

2. OEM environment or subsystem

3. CNC AxesBrainISO environment or subsystem

4. PLC AxesBrainAWL environment or subsystem

5. VisAlgo images analysis environment

Chapter 4

CNC (AxesBrainISO)

The CNC subsystem AxesBrainISO, which is able to control machine tools with programming in ISO language, is a multiple head system that has two important functionalities: the capacity to multiply the same process across more than one head, and the capacity or to perform specific processes on each head.

In the case of the AxesBrainISO subsystem the machine tool is viewed as a group of more than one head working separately or in parallel, without neglecting the fact that for auxiliary feeding and unloading devices, the heads can be managed once again in a way that is separate from the AxesBrainL automation subsystem.

Each active head is associated with a group of axes, one for each co-ordinate of the Cartesian system; if the physical axes are in a polar or “SCARA” system we can use their respective virtual axes in the grouping of axes.

Tool Path

Operating head in SCARA system on physical axes A1 and B1, which comprise virtual axes X1, Y1

Architecture

The AxesBrainISO subsystem is able to manage a multiple head machine tool with the heads operating in either parallel or independent mode.

Each head is viewed as a combination of physical axes with each co-ordinates system representing the operating head or the CNC context.

The CNC is the context for the execution of part-programs, procedures and single programming blocks

The CNC subsystem schedules the activities requested for each processing program in ISO format; activated in turn for each program there exists another scheduler that manages the creation of blocks for each head associated with the part program.

Operating head Scheduler of heads associated with Part Program part program

Operating head

Operating head Scheduler of heads associated with Part Program part program Scheduler of active programs Operating head

Scheduler of heads associated with Part Program part program Operating head

Programming rules

A work program is composed of a set of blocks which are performed in sequence. Each block corresponds to a single line and is composed of one or more functions, followed by the relative value.

A block can contain program comment information which has no effect on the program. In this case the text must be preceded by a semicolon “;” .

Example

; milling start

N 023 X100.56 Y 41.9

The character “greater than” (>) at the start of the line indicates a control or configuration command or a call to specific procedures, such as axis configuration, block repetition, etc..

Programming is a variable format procedure. This means that the number of characters required to denote a value is not fixed, and therefore no type of column layout is required. Spaces can be entered in any point of the block, because they will be disregarded. The decimal point is only entered for certain functions. If the sign is not specified, the value is assumed to be positive; negative values must be preceded by the negative sign “-”. Irrespective of the position of the function in the block, the execution of blocks occurs in the following order:

• N function

• G function

• initial M functions

• axes movement

• final M functions

It is possible to program several G functions and several M functions within the same block, but only one each of the other functions ( X, Y, Z, T, F, etc.).

G functions can be divided into several groups

It is not possible program two or more G functions of the same group in the same block.

M functions are divided into initial functions, i.e. functions that are executed before axes movements, and final functions, i.e. functions that are executed at the end of the axes movements. For each programming block it is possible to program two initial M functions and two final M functions. M functions (miscellaneous) are generally utilized to give the machine tool specific commands regarding the position of the axes or the spindle before and after a given operation.

Physical axes link The AxesBrainISO subsystem is able to manage a multiple head machine tool performing both parallel, and independent operations.

In order to implement this important function, the physical or virtual axes must be combined with the Cartesian co-ordinates system of each head. This operation can be performed statically in the system configuration, or as a set of commands embedded in the program.

In the program, the command:

> Start_heads_configuration

sets up the system to accept the actual configuration of the theoretical axes, namely: X Y Z A B C U V W and the Spindle.

the next instruction will be an assignment command for the main head:

> Base_[ name of theoretical axis: X Y Z A B C U V W or Spindle] = [ name of physical or virtual axis] this is followed by assignment commands for the other heads:

> Head_[number of additional head]_[ name of theoretical axis: X Y Z A B C U V W or Spindle ] =

[ name of physical or virtual axis]

At the end of the configuration phase the following command must be present:

> End_configuration

Example:

> Start_heads_configuration > Base_X=A1 > Base_Y=B1 > Base_Z=C1 > Base_Spindle=M1 > Head_2_X=A2 > Head_2_Y=B2 > Head_2_Z=C2 > Head_2_Spindle=M2 > End_configuration

The above example defines that the process is to be performed in parallel by two heads.

Work plane

Machine axis names can be chosen from the following: X, Y, Z, A, B, C, U, V, W

Any two of these axes form the abscissa and ordinate of the work plane, on which tool radius correction in the plane will be applied, while a third axis will assume the function of an axis that is perpendicular to the work plane, on which the tool length correction will be applied

Any additional axes are correlated to the above axes, but they are not affected BY radius and length correction values. Main work planes

Functions G17, G18 and G19 specify the three main working planes created by the system.

G17 Work Plane XY, perpendicular axis Z, the abscissa of the Cartesian plane is X and the ordinate is Y

G18 Work Plane ZX, perpendicular axis Y, the abscissa of the Cartesian plane is Z, the ordinate is X

G19 Work Plane YZ, perpendicular axis X, the abscissa of the Cartesian plane is Y, the ordinate is Z

Programming of parts in G18 and G19 is performed by rotating the drawing so that the axis of the abscissa (Z in G18, Y in G19) becomes the horizontal axis with positive values to the right.. With this strategy, the programming is fully congruent with programming performed in G17.

The values of the abscissas are positive to the right of the zero, and negative to the left. The values of the ordinates above the zero position are positive, those below it are negative.

If work planes other than XY, ZX and YZ must be defined, we must use the function G!/ followed by the names of the axes, which will be as follows (in sequence): abscissa, ordinate, and perpendicular axis.

For example, the phrase G17 UVC will assign the role of abscissa to axis U, the role of ordinate to axis V, and the role of perpendicular axis to C.

Functions G17, G18, G19 must be programmed in a dedicated block.

Motion functions

Axis movement is performed by programming the name of the axis followed by the value of the co- ordinate to be reached.

The names of the machine axes can be chosen from the following: X, Y, Z, A, B, C, U, V, W.

Axes of different mechanical units can have the same name.

The value of the co-ordinate can be either positive or negative (the + sign is not mandatory); use a decimal point rather than a comma to separate integers from decimal numbers.

The movement performed by linear axes to reach the programmed position depends on the type of preparatory function (G) utilized. If the block does not contain G functions, movement to the programmed position is performed in linear interpolation, i.e. following the straight line that joins the starting point with the programmed target point. The functions X, Y and Z are modal and do not therefore require re- programming provided the position of the respective axes is not changed.

U, V, W are additional linear and parallel axis functions that define the dimensions at which the additional axes must be positioned. Conventionally, functions U, V, W indicate additional linear axes and axes parallel to X, Y and Z. When programming functions U, V and W, note that the same information given with regard to functions X, Y and Z remains applicable.

A, B, C are additional rotary axis functions. They define the dimensions at which the additional axes named A, B, and C, must be positioned. Conventionally, functions A, B and C define additional axes that rotate, respectively, about the axes X, Y and Z. Functions A, B and C are modal and, since they express angular values, they must be programmed in degrees.

The movement functions are: G00, G01, G02, G03

G functions

These are preparatory functions that serve to set up the system or machine tool for subsequent operations. These functions are composed of the letter G followed by two (in this programming environment) or three digits, and they can be valid in the block in which they are programmed or until such a time as they are cancelled by another function. The G functions utilized in this programming environment are listed below:

G00 rapid axes positioning G01 linear interpolation G02 clockwise circular or spiral interpolation G03 counter-clockwise circular or spiral interpolation G04 timer controlled pause, dwell time programmed with K function in 0.1 sec. G09 deceleration ramp at end of block containing the function G17 specifies XY as the work plane and Z as the perpendicular plane G18 specifies ZX as the work plane and Y as the perpendicular plane G19 specifies YZ as the work plane and X as the perpendicular plane G40 cancels G41 and G42 G41 activation of tool radius correction, tool at left of profile G42 activation of tool radius correction, tool at right of profile G48 call length corrector G54 save part origins G55 activate part origin G70 programming in inches G71 programming in millimetres G80 cancellation of fixed cycles G81 fixed cycle for drilling G82 fixed cycle for spot facing G83 fixed cycle for deep hole drilling G84 fixed cycle for tapping G85 fixed cycle for boring G86 fixed cycle for trepanning G88 AxesBrainL fixed cycle G89 OEM fixed cycle G90 absolute programming G91 incremental programming G94 feedrate F in mm/min or inches/min G95 feedrate F in mm/rev. or inches/rev.

M functions

M functions are so-called various or miscellaneous functions. The functions can be programmed with the letter M followed by two, three, or four digits (from M00 to M9999).

M00 programmed stop M03 clockwise spindle rotation M04 counter-clockwise spindle rotation M05 spindle stop M06 tool change M07 secondary coolant activation M08 primary coolant activation M09 coolant deactivation M10 axes hold activation M11 axes hold deactivation M13 spindle clockwise rotation and coolant activation M14 spindle counter-clockwise rotation and coolant activation M19 spindle orientation M30 program end; resets active auxiliary functions M40 - M44 change speed range M101 - M109 AxesBrainL functions M111 - M119 OEM functions

T functions

The T function is utilized to generate a manual or automatic tool change cycle. The letters following the T function define the number of the tool to be called.

In addition to tools, the T function calls all the parameters saved in the tool data table (length and radius offsets, etc.)

The method to adopt to program a tool change cycle (manual, automatic, sequential or non-sequential, with or without tool changer arm) depends on how the cycle is implemented by the user and how the machine logic has been developed with AxesBrainL.

To deactivate the active tool length correction, program G48 L0

Functions F – S – O

The F function defines the feedrate during machining and it is programmed with the letter F followed by three digits that define the speed. The F function is modal

When programmed after G94 the function defines the feedrate F in mm/min or inches/min

When programmed after G95 the function defines the feedrate F in mm/revolution or inches/revolution

The S function defines the spindle rotation speed and it is programmed with the letter S followed by six digits defining the speed expressed in rpm.

The O function calls the origins for use in the zero homing phase, from O1 to O99.

Function O0 disables the origins and the co-ordinates are referred to the machine zero. Function O-1 calls, after programming of O0, the last programmed origin.

Program control functions

Repetition of part of a program

Utilizing L codes it is possible to repeat a program or part of a program n times. The maximum number of repeats is 32767.

The part of the program to be repeated is enclosed between a reference label and the jump instruction to the label followed by the required number of repeats.

The number of repeats can be either numerical or parametric.

Example

……. ……. L=12 definition of label ……. ……. L12 K8 jump to label 12 a total of 8 times

Subprograms within the program

A subprogram is a sequence of blocks that can be called from various points of the main program (for example, the succession of the various points on which to apply the various fixed cycles, boring, drilling, trepanning, etc.) or a profile to be called several times in different points or with different tool radius offsets.

The subprogram is called by programming the function L followed by the number of the subprogram.

Subprograms within the main program must be programmed at the end of the main program, after function M30.

Subprograms must start with the function L = subprogram number, and terminate with the return function G32.

A program can call another program and so forth up to a maximum of 8 nesting levels.

The maximum number of labels is 100, i.e. L0 to L99, to be utilized both for the repetition of parts of the program and for internal subprograms

Chapter 5

PLC (AxesBrainAWL)

The AxesBrainAWL PLC subsystem scans a PLC program cycle every 10 milliseconds. Cyclic logic routines can be used advantageously to provide the plant with the capability of immediate response to control signals.

The programming language of the PLC cycle is AWL, a set of mnemonic instructions representing the subsystem functions.

Certain synchronism instructions can be utilized to co-operate with the other subsystems.

Architecture The subsystem is able to execute a series of operations, including the program, in cyclic mode.

Cyclic execution of the operations is defined as a scanning cycle . During the scanning cycle shown in the following figure, the subsystem performs some or all of the following operations:

• reads inputs

• executes the user program

• processes synchronization requests

• writes values to the outputs

10 millisecond scanning cycle

Read inputs Execute program Process synchronization requests Write values to outputs

Reading inputs

Each scanning cycle starts by reading the current value of the digital inputs and then writing the values in the inputs process images registry.

The subsystem performs increments of eight bits (one byte) for the inputs process images registry. If the resources do not provide a physical input for each bit of the reserved byte, it will not be possible to employ them in the user program. The system resets to zero those inputs that are not used by the process images registry at the start of each cycle.

The system does not automatically update the analog inputs as part of the scanning cycle, and does not save a registry for analog input images. It is therefore necessary to access the analog inputs directly from the program.

Program execution

During the scanning cycle execution phase, the system executes the program, starting from the first operation and proceeding to the final operation.

Direct I/O operations supply the user with immediate access to inputs and outputs during the course of execution of a program or interrupt routine.

If an interrupt is utilized in the user program, the routines associated with interrupt events are saved as part of the program. Interrupt routines are not executed as a standard part of the scanning cycle, instead, they are implemented when an interrupt event occurs (interrupt events can occur at any point of the scanning cycle).

Synchronization request processing

Requests for synchronization events are answered at the end of each cycle, in such a way as to ensure that the entire cycle is concluded and the signals have been fully processed.

Writing values to digital outputs

At the end of each scanning cycle the system writes the values stored in the outputs process images registry to the digital outputs.

The subsystem performs increments of eight bits (one byte) for the outputs process images registry.

The system does not automatically update the analog outputs as a part of the scanning cycle, and does not save a registry of the analog output images. It is therefore necessary to access the analog outputs directly from the user program.

Interrupting a scanning cycle

If interrupts are used, the routines associated with each interrupt event are saved as part of the program. Interrupt routines are not executed as a standard part of the scanning cycle, instead, they are implemented when an interrupt event occurs (interrupt events can occur at any point of the scanning cycle). The interrupts are processed one after the other on the basis of priority level

Inputs and outputs process images registries

It is usually preferable to use the process images registry rather than directly accessing inputs and outputs during execution of the program for the following three reasons:

• Loading all the inputs at the top of the cycle synchronizes and freezes the values of inputs for the program execution phase within the scanning cycle. The outputs are updated by the process images registry when program execution is concluded. This generates a stabilizing effect on the system.

• The user program can access the process images registry much faster then the input and output points, thus allowing greater speed also in program execution.

• The input and output points are bit entities, which can be accessed only in binary form; on the contrary, the process images registry can be accessed in bits, bytes, words and double words, therefore, the process images registries offer greater flexibility.

An additional benefit is represented by the fact that the process image registries are sufficiently large to manage the maximum number of inputs and outputs. Since the real system consists of both inputs and outputs, there always remains a certain number of unused process addresses. These addresses can be utilized as supplementary internal markers.

Direct control of inputs and outputs

Direct operations with inputs and outputs allow immediate access to effective inputs and outputs, even though the process images registries are normally used as sources or destinations for I/O accesses. If a direction operation is utilized to access an input, the corresponding address of the inputs process images registry will not be modified. On the contrary, the corresponding address of the outputs process images registry will be updated.

Types of data and addressing modes

Use of the memory address for data access

In order to access a bit in a memory area, it is necessary to specify the address (which identifies the memory area, the byte address and the bit number).

The figure contains an example of access to a bit (defined also as “byte bit” addressing). In the following example, the memory area and byte address (I = input, 3 = byte 3) are followed by a decimal point “.” to distinguish the bit address (bit 4).

I 3 . 4 7 6 5 4 3 2 1 0 I 0 Bit of byte or bit number I 1

Decimal point to separate I 2 the byte address from bit number I 3

Byte address (byte 3 fourth I 4 byte) I 5

Area identifier (I = input) I 6

I 7

Addressing of the process images registry of inputs (I)

The system samples the physical input points at the start of each scanning cycle and writes the resulting values into the inputs process images registry. This registry can be accessed in bits, bytes, words and double words.

Format: Bit I[byte address].[bit address] I10.1

Byte IB[initial byte address] IB4

Word IW][initial byte address] IW4

Double Word ID[initial byte address] ID4

Addressing the process images registry of outputs (Q)

At the end of the scanning cycle the system copies, into the physical outputs, the values stored in the outputs process image. This registry can be accessed in bits, bytes, words and double words.

Format: Bit Q[byte address].[but address] Q10.1

Byte QB[initial byte address] QB4

Word QW][initial byte address] QW4

Double Word QD[initial byte address] QD4

Addressing the variable memory area (V)

The V memory can be utilized to store intermediate results of operations that are performed by the user program control logic. It is also possible to use the V memory to store other data of relevance to the process or the user task in question. This V memory area can be accessed in bytes, words and double words

Format:Bit V[byte address].[bit address] V10.1

Byte VB[initial byte address] VB4

Word VW][initial byte address] VW4

Double Word VD[initial byte address] VD4

Addressing of the marker area (M)

The internal marker bits (M memory) can be utilized as control relays to store the intermediate status of an operation or other control information. The marker area can be accessed in bytes, words and double words.

Format: Bit M[byte address].[bit address] M10.1

Byte MB[initial byte address] MB4

Word MW][initial byte address] MW4

Double Word MD[initial byte address] MD4

Addressing of the timers memory area (T)

The timers are elements responsible for counting incremental time changes. Timers have various resolutions from 1 ms to 100 ms. The following variables are associated with the timers.

• Current value: whole number with sign at 16 bits that saves the elapsed time counted by the timer.

• Timer bit: this bit is activated (and set to 1) if the current timer value is greater than or equal to the default bit value (the default value is entered as an integral part of the timer operation)

Addressing of the counters memory area (C)

Counters are elements that count each transition from negative to positive on the counter input or inputs. There are two types of counters: the first counts forwards only, the second counts forwards and backwards (bidirectional). The following variables are associated with counters:

• Current value: whole number with sign at 16 bits that saves the current count value.

• Timer bit: this bit is activated (and set to 1) if the current counter value is greater than or equal to the default bit. value (the default value is entered as an integral part of the count operation)

Addressing of analog inputs (AI)

The system converts an analog value of the real world (e.g. a temperature or power value) into a digital value in word format (16 bit). This value can be accessed by identification of the area (AI), the data dimension (W) and the initial byte address. The analog inputs are words and they always start on an even number byte address. The analog input values are read-only.

Format: AIW[initial byte address] AIW4

Addressing of analog outputs (AQ)

The system converts a digital value in word format (16 bits) into a proportional current or power value. These values can be written by indicating the area identifier (AQ), the data dimension (W) and the address of the initial byte. The analog inputs are words that always start on even bytes.

Format: AQW[initial byte address] AQW4

Addressing of accumulators (AC)

Accumulators are read/write devices that can be utilized as memories. For example, accumulators can be used to transfer parameters from subprograms and save the intermediate values utilized in a calculation. The system supplies four accumulators A.

Format: AC[accumulator number] AC0

Indirect addressing of subsystem memory areas

Indirect addressing uses a pointer to access memory data. The system provides the facility to use the following memory areas indirectly: I, Q, V, M, T and C. Indirect addressing of individual bits or analog values is not permitted. Creating a pointer

In order to indirectly address an area in the memory, it is first necessary to create a pointer able to point to the position in question. Pointers are memory values with a double word containing another memory address. V memory addresses or accumulators AC1, AC2, AC3 can be utilized as pointers. To create a pointer, the double word Move operation is utilized (MOVD) to transfer the indirectly addressed memory area to the pointer area. The operation input operand must be preceded by an ampersand “&” indicating that it is the memory address – and not its value – that must be transferred to the address identified by the output operand.

Example: MOVD &VB100,VD204

Using a pointer for access to data

The use of an asterisk (*) before the operand of an instruction indicates that the operand is a pointer.

Editing pointers

Users can edit the value of pointers. Since pointer values are in 32 bit format, it is necessary to use double word operations to modify the relative value. With simple mathematical operations, such as addition and incrementation, these values can be modified. Remember to make allowances for the dimensions of the data you wish to access:

For access to bytes, increase the pointer value by one

For access to words, or the current value of a timer or counter, add 2, or increase the pointer value by 2.

For access to double words, add 4 or increase the pointer value by 4.

Contact instructions

LD Load operation A Combine bit value using AND O Combine bit value using OR LDN Load negated bit value AN Combine negated bit value using AND ON Combine negated bit value using OR LDI Load value of bit directly AI Combine bit value directly using AND OI Combine bit value directly using OR LDNI Load negated bit value directly ANI Combine negated bit value using AND ONI Combine negated bit value using OR NOT Edit upper value EU Detect positive front ED Detect negative front LDB= Compare identical bytes and load result AB= Compare identical bytes and combine result using AND OB= Compare identical bytes and combine result using OR LDB>= Compare identical or higher bytes and load result AB>= Compare identical or higher bytes and combine result with AND OB>= Compare identical or higher bits and combine result using OR LDB<= Combine identical or lower bytes and load result AB<= Compare identical or lower bytes and combine result using AND OB<= Compare identical or lower bytes and combine result using OR LDW= Compare identical words and load result AW= Compare identical words and combine result using AND OW= Compare identical words and combine result using OR LDW>= Compare identical or higher words and load result AW>= Compare identical or higher words and combine result using AND OW>= Compare identical or higher words and combine result using OR LDW<= Compare identical or lower words and load result AW<= Compare identical or lower words and combine result using AND OW<= Compare identical or lower words and combine result using OR LDD= Compare identical double words and load result AD= Compare identical double words and combine result using AND OD= Compare identical double words and combine result using OR LDD>= Compare identical or higher double words and load result AD>= Compare identical or higher double words and combine result using AND OD>= Compare identical or higher double words and combine result using OR LDD<= Compare identical or lower double words and load result AD<= Compare identical or lower double words and combine the result using AND OD<= Compare identical or lower double words and combine result using OR

LDR= Compare identical real numbers and load result AR= Compare identical real numbers and combine result using AND OR= Compare identical real numbers and combine result using OR LDR>= Compare identical or higher numbers and load result AR>= Compare identical or higher real numbers and combine result using AND OR>= Compare identical or higher numbers and combine result using OR LDR<= Compare real identical or lower numbers and load result AR<= Compare equal or higher numbers and combine result using AND OR<= Compare real identical or lower numbers and combine result using OR = Assign, copy upper value of stack into specified parameter =I Assign directly, copy immediately upper value of stack into specified parameter S Enter specified number of points R Reset specified number of points SI Directly set specified number of physical outputs RI Directly reset specified number of physical outputs NOP No operation

Timer and counter instructions

TON Start timer as delay for insertion TONR Start timer as delay for insertion with memory CTU Count forwards CTUD Count forwards and backwards

Mathematical instructions

+I Sums two 16 bit integers -I Subtracts two 16 bit integers +D Sums two 32 bit integers -D Subtracts two 32 bit integers +R Sums two real numbers -R Subtracts two real numbers MUL Multiplies two integers DIV Divides two integers *R Multiplies two real numbers /R Divides two real numbers SQRT Square root of a real number

Increment and transfer instructions

INCB Increase a byte by 1 DECB Decrease a byte by 1 INCW Increase a word by 1 DECW Decrease a word by 1 INCD Increase a double word by 1 DECD Decrease a double word by 1 MOVB Transfer byte MOVW Transfer word MOVR Transfer real number BMB Transfer block of bytes BMW Transfer block of words BMD Transfer block of double words SWAP Swap bytes in word

Program control instructions

END End program JMP Jump to label LBL Define label CALL Call subprogram SBR Start subprogram RET End subprogram CRET Conditioned end of subprogram

Logic stack instructions

ALD Combine the first and second element with AND OLD Combine first and second element with OR LPS Duplicate logic LRD Copy logic LPP Pick-up logic

Boolean instructions

ANDB Combine byte with AND ORB Combine byte with OR XORB Combine byte with exclusive OR ANDW Combine word with AND ORW Combine world with OR XORW Combine word with exclusive OR ANDD Combine double word with AND ORD Combine double word with OR XORD Combine double word with exclusive OR INVB Invert byte INVW Invert word INVD Invert double word

Chapter 6

AxesBrainStudio interface environment

AxesBrainStudio is a container application for “Pages” utilized to provide the Man-machine Interface with the services made available by the AxesBrainServer; this application forms part of the functions that include management of indications and management of certain Events such as the keyboard. The main function of this application is that of bringing together the other applications and supplying a uniform method of navigating from one to the other, grouping them in separate "Environments" and displaying them with a co- ordinated graphic appearance. The pages can be created in three alternative ways: generating an OCX control with specific characteristics (can be developed in Visual Basic or Visual C++), in HTML format, or by generating a DLL utilizing the specific classes supplied by AB&T. The configuration of the pages and environments is entered in the Windows registry and uploaded when AxesBrainStudio is launched.

The interface provides management of 10 function keys on each page, with a common area that remains constantly visible for the display of system messages.

Architecture

The applications contained in “AxesBrainStudio” are called “Pages” and they are grouped together in “Environments”; the navigation feature makes it possible to move from one environment to another. During navigation, each environment will open at the page that was active the last time it was accessed.

Each "Page" is associated with an icon and an identification caption, so that once the environment has been selected the user can consult all the icons of the "Pages" in the environment and call the page of interest.

Information regarding the number of "Environments", of "Pages" associated with their icons and captions, the mode, and type of the application associated with the "Page" are entered in the AxesBrain registry, in such a way that the system configuration can be changed only by skilled software engineers.

AxesBrainStudio considers applications as functions or libraries, hence the subdivision of DLL libraries, i.e. the basic libraries which are part of the application, OCX object libraries, and HTML applications; in this case the system operates like an Internet browser.

There are three types of applications or “Pages”:

• Basic applications

• OCX user applications

• HTML user applications

Basic applications

Several applications or "Pages" have been developed for the user interface with the motion system. These pages can be subdivided into the basic environments.

System environment

“OEM Capability management” page

“2D axes path” page

“nD axes path” page

“Input and output signals management” page

“System characterization” page

Automation environment

“Edit AxesBrainL Part Program” page

“AxesBrainL cycles management” page

“GMLS cycles debug” page

“AxesBrainL resources configuration” page

CNC Environment

“Edit AxesBrainISO Part Program” page

“AxesBrainISO programs management” page

“AxesBrainISO tables management” page

“AxesBrainISO axes manual management” page

“AxesBrainISO resources configuration” page

PLC environment

“Edit AxesBrainAWL Part Program” page

“AxesBrainAWL cycle management” page

“AxesBrainAWL cycle debug” page

“AxesBrainAWL resources configuration” page

OEM Capability environment

“Generic file edit” page

“OEM subsystem management” page

“OEM resources configuration” page

Vision Environment

“Measurements” page

“Parts recognition” page

OCX applications

OCX applications are developed like a normal library, using the programming language that is most familiar to the customer.

The library will therefore be managed like a AxesBrainStudio page grouped by an environment specified in the registration.

OCX “PAGES” are capable of using, in addition to direct AxesBrainServer DCOM services, also the access to said services by means of a AxesBrainCOM OCX library.

In order to obtain a uniform User Interface, there is an AxesBrainStudio library of functions such as management of function keys, management of system messages, reception of events by the AxesBrainServer, and other commonly used functions.

HTML applications

HTML applications are developed like a normal HTML document; in this case AxesBrainStudio functions like a browser.

If follows that the document will be managed as a page from AxesBrainStudio grouped by an environment specified in the registration.

HTML documents are able to use, in addition to DCOM AxesBrainServer services, also access to said services by means of a AxesBrainCOM OCX library.

App endix A

Virtual Axes

As the name implies, virtual axes are not physical axes, but axes which for the convenience of the user, are characterized on SCARA or CYLINDRICAL geometry systems in such a way that, in addition to performing movements on physical axes, it is also possible to perform movements in accordance with a Cartesian system. With this system it is also possible to perform linear and circular interpolations.

SCARA system

Number of SCARA axes : defines the number of axes to be taken into consideration; minimum 2 (the first 2); three (1, 2, 3) or 4 (all)

In the example, all four axes are taken into consideration (the two articulations A1 and B1, the third rotary axis C1 located at the end of the second articulation, and the fourth traversing axis X2)

Name of first axis : defines the first real axis of the system (1 st articulation); axis A1 in the example

Length of first axis : defines the length of the first axis (distance between first and second articulation); L1 in the example

Name of second axis : defines the second real axis of the system (2 nd articulation); axis B1 in the example

Length of second axis : defines the length of the second axis (distance between the central articulation and the gripper axis); L2 in the example. If there is a third axis (C1 in the example), the gripper axis must be concentric with the axis or rotation of the third axis (in which case the length of the second axis is fixed). If, on the other hand, the two axes are non-concentric, the length of the second axis (with respect to the gripper axis) is variable, because it depends on the angular position of the gripper. As a consequence, since just one length value is entered, the Cartesian system thus obtained will be valid only in those conditions. On the basis of the above considerations, in the event of eccentricity, the following point must be taken into consideration:

 it is not possible to obtain linear or circular trajectories, and the greater the eccentricity the greater trajectory error will be.

Name of third axis : defines the rotating axis, if present, located at the end of the second axis; C1 in the example. The presence or absence of this axis in the table only affects the geometry of the system in terms of automatic compensation of the rotating axis, and specifically:

 Axis not defined in the table: in the event of a request for movement of axes (real or virtual) this rotating axis will be disregarded (only if it is not required for the movement)

 Axis defined in the table: in the event of a request for movement of axes (real or virtual) this rotating axis will be compensated automatically (only if it is required for the movement); the gripper on this axis will therefore always remain parallel to itself. It is implicit that if this axis is requested for the movement, the indication or non-indication of the axis in the table has no significance, because the movement that has been requested is overriding.

Name of fourth axis : defines the traversing axis, if present (traverse of the entire SCARA system); X2 in the example

Mechanical compensation : this parameter serves to identify the type of robot in accordance with the following convention:

0 = conventional SCARA robot ± 1 = SCARA robot with pantograph system

wherein moving a single axis (A1 in the example) the second axis (B1 in the example) remains parallel with respect to itself.

The algebraic sign is to be interpreted as follows: A positive sign refers to automatic compensation on axis B1, summing the angle described by axis A1.

A negative sign means automatic compensation on axis B1, subtracting the angle described by axis A1.

Absolute offset : this parameter is utilized whenever it is required to obtain an effective axes zero position that is different from the theoretical zero position.

Maximum speed : corresponds to the maximum speed required on the virtual axis; if this speed value is unattainable (bear in mind that the two real axes associated with the virtual axis each have a maximum speed) the maximum possible speed is utilized by default.

Maximum acceleration and deceleration : These values correspond to the maximum acceleration and deceleration required on the virtual axis; also for this parameter, if the values are higher than the maximum values attainable, the maximum possible acceleration and deceleration values are utilized by default.

Notes: a) Since all calculations for virtual axes are performed in accordance with classic geometry, operating on sines and cosines of angles expressed in degrees, the following points must be taken into consideration:

1 - The unit of measurement of the first three real axes must be degrees.

2 - The unit of measurement of the fourth axis can be mm or inches, depending on whether the lengths of the first and second axes are given, respectively, in mm or inches.

3 - The absolute offset of the first axis must be specified (if the fourth traversing axis is present) in such a way that the virtual axis abscissa is parallel to the fourth SCARA axis.

4 - The absolute offset of the second real axis must be given in such a way that the first two axes are aligned (arm fully extended).

5 - The directions of movement (positive, negative) of the system axes must all agree: for the first three rotating axes a positive direction means moving from the positive abscissa towards the positive ordinate; the fourth axis, if present, must have the same direction of the abscissa. The following figure provides an example of said directions.

VIRTUAL ORDINATE THIRD AXIS SECOND AXIS FIRST AXIS FOURTH AXIS VIRTUAL ABSCISSA

6 - On the basis of the considerations given in points 1-5 above, it follows that after a movement to zero of all 4 real SCARA axes, the virtual axis abscissa will be at a co-ordinate equivalent of the sum of the lengths of the first and second axes; the virtual axis ordinate will be on the zero co-ordinate.

b) With a SCARA system, it is not possible to request, in the same movement instruction, virtual axes together with the first two real axes of the system (one of the two or both together). Vice versa, it is possible to request virtual axes together with the third or fourth real axes of the system.

CYLINDRICAL system

Number of axes of the CYLINDRICAL system : defines the number of axes to be taken into consideration; 1 st + 2 nd , 1 st + 2 nd + 3 rd , 1 st + 2 nd + 3 rd + 4 th . It is recommended to indicate always 4, and if any of the axes is not present (2 nd , 3 rd , 4 th ) to omit it from the relevant lines. In the example shown, all four axes are taken into consideration.

Name of first axis : indicates the first real axis of the system; A1 in the example. The first axis is always the main rotating axis and must always be present.

Length of first axis : indicates the distance (can be 0) between the rotating axis of the first axis and the gripper axis; this distance is measured perpendicularly from the quill axis (if there is no quill, with respect to the gripper holder arm); L1 in the example.

Name of second axis : indicates the second real axis of the system; Y1 in the example. This axis, which is always the quill axis, could theoretically be absent: in this case, however, presence of the fourth axis is obligatory.

Length of second axis : indicates the distance between the rotation axis of the first axis and the gripper axis; this distance must be measured in parallel to the quill axis (if no quill is present, with respect to the gripper holder axis); in the example L2 if the second axis (quill) has no absolute axis, and 12’, if this axis is associated with an offset (02). If a third axis is present (C1 in the example), the gripper axis must be concentric with the rotation axis of the third axis (in this case the length of the second axis is fixed). If, on the contrary, the two axes are not concentric, the length of the second axis (with respect to the gripper axis) is variable, because it is independent from the angular position of the gripper. As a consequence, since a single length value is set, the Cartesian system thus obtained will be valid only in those conditions. On the basis of the above considerations, in the case of eccentricity, the following points must be taken into consideration:

 it is not possible to obtain linear or circular trajectories, and the greater the eccentricity value the greater the trajectory error.

Name of third axis : defines the rotating axis (if present) at the end of the quill (or gripper holder arm if there is no quill); C1 in the example. The definition or absence of this axis in the table only affects the geometry of the system in terms of automatic compensation of said rotating axis, and specifically:

 Axis not indicated in the table: in the event of a request for movement of axes (real or virtual), this rotary axis will be disregarded (if it is not required for the movement)

Name of fourth axis : defines the traversing axis, if present (traverse of the entire CYLINDRICAL system); X1 in the example. This axis may not be present provided the second axis is present;

Mechanical compensation : this parameter must always be set with value 0.

Absolute offset : this parameter is utilized whenever it is required to obtain an effective axes zero position that is different from the theoretical zero position.

Maximum speed : corresponds to the maximum speed required on the virtual axis; if this speed is unattainable (each real axis in the system has a maximum speed value) the maximum possible speed is utilized by default.

Maximum acceleration and deceleration : these values correspond to the maximum acceleration and deceleration required on the virtual axis, if the values are higher than the maximum available values, the maximum possible values are utilized by default.

Notes:

a) Since all calculations for virtual axes are performed in accordance with classic geometry, operating on sines and cosines of angles expressed in degrees, the following points must be taken into consideration:

1 - The unit of measurement of real rotating axes (first and third axes) must be degrees.

2 - The unit of measurement of the fourth real axis can be mm or inches, depending on whether the length of the second axis is given in mm or inches.

3 - The absolute offset of the first real axis must be specified (if the fourth traversing axis is present) in such a way that the virtual axis abscissa is parallel to the fourth CYLINDRICAL axis.

4 - The second axis (quill) may or may not be offset; if present, the offset clearly indicates a different length of the second axis.

5 - The directions of movement (positive, negative) of the system axes must all agree: for rotating axes (first and third axis) a positive direction means moving from the positive abscissa towards the positive ordinate ; linear axes (second and fourth) must have the same direction as the abscissas.

6 - The second axis (quill) cannot be located in the negative abscissa plane; if this condition is not met, rotate the first axis so that it is located in the positive abscissa plane.

The following figure contains an example of how the axes must be positioned in a cylindrical system

VIRTUAL ORDINATE SECOND AXIS (ALTERNATIVE) THIRD AXIS FIRST AXIS FOURTH AXIS VIRTUAL ABSCISSA SECOND AXIS

7 - On the basis of the considerations given in points 1-5 above, it follows that after a movement to zero of all four real CYLINDRICAL axes, the virtual axis abscissa will be at a co-ordinate equivalent to the length of the second arm, and the virtual axis ordinate will be at a co- ordinate equal to the length of the first arm. (For this latter axis the co-ordinate can be positive or negative)

b) With a CYLINDRICAL system, it is not possible to request, within the same movement instruction, virtual axes together with the two real axes (one of the two or both together) making up the cylindrical system, specifically: 1 st axis of the system (main rotational axis), 2 nd axis of the system (quill), or 4 th axis of the system (traversing) if there is no quill axis

On the contrary, it is permissible to request virtual axes together with the 3 rd and/or 4 th axis (if the second axis is present)

Checklist of real axes that cannot be combined with virtual axes in a single movement instruction:

st nd  Cylindrical system composed of 1 and 2 axis (main rotary axis + quill) Virtual axes + 1 st and/or 2 nd real axes – not permitted

st th  Cylindrical system composed of 1 and 4 axes (main rotary axis + traversing axis) Virtual axes + 1 st and/or 4 th real axes – not permitted

st nd th  Cylindrical system complete with 1 , 2 , and 4 axes Virtual axes + 1 st and/or 2 nd axes (alone or with 4 th axis) – not permitted.

Appendix B

Gantry axis

A gantry axis is a mechanically rigid structure (normally a gantry system) and it therefore corresponds to a single axis, although it is handled as though it were a pair of axes (master axis and slave axis, each with its own counting systems and drive). One of the functions of the control is that of maintaining the position of the "slave" axis as close as possible to that of the "master".

Movements requested on the Master-Slave axes are performed as described below:

The movement request can be made by means of all the movement instructions.

In the case of movement that regards only the Master axis, the Slave axis either follows the Master or remains immobile, according to whether association or dissociation conditions are present, respectively.

During the movement, the Slave axis follows the Master axis in real time

Master axis

Slave axis

Appendix C

Axis control with handwheel

Axes can be positioned in manual mode with the use of a device designated electronic handwheel, which is viewed by the system as a read-only axis.

The position value read on the electronic handwheel modifies the position of the associated axis, therefore making it possible to perform micrometric movements.

The handwheel is viewed as a read-only axis which, by means of appropriate commands, is locked to the axis that it is to control.

In the AxesBrainL automation language, the instruction “-HMS” offers the facility for the insertion and exclusion of a "master" handwheel axis and a "slave" positioning axis.

To manage the combination of the handwheel axis with the positioning axis in the "DCOM" environment, the “WriteAxesRegister” service must be utilized for both axes.

Appendix D

Electronic cams

The electronic cam makes it possible to associate the position of a group of axes with a master axis and a multiple positions table.

This makes it possible to simulate the behaviour of cams electronically, replacing the mechanical system with an analog system formed by a group of slave axes and a master axis which may be read-only.

The rules of motion of the cam followers is defined as a vector array which establishes the positions with respect to movement of the cam.

In the AxesBrainL automation language, the instruction “-HEC” is used to manage electronic cams.

To manage electronic cams in the "DCOM" environment, the “WriteAxesRegister” service must be utilized for all the axes.

Appendix E

Continuous motion

The various types of continuous motion refer to the following theoretical profile:

Continuous motion parameters a = switch (from 0 to 3) that determines the type of continuous motion as follows: 0 refers to normal continuous motion 1 refers to a type 1 spline 2 refers to a type 2 spline 3 refers to a type 3 spline b = speed reduction coefficient (from 0 to n) at each direction change between points of the profile.

+ = immediate start of movements.

- = start of movements subject to the fulfilment of the following conditions: • HCL instruction found in the Part Program; • new STC instruction with positive b parameter found in the Part Program; • saturation of the buffer containing the movement entities relative to continuous motion;

c = value (from 0 to 1) that determines the type of node (arc flattened or not flattened) between points of the profile, as follows: 0 means straight line (completely flattened arc) between the various points; 1 means normal arc between the various points; from >0 to <1 means more or less flattened arc; the smaller the value, the more the arc will be flattened;

a) In the case of continuous normal motion (parameter a = 0), there is always an overshoot after each point in the profile. The overshoot speed after each movement is directly proportional to the acceleration and it is greater (with increase) or smaller (with decrease) than the coefficient in a non- proportional manner with respect to the angle α (direction change between two successive movements). Since the maximum overshoot speed cannot, in any event, exceed the maximum axis speed, a high coefficient value is significant only with a small acceleration value; on the contrary, with a high acceleration value a small coefficient value becomes significant (if the value is high, it is anyway forced to the maximum permissible value).

Examples of profile with continuous normal motion Practical profile with coefficient of parameter b = 0

Example of profile with normal continuous motion Practical profile with coefficient for speed reduction at each direction change between the various points of the profile = 0

Practical profile with coefficient different from 0

OVERSHOOT

b) In the case of spline 1 movements, the overshoot after each profile point is significantly lower than that relative to a normal continuous movement; indeed, overshoot is virtually inexistent if the value 1 is assigned to parameter c; and it deviates from 0 towards an increasingly high value (although always relatively low) the more the value of the conjunction parameter (flattening of the arc) approaches 0 (straight line between the various points, with completely flattened arc). Also for this type of continuous movement there is a change of speed along the profile, although it is far less evident than in the case of normal continuous movements; the speed on the profile will be all the more uniform the smaller the angle "a" and the closer the value of parameter "o" approaches 1, and the higher the speed reduction coefficient value (even though this factor has relatively little influence).

Example of profile with spline type 1

SMALL OVERSHOOT

Profile obtained with parameter b=0 and speed reduction coefficient different from 0; if the speed reduction coefficient is 0, there will be no overshoot.

Profile obtained with parameter c= i (speed reduction coefficient different from 0)

Profile obtained with parameter c between 0 and 1 (speed reduction coefficient different from 0) o) Type 2 splines (parameter a = 2) and type 3 splines (parameter a = 3) result in behaviour similar to the type 1 spline but with the difference that, for the type 2 spline, the precalculation on the profile must be done taking into consideration 3 points of the profile, while for the type 3 spline a total of 5 points must be taken into consideration.

Examples of type 2 and type 3 spline profile

SMALL OVERSHOOT

Profile obtained with parameter c = 0 and STC coefficient different from 0, if the STC coefficient is equal to 0, there will be no overshoot.

Profile obtained with parameter c =1 (STC coefficient different from 0)

Profile obtained with parameter c between 0 and 1 (STC coefficient different from 0).

Appendix F

Integration with vision system

Integration with the VisAlgo images analysis environment can be performed in two modes: either by means of the specific requests of the AxesBrainServer which make calls to the basic functions or requests to execute analysis cycles; a second method is to utilize AxesBrainL language vision interface instructions.

AxesBrain L Automation

Vision integration Vision VisAlgo functions a) Image analysis functions Programmed cycles Remote or b) Analysis cycles Local connection AxesBrain Server (DCOM)

Image analysis integration diagram

As shown in the diagram, the machine responsible for image analysis can be a remote PC connected in a LAN or over the Internet.

VisAlgo

The VisAlgo package operates by means requests for image analysis functions that perform tasks of : • Image filtration and manipulation • Light analysis and automatic extraction of thresholds • Insertion of blobs on rectangles of interest • Extraction of outlines on intersections of figures on rectangles of interest • Extraction of borders • Measurement of outlines • Extraction of entities on borders • Measurement on entities

Moreover, a VisAlgoL language is provided, with the capacity to program image processing cycles, in such a way as to obtain results oriented towards real situations.