SPiiPlus ACSPL+

Programming Language for

SPiiPlus Motion Controllers

Programmer’s Guide

Document part no. TM-SPIPL-SW0

Document revision no. 4.22
Document revision no. 4.22 (June 2006)
Document part no. TM-SPIPL-SW0
COPYRIGHT
Copyright © 1999 - 2006 ACS Motion Control Ltd.
Changes are periodically made to the information contained in this guide. The changes are published in
release notes and will be incorporated into future revisions of this guide.
No part of this guide may be reproduced in any form, without permission in writing from ACS Motion
Control.
TRADEMARKS
ACS Motion Control, PEG, and SPii are trademarks of ACS Motion Control Ltd.
Visual Basic and Windows are registered trademarks of Microsoft Corp.
The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.

Website: http://www.AcsMotionControl.com/
E-mail: [email protected]
[email protected]

ACS Motion Control Inc.

14700 28th Ave North - Suite 25
Plymouth, MN 55447
USA
Tel.: +1 (763) 559-7669, 800-545-2980
Fax: +1 (763) 559-0110

ACS Motion Control Ltd.

Ramat Gabriel Industrial Park
POB 5668
Migdal Ha'Emek, 10500
ISRAEL
Tel: +972 ((0)4) 6546440
Fax: +972 ((0)4) 6546443
NOTICE
Information deemed to be correct at time of publishing. ACS Motion Control reserves the right to change
specifications without notice. ACS Motion Control is not responsible for incidental, consequential, or
special damages of any kind in connection with this document.
 R e cen t C han g es t o t h is Gu id e I

RECENT CHANGES TO THIS GUIDE

Ver. Date Page Change

May 04 5-16 Correction: Maximum size of a user array is 30000 elements.

May 04 4-22 New: #SC terminal command reports the current safety
configuration.
May 04 5-120 New: safetyconf program command configures a specified fault
for a specified group of axes.
May 04 5-121 New: safetygroup program command.
• Copies the fault configuration from the first axis in the axis-
list to all subsequent axes in the list
• Determines that the axes respond as a block to kill and
disable operations applied to any axis in the group.
April 04 Clarification regarding copytodpr programming command: the
command can take up to eight standard variables.
4.20 July 03 5-116 Commutation: commut command. See also SPiiPlus Setup
Guide.
4.20 July 03 10-3 Mechanical Brake Output Assignment: Some controller models
require assignment of digital outputs for this function and other
models have dedicated brake outputs.
4.20 July 03 7-7, 10-1 Position Event Generation (PEG) Outputs:
• assignpeg command configures digital outputs for PEG
functionality and sets the initial state of PEG state outputs.
• PEG Output Assignment: Some controller models require
assignment of digital outputs for the PEG function and other
models have dedicated PEG outputs.
4.20 July 03 10-5 Dual port RAM: The S_FLAGS.#COPYTO bit governs copying
to DPRAM.
The S_FLAGS.#COPYFROM bit suspends governs copying
from DPRAM
4.20 July 03 - Description of DC brushless (AC servo) motor support, including
software commutation and homing, moved to SPiiPlus Setup
Guide.
4.20 July 03 8-32 For integrated models (i.e., SPiiPlus PCI-DDM4A) only: New
fault: HSSI not connected.
4.20 July 03 5-11 Description added of how axes are designated in commands.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

II R e c e n t C h a n ge s t o t hi s G ui de

Ver. Date Page Change

4.20 July 03 5-55 sysinfo function now supports retrieving analog I/O voltage
ranges and the size of the controller DPRAM (DPRAM is
available in PCI models only).
4.20 July 03 9-8 New analog I/O section includes description of signal monitoring
via the outputs.
4.20 July 03 5-94 start, call, and goto commands no longer support line-number
argument, only label-name argument.
4.20 July 03 8-40 Extended fault handling capabilities.
4.20 July 03 7-21 Mechanical braking via digital outputs.
4.20 July 03 6-10 New motion command: track. Generates a new move each time
the TPOS (target position) variable changes.
4.20 July 03 Pg. 11-34, New motion-related standard variables: GMTYPE (motion type)
Pg. 11-69 and TPOS (target position).
4.20 July 03 10-5 DPRAM (PCI-based controllers) functionality expanded with two
new commands:
• The copyfromdpr command instructs the controller to
continuously copy values from the DPRAM to standard
variables.
• The stopcopytodpr command cancels all previously
executed copytodpr and copyfromdpr commands, stopping
the copying of variables to/from the DPRAM.

4.01 Aug. 02 5-109 Commands section updated, including expanded description of

connect command and new description of depends command.
4.01 Aug. 02 6-1 New ptp command suffix, e, delays execution of next command
in program until the point-to-point motion terminates..
4.01 Aug. 02 11-20 Standard variable CTIME now supports the values, 0.5, 1, or 2.
4.01 Aug. 02 11-59 New standard variables affecting servo loops added: SLCOFFS,
SLCORG, and SLIOFFS.
4.01 Aug. 02 5-55 sysinfo function updated.
4.01 Aug. 02 7-16 New Sin-cos encoder filter.
4.01 Aug. 02 5-57 getconf and setconf functions now support input signal edge (key
26), commutation (keys 214 to 217 – applies for brushless motors
only), and segmented motion (key 301).
4.01 Aug. 02 5-103 Updated description of kill and killall commands.
4.01 Aug. 02 5-102 Updated description of enable and disable commands.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 R e c e n t C h a n ge s t o t hi s G ui de III

Ver. Date Page Change

4.01 Aug. 02 8-1 Updated description of Safety Control, including changes in

default responses, changes in software limit behavior, new fclear
command, and new strict fault processing mode.
4.01 Aug. 02 7-4 Data collection is unavailable when the SPiiPlus MMI Scope is
active.
4.01 Aug. 02 5-108 Axes specified by group, split or splitall commands, commands
must be idle when the command is executed.
4.01 Aug. 02 5-39, 5-43 Updated description of arguments in the dsign and lag functions.
4.01 Aug. 02 5-86 The goto command can only point to a label, not to a line number.
4.01 Aug. 02 11-66 Size of variables SMNA and SMNV is model-dependent and
equals number of SPs.
4.01 Aug. 02 8-27, 5-57 Integrated models only: Extended drive alarm fault support
includes cause of alarm. Accessible from MERR variable and via
getconf function.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 C on t en t s V

CONTENTS

FIGURES XVII

1. INTRODUCTION 1-1

1.1. INTEGRATED AND NON-INTEGRATED CONTROLLER PRODUCTS 1-1

1.2. ABOUT ACS MOTION CONTROL MOTION CONTROLLERS 1-2

1.3. ORGANIZATION OF THIS GUIDE 1-2

1.4. RELATED SPIIPLUS DOCUMENTATION 1-3

1.5. RELATED SPIIPLUS TOOLS 1-3

1.6. CONVENTIONS USED IN THIS GUIDE 1-4

1.6.1. TEXT CONVENTIONS 1-4

1.6.2. STATEMENT CONVENTIONS 1-5

2. GLOSSARY 2-1

3. SPIIPLUS SOFTWARE ARCHITECTURE 3-1

3.1. HARDWARE AND FIRMWARE 3-1

3.1.1. HARDWARE STRUCTURE 3-1

3.1.2. FIRMWARE 3-2

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

VI C o n t ent s

3.1.3. CONTROLLER CYCLE AND SERVO TICK 3-3

3.1.4. REAL-TIME AND BACKGROUND TASKS 3-3

3.2. CONCEPT OF USER APPLICATION 3-4

3.2.1. FIRMWARE, USER APPLICATION AND TOOLS 3-4

3.2.2. USER APPLICATION COMPONENTS 3-5

3.2.3. USER APPLICATIONS CATEGORIES 3-6

3.2.4. TOOLS FOR DEVELOPING USER APPLICATIONS 3-6

3.3. PROGRAMMING RESOURCES 3-7

3.3.1. COMMANDS 3-7

3.3.2. PROGRAM BUFFERS 3-8

3.3.3. COMMAND EXECUTION 3-8

3.3.4. STANDARD VARIABLES 3-9

3.3.5. USER VARIABLES 3-9

3.3.6. NONVOLATILE (FLASH) MEMORY AND POWER UP PROCESS 3-10

3.3.7. CONNECTION TO THE PLANT 3-10

3.4. MOTION 3-16

3.4.1. MOTION OVERVIEW 3-16

3.4.2. AXIS GROUP AND LEADING AXIS 3-18

3.4.3. TIME-BASED MOTION AND MOTION PROFILE 3-19

3.4.4. MASTER-SLAVE MOTION – FOLLOWING A MASTER 3-21

3.4.5. PHYSICAL ASPECTS OF MOTION 3-22

3.4.6. MOTION STATE VARIABLES 3-24

3.4.7. MOTION SEQUENCING 3-25

3.4.8. CHANGES ON THE FLY 3-27

4. TERMINAL COMMANDS 4-1

4.1. PROGRAM MANAGEMENT COMMANDS 4-1

4.1.1. GENERAL 4-1

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 C o n ten t s VI I

4.1.2. COMMAND STRUCTURE 4-2

4.1.3. PROGRAM LISTING 4-5

4.1.4. EDITING A PROGRAM IN A BUFFER 4-7

4.1.5. SEARCH COMMANDS 4-10

4.1.6. VARIABLE LISTING 4-12

4.1.7. EXECUTION CONTROL 4-14

4.1.8. INTEGRITY CONTROL 4-20

4.1.9. REPORT OF REAL-TIME USAGE (#U) 4-21

4.1.10. APPLICATION PROTECTION (#PROTECT, #UNPROTECT) 4-21

4.1.11. REPORT SAFETY CONFIGURATION (#SC) 4-22

4.2. QUERY COMMANDS 4-23

4.2.1. GENERAL 4-23

4.2.2. QUERY OF CONTROLLER VERSION AND SERIAL NUMBER 4-24

4.2.3. QUERY OF PROGRAM STATUS 4-25

4.2.4. QUERY OF MOTOR AND AXIS STATUS 4-25

4.2.5. QUERY OF STANDARD VARIABLES AND ARRAYS 4-27

4.2.6. QUERY OF USER VARIABLE/ARRAY 4-30

4.2.7. QUERY OF SP VARIABLES 4-33

4.2.8. FORMATTING QUERY DATA PRESENTATION 4-34

4.3. NONVOLATILE MEMORY MANAGEMENT COMMANDS 4-36

4.3.1. POWER-UP SEQUENCE 4-37

4.3.2. SAVING APPLICATION VARIABLES AND SP DATA 4-38

4.3.3. LOADING APPLICATIONS, VARIABLES AND SP DATA 4-40

4.3.4. CLEARING BUFFERS (#CLEAR) 4-42

4.3.5. RESETTING THE CONTROLLER (#RESET) 4-42

4.3.6. RESTARTING THE CONTROLLER (#HWRES) 4-42

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

VII I C o nt en t s

5. ACSPL+ MULTIPROGRAMMING LANGUAGE 5-1

5.1. EXECUTING ACSPL+ PROGRAMS 5-1

5.1.1. IMMEDIATE EXECUTION VS. STORED PROGRAM 5-1

5.1.2. PROGRAM BUFFERS 5-2

5.1.3. EXECUTION OF A SINGLE PROGRAM 5-2

5.1.4. CONCURRENT EXECUTION 5-3

5.1.5. IMMEDIATE EXECUTION 5-3

5.1.6. AUTOROUTINES 5-4

5.1.7. SYNCHRONIZATION AND MUTUAL EXCLUSION 5-4

5.1.8. EXECUTION RATE 5-6

5.1.9. DYNAMIC BUFFERS 5-6

5.2. ACSPL+ SYNTAX 5-9

5.2.1. KEY WORDS 5-9

5.2.2. NAMES: VARIABLE AND LABEL 5-10

5.2.3. CASE SENSITIVITY 5-10

5.2.4. COMMANDS, LINES, AND COMMAND AGGREGATES 5-11

5.2.5. AXIS DESIGNATIONS 5-11

5.2.6. COMMENTS 5-12

5.2.7. SYNTAX CONVENTIONS 5-12

5.3. VARIABLES 5-12

5.3.1. VARIABLE ATTRIBUTES 5-12

5.3.2. NAME 5-13

5.3.3. CLASS: STANDARD OR USER 5-13

5.3.4. SCOPE 5-13

5.3.5. LIFETIME 5-14

5.3.6. ACCESSIBILITY 5-15

5.3.7. TYPE: INTEGER AND REAL 5-15

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 C o n t en t s IX

5.3.8. SIZE 5-16

5.3.9. VALUE 5-16

5.4. VARIABLE DECLARATION 5-17

5.4.1. DECLARATION OF LOCAL VARIABLES 5-17

5.4.2. DECLARATION OF GLOBAL VARIABLES 5-18

5.4.3. PERSISTENT GLOBAL VARIABLES 5-18

5.5. ARRAYS AND INDEXING 5-19

5.5.1. SCALARS AND ARRAYS 5-19

5.5.2. STANDARD ARRAYS 5-20

5.5.3. EXPLICIT INDEXING 5-20

5.5.4. AXIS-LIKE INDEXING OF STANDARD ARRAYS 5-21

5.5.5. POSTFIX INDEXING OF STANDARD ARRAYS 5-22

5.6. USING VARIABLES 5-23

5.6.1. QUERYING VARIABLES 5-23

5.6.2. VARIABLE AS OPERANDS IN EXPRESSIONS 5-23

5.6.3. VARIABLES AS ARGUMENTS IN COMMAND OR FUNCTION 5-24

5.6.4. ASSIGNMENT TO VARIABLE 5-24

5.6.5. VARIABLES IN ACSPL+ TERMINAL COMMANDS 5-25

5.7. FUNCTIONS 5-25

5.7.1. LIST OF FUNCTIONS 5-26

5.7.2. ARITHMETICAL FUNCTIONS 5-28

5.7.3. STATISTICAL FUNCTIONS 5-36

5.7.4. SIGNAL PROCESSING FUNCTIONS 5-38

5.7.5. SERVO PROCESSOR FUNCTIONS 5-52

5.7.6. OTHER FUNCTIONS 5-55

5.8. EXPRESSIONS 5-66

5.8.1. GENERAL 5-66

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

X C o nt en t s

5.8.2. CALCULATION ORDER 5-66

5.8.3. EXPRESSION TYPE 5-67

5.8.4. OPERANDS 5-68

5.8.5. ARITHMETICAL OPERATORS +, -, *, / 5-69

5.8.6. COMPARE OPERATORS =, <>, >, >=, <, <= 5-69

5.8.7. BITWISE AND LOGICAL OPERATORS & (AND), | (OR), ~ (EXCLUSIVE OR (XOR)) 5-70

5.8.8. UNARY OPERATORS -, ~, ^ 5-70

5.8.9. BIT SELECTION OPERATOR (DOT) 5-71

5.9. COMMANDS 5-71

5.9.1. INTRODUCTION TO COMMANDS 5-71

5.9.2. LIST OF COMMANDS 5-72

5.9.3. ASSIGNMENT COMMAND 5-75

5.9.4. PROGRAM-FLOW COMMANDS 5-78

5.9.5. SYNCHRONIZATION COMMANDS 5-87

5.9.6. AUTOROUTINE MANAGEMENT COMMAND 5-90

5.9.7. PROGRAM MANAGEMENT COMMANDS 5-93

5.9.8. INTERACTION COMMANDS 5-97

5.9.9. AXIS/MOTOR MANAGEMENT COMMANDS 5-101

5.9.10. MOTION COMMANDS 5-117

5.9.11. MISCELLANEOUS COMMANDS 5-118

5.10. PROTECTION 5-121

5.10.1. PROTECTED FEATURES 5-122

5.10.2. SWITCHING BETWEEN PROTECTED AND CONFIGURATION MODES 5-123

5.10.3. CFG VARIABLE 5-123

5.10.4. PROTECTION OF VARIABLES 5-123

5.10.5. PROTECTION OF ACSPL+ PROGRAMS 5-124

5.10.6. PRIVILEGED BUFFER 5-124

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 C o n t en t s XI

5.10.7. COMMUNICATION SHUTDOWN 5-125

6. MOTION 6-1
6.1. POINT TO POINT MOTION 6-1

6.1.1. PTP COMMAND 6-1

6.1.2. MULTI-AXIS POINT TO POINT MOTION 6-3

6.1.3. ADVANCED TOPICS 6-5

6.2. JOGGING MOTION 6-9

6.2.1. JOG COMMAND 6-9

6.2.2. MULTI-AXIS JOGGING 6-10

6.3. TRACK MOTION 6-10

6.3.1. SINGLE-AXIS TRACK MOTION 6-11

6.4. MULTIPOINT MOTION 6-13

6.4.1. MPTP, POINT, MPOINT, AND ENDS COMMANDS 6-13

6.4.2. ADVANCED TOPICS 6-16

6.5. ARBITRARY PATH MOTION 6-20

6.5.1. PATH COMMAND 6-20

6.5.2. POINT AND MPOINT COMMANDS 6-21

6.6. PV AND PVT SPLINE MOTION 6-23

6.6.1. PVSPLINE COMMAND 6-24

6.6.2. INTERPOLATION BETWEEN THE POINTS 6-25

6.6.3. POINT COMMAND 6-26

6.6.4. MPOINT COMMAND 6-27

6.6.5. USE OF STANDARD VARIABLES 6-27

6.6.6. SPLINE MOTION EXAMPLE 6-28

6.7. MASTER-SLAVE MOTION 6-30

6.7.1. BASICS 6-30

6.7.2. MASTER COMMAND 6-30

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

XII C on t en t s

6.7.3. SLAVE COMMAND 6-31

6.7.4. ADVANCED TOPICS 6-31

6.8. SEGMENTED MOTION 6-33

6.8.1. MSEG, PROJECTION, LINE, ARC1, ARC2, STOPPER, ENDS COMMANDS 6-33

6.8.2. ADVANCED TOPICS 6-36

6.9. OPEN-LOOP OPERATION (TORQUE CONTROL) 6-42

7. ADVANCED FEATURES 7-1

7.1. DATA COLLECTION 7-1

7.1.1. STANDARD VARIABLES INVOLVED IN DATA COLLECTION 7-2

7.1.2. UNDERSTANDING SYSTEM DATA COLLECTION 7-4

7.1.3. AXIS DATA COLLECTION 7-5

7.2. POSITION EVENT GENERATION (PEG) 7-6

7.2.1. PEG INITIALIZATION 7-7

7.2.2. SYNCHRONOUS AND ASYNCHRONOUS PEG 7-8

7.2.3. INCREMENTAL PEG (PEG_I COMMAND) 7-9

7.2.4. RANDOM PEG (PEG_R COMMAND) 7-10

7.2.5. TERMINATING PEG PREMATURELY (STOPPEG COMMAND) 7-11

7.2.6. PEG STATUS 7-12

7.2.7. EXAMPLES 7-12

7.3. SIN-COS ENCODER MULTIPLIER (OPTION) CONFIGURATION 7-14

7.3.1. SIN-COS ENCODER MULTIPLIER 7-15

7.3.2. SIN-COS FILTER 7-16

7.4. INTERRUPTS 7-17

7.4.1. HARDWARE INTERRUPTS 7-17

7.4.2. SOFTWARE INTERRUPTS 7-18

7.4.3. SOFTWARE INTERRUPT TAGS 7-19

7.4.4. INTERRUPT CONFIGURATION VARIABLES 7-20

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 C o nt en t s XII I

7.5. MECHANICAL BRAKE SUPPORT 7-21

7.5.1. BRAKE OUTPUT ASSIGNMENT 7-21

7.5.2. BRAKE OPERATION 7-22

8. SAFETY CONTROL 8-1

8.1. INTRODUCTION TO SAFETY CONTROL 8-1

8.1.1. SAFETY CONTROL AS A CONTROLLER TASK 8-1

8.1.2. TYPES OF MALFUNCTIONS 8-2

8.1.3. HOW THE CONTROLLER DETECTS MALFUNCTIONS 8-2

8.1.4. FAULTS 8-2

8.1.5. CONTROLLER RESPONSE 8-3

8.2. SAFETY CONTROL SUMMARIES 8-3

8.2.1. SUMMARY OF FAULTS AND DEFAULT RESPONSES 8-3

8.2.2. SUMMARY OF SAFETY INPUTS 8-7

8.2.3. SUMMARY OF SAFETY-RELATED VARIABLES 8-8

8.3. WORKING WITH FAULTS 8-9

8.3.1. ADDRESSING THE FAULT BITS 8-9

8.3.2. QUERYING FAULTS 8-10

8.3.3. USING THE FAULT BITS IN COMMANDS: IF, WHILE, TILL 8-11

8.3.4. CREATING FAULT-PROCESSING AUTOROUTINES 8-12

8.3.5. DISABLING FAULT PROCESSING 8-14

8.3.6. DEFINING THE ACTIVE LEVEL OF SAFETY INPUT 8-15

8.3.7. FAULT PROCESSING MODES 8-17

8.4. DETAILED DESCRIPTION OF FAULTS 8-18

8.4.1. LIMIT SWITCHES: #LL, #RL 8-18

8.4.3. SOFTWARE LIMIT SWITCHES: #SLL, #SRL 8-20

8.4.4. POSITION ERROR: #PE 8-21

8.4.5. CRITICAL POSITION ERROR: #CPE 8-23

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

XIV C on t en t s

8.4.6. ENCODER ERROR: #ENC, #ENC2 8-25

8.4.7. ENCODER NOT CONNECTED: #ENCNC, #ENC2NC 8-26

8.4.8. DRIVE ALARM: #DRIVE 8-27

8.4.10. VELOCITY LIMIT: #VL 8-28

8.4.11. ACCELERATION LIMIT: #AL 8-29

8.4.12. CURRENT LIMIT: #CL 8-30

8.4.13. SERVO PROCESSOR ALARM: #SP 8-31

8.4.14. HSSI NOT CONNECTED: #HSSINC 8-32

8.4.15. EMERGENCY STOP: #ES 8-32

8.4.16. PROGRAM ERROR: #PROG 8-33

8.4.17. MEMORY OVERFLOW: #MEM 8-34

8.4.18. TIME OVERUSE: #TIME 8-35

8.4.19. SERVO INTERRUPT: #INT 8-36

8.5. DETAILED DESCRIPTION OF FAULT PROCESSING 8-37

8.5.1. EXAMINING FAULT CONDITIONS - FLOW CHART 8-38

8.5.2. EXAMINING MOTOR FAULT CONDITIONS 8-39

8.5.3. EXAMINING SYSTEM FAULT CONDITIONS 8-39

8.6. EXTENDED FAULT CONFIGURATION 8-40

9. INPUTS AND OUTPUTS 9-1

9.1. DIGITAL I/O 9-1

9.1.1. GENERAL 9-1

9.1.2. I/O DESIGNATION 9-2

9.1.3. IN AND OUT VARIABLES 9-3

9.1.4. PLC IMPLEMENTATION 9-6

9.1.5. SUPPORT FOR HSSI COMMUNICATION 9-7

9.2. ANALOG I/O 9-8

9.2.1. MONITORING SIGNALS VIA ANALOG OUTPUTS 9-8

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 C o n t ent s XV

10. MODEL-DEPENDENT FEATURES 10-1

10.1. PEG OUTPUT ASSIGNMENT 10-1

10.1.1. PEG OUTPUT ASSIGNMENT FOR SPIIPLUS PCI-4/8 AND SPIIPLUS PCI-DDM4 10-1

10.1.2. PEG OUTPUT ASSIGNMENT FOR SPIIPLUS CM MODULES 10-2

10.2. MECHANICAL BRAKE OUTPUT ASSIGNMENT 10-3

10.2.1. BRAKE OUTPUT ASSIGNMENT FOR SPIIPLUS PCI-4/8 AND SPIIPLUS PCI-DDM4 10-3

10.2.2. BRAKE OUTPUT ASSIGNMENT FOR SPIIPLUS CM 10-4

10.3. DPRAM FOR FAST HOST COMMUNICATION (PCI-BASED CONTROLLER MODELS) 10-5

10.3.1. COPYTODPR COMMAND 10-5

10.3.2. COPYFROMDPR COMMAND 10-6

10.3.3. STOPCOPYTODPR COMMAND 10-8

10.3.4. DPRAM ALLOCATION IN GLOBAL VARIABLE DECLARATION 10-8

10.3.5. EXAMPLE: SETTING DIGITAL OUTPUTS FROM THE HOST 10-9

10.3.6. EXAMPLE: STARTING PTP MOTION FROM THE HOST 10-11

10.4. DYNAMIC BRAKING (FOR INTEGRATED MODELS) 10-13

10.5. CONSTANT CURRENT MODE (FOR INTEGRATED MODELS) 10-13

11. STANDARD VARIABLE REFERENCE 11-1

11.1. STANDARD VARIABLES ORDERED BY GROUP 11-1

11.1.1. STATE 11-1

11.1.2. MOTION 11-2

11.1.3. PROGRAM EXECUTION CONTROL 11-3

11.1.4. GENERAL PURPOSE 11-3

11.1.5. INPUT/OUTPUT 11-4

11.1.6. DATA COLLECTION 11-4

11.1.7. MONITORING 11-4

11.1.8. SAFETY CONTROL 11-4

11.1.9. CONFIGURATION 11-5

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

XVI C on t en t s

11.1.10. SERVO LOOP 11-7

11.2. STANDARD VARIABLES ORDERED ALPHABETICALLY 11-9

11.3. STANDARD VARIABLES REFERENCE 11-14

12. ERROR/DIAGNOSTIC 12-1

12.1. GENERAL 12-1

12.2. ERROR CODES 12-1

12.2.1. ERROR CODE RANGES 12-2

12.3. ERROR DETECTION 12-3

12.4. ERROR INDICATION 12-3

12.4.1. ERRORS IN RECEIVED COMMANDS 12-3

12.4.2. ERRORS IN ACSPL+ PROGRAMS 12-3

12.4.3. MOTION TERMINATION CODES 12-4

12.4.4. MOTION TERMINATION AND MOTOR DISABLE CODES 12-5

12.5. ERROR REFERENCE 12-5

APPENDIX A – HOST COMMUNICATION PROTOCOL 33

APPENDIX B - PREVIOUS RELEASE NOTES 41

INDEX 12-1

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Fi gu r es XVI I

FIGURES

FIGURE 3-1 Controller hardware block chart............................................................................. 3-1

FIGURE 4-2 The Internal Structure of the Controller Cycle....................................................... 3-4
FIGURE 3-3 User Application Block Diagram ........................................................................... 3-5
FIGURE 3-4 SPii-plant connections and related parameters..................................................... 3-11
FIGURE 3-5 Motion Variables.................................................................................................. 3-17
FIGURE 3-6 Motion profile ...................................................................................................... 3-20
FIGURE 4-1 Interaction of program buffer states ..................................................................... 4-14
FIGURE 6-1 Multi-axis move used in ptp /m example ............................................................... 6-4
FIGURE 6-2 An example of target point as expression............................................................... 6-6
FIGURE 6-3 Graphical representation of motion with non-zero final velocity........................... 6-8
FIGURE 6-4 Example of multipoint motion.............................................................................. 6-14
FIGURE 6-5 Example of the use of the Point command ........................................................... 6-16
FIGURE 6-6 Example of target point as expression.................................................................. 6-17
FIGURE 6-7 Example of motion with segment commands....................................................... 6-35
FIGURE 6-8 Example of argument as expression ..................................................................... 6-38
FIGURE 6-9 Example of a rectangular path.............................................................................. 6-39
FIGURE 7-10 Jitter without (A) and with (B) Enhanced-Resolution Filter .............................. 7-17
FIGURE 7-11 Timing of Disable Process.................................................................................. 7-24
FIGURE 8-1 The use of limit switches...................................................................................... 8-18
FIGURE 8-2 Example of the use of variables in a typical motion profile................................. 8-22
FIGURE 8-3 Fault examination flow chart................................................................................ 8-38

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

XVIII F ig u res

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 In t ro d u c t io n 1-1

1. INTRODUCTION

This guide describes the ACSPL+ programming language for SPiiPlus™ motion controller
products. ACSPL+ is a powerful programming language developed specifically for SPiiPlus
motion controllers. ACSPL+ incorporates many advanced features, including:
ƒ powerful programming elements such as arithmetical and logical expressions, user-defined
variables with local and global scope, user-defined one- and two-dimensional arrays
ƒ execution of up to 10 programs simultaneously
ƒ program isolation: each program resides in a separate buffer
ƒ rich set of motion types, providing a large degree of versatility
ƒ advanced implementation of master-slave motion
ƒ axis-independent programming
ƒ on-condition autoroutines

1.1. Integrated and Non-Integrated Controller Products

The SPiiPlus series of motion controllers includes non-integrated models (controller only) and
integrated models (controller, drives, and power supply).
The SPiiPlus PCI-4/8 is a non-integrated model. The SPiiPlus PCI-DDM4A is an integrated
model, comprising a SPiiPlus PCI-DDM4A controller, SPiiPlus PCI-DDM4A-DR (digital drives),
and a SPiiPlus PCI-DDM4A-PS (power supply).
Most elements of ACSPL+ are implemented the same for both integrated and nonintegrated
controllers. Where there are differences, these are noted in this guide.
Features that can vary by controller model include:
• the number of axes.
• the number of inputs and outputs

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

1-2 I nt r o du c t io n

• the number of Servo Processors

See also model-dependent features page 9-8.

1.2. About ACS Motion Control Motion Controllers

ACS Motion Control motion controllers feature state-of-the-art proprietary technology used in
thousands of demanding systems. Applications include semiconductor assembly and testing,
electronic assembly and inspection, automated assembly, material handling, digital printing,
medical imaging, converting equipment, and packaging machinery. User-friendly capabilities
simplify programming popular motion tasks such as advanced pick and place, master/slave, and
electronic gearing and cam.
SPiiPlus motion controllers can be programmed to handle motion, time, and I/O events. This full-
sized PCI cards can operate stand-alone, without a PC, offering the user the ability to operate
outside the PCI Bus via serial communication and an external power supply. In addition to the
PCI Bus interface, the SPiiPlus PCI also supports serial RS-232 and Ethernet communications.
Every unit meets stringent safety and EMC standards and is CE compliant. The SPiiPlus PCI-4/8
motion controller is manufactured according to ISO 9001 certified management system. ACS
Motion Control is certified compliant with the ISO 9001 quality management standard.

1.3. Organization of this Guide

This guide describes the features and use of the ACSPL+ programming language. For hardware
related information see the specific controller Hardware Guide.
Chapter 2 Glossary: Glossary of SPiiPlus and motion control terms.
Chapter 3 SPiiPlus Software Architecture: General introduction to the software environment
including controller, terminal commands, and programs.
Chapter 4 Terminal Commands: Queries, program management, and memory management.
Chapter 5 ACSPL+ Multiprogramming Language: ACSPL+ programming, including variables,
functions, expressions, commands, syntax conventions, and program execution..
Chapter 6 Motion: Motors and axes, motion scenarios, motion profile generation, motion
execution, and motion types.
Chapter 7 Advanced Features: Data collection, Position Event Generation (PEG™), sin-cos
encoder multiplier (option) configuration, DPRAM, interrupts, and mechanical brake support.
Chapter 8 Safety Control: Controller safety features..
Chapter 9 Inputs and Outputs: Inputs and outputs, including I/O designations, IN and OUT
variables, I/O usage, and PLC implementation.
Chapter 10 Model-Dependent Features: Features and functionalities that are product-specific.
Chapter 0 Programming Examples: Source code for common motion programming tasks.
Chapter 11 Standard Variable Reference: Reference for standard variables, including name and
description of each standard variable.
Chapter 12 Error/Diagnostic: List of error messages and possible solutions.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 In t ro d u c t io n 1-3

1.4. Related SPiiPlus Documentation

TABLE 1-1 Related SPiiPlus Documentation

Document Description

SPiiPlus <Product> Specifications, installation diagram, and electrical interface

Hardware Guides description for motion control product.
HSSI Modules Hardware High-Speed Synchronous Serial Interface (HSSI)
Guide expansion modules description, installation, and
operational procedures.
SPiiPlus Setup Guide Communication, configuration and adjustment procedures
for SPiiPlus motion control products.
SPiiPlus MMI User’s Guide Multipurpose user interface for configuring and adjusting
the controller, managing ACSPL+ programs, and tracking
performance.
SPiiPlus MultiDebugger ACSPL+ program development environment.
User’s Guide
SPiiPlus C Library Reference C++ and Visual Basic® libraries for host computer
programs.

1.5. Related SPiiPlus Tools

TABLE 1-2 Related SPiiPlus Tools

Tool Description

SPiiPlus MMI A multipurpose user interface with the controller including:

Program management, Motion management, Communication
terminal, Four channel digital oscilloscope, Safety and I/O
signals monitor, Signal tuning and adjustment, Version
Changer, and a fully interactive simulator.
SPiiPlus MultiDebugger An interactive tool for SPiiPlus ACSPL+ multiprogramming
that includes: Progress window for monitoring the status and
simultaneous debugging of up to 10 programs, normal and step-
by-step execution, programmable breakpoints, and a fully
interactive simulator.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

1-4 I nt r o du c t io n

Tool Description

SPiiPlus C Library A DLL (Dynamic Link Library) that supports host application
programming in a variety of languages including C/C++ and
Visual Basic. The library introduces a new level of application
support with a built-in controller simulator and it also provides
outstanding debugging capabilities. All tools are provided with
a full simulator of the controller.
SPiiPlus SPiiDebugger A developing and debugging environment for real-time motion
control algorithms.

1.6. Conventions Used in this Guide

Several text formats and fonts are used in the text to convey information about the text. Command
syntax follows normal usage.

1.6.1. Text Conventions

See also syntax conventions (5.2.7).

Text Description

Bold ACSPL+ elements (commands, functions, operators, standard variables,

etc.) when mentioned in the text.
Software tool menus, menu items, dialog box names and dialog box
elements.
Italic Emphasis or an introduction to a key concept. .
Monospace Code examples.
Italic Information in code examples that the user provides.
monospace
ALL CAPS Names of standard variables. (Keyboard) key names [example: SHIFT
key].
blue italic Names of other documents.
blue underlined Links within this document, to web pages, and to e-mail addresses.
| Symbol used in nested menu items and dialog box options leading to a
final action. For example, the sequence
Debug | New Watch | Real-time |
Directs the user to open the Debug menu, choose the New Watch
command, and select the Real-time option.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 In t ro d u c t io n 1-5

1.6.2. Statement Conventions

The following statement formats are used in this guide.

Warning
A warning describes a condition that may result in serious bodily injury or death

Caution
A caution describes a condition that may result in damage to equipment

Note
Notes contain helpful information and tips

This symbol indicates a topic for advanced users.

MODEL
DEPENDENT
Highlights a specification, procedure, condition, or statement that
depends on the product model.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 Glo s sar y 2- 1

2. GLOSSARY

ACSPL+ A programming language for multi-program motion control.

Provides access to SPiiPlus resources and strict timing of
program execution.
ACSPL+ command The smallest executable unit of ACSPL+. Several commands
can be combined in one ACSPL+ line to be executed in one
controller cycle.
ACSPL+ line A line of code, containing one or more ACSPL+ commands.
Can be stored in a buffer as a part of an ACSPL+ program, or
can be sent to the controller for immediate execution. By
default, one ACSPL+ line is executed in one controller cycle.
ACSPL+ program A sequence of ACSPL+ lines, loaded in one buffer.
ACSPL+ variable Can be user variable (user-defined) or standard variable
(predefined in firmware).
analog inputs/outputs The controller's analog inputs accept a signal (voltage range is
model-dependent) from an external source such as a sensor or a
potentiometer.
The analog outputs supply a signal voltage range is model-
dependent) to an external acceptor such as a scope or power
amplifier.
An ACSPL+ command can access the analog inputs/outputs
through the standard variables AIN/AOUT.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

2-2 G l os s a r y

application In a broad sense, an application is any user installation that

includes a SPiiPlus controller.
In this document the application is considered in a narrow
sense, as a set of files that tailors the controller to the specific
controlled plant. The set includes the following:
• configuration variableS
• ACSPL+ program
• SP program
An application can be stored in the controller’s nonvolatile
memory, so that the controller will be ready to control the plant
immediately after power-up. An application can also be stored
as a file in the host computer and downloaded to the controller
as required.
An application can also include an external host-based
program, which is stored and executed on the a PC host
computer..
application protection Application protection does the following:
• Protects the user application from unintentional
modification.
• Prevents harmful operator intervention while the
application is running.
• Restricts erroneous changes to critical data and
execution of potentially dangerous operations while the
application is running.
At any time the user can enable or disable application
protection. When application protection is disabled, none of the
protections specified above apply.
When application protection is enabled, the controller is said to
be in protected mode. When application protection is disabled,
the controller is said to be in configuration mode.
array A standard variable or user variable that contains more than
one value (element), as opposed to a SCALAR. All values in
an array belong to the same type, either integer or real.
An array can be one-dimensional (vector) or two-dimensional
(matrix).
autoroutine A subroutine in an ACSPL+ program activated automatically
once a specific condition is satisfied. The user specifies the
activation condition and the action executed in autoroutine. A
number of autoroutines can be defined in a user application.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Glo s sar y 2- 3

axis An abstraction of the controlled motor.

Within the controller an axis is represented by a set of standard
variables specifying axis position, velocity, etc. One or more
axes serve as an environment for motion.
The connection between the controller axes and the physical
motor may range from a simple one-to-one correspondence
(default), to sophisticated formulae that calculate the motor
position using several controller axes.
axis group A set ox axes who act as a coordinated unit. Axis group
provides an environment for multi-axis motion.
The controller creates and destroys axis groups automatically
as required by the executed motion. However, the user can
create a permanent axis group that cannot be destroyed
automatically.
buffer A container for an ACSPL+ program. The SPiiPlus PCI-4/8
controller contains 10 buffers; therefore up to 10 ACSPL+
programs can be stored in the controller.
The programs stored in different buffers can be executed
concurrently; therefore multi-programming in the controller is
limited to 10 concurrent ACSPL+ programs.
closed loop An element of servo control that causes the specific parameter
(feedback) to follow the desired value (reference). For servo
motors the controller provides position, velocity and
(sometimes) current closed loop.
Within the controller all closed loops are digital. The servo
processor assigned to the axis provides all necessary
calculations.
configuration mode Mode of application protection where application and critical
data can be modified by user. Opposite of protected mode.
configuration variable A subset of standard variables that tailor the controller to a
specific controlled plant. The user typically defines these
variables when building an application, and thereafter does not
change them. The values of the configuration variables are a
part of the application. As a rest of the application the values
can be stored in the nonvolatile memory. The controller
automatically retrieves the values from the nonvolatile memory
on power-up.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

2-4 G l os s a r y

controlled plant An object of the control that includes the following

components:
• Mechanical part
• Motors
• Feedback sensors
• Additional sensors and actuators connected to the
controller’s digital or analog inputs/outputs
controller One of the SPiiPlus line of compatible controllers. The models
in the line differ by packaging characteristics, available
communication channels, number of controlled axes, and
internal resources. All models share the same basic architecture
and programming language.
Information in this guide applies for SPiiPlus controllers.
controller cycle A primary period within the controller time framework. The
controller aligns all its operations to this period.
The controller cycle is fixed at 1 millisecond.
data collection The process of sampling the values of specified variables and
storing them in a specified array.
digital inputs/outputs Digital input accepts binary signal from an external source such
as a switch or a relay. Digital output provides binary signal to
an external acceptor such as an LED or actuator. An ACSPL+
command can access the analog inputs/outputs through the
controller standard variables IN / OUT.
factory default Set of controller configuration variables, SP programs and SP
data written to the controller nonvolatile memory as a part of
the firmware. The user application can replace one or more
parts of the factory default. However, the controller can be
returned to factory default at any time by using the #RESET
command.
fault An abnormal situation detected by the controller. The
controller detects the faults by examining the fault conditions
as a part of safety control process. The fault conditions include
verification of the safety inputs as well as internal integrity.
Once a fault is detected, the controller raises a corresponding
bit in the FAULT or S_FAULT variable. For a number of
faults the controller provides default response. The user can
define (or redefine) the desired response for any fault using
autoroutines.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Glo s sar y 2- 5

firmware A set of files factory-written in the nonvolatile memory. The

firmware includes the MPU program, the default SP programs,
and the default values of the configuration variables. The user
cannot modify the firmware (however, using SPiiPlus MMI the
user can upgrade the firmware version).
If an application includes the values of the configuration
variables and/or SP programs, the controller on the power-up
retrieves the application instead of the factory defaults. The
user can delete the application at any time and to return to the
factory defaults by using the #RESET command.
global variables Variables that are common for all buffers.
A variable can have either global or local scope. All standard
variables have global scope. A user variable's scope is specified
in the variable declaration.
hardware The physical components of the SPiiPlus Motion Controller.
The principal hardware components include the MPU the
Servo Processor, and the nonvolatile memory.
host The user-supplied computer that communicates with the
controller.
host-based program A program written in C, C++ or any other programming
language that runs on the host computer and communicates
with the controller.
hssi High-Speed Synchronous Serial Interface. One of the standard
features in the SPiiPlus controllers. Provides extension of the
controller digital inputs/outputs. An ACSPL+ command can
access the HSSI extension through the controller standard
variables EXTIN and EXTOUT. HSSI is described in detail in
the HSSI Modules Hardware Guide.
terminal command Command that is executed immediately and are not stored in a
buffer. An terminal command can be sent to the controller
through any communication channel. Terminal command s
start with # or ?.
immediate execution A mode of command execution, when a command received via
any communication channel is not stored in a buffer but is
executed by the controller immediately.
A terminal command is always executed immediately. An
ACSPL+ command can either be executed immediately or
stored in a buffer.
index 1. An input signal from the encoder or similar sensor that
defines an absolute origin of the motor. The signal cause
latching of the current encoder position.
2. A syntax element of the ACSPL+ language that provides
access to a specific element of array.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

2-6 G l os s a r y

leading axis The first specified axis in an axis group. The standard variables
related to the leading axis define motion parameters for the
entire group. The same variables of other axes in the group
have no effect on the group motion.
local variables Variables that are accessible only within the buffer that they
are declared.
A variable can have either global or local scope. All standard
variables have global scope. A scope of user variable is
assigned in the variable declaration.
mark A dedicated controller input signal that latches the current
encoder position (saves the position to a register). The register
value is assigned to the MARK variable. A similar mechanism
supports secondary encoders, with the input signal called
MARK2 and the value assigned to the M2ARK variable.
master-slave motion Motion that evolves according to some external or internal
signal, as opposed to the time-based motion that evolves as a
function of the time.
In a simple case, an axis involved in a master-slave motion can
reproduce the motion of another axis.
matrix A two-dimensional array.
motion Process in the controller that results in a change in internal
variables of the controller, and can result in physical effects
such as motor movement.
motion profile Diagram of position or velocity against the time in a time-
based motion. The controller provides a third-order motion
profile using the velocity, acceleration, deceleration and jerk
supplied by the standard variables.
motor The part of the controlled plant that performs physical
movement on one axis.
mpu Main Processing Unit. The hardware component that executes
mpu program.
mpu program The principal part of the firmware. Implements the most
controller functions. Is stored in the nonvolatile memory and
cannot be modified by the user. The controller automatically
retrieves the MPU program on the power-up.
nonvolatile memory A type of memory that retains the values when the power is off.
In the SPiiPlus PCI-4/8 the nonvolatile memory stores the
firmware and the application.
protected mode Mode of application protection where application and critical
data are protected from user intervention. Opposite of
configuration mode.
read-only variable A standard variable that can be read from the controller but
cannot be assigned.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Glo s sar y 2- 7

safety control The function of the controller that ensures safe operation of the
system. Consists of the verification of numerous fault
conditions that the controller executes each controller cycle
irrespective of any other activity. Once a fault condition is
satisfied, the controller raises the corresponding fault.
safety inputs Digital inputs that the controller examines in the process of
safety control.
scalar A standard variable or user variable that contains one value, as
opposed to array.
servo tick The period of SP program execution. The SPiiPlus PCI-4/8
controllers have a standard servo tick of 50 microseconds (20
kHz). This defines the sampling rate implemented in the servo
processor for digital servo control and fine interpolation .
settling time The time required for a motor to reside within a target envelope
(see also TARGRAD variable on page 11-68) around the target
point before the controller raises the in-position bit in the MST
variable.
simulator An integrated part of each SPiiPlus PCI-4/8 tool that emulates
the controller operations without producing actual movement.
The Simulator is useful while developing the user application,
for learning ACSPL+ and for demonstration purposes.
SP (servo processor) The component that incorporates a powerful RISC processor
and an extensive periphery for connecting sensors and
actuators. The controller includes 2 or 4 SPs; one SP provides
control for 2 axes. The SP executes the most time-consuming
tasks like digital closed-loop control and fine interpolation. The
latest version is the SPii.
SP program The part of the firmware executed in a servo processor. The SP
program is stored in the nonvolatile memory. The controller
automatically retrieves the SP program on power-up.
The user can modify an SP program in order to implement
specific filters and tailor the control algorithm to the controlled
plant.
SP variables Variables declared in SP program.
SPii Current version of SPii (written SPii).
SPiiPlus Family of controller products built around the SPii.
SPiiPlus C library A library of subroutines developed with the controller. The
library facilitates creating Windows®-based applications that
support the controller.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

2-8 G l os s a r y

standard variable Predefined ACSPL+ variable. Standard variables are used for
many tasks including configuring the controller and providing
information about application. Standard variables can be used
in any Error! Reference source not found. or ACSPL+
command without explicit declaration, as opposed to user
variables.
time-based motion Motion that evolves as a function of time, as opposed to
master-slave motion. The characteristic feature of a time-based
motion is a motion profile that shows the motion progress
against the time.
tools A set of Windows applications provided with the controller to
aid the user in developing and implementing an application.
Each tool communicates with the controller in order to perform
various functions. Each tool includes a controller simulator,
which enables the tool to be used without requiring a physical
connection to the controller.
user variable User defined ACSPL+ variable as opposed to standard
variables.
vector A one-dimensional array.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s So f t w a r e A r c h i t e c t u re 3-1

3. SPIIPLUS SOFTWARE ARCHITECTURE

3.1. Hardware and Firmware

3.1.1. Hardware Structure

The following diagram shows the principal parts of the controller hardware:

MPU Interaction
SPii with
Interaction SPii
SPii the controlled
with SPii
the Host plant
computer

Flash memory

FIGURE 3-1 Controller hardware block chart

The Motion Processing Unit (MPU), which executes most of the controller tasks, is a powerful
586 or Pentium processor.
The SPii™, a proprietary ACS Motion Control Servo Processor (SP), executes the real-time tasks
such as implementation of the real time control algorithms. Each SPii controls two axes. The SPii
includes all the necessary peripherals that are needed for a high performance axis control, such as
encoder counters, D to A interface, smart inputs and outputs.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-2 S Pi i Pl us S o f t w a r e A rc h i t e c t u r e

Nonvolatile (flash) memory retains its stored data after the power to the controller is cut off. In
the SPiiPlus PCI-4/8 the firmware and the application are stored in the nonvolatile memory.

3.1.2. Firmware
The firmware consists of a set of files factory-written in the nonvolatile (flash) memory.
The user cannot erase or modify the firmware. However, the user is able to update the firmware
version with a special tool that is part of the SPiiPlus MMI that is supplied with the controller.
The firmware files include the following:
ƒ MPU program.
ƒ SP program (one for all SPs, or individual programs for each SP).
ƒ Default values of the controller’s configuration variables.
Executing #SAVE command pairs stores user ACSPL+ programs files and configuration
variables in the nonvolatile (flash) memory. Executing #SAVESP command pairs does the same
for user SP programs The controller will then use the user-written configuration values and SP
programs instead of the factory default. However, the factory-written files are retained and never
erased. The controller retrieves the factory default following execution of #RESET command
pairs.

3.1.2.1. Firmware Tasks

The MPU program executes the following tasks:
ƒ Communication with the SPs
ƒ Motion profile generation (calculation of APOS)
ƒ Calculation of Reference Position (RPOS)
ƒ Safety control
ƒ Data collection
ƒ Position Event Generation (PEG)
ƒ Processing of Index and Mark inputs
ƒ Execution of ACSPL+ programs
ƒ Communicating to Serial Link, Ethernet, PCI
ƒ Execution of terminal commands received from the Host
ƒ Housekeeping
The SP program executes the following tasks, each servo tick (50 micro seconds):
• Processing of the Feedback Position
• Fine interpolation of the Reference Position
• Control algorithm for position loop
• Control algorithm for velocity loop
• Control algorithm for current loop (if appropriate)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s So f t w a r e A r c h i t e c t u re 3-3

• Calculation of RMS current

• If the control object requires a special control algorithm, sophisticated filters, non-standard
feedback processing, etc., the user is able to prepare his own version of SP program that
satisfies these specific requirements.

3.1.3. Controller Cycle and Servo Tick

The firmware operates in a rigid real-time framework. The two principal parts of the firmware, the
MPU program and the SP programs, are real-time programs operating in strict synchronism.
The SP interrupt has a fixed interval period (called a servo tick) of 50 microseconds (20kHz).
Most SP tasks are executed each servo tick. Therefore, the SP executes the servo control
algorithm at a constant rate of 20kHz irrespective of the number of axes and other factors.
The 20kHz SP clock is divided by a factor of 20, generating a 1kHz clock for MPU interrupts.
The new clock, the controller cycle, is 1.0 milliseconds.

3.1.4. Real-Time and Background Tasks

MPU program tasks are divided into two categories:
ƒ Real-time tasks
ƒ Background tasks
The real-time tasks are executed in strict synchronism with the MPU interrupt. Each controller
cycle, a required part of each real-time task is executed. The overall time of all real-time tasks
executed in one controller cycle must be less than the one controller cycle.
Background tasks are not synchronous with the MPU interrupt. Execution of a background task
may overlap two or more controller cycles.
The following MPU tasks are the real-time tasks that are executed each controller cycle:
ƒ Communication with the SPs
ƒ Motion profile generation (calculation of APOS)
ƒ Calculation of Reference Position (RPOS)
ƒ Safety control
ƒ Data collection
ƒ Position Event Generation (PEG)
ƒ Processing of Index and Mark inputs
ƒ Execution of ACSPL+ programs
The following MPU tasks are the background tasks and are asynchronous to the controller cycle:
ƒ Communicating to Serial Link, Ethernet, PCI
ƒ Execution of terminal commands received from the Host
ƒ Housekeeping

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-4 S Pi i Pl us S o f t w a r e A rc h i t e c t u r e

MPU interrupt MPU interrupt

Controller cycle (1 ms) Next controller cycle

Real-time tasks Background tasks

FIGURE 3-2 The Internal Structure of the Controller Cycle

The MPU interrupt invokes the real-time tasks. When all real-time tasks required in the current
cycle are completed, the controller starts executing the background tasks. If the background tasks
complete before the next MPU interrupt occurs, the controller remains idle for the rest of the
cycle.
The exact time of the real-time and background tasks in each controller cycle depends on many
factors and cannot be precisely specified. The following paragraphs explain different situations in
controller cycle utilization.
If the background task execution does not finish in one controller cycle, the background execution
is interrupted and continues after execution of the real-time tasks during the next cycle. Therefore,
background tasks may overlap into the next MPU interrupt without causing a problem. However,
overflow of real-time tasks into the next MPU interrupt is abnormal, and may cause problems
with program execution. When this occurs, the controller latches the Time Overuse fault. This
fault has no default response in the controller, but the user application can monitor the fault and
define a proper response.
The user can monitor if the usage of the controller cycle is close to critical. The command #U
(See page 4-21) reports the usage as a ratio of real-time tasks execution time and the controller
cycle. A maximum value of 90% is considered dangerous. If the usage limit is reached, the user
has to modify his application or to use a more powerful model of SPiiPlus PCI-4/8.

3.2. Concept of User Application

3.2.1. Firmware, User Application and Tools

The firmware is a program that is stored in the controller’s nonvolatile memory, that defines the
basic functionality of the controller. Among these functions are the preparing, storing and
executing user applications.
The user application tailors the controller to the user’s specific controlled plant. The controller
can control various plants with different number of axes, mechanical construction, timing
requirements, etc. The user application specifies the exact control and monitoring actions that
must be executed in different conditions, including the exact sequences of motions, activation of
outputs, response to inputs and interactions with the operator.
SPiiPlus Tools are Windows-based programs that provide the user with support in different stages
of the application such as initial set up and tuning, ACSPL+ application development, host
application interaction with the controller, and manual control.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s So f t w a r e A r c h i t e c t u re 3-5

3.2.2. User Application Components

The following diagram shows the parts of user application in the gray blocks and the relevant
parts of firmware in the white blocks:

Host-based Command SP
program interpreter program

Controller
ACSPL+ variables
program
Configuration
variables

FIGURE 3-3 User Application Block Diagram

• Host-based program: A program written in C, C++ or any other programming language that
runs on the host computer and communicates with the controller. The host-base program
uses any communication channel provided by the controller; serial link, Ethernet, FIFO, dual
port ram. The program issues commands to, and reads data from, the controller. The program
can provide front-end user interfaces, motion sequencing, high-level decision-making and
other application specific functions. This part of user application can be absent if the
controller works stand-alone without connection to the host.
The design of host-based programs is not the primary subject of this guide. For Windows
programming, refer to the SPiiPlus C Library Reference Guide. For other operating system
programming, (Unix, Linux, etc.) see Appendix A in this guide.
• ACSPL+ program: A sequence of ACSPL+ commands can be downloaded to the controller
as an ACSPL+ program. There are 10 buffers for ACSPL+ programs. An ACSPL+ program
is executed inside the controller with strict timing and with no communication delay.
ACSPL+ programs are almost always present in user applications. Occasionally, the
ACSPL+ programs are absent and the host commands all controller actions.
• Configuration variables: The firmware includes a set of predefined variables that can be used
by ACSPL+ programs and by terminal commands. The configuration variables are included
in this set. The values of the configuration variables are defined by the user to tailor the
controller operation to a specific task and plant control. For example, ACC defines the
acceleration that is used for motion generation. The SAFINI variable defines the polarity of
the input safety signals.
The configuration variables are always present in user applications.
• SP programs: The firmware includes SP real time control programs as a standard part of the
controller. The user can modify these programs, making it part of the user application. SP
real time control programs are rarely present in user applications and are not covered in this
manual.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-6 S Pi i Pl us S o f t w a r e A rc h i t e c t u r e

3.2.3. User Applications Categories

The user can use different strategies to build an application, including:
ƒ Stand-alone application.
No physical link to a host. No host-based program. ACSPL+ programs are stored in the
controller nonvolatile (flash) memory. The ACSPL+ programs start running after power-up
and implement all application functions.
ƒ Host-driven application:
No ACSPL+ programs. The host issues all commands to be executed by the controller. This
approach is applicable only for non-time-critical applications.
ƒ Hybrid application:
A host-based program plus one or more ACSPL+ programs. Most user applications fall into
this category.

3.2.4. Tools for Developing User Applications

The controller is supported by a rich set of software tools that are useful in all stages of
application development.
The following table describes which support tools are needed for different stages of application
development. With the exception of the SPiiPlus C Library, all of the tools are Windows
applications.
Development of host-based program SPiiPlus C Library
Development of ACSPL+ program SPiiPlus MultiDebugger
Setting the configuration variables SPiiPlus MMI – Configurator
Fine tuning the servo loop parameters SPiiPlus MMI – Adjuster
Development of SP program SPiiPlus SPiiDebugger
Testing the application with motion SPiiPlus MMI – Scope, Motion Manager, etc.
Saving and copying controller application SPiiPlus MMI – Saver/Loader
Upgrading firmware SPiiPlus MMI – Version changer

3.2.4.1. File Extensions Used in SPiiPlus Tools

Several file formats are used to store data and programs used with SPiiPlus Tools.

TABLE 3-3 SPiiPlus Tool File Types

File Contains Associated SPiiPlus MMI

Component (| other SPiiPlus Tool)

.par controller parameters SPiiPlus MMI Configurator

.prg ACSPL+ Program SPiiPlus MMI Program Manager;
SPiiPlus MultiDebugger

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s So f t w a r e A r c h i t e c t u re 3-7

File Contains Associated SPiiPlus MMI

Component (| other SPiiPlus Tool)

.spi application (includes controller SPiiPlus MMI Saver/Loader;

parameters + adjustment parameters + SPiiPlus MMI Upgrader
ACSPL+ program + SP files)
.dba amplifier database SPiiPlus MMI Adjuster
.dbf encoder database SPiiPlus MMI Adjuster
.dbm motor database SPiiPlus MMI Adjuster
.txt communication log SPiiPlus MMI Communication Viewer
.htm Print to file SPiiPlus MMI Program Manager and Scope

3.3. Programming Resources

The controller-based parts of the user application operate in the environment created by the
firmware. The environment includes a set of resources that the user application can use. This
section provides a short description of the available resources.

3.3.1. Commands
The controller supports a rich set of commands.
The controller can either execute a command immediately when the command is received through
one of the communication channels or the controller can store a sequence of commands in a
buffer and execute them as a program. The command set is subdivided into two types of
commands:
• terminal command (page 4-1) that cannot be stored in a buffer and always are executed
immediately. Each terminal command starts with ? (query command) or # (management
command). For example:
?FPOS Display the current position of all motors.

#0L List the complete program in buffer 0.

• ACSPL+ commands (page 5-71) that can either be executed immediately or can be stored in
a buffer. Examples of ACSPL+ commands:
enable X Enable motor X

Var = 5*Var2 Assign the result of expression to variable Var

wait 50 Delay the program for 50 milliseconds

ptp X,3000 Move the X motor to point 3000

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-8 S Pi i Pl us S o f t w a r e A rc h i t e c t u r e

3.3.2. Program Buffers

The controller provides 10 buffers for storing ACSPL+ programs. The controller defines the size
of each buffer according to the required size of the program. For all practical purposes, the user
can consider the size of each buffer to be unlimited.
A program stored in a buffer can be edited, compiled and executed independently of the programs
in other buffers. For example, a program in buffer 0 may be running, while the user edits the
program in buffer 1.
Programs stored in different buffers can be executed concurrently. Each buffer defines an
execution thread connected to this buffer. When the user activates a program in a buffer, the
program is executed in a separate thread. Therefore, up to 10 ACSPL+ program can be executed
concurrently.
A buffer also provides isolation between the programs. All labels and local variables defined in a
program are isolated in their buffer and are inaccessible from any other buffer. For example, two
programs can contain similar user-defined labels, but the controller considers each label as
belonging only to the buffer that it is contained in, and relates to all references to the label
appropriately.

3.3.3. Command Execution

3.3.3.1. Terminal commands

A terminal command (page 4-1) cannot be stored in a buffer. Once a terminal command is
received via any communication channel, the controller executes it immediately or rejects the
command if it cannot be executed.
The controller executes terminal commands as a background task. One terminal command cannot
be interrupted by another. The controller finishes execution of a command, sends a reply, and
only then continues to the next command. Therefore, a host-based process that sends commands is
guaranteed to receive the replies in the same order as the commands were sent.
Typically, execution of a terminal command takes 1-2 controller cycles. The commands that
supply or request a great amount of data, such as query of a large array, may require a longer
processing time.
Processing time can also be affected by a high MPU usage. The real-time tasks always have the
greatest priority. If the usage (percentage of the real-time tasks in the controller cycle) reaches
90% or more, the response time of the controller deteriorates. If an application requires the fastest
response to terminal commands, the user must keep the usage below 50%.

3.3.3.2. ACSPL+ Commands

There are two methods for executing ACSPL+ commands (page 5-71):
• Execute immediately.
• Store a sequence of commands in a buffer and then execute the sequence as an ACSPL+
program.
If the prompt is : (colon), no program buffer is open for editing, and an ACSPL+ command,
transmitted to the controller through any communication channel, is executed immediately.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s So f t w a r e A r c h i t e c t u re 3-9

If the prompt contains a line number like 2:00001>, a program buffer is open for editing, and an
ACSPL+ command, transmitted to the controller through any communication channel, is stored in
the open buffer, as part of an ACSPL+ program.
Immediate execution of ACSPL+ commands is a background task. Therefore, the processing time
can be affected by a high MPU usage. The real-time tasks always have the highest priority. If the
usage (percentage of the real-time tasks in the controller cycle) reaches 90% or more, the response
time of the controller deteriorates. If an application requires the fastest response to terminal
commands, the user must keep the usage below 50%.
Executing an ACSPL+ program from a buffer is different, because the controller executes a
buffered ACSPL+ program as a real-time task. Up to 10 buffered ACSPL+ programs can be
executed simultaneously, and in parallel, the controller can execute a terminal command.

3.3.3.3. Dynamic Buffer

One or more program buffers can be configured as dynamic buffer.
Unlike a regular buffer, the dynamic buffer does not separate the tasks of loading, compiling, and
executing a program. An ACSPL+ line directed to a dynamic buffer is immediately compiled and
ready for execution. If, the buffer was empty, the new line is executed immediately after
compilation. If there are previously inserted lines, the new line is stored in the buffer and waits for
its turn to execute. Once the line has executed in the dynamic buffer, the controller removes the
line from the buffer.
Therefore, execution in a dynamic buffer combines the features of immediate execution with
those of storage followed by execution. A dynamic buffer effectively works as a FIFO buffer for
inserted ACSPL+ lines.

3.3.4. Standard Variables

The controller provides a set of predefined variables called standard variables (page 11-1).
Standard variables can be used without declaration in any command, either immediate or
buffered.
The standard variables are divided into two categories:
ƒ State variables. Examples are FPOS (Feedback Position), which reports the immediate
position of a motor and MST (Motor State), which indicates the motor status, including
whether it is enabled and whether is involved in a motion.
ƒ Configuration variables. The values of the configuration variables tailor the controller to a
specific control object. Examples are ACC (Acceleration), which specifies a tolerable
acceleration of a motor and SLLIMIT (Software Left Limit), which specifies a lower limit
for the area of motion, etc.
Standard variables are mentioned throughout this guide where they relate to a particular element
or feature of ACSPL+.

3.3.5. User Variables

In addition to the set of standard variables, the user can declare variables with user-defined names
as required in the application.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-10 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

A user variable can be declared as scalar, one-dimensional array (vector) or two-dimensional

array (matrix). An array cannot contain more than 10000 elements.
A user variable can be declared as local or global. Local variables are accessible only within the
buffer that the declaration resides in. Global variables are common to all buffers and can be
accessed from any buffer.

3.3.6. Nonvolatile (Flash) Memory and Power Up Process

The on board nonvolatile (flash) memory retains information while power is off.
The nonvolatile (flash) memory stores the following data:
ƒ Firmware
ƒ User application
A new controller is supplied with only the firmware stored in the nonvolatile (flash) memory. The
user cannot erase or modify the firmware.
Issuing #SAVE commands stores user ACSPL+ programs and configuration variable values in the
controller's nonvolatile memory. #SAVESP commands do the same for SP programs.
Issuing a #RESET command retrieves the default variable values, clears ACSPL+ programs in all
buffers, and resets all SP programs.
During the power-up process (page 4-37)the controller loads the firmware, the ACSPL+
programs, the configuration variables and the SP programs from the nonvolatile (flash) memory.
If the user did not store any component of configuration variables or SP programs, the controller
loads the default firmware component.

3.3.7. Connection to the Plant

3.3.7.1. General Diagram

All connections between the controller and the controlled plant are provided through the SP
processors as shown in the following diagram:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-11

CONTROLLER

RPOS Direct
transform SP ±10V signals
to drivers

FPOS Feedback
transform Encoder
signals
IST
IND
MARK Feedback Mark inputs
MARK2 transform

FAULT
S_FAULT Safety
control Safety signals

IN
Digital inputs

OUT
Digital
outputs

AIN
Analog inputs

AOUT
Analog
outputs

EXTIN
HSSI
EXTOUT

FIGURE 3-4 SPii-plant connections and related parameters

The standard variables that provide access from user application to the control object are shown to
the left. The following variables are available:
• RPOS – Reference Position, array of eight elements, contains the desired motor position
calculated by the controller.
• FPOS – Feedback Position, array of eight elements, reads the current motor position.
• IND – Index Position, array of eight elements, reads the position of the last encountered
encoder index.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-12 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

• MARK – Mark Position, array of eight elements, reads the position of the last encountered
Mark signal.
• M2ARK – Secondary Mark Position, array of eight elements, reads the position of the last
encountered Mark2 signal.
• FAULT – Faults, array of eight elements, the bits of the variable report the axis-related
faults detected by the safety control
• S_FAULT – System Faults, scalar, the bits of the variable report the system faults detected
by the safety control.
• IN – General Purpose Inputs, array of eight elements, each bit reports the state of one
general-purpose input.
• OUT – General Purpose Outputs, array of eight elements, each bit defines the state of one
general-purpose output.
• AIN – Analog Inputs, array of 16 elements, each element reads the numerical value of the
voltage supplied to one analog input. The number of analog inputs varies depending on the
controller model.
• AOUT – Analog Outputs, array of 16 elements, each element defines the voltage generated
by one analog output. The number of analog inputs varies depending on the controller
model.
• EXTIN – Extended Inputs, array of eight elements, each bit represents a bit in the input or
HSSI register.
• EXTOUT – Extended Outputs, array of eight elements, each bit represents a bit in the HSSI
register

3.3.7.2. User-Defined Units

The controller allows the user to define the units used for motion programming and monitoring.
During the configuration stage, the user sets the value of the EFAC parameter to specify the ratio
between the desired unit and an encoder count for each axis. For example, if the encoder
resolution is 1000 counts per millimeter, and the user desires to program in millimeters, the
corresponding EFAC element must be set to 0.001.
The user-defined units apply for all motion commands, so that all position-related arguments must
be specified in user-defined units. The user-defined units also affect all position-related standard
variables. For example, if the user-defined units are millimeters, then the unit of RPOS, FPOS,
APOS, MPOS, IND, MARK, etc., will be in millimeters.
The user unit also affects velocity, acceleration and jerk variables. For example, if the EFAC
value defines user unit as millimeter, then the unit of VEL, RVEL, FVEL, XVEL, etc., will all
be millimeters per second. The unit of the variables ACC, DEC, KDEC, RACC, FACC, etc.,
will be millimeters per second2. The unit of the variables JERK, GJERK will be millimeters per
second3.
The user can define the same or different units for each axis, irrespective of the encoder
resolution.
Example (rotary motor):
Feedback resolution: 2000 lines/ rotation

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-13

Internal Multiplier: x4
User units: 360 degrees per rotation

Calculation: EFAC = 360 / (2000x4) = 0.045

Example (linear motor):
Feedback resolution: 2 micron (500 lines/mm)
Internal Multiplier: x4
User units: mm

Calculation: EFAC = 1 / (500x4) = 0.005

Example (linear motor, sin-cos encoder):
Encoder resolution: 500 lines/mm
Internal Multiplier: x64
User units: mm

Calculation: EFAC = 1 /(500x64) = 0.00003125

Example (rotary motor connected to ball screw):
Feedback resolution: 2000 lines/ rotation
Gear ratio: 1 motor rotation=0.5mm motion of load
Internal Multiplier: x4
User units: mm
Calculation: EFAC = 1 / (2000 x4 x(1/0.5))= 0.000625

3.3.7.3. Direct and Feedback Transform

The SPii accepts the encoder signals and calculates the feedback position in encoder counts. All
servo algorithms in the SPii are based on encoder counts, not user units.
Therefore, when reading the feedback position from the SP, the controller executes feedback
transform according to the formula:
FPOS = FP*EFAC + EOFFS
where FPOS is the controller feedback position in user units, FP is an SP-calculated feedback
position in encoder counts, EFAC is a user-defined value of the corresponding EFAC factor, and
EOFFS represents an offset.
EOFFS is a read-only standard variable that provides the offset between the SP-calculated
position and the controller feedback position. The value of EOFFS changes when the set
command defines a new origin for an axis.
When writing the reference position to the SP, the controller executes direct transform described
by the formula:
RP = (RPOS – EOFFS) / EFAC
where RPOS is the controller reference position in user units, and RP is the SP reference position
in encoder units.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-14 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

3.3.7.4. Index and Mark Values

Index and mark processing is based upon the SP hardware latch of the encoder reading when the
index or mark input signal occurs. The latched position is accurate to within one encoder count at
speeds of up to 5 million counts per second.
The following input signals are used for position latching:
ƒ Encoder index. One index signal is available per axis.
ƒ Mark and Mark2. These signals are available only for axes X, Y, Z, and T.
Each of the three signals has an independent circuit and a separate latch register. The circuit
latches the encoder reading in the register on the positive edge of the corresponding signal.
The controller further processes the latched signal. In this example we will use the index to
explain the process. Processing the mark values is similar.
When the index signal latches the encoder reading, the controller raises a flag (the bit IST.#IND),
converts the value into user units (scale and offset), and stores the value in the variable IND.
Afterwards, as long as the IST.#IND bit is set, the controller ignores any new index occurrences.
Therefore, the IND variable does not change even if a new index was encountered. To reactivate
the index latching, the user must explicitly reset the IST.#IND bit.
The following program fragment reports the index value each time that the index is encountered:
X_IST.#IND = 0 Reset any index encountered previously
INDREP: Start of the loop
till X_IST.#IND Wait until the index is latched
disp X_IND Report the index position
X_IST.#IND = 0 Reactivate index latching
goto INDREP Go to the loop start

3.3.7.5. Safety Inputs

The following safety inputs are available for each axis:
Left Limit Signal from Left Limit switch.
Right Limit Signal from Right Limit switch.
Drive Alarm Alarm signal from the drive: normally is on when the drive is
disabled, and is off when the drive is enabled
The following safety input is not related to a particular axis and indicates a general failure of the
control object:
Emergency Stop General failure of the control object
The controller processes each safety input and raises the corresponding fault bit in the FAULT or
S_FAULT variable accordingly. The following bitmapped variables are involved in the
processing of the safety inputs:
ƒ SAFIN and S_SAFIN, read-only variables (except when used with Simulator) – indicate the
raw state of safety inputs before any processing

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-15

ƒ SAFINI and S_SAFINI, configuration variables – define the active state of each signal,
specifying inversion of a signal if required
ƒ FMASK and S_FMASK, configuration variables – enable or disable using each signal in
the safety control
ƒ FAULT and S_FAULT, read-only variables – indicate the faults detected by the safety
control
ƒ FDEF and S_FDEF, configuration variables – enable or disable the controller default
response when the fault occurs
See also safety, page 8-1.

3.3.7.6. Digital Inputs/Outputs

A digital input accepts a binary signal from an external source, such as a switch or a relay. A
digital output provides a binary signal to an external acceptor such as an LED or actuator. Unlike
the safety inputs, a digital input or digital output has no predefined function in the controller. The
user can connect signals to inputs / outputs and process them as required by the application.
The inputs are represented by the integer array IN. The outputs are represented by the integer
array OUT. Each digital input / output is treated as one binary bit. The low voltage level
corresponds to zero and high voltage level corresponds to one. Each element of the IN and OUT
arrays is a 32-bit integer number that can represent up to 32 inputs or outputs. In all current
models, the number of inputs and outputs is less than 32, therefore all actual inputs and outputs
are represented in IN0 and OUT0. All other elements of IN and OUT are reserved for future
extension. For the exact number of inputs/outputs see the specifications of the controller model.
The following example shows an autoroutine that changes the state of output 5 once the state of
input 3 changes from 0 to 1.
on IN0.3 Activate autoroutine on positive edge of input 3

OUT0.5 = ^OUT0.5 Invert the state of output 5

ret End of the autoroutine

See also digital inputs/outputs, page 9-1.

3.3.7.7. Analog Inputs/Outputs

Analog input accepts analog signal from an external source, such as a sensor or a potentiometer.
Analog output provides analog signal to an external receiver, such as an actuator or a measuring
device. Analog inputs/outputs have no predefined function in the controller. The user can connect
signals to inputs/outputs and process them as required by the application.
The analog inputs are represented by the integer array AIN and the analog outputs are represented
by the integer array AOUT. Each analog input/output is represented by one array element.

The range of the AIN/AOUT arrays depends on the type of the input/output and the bit resolution
of the ADC/DAC.
Example, for ±10V analog outputs with 16-bit DAC resolution, the AOUT range is from -32768
(for –10V) to +32767 (for +10V).

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-16 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

Example: For ±1.25V analog inputs with 14-bit DAC resolution, the AIN range is from -8192 (for
–1.25V) to +8192 (for +1.25V).
If an analog output is connected to a drive it has a dedicated destination and cannot be used as a
general-purpose analog output.
For model-dependent analog I/O information (for example, the number and range of inputs and
outputs) see the controller's Hardware Guide.
The following example represents an autoroutine in SPiiPlus PCI-4/8 that displays a message
when the voltage in the 3rd analog input rises above +.75V:
on AIN3 > 4096 Activate autoroutine once the value of AIN3
exceeds 4096 (+.75V)
disp “AIN3 > .75V” Display a message

ret End of the autoroutine

3.3.7.8. High-Speed Synchronous Serial Interface (HSSI)

The HSSI provides a simple interface for various external devices.
The HSSI provides up to 256 input bits and up to 256 output bits. Not every controller model
supports all 512 bits. For the exact number of inputs and outputs supported, see the controller
model's Hardware Guide.
The HSSI bits are represented by an integer array EXTIN/EXTOUT. Each HSSI bit corresponds
to one bit in one element of the EXTIN/EXTOUT array. Which element represents input bits and
which element represents output bits depends on the controller model.
The HSSI bits have no predefined function in the controller. The user is free to use HSSI as
required in the application. In the simplest case the HSSI bits can be used for extension of the
digital inputs/outputs. In a more sophisticated application, any sensor or actuator, including
encoders and drives can be connected through the HSSI.
The HSSI interface is described in detail in the SPii/SPiiPlus HSSI Modules Guide.

3.4. Motion
This section provides a brief description of the concept of motion in SPiiPlus controllers. For
more implementation information, see Chapter 6.

3.4.1. Motion Overview

There are many variables that affect motion or provide information about motion. Here, only the
more commonly used variables will be discussed.
MPOS (master position), APOS (axis position), RPOS (reference position) and FPOS (feedback
position) are all vectors sized according to the number of axes. For example, for the eight-axis
SPiiPlus PCI-8, each of these variables has eight elements.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-17

master MPOS FPOS Feedback SPii

command transform program

Motion- Motion APOS connect RPOS Direct

defining generator command transform
command

FIGURE 3-5 Motion Variables

All variables are read-only.
After power-up, all elements of MPOS are equal to zero. The controller does not calculate MPOS
unless the user or application executes a master command (see page 6-30) for an element of
MPOS. The master command specifies a formula for calculating the element. The controller
stores this formula and then every controller cycle it updates the element using the stored formula.
Additional master commands can be issued, each specifying a specific formula for an MPOS
element. The controller stores the additional formulas, updating the elements every controller
cycle.
Thus, the controller can store master formulas for up to all eight elements of MPOS.
If a new master command specifies a formula for an MPOS element that already has a stored
formula, the controller overwrites the old formula and starts using the new formula.
Time-based motion does not use the MPOS elements. An MPOS element is only used in master-
slave motion and when the corresponding axis for that element is a single axis, or a leading axis in
an axis group (see Axis Group and Leading Axis, Section 3.4.2).
Motion generation starts when a motion command (see Motion, Section 6) is executed and
continues until the motion reaches the target point, fails, or another command interrupts the
motion.
The elements of APOS (Axis Position) represent logical axes and are the results of the motion
generation.
New values for APOS are generated every controller cycle by even if no physical motor is
moving. This virtual motion can be viewed on the SPiiPlus MMI Scope like any physical
motion.
A single-axis motion profile generator calculates one element of APOS. Up to eight single-axis
motions can be generated concurrently.
A multi-axis motion generator calculates several elements of APOS. Single and multi-axis
motions can be generated concurrently as long as they refer to separate axes.
The connection between the logical APOS axes and the real world motors (represented by
reference position RPOS) is defined by the connect command and can be changed by the user. At
power-up each axis RPOS is equal to the corresponding axis APOS value (connect RPOS =
APOS). Each controller cycle the controller calculates values for each RPOS element, using the
stored connect formula.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-18 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

The user or the application can change the connect formula by using the connect command. The
controller overwrites the old formula and continues calculations according to the new formula –
similar to the master command.
Occasionally, the connect formulas must be changed during program execution. In most
applications using connect definitions the definitions are in the application's AUTOEXEC area.
The controller transfers each RPOS element to the corresponding SPii program as a reference
value for the corresponding physical motor (see page 3-13 for explanation of the direct and
feedback transforms). The SPii program executes the control algorithm that causes the motor to
follow the reference value.

3.4.2. Axis Group and Leading Axis

After power-up the controller contains no axis groups and each axis is considered as a single axis.
A single axis can be managed independently of any other axis. A one-axis motion can be executed
for a single axis concurrently with any other motions that involve other axes. The controller
effectively can be used as eight independent one-axis controllers.
When a multi-axis motion is executed, the involved axes act as a coordinated unit. The controller
aggregates the involved axes in an axis group. The controller automatically creates and destroys
axis groups as required for motion execution. For example, the motion command:
ptp XZT,100,200,50 Move X,Z,T to point X=100, Z=200, T=50
automatically creates axis group XZT and automatically destroys it when one or more of the X,Y
or T axes are required for creating another axis group.
The first axis specified in an axis group is the leading axis. A leading axis differs from the other
axes in the group in two ways:
ƒ The controller uses variables VEL (Velocity), ACC (Acceleration), DEC (Deceleration),
KDEC (Kill Deceleration), JERK (Jerk) of the leading axis for the motion profile of the multi-
axis motion. The same variables of any other axis in the group have no effect on the motion.
(Except when a /w suffix is used PTP command, as explained later in this section.)
ƒ During motion, the controller updates the group variables GPATH (Group Path), GVEL
(Group Velocity), GACC (Group Acceleration), GJERK (Group Jerk), GRTIME (Remaining
Motion Time), GMOT (Group Motion Number), GMQU (Group Motion Queue), GSEG
(Group Segment Number) only for the leading axis. The same variables of any other axes in
the group are not updated.
Example:
The motion initiated by the command:
ptp XZT,100,200,50 Move X,Z,T to the point X=100, Z=200, T=50

builds the motion profile using the parameters X_VEL, X_ACC, X_DEC, X_JERK.
Parameters Z_VEL, T_VEL, Z_ACC, etc. have no effect on the motion. Similarly, during
the motion the controller updates variables X_GPATH, X_VEL and so on, but does not
update Z_PATH, T_PATH, Z_VEL, etc.
Motion initiated by the command:
ptp ZXT,200,100,50 Move X,Z,T to the point X=100, Z=200, T=50

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-19

builds the motion profile using the parameters Z_VEL, Z_ACC, Z_DEC, Z_JERK and
updates variables Z_GPATH, Z_VEL and so on.
In other respects, the order of axes in a group is insignificant. The effect of the following two
commands is the same:
ptp XZT,100,200,50 Move X,Z,T to the point X=100, Z=200, T=50

and
ptp XTZ,100,50,200 Move X,Z,T to the point X=100, Z=200, T=50

In some cases, the user may wish to explicitly manage axis groups, not relying on the automatic
handling by the controller. The ACSPL+ command group creates an axis group and the command
split destroys it. The controller never automatically destroys a group created with the explicit
group command. Explicit group managing can be useful if several axes must be always used
together or for a long time.
A single axis in a one-axis motion plays the same role as a leading axis in a multi-axis motion. A
single axis can be treated as an axis group consisting of one axis.
The M suffix for the PTP command causes the controller to automatically calculate and use the
maximum motion parameters available for the group. An advantage of using this suffix is that it
frees you from having to keep track of the leading axis' motion parameters.
ptp /m XYZ,20,40,300 Move X,Y,Z to the point X=20, Y=40, Z=300
using the maximum motion parameter values

For more information about the M suffix, see Section 6.1.2.

3.4.3. Time-Based Motion and Motion Profile

All motions provided by the controller can be divided into two classes: time-based motions and
master-slave motions.
A time-based motion progresses as a function of time, following an internal generated profile or a
table that defines an arbitrary path as a function of time. Each controller cycle, new values of
APOS are generated for the involved axes.
For a nonarbitrary path, such as point to point motion, the motion profile generator calculates
APOS in two stages:
1. The profile generator calculates the group variables GPATH, GVEL, GACC, GJERK,
GRTIME for the leading (or single) axis.
2. The profile generator produces new APOS points for each axis.
Values of GPATH and GVEL as a function of time constitute a motion profile.
The controller generates a third-order motion profile. GPATH is a third-order polynomial
function of time.
A typical motion profile of a point-to-point motion is presented in the following plot. The group
velocity (GVEL) as a function of time:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-20 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

FIGURE 3-6 Motion profile

The profile consists of 7 segments. The current phase of a motion is reported by the standard
variable GPHASE, which can have the following values:
0 – no motion
1 – acceleration buildup
2 – constant acceleration
3 – acceleration finishing
4 – constant velocity
5 – deceleration buildup
6 – constant deceleration
7 – deceleration finishing
8 – kill deceleration
The following three phases apply only to master-slave motion (see Section 3.4.4).
9 – asynchronous phase of master-slave motion
10 – synchronous phase of master-slave motion
11 – stalled phase of master-slave motion.
The following formulae describe the group variable calculation for each segment of motion shown
in FIGURE 3-6. The desired values of velocity, acceleration, deceleration, jerk are specified by
the elements of the VEL, ACC, DEC, JERK variables. T is the time that elapsed since the
beginning of the segment:
1. Approaching the desired acceleration:
GJERK = JERK
GACC = JERK*T

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-21

GVEL = JERK*T2/2
GPATH = JERK*T3/6
2. Move with constant acceleration:
GJERK = 0
GACC = ACC
GVEL = GVEL1 + ACC*T
GPATH = GPATH1 + GVEL1*T + ACC*T2/2
3. Approaching the desired velocity:
GJERK = –JERK
GACC = ACC – JERK*T
GVEL = GVEL2 + ACC*T – JERK*T2/2
GPATH = GPATH2 + GVEL2*T + ACC*T2/2 – JERK*T3/6
4. Move with constant velocity:
GJERK = 0
GACC = 0
GVEL = VEL
GPATH = GPATH3 + VEL*T
5. Approaching the desired deceleration:
GJERK = –JERK
GACC = –JERK*T
GVEL = VEL – JERK*T2/2
GPATH = GPATH4 + VEL*T – JERK*T3/6
6. Move with constant deceleration:
GJERK = 0
GACC = – DEC
GVEL = GVEL5 – DEC*T
GPATH = GPATH5 + GVEL5*T – DEC*T2/2
7. Approaching the desired position:
GJERK = JERK
GACC = –DEC + JERK*T
GVEL = GVEL6 – DEC*T + JERK*T2/2
GPATH = GPATH6 + GVEL6*T – DEC*T2/2 + JERK*T3/6
The profile may lack one or more segments. For example, if the desired velocity is too high, the
profile will not include the constant-velocity segment.
The profile remains basically the same for all time-based motion types.
Conversion of GPATH values to APOS values depends on the motion trajectory. The controller
calculates APOS values as projections of the current motion point to each axis.

3.4.4. Master-Slave Motion – Following a Master

A master-slave motion does not use time as a base for motion calculation. Instead, the axis
follows the value of MPOS.
In a simple case, activation of the master-slave motion may look like the following:
master X_MPOS = Y_FPOS
Define the Y feedback as a master for the

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-22 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

X axis
slave X Activate the master-slave motion of X

The X motor will now follow the Y feedback.

In addition to variables, arbitrary expressions can also be specified to the right side of the equal
sign in the master command. Thus, the controller provides a large variety of variants in master-
slave motion, a few of which are listed below:
ƒ Electronic gearing: the formula specifies a feedback signal multiplied by a constant or
variable factor.
ƒ CAM motion: the formula contains a function of a master signal.
ƒ Multi-axis master-slave: several axes are slaved to the same master.
ƒ Multi-channel following: the master is defined as a sum of two signals. For example, one
signal supplies the desired position and the second introduces correction.
The controller supports two modes of following:
ƒ Velocity lock
ƒ Position lock
In velocity lock the slave reproduces the velocity of the master. The position of the slave follows
the master with an offset. As long as the slave is synchronized with the master, the offset remains
constant. In this mode the absolute value of the master is ignored. The slave reproduces only
incremental changes of the master value.
In position lock the slave follows the absolute position of the master. Even if the velocities of the
master and slave are the same, the motion is not considered synchronous until the slave position is
equal to the master value.
For more information about master-slave motion, see Section 6.6.

3.4.5. Physical Aspects of Motion

The above discussion creates the impression that the motion is purely a logical process – a
sophisticated sequence of calculations that results in changing APOS and other controller
variables. This is true to some extent; the controller can execute a motion without any actual
physical motion taking place (a virtual motion). In the Simulator (SPiiPlus MMI User’s Guide)
this is the only possible form of motion.
However, the purpose of the controller is physical motion. FIGURE 3-5 summarizes what
happens after the controller has calculated APOS. This section describes the operations in more
detail.

3.4.5.1. Transforming Axis Position (APOS) to Reference Position (RPOS)

The variables MPOS and APOS (as well as GPATH, GVEL, etc… mentioned above) belong in
the realm of logical motion and logical axes, while the variables RPOS (reference position) and
FPOS (feedback position) relate to physical motors. The connection between the two groups of
variables is provided by the connect formula.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-23

At power-up the controller establishes default connection between RPOS and APOS. By default
connection the controller in each controller cycle assigns value of APOS to RPOS that
corresponds to the result of command connect RPOS = APOS. In many applications, this default
connection is appropriate. When working with the default connection, the user can ignore the
difference between the logical axes and the physical motors, and changing APOS directly causes
motion of the motor.
The user can modify the connection between APOS and RPOS by using the connect command.
In most applications, the connect command is executed once for each motor, normally as part of
the AUTOEXEC execution. Listed below are some of the tasks that can be resolved using the
appropriate CONNECT formulae:
ƒ Introduce a gear ratio between the logical axis and the physical motor.
ƒ Compensate for encoder errors and backlash.
ƒ Compensate for non-orthogonality of the machine slides.
ƒ Compensate for undesired mutual interference between machine coordinates.
ƒ Define the physical motion as a sum of a logical motion and a compensating signal.
ƒ Define the physical motion as a sum of two or more logical motions.
ƒ Inverse kinematics, such as programming in Cartesian coordinates the machine that actually
has a polar kinematics.

3.4.5.2. Two Motor States

Changing an element of RPOS causes the motor to move only if the motor is enabled. The
controller distinguishes between the two states of a motor: enabled and disabled.
The commands enable and disable transfer the motor from one state to another. At power-up all
motors are disabled. The controller never transfers a motor automatically from disabled to enabled
state. Only the enable command can enable a motor. The transfer from enabled to disabled state
can be the result of a disable command or the result of an automatic response to a detected fault
(see Safety Inputs page 3-14).
While a motor is disabled, the controller does not execute the close loop control algorithm, the
drive command output signals are set to zero, and the Drive Enable signal is set to non-active
state. The controller continuously processes the motor’s position feedback. While a motor is
disabled (F_POS=R_POS), the controller assigns FPOS to RPOS and the position error is
considered zero.
The controller starts calculating RPOS according to the connection formula. Before this, the
controller shifts APOS so that no jump occurs in the RPOS value and in the physical position of
the motor. While a motor is enabled, the controller executes the close loop control algorithm,
generates the required commands to the drive and enables the drive. Any change of the RPOS
value causes the motor move, so that the FPOS follows the RPOS closely. The position error
variable PE displays the difference between RPOS and FPOS.

3.4.5.3. User Units

The units of the variables MPOS, APOS, RPOS, FPOS, as well as other motion-related
variables, are user units. The units of the corresponding variables in the SPii control algorithm are

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-24 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

encoder counts. The controller automatically makes all necessary transforms. The user only needs
to configure the EFAC value for each axis, to set the units used for the application.

3.4.6. Motion State Variables

The variables, AST (Axis State) and MST (Motor State) provide information about the currently
executed motion. AST provides information about the logical motion and MST about the physical
motion of the motor.
Both variables are arrays of eight elements. Each element of MST reflects the state of the
corresponding motor. Each element of AST reflects the state of the motion of the corresponding
axis. Each element of MST is always meaningful and is updated each controller cycle. An
element of AST is updated only if the corresponding axis is a single axis or a leading axis in an
axis group. The AST element is not updated for axes that are not leading axes in an axis group.
Both variables are bit-mapped. Each bit is on or off depending on the corresponding state.
The AST variable contains the following bit assignments:
Bit name No. Description
#LEAD 0 The bit is set if the axis is leading in a group
#PEG 2 The bit is set when PEG is in progress
#DC 3 The bit is set while the axis data collection is in progress
#MOVE 5 The bit is set while the axis is involved in a motion
#ACC 6 Accelerating
#BUILDUP 7 Segments build-up
#VELLOCK 8 The bit raised when the slave is synchronized to master in
velocity lock mode. While the bit is raised the slave velocity
strictly follows the master velocity.
#POSLOCK 9 The bit is raised when the slave is synchronized to master in
position lock mode. While the bit is raised the slave position
follows strictly the master position.

The MST variable contains the following bits:

Bit name No. Description
#ENABLED 0 The bit is set when the motor is enabled.
#OPEN 1 The bit is set when the motor is operating with open loop control.
#INPOS 4 The bit is set when the motor has reached a target position.
Setting of this bit is controlled by variables TARGRAD and
SETTLE.
#MOVE 5 The bit is set when the motor is moving.
#ACC 6 The bit is set when the motor is accelerating.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-25

In the left column of each table a bit constant is specified that can be used to address the required
bit in an ACSPL+ command. For example, the following command can be used to wait for the
end of the X-axis motion:
till ^X_AST.#MOVE Wait until the X axis finishes its motion

The following command waits until the T motor reaches the target point:
till T_MST.#INPOS Wait until the T motor reaches the target point

Both the AST and MST include similar bits #MOVE and #ACC. However, the meaning of the
bits may be different. Obviously, if the application defines a sophisticated connect formula, the
motor may move while the corresponding axis is not moving. However, even with the default
connection when the RPOS element simply follows the APOS element, the #MOVE bits may be
different. The #MOVE bit in AST reflects the state of a logical motion and drops to zero
immediately after the motion end. The #MOVE bit in MST drops to zero only when the motor is
not moving and the #INPOS condition is satisfied. Usually, the #MOVE bit in MST indicates the
end of motion later than the #MOVE bit in AST.
See also the reference for AST (page 11-17) and MST (page 11-48).

3.4.7. Motion Sequencing

This section describes the concurrency and synchronization of ACSPL+ programs and motion
execution. In this section, all commands are assumed to be executed as a part of an ACSPL+
program located in a program buffer. Immediate execution is discussed at the end of the section.

3.4.7.1. Concurrency of Program and Motion

A motion is planned by a motion command like ptp or slave. Actual motion may or may not start
immediately.
The following part of a program implements a reciprocated motion of the X motor between points
±1000:
local int Targ Declare local variable Targ

Targ = 1000 Initialize Targ to 1000

ST: Label

ptp X,Targ Move to point 1000 or –1000

Targ = -Targ Prepare Targ for the next cycle

goto ST Repeat
Let’s see what happens on each cycle when the ptp command is executed.
When the ptp command is executed for the first time, motion towards point +1000 is generated. If
the motor is enabled and not moving, the motion starts immediately (in the next controller cycle).
The command does not delay the program, therefore the execution of the command takes one

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-26 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

controller cycle. The motion continues in parallel with program execution. The controller
executes the assignment of Targ, then the goto command, and then to the ptp command
The next ptp command activates the second motion towards point –1000. The first motion is not
yet finished, and the second motion does not start immediately. Instead, the motion is placed into
the motion queue waiting for the termination of the first motion. Like the first ptp command, the
second ptp command is not delayed, and execution takes one controller cycle.
The 3rd, 4th and 5th ptp commands proceed in the same way. In most cases, the first motion is still
in progress, and all activated motions are placed into the motion queue to be executed in turn. The
program continues without any delay.
This behavior changes when the motion queue is full (the motion queue capacity is four waiting
motions). The motion activated by the 6th ptp command cannot be placed into the motion queue if
the first move is still in progress. At this point the controller automatically delays execution of the
command. The program waits as long as the first motion is in progress. When the first motion
ends, the controller extracts the second motion from the motion queue and starts its execution.
The motion queue now has a place for another motion, and in the same cycle the controller
accomplishes execution of the 6th ptp command and places the 6th motion into the motion queue.
When executing the 7th and all subsequent ptp commands, the motion queue is likely to be full.
Therefore, the command execution is delayed until the end of a motion.
Note that the controller automatically manages synchronization of the program and motion
sequence, and no action is required from the user.

3.4.7.2. Motion Queues

In the previous example, motion was in the X-axis. What happens if, in parallel to the motion in
the X-axis a concurrent program in another buffer executes the same sequence for the Y axis?
Will the motion sequences for two axes interfere or delay one another?
The controller independently operates each axis. The controller supports an independent motion
queue for each axis. Several programs in several buffers can simultaneously operate different axes
without any interference. If, the application requires interaction between axes, the user can
provide it using global variables.
In multi-axis motion, the situation is more complicated. When the controller creates an axis group,
it destroys the motion queues for the involved individual axes and creates a new motion queue for
the group. Therefore, an axis group has a single motion queue. If at the moment of group creation
any of the destroyed queues has a non-finished motion, the controller delays creation of the group
until all motions of all involved axes are over.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 SP i i P l u s S of t w a r e A r c h i t e c t u re 3-27

Example:
ptp X,100 Move X to point 100

ptp XYZ,0,100,200 Move XYZ to point 0,100,200

Assuming that the X axis is not in a group and that the X motion queue is not full, the first ptp
command activates the motion and is executed without any delay. The following ptp requires
creation of XYZ axis group. The group cannot be created as long the X motion is in progress.
Therefore, the controller delays the program. Only when the X motion is over, does the controller
create the axis group, and activate the motion, allowing the program continues.

3.4.7.3. Immediate Execution of Motion Commands

When a motion command is not included in a program, but is received from a communication
channel, the controller executes the command immediately.
A terminal command never delays the execution of an ACSPL+ program. If the terminal
command cannot be executed immediately (if the motion queue is full for example), the controller
rejects the command and generates an error.

3.4.8. Changes On the Fly

Sometimes when a motion is already in progress, the application requires to change the motion
process. There are two possibilities:
ƒ Terminate the current motion prematurely and transfer smoothly to the next motion.
ƒ Change velocity and/or acceleration on the fly.

3.4.8.1. break command

The break command terminates the current motion immediately without any deceleration profile
and provides a smooth transition to the next motion.
For example, an application includes a camera that takes snapshots of the handler while in motion
and supplies a corrected value for the final motion coordinate. The following commands provide
the motion:
ptp X,1000 Activate motion to an interim point

till Correction_available Wait until the camera measurement is done

break X Interrupt the current motion

ptp X, Corrected_value Activate motion to the corrected point

Upon the break command, the controller does not build the deceleration profile for the first ptp
motion. Instead, the controller terminates the motion immediately and builds a smooth profile for
the next ptp motion.
Neither the first nor the second motion must necessarily be point to point (ptp) motion. Motions
of any type are compatible with the break command. However, if the break command is applied
to multi-axis motion, the following limitation must be taken into account: The break command

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

3-28 S Pi i Plu s S o f t w a r e A rc h i t e c t u r e

provides smooth transition to the next motion in terms of the motion profile. In the case of a
single-axis motion, this guaranties smoothness of motion. In case of multi-axis motion, this
guaranties the smoothness of the vector motion. If the interrupted and the interrupting motions
have different direction of vectors at the break time, there will be an abrupt change in an axis
velocity. Therefore, when applying the break command to a multi-axis motion, the user must
assure that the two motions to be tangent or nearly tangent to each other at the break point.
NOTE

The break command is not supported in path or master-slave motion.

3.4.8.2. Changing Velocity On the Fly

Another frequent requirement in motion control is changing the velocity on the fly.
Assigning a new value to the VEL variable sets the required velocity for the future motion
commands, but has no effect on the motions that are already in progress or are waiting in a motion
queue.
The imm command provides a convenient way to affect the motion in progress.
The command:
imm X_VEL = 20000 Assign X_VEL, change velocity in executed and
waiting motions
changes the X_VEL value and in the same time changes the required velocity in the currently
executed X-axis motion and in all motions waiting in the motion queue of X axis.
The controller starts changing the velocity immediately and provides a smooth transition to the
new velocity.

3.4.8.3. Changing Acceleration and Jerk On the Fly

The imm command can assign values not only to the VEL variable but also to variables ACC
(Acceleration), DEC (Deceleration), JERK (Jerk) and KDEC (Kill Deceleration). The imm
command assigns the new value to the specified variable and sets the new desired value to all
motions that are executed or waiting in the queue of the specified axis.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Ter m inal C o mman ds 4- 1

4. TERMINAL COMMANDS

4.1. Program Management Commands

4.1.1. General
Use program management commands to:
ƒ Open and close program buffers
ƒ Insert program lines in a buffer
ƒ Delete program lines in a buffer
ƒ List a full program or selected lines in a buffer
ƒ Search for specific a name in a buffer
ƒ Display information about standard and user variables
ƒ Compile or decompile a program
ƒ Start, stop, pause, resume a program
ƒ Debug a program
ƒ Check the integrity of firmware and user application
ƒ Display the real-time usage of the controller
Program management commands are executed immediately and cannot be part of a program.
They are usually issued through the Terminal.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 2 T e r min al C o mman d s

Program management commands start with the # character.

Examples:
#0L List the complete program in buffer 0.
#9L1,10 List lines 1 to 10 in buffer 9.
##L1 List the first lines in all buffers.
#1 Open buffer 1 for editing.
#1I5 Open buffer 1 for editing, set insert point before line 5.
# Close the open buffer.
#4D3 Delete line 3 in buffer 4.
#4D5,9 Delete lines 5 to 9 in buffer 4.
#3F/Lab Find the text "Lab" in buffer 3.
#6C Compile the program in buffer 6.
##C Compile the programs in all buffers.
#7X Execute the program in buffer 7.
#8X10 Execute the program in buffer 8, starting from line 10.
#9X/Start Execute the program in buffer 9, starting from label Start.
#7S Stop the program in buffer 7.
##S Stop all programs.
#8P Pause the program in buffer 8. The command #8X will resume
execution from the following command line.
#VS Display the list of standard variables.
#5V Display the list of user variables declared in the 5th buffer.
#IR Display Integrity Report.
#U Display real-time usage of the controller.

4.1.2. Command Structure

The general pattern of program management commands is:

#[buffer qualifier[command code[line qualifier]]]

With the exception of the commands for opening and closing a buffer (See next section), all
commands contain at least the prefix #, a buffer qualifier and a command code.
All components in a command must follow without space or other delimiters. If a line qualifier
contains two line numbers or label and number, they must be separated by a comma.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Ter m inal C o mman ds 4- 3

4.1.2.1. Opening And Closing Buffers

Use the command:

#[buffer number]
to open a buffer, and the command:

#
to close the buffer.

4.1.2.2. Buffer Qualifier

Buffer qualifiers are specified in two forms:
ƒ An integer number that addresses a specific buffer or
ƒ The character # that addresses all program buffers in one command
The controller contains 10 program buffers numbered from 0 to 9. Use an integer buffer qualifier
to address a specific buffer. For example:
#9L1 List the first line in buffer 9.
Character # as a buffer qualifier specifies all buffers. Several commands can be addressed to all
buffers in one command. For example:
##L1 List the first line in all buffers.
Only the following commands can address all buffers:
L List
C Compile
S, SR Stop, Stop and Reset
P Pause
F, FI Find
BR Reset breakpoints
All other commands operate with one buffer only, and must specify the buffer number.

4.1.2.3. Command Code

Command code consists of one, two or three letters. The following codes are available:
L List
I Insert
D Delete
C Compile
X Execute
XS Execute one step
XD Execute in debug mode

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 4- 4 T e r min al C o mman d s

S Stop
SR Stop and reset
P Pause
F Find
FI Find (case insensitive)
BS Set breakpoint
BR Reset breakpoint
SI List system information
SC List safety system configuration
VS, VSF List Standard Variables
V, VF List User Variables
VSP List SP variables

4.1.2.4. Line Qualifier

A line qualifier can appear in one of four forms, as shown in the following table:

Line qualifier type Example Explanation

Single number #4L1 List the first line in buffer 4
Two numbers separated by #5L10,12 List lines 10 through 12 in buffer 5
comma
Label preceded by / (slash) #0L/start List the line that contains label start in buffer 0
character
Label preceded by / (slash) #9L/start,3 List three lines starting from label start in buffer 9
character, then comma and
number

The requirements for using a line qualifier depend on the command used.

Command Required Line Qualifier

L (List) Line qualifier is optional. If used, line qualifier can be
specified in any of four forms.
I (Insert) Line qualifier is optional. If used, qualifier can be
specified as a single number or label.
D (Delete) Line qualifier is required. Line qualifier can be specified
as a single number or two numbers separated by comma.
C (Compile) Do not use line qualifier.
X (Execute) Line qualifier is optional. If used, line qualifier can be

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Ter m inal C o mman ds 4- 5

specified as a single number or label.

XS (Execute one step) Line qualifier is optional. If used, line qualifier can be
specified as a single number or label.
XD (Execute, debug mode) Line qualifier is optional. If used, line qualifier can be
specified as a single number or label.
S (Stop) Do not use line qualifier.
SR (Stop and reset) Do not use line qualifier.
P (Pause) Do not use line qualifier.
F (Find) Line qualifier is required. Line qualifier can be specified
as a label or as a label followed by number.
FI (Find, case insensitive) Line qualifier is required. Line qualifier can be specified
as a label or as a label followed by number.
BS (Set breakpoint) Line qualifier is required. Line qualifier can be specified
as a single number or label.
BR (Reset breakpoint) Line qualifier is optional. If used, line qualifier can be
specified as a single number or label.

4.1.3. Program Listing

Use the L command to obtain a program listing. For dynamic buffers, the L command obtains the
current buffer contents at the time the command is issued.

4.1.3.1. Full Program Listing

Use the command
#"buffer number"L
To list the full program in the specified buffer.
The listing contains all program lines preceded by line numbers. Each line appears exactly as it
was inserted. No automatic formatting is provided.
Example:
Provide a program listing for buffer #3
#3L

1: MovePTP:
2: X_VEL = 20000
3: ptp X, 4000
4: till ^X_MST.#MOVE
5: stop

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 6 T e r min al C o mman d s

4.1.3.2. Partial Program Listing

When a line qualifier is added to the L command, it provides partial listing of the program.
The line qualifier can be:
ƒ A single number, specifying one specific line
ƒ Two numbers, specifying a range of lines. If the second number is larger than a total number
of lines in the program, the list range spans the last program line
ƒ A label, specifying the line that contains the label
ƒ A label followed by a number, specifying a range of lines starting from the label
Examples:
List line 4 in buffer 3:
#3L4

4: till ^X_MST.#MOVE
List lines from 1 to 3 inclusively in buffer 5
#5L1,3

1: movePTP:
2: X_VEL = 20000
3: ptp X, 4000
List the line that contains the label MovePTP in buffer 5:
#5L/MovePTP

1: movePTP:
List 3 lines, starting from the label movePTP in buffer 5:
#5L/MovePTP, 3

1: movePTP:
2: X_VEL = 20000
3: ptp X, 4000

4.1.3.3. Listing All Buffers

To address all buffers use the # character instead of the buffer number in the list command. For
example, the command ##L provides a listing of all programs in all buffers.
List commands that address all buffers can contain any line qualifier.
For example, the following command lists the first line in each buffer. If the buffer does not
contain the specified line number, the buffer number only is listed:
: ##L1

Buffer 0
Buffer 1

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Ter m inal C o mman ds 4- 7

1: ! Homing of all axes

Buffer 2
1: ! Registration motion
Buffer 3
1: MovePTP:
Buffer 4
1: ! PLC program
Buffer 5
Buffer 6
Buffer 7
Buffer 8
Buffer 9

Note
It is recommended to place a remark with a short program description in the
first line of each your programs. This allows you to use the command ##L1
to get quick information about all loaded programs.

4.1.4. Editing a Program in a Buffer

NOTE While the terminal command set supports editing in a buffer, it is more
convenient and recommended to use the editing features of the SPiiPlus
Tools, specifically the Program Manager feature of the SPiiPlus MMI
or the SPiiPlus MultiDebugger.

4.1.4.1. Opening and Closing a Buffer

Before a program line can be inserted in a buffer, the buffer must be open by the Open or Insert
command. When a buffer is open, the controller prompt shows the buffer number and the insert
line number. For example:
3:00006> Buffer 3 is open, insert line is 6.
The Open command opens the buffer and sets the insert line as follows:
ƒ If the buffer is empty, the insert line is 1.
ƒ If the buffer already contains a program, the insert line is set after the last line of the
program.
The Insert command without a line qualifier operates exactly as the Open command. If a line
qualifier is specified, the Insert command opens the buffer and sets the insert line before the line
defined by the line qualifier. If the line number specified in the line qualifier is larger than the
total number of lines in the program, the insert line is set after the last program line.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 8 T e r min al C o mman d s

The # character without buffer qualifier closes the open buffer.

Examples:
#0 Open buffer 0
0:00001> Buffer 0 is empty
#3 Open buffer 3
3:00006> Buffer 3 contains 5 lines. The insert line is set
to 6.
#3I

3:00006> The command does not specifies a line

qualifier. It is identical to the command #3
#3I2

3:00002> Insert line is set before line 2

# Close the buffer
: The prompt indicates that all buffers are closed

4.1.4.2. Inserting Program Lines

When a program buffer is open, ACSPL+ commands are stored in the buffer (and are not
executed immediately).
Terminal commands that start with # or ?, are not stored in the buffer even if the buffer is open,
but are executed immediately.
The controller checks the syntax of inserted ACSPL+ lines and any immediately reports any
errors detected.
Example of an editing session:
#0 Open buffer 0
0:00001> Buffer 0 is empty
X_VEL = 20000 NOTE: Enter the program lines sequentially. After
each line the insert line number is incremented
0:00002>
ptp X, 4000
0:00003>
till ^X_MST.#MOVE
0:00004>
stop
0:00005>
#0L List the program

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Ter m inal C o mman ds 4- 9

1: X_VEL = 20000
2: ptp X, 4000
3: till ^X_MST.#MOVE
4: stop
0:0005> The buffer remains open
#0I1 Change the insert line number to 1
0:0001> Insert line is set before the first line
MovePTP: Insert label
0:0002>
#0L List the program
1: MovePTP:
2: X_VEL = 20000
3: ptp X, 4000
4: till ^X_MST.#MOVE
5: stop
0:0002> The buffer remains open
# Close the buffer
: The prompt indicates that all buffers are closed

4.1.4.3. Deleting Lines

The Delete command deletes the specified lines in the buffer.
A line qualifier in the Delete command is obligatory. The line qualifier can be:
ƒ A single number, specifying one specific line or
ƒ Two numbers separated by comma that specify a range of lines. If the second number is
larger than a total number of lines in the program, the delete range includes the last program
line.
If a buffer is open, the Delete command that addresses the buffer shifts the insert line to before the
first undeleted line.
Example:
#0L List buffer 0
1: MovePTP:
2: X_VEL = 20000
3: ptp X, 4000
4: till ^X_MST.#MOVE
5: stop

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 10 T e r min al C o mman d s

:
#0D3 Delete line 3 in buffer 0.
:
#0L List buffer 0
1: MovePTP:
2: X_VEL = 20000
3: till ^X_MST.#MOVE
4: stop
:
#0 Open buffer 0
0:0005>
#0D2,3 Delete lines 2-3 in buffer 0
0:0002> Insert point shifts to deleted lines
#0L List buffer 0
1: MovePTP:
2: stop
0:0002>

4.1.5. Search Commands

Use search commands to search for a specific text in a specified buffer or in all buffers.
The following commands are available:
F Case sensitive
FI Case insensitive
The line qualifier in search commands must be specified as a label or as a label and number
separated by comma. The label in the line qualifier is not limited to the existing labels in the
program, any name may be specified. Therefore, the commands can be used to search for any
variable, constant, label or keyword.
If the line qualifier contains a comma and a number, the number defines the start line for the
search. Otherwise, the search starts from the first line.
The search terminates when the first entry of the specified text is found, or the buffer end is
reached. The command reports the line that contains the text, or an error message if the text was
not found.
To find the next entry, the user must execute the command again, specifying the new start line
number of the reported line plus one.
If the # character is specified instead of the buffer number, the search command addresses all
buffers. In this case the command finds the first entry in each buffer.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-11

Examples:
#0L List buffer 0
1: MovePTP:
2: X_VEL = 20000
3: ptp X, 4000
4: till ^X_MST.#MOVE
5: stop
:
#0F/X Find X in buffer 0
0002 First entry in line 2
:
#0F/X,3 Find the next entry
0003 Next entry in line 3
:
#0F/X,4 Find the next entry
0004 Next entry in line 4
:
#0F/X,5 Find the next entry
?1078 No more entries
:
##F/MovePTP Find MovePTP in all buffers
Buffer 0: No matches
Buffer 1: No matches
Buffer 2: No matches
Buffer 3: 0001 Entry is found in line 1
Buffer 4: No matches
Buffer 5: No matches
Buffer 6: No matches
Buffer 7: No matches
Buffer 8: No matches
Buffer 9: No matches
:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 12 T e r min al C o mman d s

4.1.6. Variable Listing

ƒ Use the VS or VSF command to obtain a list of standard variables.
ƒ Use the V or VF command to obtain a list of user variables.
ƒ Use the VSP command to obtain a list of SP variables.

4.1.6.1. List of Standard Variables

Use the command
#VS
to list all standard variables in the controller. Only the names of the variables are printed.
Use the command
#VSF
to list all standard variables in the controller along with the variable information. In addition to a
variable name the printout contains the variable type, the number of elements (for array only),
address of the variable in the controller memory and the step between array elements (for array
only).
Example:
Provide a list of standard variable names:
#VS

ACC
AERR
AFLAGS
AIN
… and so on
Provide a list of standard variable names with additional information:
#VSF

ACC real(8) @00D0F810,8

AERR int(8) @004B14B4,4
AFLAGS int(8) @00D0FCD8,4
AIN int(8) @004A57B0,4
… and so on

4.1.6.2. List of User Variables

Use the command
#"buffer number"V

to list the user variables declared in the specified buffer.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-13

Use the command

#V

to list the user variables declared in all buffers.

Use the command
#"buffer number"V or #VF or VF

to print additional information about user variables. Additional information includes the variable
type, the dimension (for array only) and the address of the variable in the controller memory.
Example:
Provide a list of user variables in buffer 9:
#9V

ITIME Global
TS_AMP1 Local
TS_AMP0 Global
Provide a list of user variables in buffer 9 with additional information:
#9VF

ITIME Global real @00DA0C50

TS_AMP1 Local int @00DA1A30
TS_AMP0 Global int @00DA0C80

4.1.6.3. List of SP variables

The command

#VSPn
where n is an SP number, provides a list of SP variables that are defined in the program in the
specified SP. Each variable name in the list is accompanied by an SP address of the variable.
For example:
#VSP0 List the variables in SP 0
X_I_RMS_SUML @089 Variable X_I_RMS_SUML resides in SP address 089
X_I_RMS_SUMH @08a Variable X_I_RMS_SUMH resides in SP address 08a
A_I_RMS_SUML @08b Variable A_I_RMS_SUML resides in SP address 08b
A_I_RMS_SUMH @08c Variable A_I_RMS_SUMH resides in SP address 08c
X_OPEN_L @08d Variable X_OPEN_L resides in SP address 08d
A_OPEN_L @08e Variable A_OPEN_L resides in SP address 08e
X_FN_SW @08f Variable X_FN_SW resides in SP address 08f
A_FN_SW @090 Variable A_FN_SW resides in SP address 090

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 14 T e r min al C o mman d s

X_NOTCH_ENC_AMP @091 Variable X_NOTCH_ENC_AMP resides in SP address 091

A_NOTCH_ENC_AMP @092 Variable A_NOTCH_ENC_AMP resides in SP address 092

4.1.7. Execution Control

4.1.7.1. Program Buffer States

The following diagram shows the program buffer states and the terminal commands that affect the
states:

#P

#X
Run Suspended

#S

#X
#X #S
#SR

#SR

Not Compiled
#C
compiled

#SR

FIGURE 4-1 Interaction of program buffer states

The program buffer enters the Not Compiled state:
• After any change in the program text
• Following execution of the SR Command (Stop and Reset)
The program buffer enters the Compiled state:
• Following execution of the C Command (Compile) the program buffer is transferred from Not
Compiled to Compiled state.
• Command S (Stop) transfers the program buffer from Run or Suspended state to Compiled
state.
• Following program termination with ACSPL+ command stop (or ret if autoroutine was
executed).
• When the program fails due to an error
The program buffer enters the Run state:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-15

• When command X is executed.

• When another program executes a start command, or autoroutine condition is satisfied.
The program buffer enters the Suspended state:
ƒ When the P (Pause) Command is executed
ƒ When ACSPL+ command pause is executed
ƒ When a breakpoint in the program is encountered.

4.1.7.2. Compile
The C command compiles a program in the buffer or all programs in all buffers, depending on the
qualifier. If the buffer qualifier is specified as the # character instead of the buffer number, the
Compile command compiles all programs in all buffers.
The Compile command must not include a line qualifier and is prohibited when the buffer is in
Run or Suspended states.
The Compile command is not obligatory in order to execute a program. When the X (Execute)
command is issued, the controller automatically compiles the program if it was not previously
compiled. However, a separate compilation step is required in the following cases:
ƒ The user desires to check program correctness without execution.
ƒ The program is not intended for direct start, but contains autoroutines. The autoroutines are
ready for execution only after compilation.
ƒ The program is intended for starting from another program by the start command. The
program started by the start command must be compiled before the start command can be
executed.
If the program is successfully compiled, the controller prints a short report of how many lines
were compiled. If an error was encountered, the controller reports the error code and the line
number in which the error was found.
Examples:
#0C Compile the program in buffer 0
5 lines compiled The program was compiled successfully
:
#9C Compile the program in buffer 9
?2026 in line 16 Error 2026 was found in line 16
:
??2026 Explain error 2026.
Undefined variable name
##C Compile the programs in all buffers
Buffer 0: 5 lines compiled The program was compiled successfully
Buffer 1: 18 lines compiled The program was compiled successfully

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 16 T e r min al C o mman d s

Buffer 2: empty The buffer is empty

Buffer 3: 5 lines compiled The program was compiled successfully
Buffer 4: empty The buffer is empty
Buffer 5: empty The buffer is empty
Buffer 6: empty The buffer is empty
Buffer 7: empty The buffer is empty
Buffer 8: empty The buffer is empty
Buffer 9: ?2026 in line 16 Error 2026 was found in line 16
:

4.1.7.3. Execute
The Execute command X starts a program in a specific buffer, and can be executed in any
program state except the Run state
The buffer qualifier in the command must specify one buffer only.
The line qualifier in the command can be a line number or a label. Execution starts from the
specified line. The line qualifier is optional. If the line qualifier is omitted, the program starts from
the first line.
If the state of the program is Not Compiled, the controller first compiles the program and then
starts it. If an error was encountered during compilation, the program does not start.
If the state of the program is Suspended, the X command resumes the program execution. In this
case the command must not contain line qualifier because execution resumes from the point where
the program was suspended.
Examples:
#1X Execute the program in buffer 1
:
?1 Query status of buffer 1
Buffer 1: 18 lines, running at line 7
:

4.1.7.4. Stop
There are two commands that terminate program execution:
ƒ S - Stop
ƒ SR - Stop and Reset
The Stop command S terminates program execution in a buffer or execution of all programs in all
buffers.
The Stop and Reset command SR terminates program execution in a buffer or execution of all
programs in all buffers, and resets the buffer or all buffers to the Not Compiled state.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-17

Use the buffer qualifier # to stop all programs in all buffers.

Stop commands must not include line qualifier.
Stop commands are allowed in any program state.
The SR (Stop and Reset) command provides the de-compile function, which is useful if the
program contains autoroutines that are ready to start when the buffer is in Compiled state. By
issuing the SR command, the user effectively prevents the activation of autoroutines.
Examples:
#1S Terminate the program in buffer 1
:
?1 Query status of buffer 1
Buffer 1: 18 lines, terminated in line 7
:
#1SR Reset the program in buffer 1
:
?1 Query status of buffer 1
Buffer 1: 18 lines, not compiled
:
##SR Reset all programs in all buffers
:

4.1.7.5. Pause
The Pause command P suspends program execution in a buffer or, if preceded by the # character
instead of a buffer number, the execution of all programs in all buffers.
Pause commands must not include a line qualifier.
Pause commands are allowed in any program state, but in all states other than Run the command
has no effect.
If the program is in Suspended state, the X (Execute) command resumes execution. The S (Stop)
command transfers the buffer to Compiled state. The SR (Stop and Reset) command transfers the
buffer to Not Compiled state.
Examples:
#1P Suspend the program in buffer 1
:
?1 Query status of buffer 1
Buffer 1: 18 lines, suspended in line 7
:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 18 T e r min al C o mman d s

#1SR Reset the program in buffer 1

:
?1 Query status of buffer 1
Buffer 1: 18 lines, not compiled
:
##P Suspend all programs in all buffers
:

4.1.7.6. Debug commands

The SPiiPlus MultiDebugger incorporates all necessary operations and provides you with an
integrated environment that completely supports the debugging process. You will therefore rarely
need to directly use the Debug commands described below
The following debug commands are supported:
XS (Execute one step) Execute one program line.
After executing one line, the buffer automatically moves
to Suspended state.

XD (Execute in debug mode) Execute the program up to the next breakpoint.

The command is similar to the X command. The
difference is that the X command ignores breakpoints in
the program. If the program is started by the XD
command, it will stop when it reaches a breakpoint. At
breakpoint the program transfers to a suspended state and
can be started again by the X, XS, or XD commands.

BS (Set breakpoint) Set a breakpoint at the specified line.

Any number of breakpoints can be set in a program.
For breakpoints to be active, the program must be started
with the XD command.
In program listing the, lines with breakpoint are indicated
by an asterisk.

BR (Reset breakpoint) Reset breakpoint at the specified line or all breakpoints.

If the line qualifier specifies a line, the command resets
one breakpoint at this line.
If the line qualifier is omitted, the command resets all
breakpoints in the buffer.
If the buffer qualifier is specified as # and the line

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-19

qualifier is omitted, the command resets all breakpoints in

all buffers.
Example:
#0L List buffer 0
1: MovePTP:
2: X_VEL = 20000
3: ptp X, 4000
4: till ^X_MST.#MOVE
5: stop
:
#0BS3 Set breakpoint at line 3
:
#0L List buffer 0 – asterisk indicates the breakpoint
1: MovePTP:
2: X_VEL = 20000
3:*ptp X, 4000
4: till ^X_MST.#MOVE
5: stop
:
#0XD Execute the program in debug mode
:
?0 Query buffer state
Buffer 0: 5 lines, suspended in line 3
:
#0XS Execute line 3
:
?0 Query buffer state
Buffer 0: 5 lines, suspended in line 4
:
#0XD Execute the rest of the program
:
?0 Query buffer state
Buffer 0: 5 lines, terminated in line 5

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 20 T e r min al C o mman d s

4.1.8. Integrity Control

Integrity Control validates the firmware and the user application stored in the controller.
The following groups of files are stored in the internal file system of the nonvolatile memory:
ƒ Firmware: files SB4.EXE, SB4.BIN, SBAUTO.BT
ƒ Default configuration values: files PAR.### and PARn.### , where n = 0,1…
ƒ Default ACSPL+ programs: files ACSPLnn.###, where nn = 00,01,02…
ƒ Default SP programs: files DSP.### and/or DSPn.###, where n = 0,1…
ƒ Saved configuration values: files PAR.$$$ and PARn.$$$ , where n = 0,1…
ƒ Saved ACSPL+ programs: files ACSPLnn.$$$, where nn = 00,01,02…
ƒ Saved SP programs: files DSP.$$$ and/or DSPn.$$$, where n = 0,1…
Firmware and the default files present in the controller from the beginning and can be replaced
only by the Version Changer of SPiiPlus MMI (see the SPiiPlus MMI User’s Guide).
The saved files compose the user application. Saved files are created or replaced by the memory
management commands (See Section 4.3).
Integrity Control is active for the all files specified above. The controller stores the size and
checksum of each file, existing or created. The controller then compares the stored size/checksum
with size/checksum of the actual file to expose damaged files. Validation is performed
automatically on power-up. Use the #IR command to validate files after power-up (See below)

4.1.8.1. Integrity Violation Fault

The bit of the Integrity Violation fault resides in variable S_FAULT, and can be addressed as
S_FAULT.#INTGR or S_FAULT.30.
The fault has no default response. The masks S_FMASK and S_FDEF do not affect processing
of the bit.
The controller automatically validates integrity on power-up before loading the user application.
Therefore, the user is able to define AUTOEXEC program that checks the Integrity Violation
fault and reports the error as required.

4.1.8.2. Integrity Report Command

The terminal command #IR activates integrity validation and provides a report of current integrity
state.
If any integrity problem is detected, the command raises fault bit S_FAULT.#INTGR.
The report displays a list of files. Each list entry displays a file name, expected file size and
checksum of the file and actual file size and checksum. The following is an example of an
integrity report:
#IR

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-21

Size Checksum
Registered Actual Registered Actual
c:\
sb4.exe 0009C270 0009C270 1D3E468E 1D3E468E
sb4.bin 000057D4 000057D4 D71BE07B D71BE07B
c:\sb4\dsp
dsp.### 000017EC 000017EC 97E015CF 97E015CF
c:\sb4\startup
par.### 0000048F 0000048F A7EF3712 A7EF3712
System Integrity is OK
:

4.1.9. Report of Real-Time Usage (#U)

The #U command provides a report of Real Time Usage. The controller continuously measures
the time taken by real-time tasks (For an explanation of real-time tasks see .)
When the #U command is received, the controller analyzes the measured times during the last 50
controller cycles and calculates minimal, maximal and average time. The results are reported in
percents.

4.1.10. Application Protection (#PROTECT, #UNPROTECT)

The following terminal commands switch between protected mode and configuration mode:
#PROTECT
#UNPROTECT
The #PROTECT command applies application protection (puts the controller in protected mode).
The #UNPROTECT command disables application protection (returns the controller to
configuration mode).
For a description of application protection, see Section 5-121.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 22 T e r min al C o mman d s

4.1.11. Report Safety Configuration (#SC)

The command #SC reports the current safety system configuration.
The controller response includes the following:
• active safety groups
• the configuration of each fault for each motor
For example:

#SC

Safety Group(s): XZT

Bit Code Fault X Y Z T A B C D

0 #RL Right Limit K K K K K K K K

1 #LL Left Limit K K K K K K K K

5 #SRL Software Right Limit K K K K K K K K

6 #SLL Software Left Limit K K K K K K K K

7 #ENCNC Encoder Not Connected D D D D D D D D

8 #ENC2NC Encoder2 Not Connected - - - - - - - -

9 #DRIVE Drive Alarm KD+ KD+ KD+ KD+ KD+ KD+ KD+ KD+

10 #ENC Encoder Error D D D D D D D D

11 #ENC2 Encoder 2 Error - - - - - - - -

12 #PE Position Error

13 #CPE Critical Position KD+ KD+ KD+ KD+ KD+ KD+ KD+ KD+
Error

14 #VL Velocity Limit K K K K K K K K

15 #AL Acceleration Limit K K K K K K K K

16 #CL Overcurrent KD+ KD+ KD+ KD+ KD+ KD+ KD+ KD+

17 #SP Servo Processor Alarm D D D D D D D D

25 #PROG Program Error K K K K K K K K

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-23

26 #MEM Memory Overuse

27 #TIME Time Overuse

28 #ES Emergency Stop KD KD KD KD KD KD KD KD

29 #INT Servo Interrupt D D D D D D D D

30 #INTGR Integrity Violation D D D D D D D D

The following designations are used in the report:

---: fault detection is disabled (FMASK=0)
(blank): fault response is disabled (FDEF=0) or no default response is defined
K: response is kill
D: response is disable
KD: response is kill-disable
+: generalized fault

4.2. Query Commands

4.2.1. General
Use query commands to obtain information from the controller. Query com mands start with the ?
character and are followed by one or more query specifications. Query commands are executed
immediately and cannot be part of a program. They are usually issued through the Terminal (For
additional information about the Terminal see the SPiiPlus MultiDebugger User’s Guide).
The following data may be addressed by a query command:
ƒ Status of a program buffer
ƒ Status of an axis and motor
ƒ Value of a standard variable
ƒ Value of a standard state or flag variable
ƒ Value of a user global variable
ƒ Value of a user local variable
ƒ One element, range of elements, or all elements of standard array, user global array or user
local array
Examples:
?VR Display the version number of the controller.

?SN Display the serial number of the controller.

?3 Display the status of buffer 3.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 24 T e r min al C o mman d s

?# Display the status of all buffers.

?X Display the status of axis X and motor X.

?$ Display the status of all motors.

?% Display the status of all axes.

?X_FPOS Display the current position of motor X.

?FPOS(0) Display the current position of motor X. Identical to the previous

query. Axes can also be referenced by numbers.
?FPOS Display the current position of all motors.

?FPOS,RPOS Display the current position of all motors and reference value of all
axes.
?Var Display the value of user global variable Var. The variable may be
of either integer or real type, and may be either scalar or array.
?5:Var Display the value of local user variable Var in buffer 5. The variable
may be of either integer or real type, and may be either scalar or
array. A user variable must be declared in a program and the
program must be compiled.
? Repeat the last executed query command

A query command may contain several query specifications in one line, separated by comma or
space. For example, the command
?FPOS, RPOS

is equivalent to the two sequential commands

?FPOS

and
?RPOS

The only exception to this format is that the multiple status queries ?#, ?$ and ?% must appear in
separate lines.

4.2.2. Query of Controller Version And Serial Number

Query ?VR reads the controller version number. The number appears in format
DD.DD-DDa
where D stands for any digit and a stands for any low-case letter.
Query ?SN reads the controller serial number. The number is factory assigned, and is unique for
each controller.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-25

4.2.3. Query of Program Status

Program status query consists of a query sign and one or more program buffer numbers.
To obtain a status report for all program buffers use command ?#.
The buffer status report contains the following information:
ƒ Number of program lines stored in the buffer
ƒ State of the program: compiled, not compiled, running, terminated
ƒ Current executed line of the running program
ƒ Reason for termination, if applicable
ƒ Line of termination, if applicable
Examples:
: ?1 What is the status of buffer 1?
Buffer 1: 106 lines, not compiled
: ?1, 2, 3 What is the status of buffers 1, 2
and 3?
Buffer 1: 106 lines, not compiled
Buffer 2: 192 lines, running in line 153
Buffer 3: 85 lines, terminated in line 48, error code 123
: ?# What is the status of all the buffers?
Buffer 0: empty
Buffer 1: 106 lines, not compiled
Buffer 2: 192 lines, running in line 89
Buffer 3: 85 lines, terminated in line 48, error code 123
Buffer 4: 378 lines, terminated in line 227
Buffer 5: 8 lines, compiled, not running
Buffer 6: empty
Buffer 7: empty
Buffer 8: empty
Buffer 9: empty

4.2.4. Query of Motor And Axis Status

Motor and axis status query consists of a query sign and one or more motor designations (lower
case) or axis designations (upper case). Motor and axis status query are not case sensitive,
therefore, as a response to motor or axis query the controller provides both motor and axis status
(See Chapter 4: Software Overview for a discussion of motors and axes).

4.2.4.1. Motor Status

Each motor status report normally consists of one line. However, if there is one or more
exceptions reported by the motor a second line is added.
The first line provides the following information:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 26 T e r min al C o mman d s

ƒ Is the motor enabled or disabled

ƒ The reason why the motor is disabled (if applicable)
ƒ Is the motor moving
ƒ Is the motor accelerating or decelerating
ƒ Is the motor in position (which means the motor is not moving and is within specified
envelope from the target point)
A second line is added only if one or more faults are activated for the reported motor. If several
exceptions are activated, the line specifies all them.
The command:
?$

queries the status of all motors, but not axes.

4.2.4.2. Axis Status

Axis status displays the following information:
ƒ Is the axis is included in an axis group
ƒ Is the axis is involved in a motion.
ƒ The termination code of the last executed motion (if applicable)
The command
?%

queries the status of all axes (but not motors).

4.2.4.3. Examples of Motor And Axis Queries:

: ?X What is the status
of motor x and axis
X?
Motor x: enabled, idle, in position
Axis X: not in group, idle

: ?Z What is the status

of motor z and axis
Z?
Motor z: enabled, moving, not accelerating, not in position
Axis Z: in group TZ, in Segmented motion

: ?X, Z What is the status

of motor z and x,
and axis Z and X?
Motor x: enabled, idle, in position

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-27

Axis X: not in group, idle

Motor z: enabled, moving, not accelerating, not in position
Axis Z: in group TZ, in Segmented motion
: ?$ What is the status
of all the motors?
Motor x: enabled, idle, in position
Motor y: enabled, idle, not in position
Exceptions:
Right Limit.
Motor z: enabled, moving, not accelerating, not in position
Motor t: enabled, moving, not accelerating, not in position
Motor a: disabled
Motor b: disabled
Motor c: disabled
Motor d: disabled
: ?% What is the status
of all the axes?
Axis X: not in group, idle
Axis Y: not in group, idle
Axis Z: in group TZ, in Segmented motion
Axis T: in group TZ, in Segmented motion
Axis A: not in group, idle
Axis B: not in group, idle
Axis C: not in group, idle
Axis D: not in group, idle

4.2.5. Query of Standard Variables and Arrays

Use the query sign and one or more standard variable names to query standard variables.

4.2.5.1. Scalar Variables

The response to a query of scalar variable consists of one number. For example, the following
query displays the requested baud rate for serial communication:
: ?BAUD What is the baud rate?
115200

4.2.5.2. Querying Arrays

All elements, specific elements, or a range of elements in an array can be queried.

4.2.5.2.1. Querying All Elements in an Array

If a variable represents an array, query of the variable name without index displays all elements of
the array.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 28 T e r min al C o mman d s

For example, the following query displays the motor feedback for each axis:
: ?FPOS What is the feedback position of each of the motors?
1823 –8220 22900 1000 0 0 0 0
The standard variable V represents an array of 100 integer values. Query of V without indexes
reports the values of all array elements:
: ?V

0 2 4 6 8 10 12 14
16 18 20 22 24 26 28 30
32 34 36 38 40 42 44 46
48 50 52 54 56 58 60 62
64 66 68 70 72 74 76 78
80 82 84 86 88 90 92 94
96 98 100 102 104 106 108 110
112 114 116 118 120 122 124 126
128 130 132 134 136 138 140 142
144 146 148 150 152 154 156 158
160 162 164 166 168 170 172 174
176 178 180 182 184 186 188 190
192 194 196 198

4.2.5.2.2. Querying a Specific Element in an Array

One element of FPOS can be selected by axis specification or by indexing. Index can be specified
with or without brackets. All three possibilities are used in the following query that requests the
feedback position of X, Y and Z motors:
: ?X_FPOS, FPOS1, FPOS(2)

1823
-8220
22900
The following three queries, that request the feedback position of the X motor, are identical:
: ?X_FPOS, FPOS0, FPOS(0)

1823
1823
1823
One element of V can be queried with indexing:
: ?V(97)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-29

194

4.2.5.2.3. Querying a Range of Elements in an Array

The following query displays the motor feedback of Z and T axes:
: ?FPOS(2,3) What is the feedback position of axes Z and T?
22900 1000
The following query addresses a range of V elements from 10 to 20 inclusively:
: ?V(10,20)

20 22 24 26 28 30 32 34
36 38 40

4.2.5.3. Querying States and Flags

Each state and flag standard variable is a collection of bits. Each bit within the variable has its
own function. The variable is reported in a format that displays the state of each bit with a short
explanation. The variables that are reported in this format are:
AFLAGS Axis Flags See page 11-16
AST Axis State See page 11-17
FAULT Faults See page 11-30
FDEF Fault Default Response Mask See page 11-30
FMASK Fault Mask See page 11-31
S_FAULT System Faults See page 11-53
S_FDEF System Fault Default Response Mask See page 11-53
S_FMASK System Fault Mask See page 11-55
S_FLAGS System Flags See page 11-54
S_ST System State See page 11-56
COMMFL Communication I/O Flags See page 11-19
MFLAGS Motor Flags See page 11-45
IMASK Index Mask See page 11-38
IST Index State See page 11-41
MST Motor State See page 11-48

Note
The data reported by Axis and Motor status queries, is a compressed
extraction from AST, MST and FAULT variables

For example:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 30 T e r min al C o mman d s

: ?X_MST What is the state of motor x?

0 ON Enabled
1 OFF Open Loop
4 ON In Position
5 OFF Moving
6 OFF Accelerating

The first column in the response contains the bit number in MST. Only the bits that have a
defined function are listed in the reply, in this example bits 0,4,5,6. The second column indicates
the state of each bit. The third column displays short explanation for each bit. In the example the x
motor is enabled, is located within target envelope from the desired position, is not moving and is
not accelerating.

4.2.5.4. Querying Inputs/Outputs

Digital inputs are represented by the standard variable IN. Digital outputs are represented by
standard variable OUT. Both input and output variables are reported in binary format:
: ?IN0 What is the status of
Input 0?
10111001,00011010,00000100,00000000

: ?OUT (0, 3) What is the status of bit 3

of Input 0?
10111001,00011010,00000100,00000000 00000000,00000000,
00000000,00000000
00000000,00000000,00000000,00000000 00000000,00000000,
00000000,00000000

4.2.6. Query of User Variable/Array

User-defined variables and arrays can also be queried.

4.2.6.1. Validity of User Variables

Unlike standard variables, a user variable is not always valid. Attempts to query an invalid
variable causes an error.
A user variable is valid only if the three following conditions are met:
ƒ The variable is explicitly declared in an ACSPL+ program
ƒ The program is inserted in one of program buffers
ƒ The program is compiled
If any of these conditions is not satisfied, the controller treats the variable name as unknown and
an error will be produced.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-31

4.2.6.2. Global Variables

Variables that are declared as global are common for all program buffers. As long as a global
variable is valid, it can be queried exactly like a standard variable.
Assuming that at least one compiled program includes the following definitions:
GLOBAL INT UserGlobInt, UserGlobArray(10)

GLOBAL REAL UserGlobReal

Then the following queries can be issued:

: ? UserGlobInt, UserGlobReal

1234
3.141
: ? UserGlobArray

15 1 9 154 227 3 41 213

0 14
: ? UserGlobArray(3), UserGlobArray(7)

154
213
: ? UserGlobArray (3, 7)

154 227 3 41 213

4.2.6.3. Local Variables

A local variable is valid only within the buffer where it is declared. Even if two buffers contain
similar declarations of a local variable, the declarations define two separate variables; each
localized in its buffer.
Query of a local variable must always specify the buffer that contains the variable.
Assuming that buffer 3 contains a program that declares the variable:
LOCAL INT UserLocInt

and that buffer 6 contains a program that declares the variables:

LOCAL REAL UserLocArray (20), UserLocReal

Both programs are compiled. The following queries are then issued:
: ? 3:UserLocInt, 6:UserLocReal What is the status of
variable UserLocInt in
buffer 3, and UserLocReal
in buffer 6?
3
114.7
: ? 6:UserLocArray What is the status of
variable UserLocArray in

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 32 T e r min al C o mman d s

buffer 6?
0.012 0.43 9.8 0.42 7.134 0 0 213.3
0 1.4
: ? 6:UserLocArray(3), 6:UserLocArray(7) What is the status of
element 3 of variable
UserLocArray in buffer 6,
and element 7 of variable
UserLoc Array in buffer
6?
0.42
213.3
: ? 6:UserLocArray (3, 7) What is the status of
elements 3 and 7 in
variable UserLocArray in
buffer 6?
0.42 7.134 0 0 213.3

4.2.6.4. Two-Dimensional Arrays

Two-dimensional arrays are queried in a similar way to one-dimensional arrays.
Assume buffer 5 contains a compiled program that declares the variable:
GLOBAL INT UserMatrix(3) (5)

The variable contains the following values:

11 12 13 14 15
21 22 23 24 25
31 32 33 34 35
Then the following query displays all elements of the array:
: ? UserMatrix

11 12 13 14 15
21 22 23 24 25
31 32 33 34 35

The following query displays one element of the array:

: ? UserMatrix(1)(2)

23

The following query displays one row of the matrix:

: ? UserMatrix(1)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-33

21 22 23 24 25

The following query displays a range of elements from one row of the matrix:
: ? UserMatrix(1)(2, 4)

23 24 25

The following query displays one column of the matrix:

: ? UserMatrix(0, 2)(2)

13
23
33

The following query displays a submatrix:

: ? UserMatrix(1, 2)(2, 3)

23 24
33 34

4.2.7. Query of SP Variables

SP variables can be queried similarly to other variable types

4.2.7.1. Query SP Variable

The command resembles the query command for controller variables:

? SP-variable-specification
SP variable specification consists of two parts separated by colon. The first part contains the
letters "SP" followed by the requested Servo Processor number. The second part is a variable
name. For example:
?SP0:X_POS_GA Query position loop gain of the X axis

320 Position loop gain of the X axis is 320

?SP3:X_POS_GA Query position loop gain of the T axis

800 Position loop gain of the X axis is 800

4.2.7.2. Query SP Variable Metadata

The command

?@ SP-variable-specification

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 34 T e r min al C o mman d s

displays the SP address of the variable and the permitted range (maximum and minimum allowed
values). SP variable specification consists of two parts separated by colon. The first part contains
the SP letters and the requested Servo Processor number. The second part is a variable name.
For example:
?@SP0:X_POS_GA Query information about X_POS_GA variable in SP 0

SP address,Min,Max: 100, -32768, 65535

4.2.8. Formatting Query Data Presentation

Query commands described above display the requested data in a default format that can differ
from variable to variable. In certain applications, you may need to see data presented in another
format. For example, hexadecimal presentation is required, or a state variable needs to be obtained
as a number, not in bit-list form.

4.2.8.1. Default Formats

All the queries described above, produce a variable report in a default format depending on the
queried variable. In some cases the default format produces unsatisfactory results. For very large
or small real values the output may appear misleading because very large or small values may
require more positions than allocated by the default.
The default format for all real variables is similar to C format "%10G", where each real value is
represented by 10 digits. The controller automatically chooses the position of decimal point and
the number of digits right to the decimal point. If required, the controller uses an exponential
format, like 3.14E-13.
The default format for all user integer variables and for all standard integer variables, except
states flags, and I/O variables, is similar to C format "%10i" that specifies 10 digits for each
integer number.
State and flag variables are reported in special format as described in Querying states and flags
section (see page 4-29).
The standard IO arrays IN and OUT are reported in binary format.
You are allowed to override default format and to request one of the predefined formats, or
specify your own format.

4.2.8.2. Predefined Formats

The controller provides several predefined formats that can be used instead of the default format
for querying variables:
?D/ Decimal format. This format is identical to the default format for
integer variables. When applied to a state variable, the format
displays the decimal presentation of the variable. C-equivalent:
"%10i".
?X/ Hexadecimal format. When applied to an integer variable, this format
displays the hexadecimal presentation of the variable. C-equivalent: "
%08X".

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-35

?B/ Binary format. This format is identical to the default format for
variables IN, OUT. When applied to an integer variable, the format
displays the binary presentation of the variable.
?E/ Extended format. This format is useful for very large or small real
values, when the default format produces ambiguous results because
the default does not provide enough positions to display very large or
very small numbers. When applied to a real variable, the format
displays each value in 20 positions. C-equivalent: "%20G".

Examples:
: ?D/ MST Display the motor state in
decimal format
3 15 15 3 0 0 0 0
: ?X/Y_MST

00000000
: ?B/X_MST Display the state of motor x in
binary format
00000000,00000000,00000000,00000011
: ?E/UserReal Display the status of variable
UserReal in extended format
1.00000000000001

4.2.8.3. User-Defined Format

If the default format or any other predefined format is not suitable for your needs, you may
specify your own format using C notation. The specification is placed just before the variable
name in curled brackets. The specification applies only to one following name. If an array is
queried, the specification applies to each element of the array.
C notation provides an unlimited number of possible formats. Here are several examples of
formatting:
?{%12.3f}FPOS The motor feedback values for all axes are
displayed in 12 digits, fixed decimal point, 3
digits after the point. The same format applies
to all 8 values.
?{%8.0f}X_FPOS 8 digits, no decimal point, no fraction digits.
?{XFPOS = %8.0f}X_FPOS The response will look like XFPOS = 1234.
?{%08X} X_MST 8 digits, hexadecimal format with leading zeros

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 36 T e r min al C o mman d s

4.3. Nonvolatile Memory Management Commands

The nonvolatile memory stores programs and data that are the components of a user application.
The controller loads the user application during power-up initialization, and uses the contents of
the nonvolatile memory to define the initial state of the controller after power-up.
Memory management commands provide the following functions:
ƒ Save to or load from the nonvolatile memory all or any of the following data:
• ACSPL+ programs in all buffers or one specified buffer
• Configuration variables for all axes or one specified axis
• SP data (program and memory initialization) of all SPs or one specified SP
ƒ Reset all contents of nonvolatile memory to the factory default
ƒ Restart the controller
For safety reasons, certain memory management commands also stop all programs and disable all
drives.
Memory management commands are executed immediately and therefore cannot be part of a
program and cannot be stored in a program buffer.
Memory management commands start with the # character.
Note
Some of the memory management commands are available as menu
commands or buttons in the SPiiPlus MMI and SPiiPlus MultiDebugger. For
further details see the SPiiPlus MMI User’s Guide and the SPiiPlus
MultiDebugger User’s Guide.
The following memory management commands are available:
#SAVE Saves all ACSPL+ programs and configuration variable values.
#SAVEPROG Without argument, saves all ACSPL+ programs in all buffers.
#SAVEPROG With argument, saves the ACSPL+ program from the specified buffer.
#SAVEPAR Without argument, saves all configuration variables.
#SAVEPAR With argument, saves the configuration variables of the specified axis.
#SAVESP Without argument, saves SP data of all SPs.
#SAVESP With argument, saves the SP data of the specified SP.
#LOAD Loads all saved ACSPL+ programs and configuration variables. Also stops
all programs and disables all drives.
#LOADPROG Without argument, loads all saved ACSPL+ programs in the corresponding
buffers. Also stops all programs and disables all drives.
#LOADPROG With argument, loads the saved ACPSL+ program to the specified buffer,
or clears the buffer if the program for this buffer was not saved. Also stops
all programs and disables all drives.
#LOADPAR Without argument, loads all configuration variables with their stored value,

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-37

or with factory default if no value was stored. Also stops all programs and
disables all drives.
#LOADPAR With argument, loads the configuration variables for the specified axis with
their saved values or factory default. Also stops all programs and disables
all drives.
#LOADSP Without argument, loads saved or factory SP data to all SPs.
#LOADSP With argument, loads the saved or factory SP data to the specified DSP.
#CLEAR Clears ACSPL+ programs in all buffers. Also stops all programs and
disables all drives.
#RESET Clears all previously saved data in the nonvolatile memory and restarts the
controller. As a result, the controller resets to the factory default state.
Also stops all programs and disables all drives.
#HWRES Restarts the controller. The controller initiates power-up initialization (See
next page). Also stops all programs and disables all drives.

Examples:

#SAVE Save the controller state (configuration variable values and all ACSPL
programs) to nonvolatile memory.
#LOAD
Load the controller state from the nonvolatile memory.
#SAVEPROG 2
Save ACSPL+ program from buffer 2.
#LOADPROG Load all previously saved ACSPL+ programs to the corresponding
buffers.
#SAVEPAR
Save all configuration variables.
#LOADPAR 2
Load the configuration variables of the Z axis.
#SAVESP 2
Save the SP data (program and memory initialization) from second SP.
#LOADSP
Load SP data to all SPs and start them up.
#RESET
Reset to the factory default and restart the controller.
#HWRES
Restart the controller and reload all data.

4.3.1. Power-Up Sequence

On power-up the controller executes the following initialization sequence:
1. Load the firmware into RAM and start execution.
2. Initialize hardware/software. At this stage the controller assigns initial values to all report
variables such as FPOS.
3. Initialize all SPs. If SP data was previously saved, the SP is initialized with the saved SP data.
Otherwise, the factory default is loaded to the SP.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 38 T e r min al C o mman d s

4. Initialize all configuration variables. If a value of a configuration variable was previously

saved, the saved value is retrieved. Otherwise the variable is assigned with the factory default
value.
5. Initialize all program buffers. If a buffer was previously saved, the saved ACSPL+ program is
retrieved. Otherwise the buffer is loaded with the factory default program (Typically the
factory default is an empty program, therefore loading the factory default results in clearing
the buffer).
6. Start up each SP.
7. Find label AUTOEXEC in buffer 0. If the label exists, start up the ACSPL+ program from
this label.
8. Repeat the step 7 for each buffer. If the controller finds AUTOEXEC in a buffer the
controller initiates the program, then looks for AUTOEXEC in the next buffer and so on. If
no AUTOEXEC is found, no ACSPL+ program starts.
As a result of initialization sequence, the controller loads the application saved in the nonvolatile
memory or loads the factory default if no application was saved yet.

4.3.2. Saving Application Variables and SP Data

4.3.2.1. Saving the Entire User Application (#SAVE)

NOTE
In SPiiPlus MMI and SPiiPlus MultiDebugger, the #SAVE command
can not be executed from the Terminal window- only from the Tools
menu or the Communication Viewer window.

The command
#SAVE

saves a complete set of data, comprising a "user application," to the nonvolatile memory.
The following data is saved:
ƒ ACSPL+ programs in all the buffers. If a buffer is empty, the command clears up any
ACSPL+ program saved before from this buffer
ƒ The current values of all configuration variables
The result of the #SAVE command is equivalent to the result of the following commands:
#SAVEPROG

#SAVEPAR

The saved data replaces any data that was saved before by any save command. Therefore the
#SAVE command erases the result of any save command that was previously executed. Recovery
of the erased data is impossible. However, the #RESET command restores the factory default
settings.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-39

4.3.2.2. Saving Program Buffers (#SAVEPROG)

The command
#SAVEPROG

without a parameter saves all ACSPL+ programs in all buffers in the nonvolatile memory.
The command
#SAVEPROG "buffer number"

saves the ACSPL+ program from the specified buffer in the nonvolatile memory.
The saved program replaces any ACSPL+ program that was previously saved to this buffer. The
SAVEPROG command with a buffer number affects only the saved program for the specified
buffer. All other buffers are unaffected.

4.3.2.3. Saving Configuration Variables (#SAVEPAR)

The command
#SAVEPAR

without parameter specification saves the values of all the configuration variables in the
nonvolatile memory.
The command
#SAVEPAR "axis number"

saves the values of the configuration variables for the specified axis in the nonvolatile memory.
The newly saved values replace the previously saved values.
The command SAVEPAR with axis number specification affects only the saved values for the
specified axis. All other axes are unaffected.

4.3.2.4. Saving SP Data (#SAVESP)

The command
#SAVESP

without parameter specification saves the SP data of all SPs in the nonvolatile memory.
The command
#SAVESP "SP number"

saves the SP data of the specified SP in the nonvolatile memory.

SP data consists of SP programs and the SP memory initialization. Memory initialization includes
the control loop parameters, such as gains and PID coefficients.
The newly saved SP data replaces all data previously saved for the corresponding SP. The
#SAVESP command with an SP number affects only the saved SP data for the specified SP. Any
SP data previously saved in any other SP remains unchanged.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 40 T e r min al C o mman d s

Use the SPiiPlus SPiiDebugger and SPiiPlus MMI to configure SP memory initialization and to
interact with the SP program. The Adjuster in the SPiiPlus MMI (See the SPiiPlus Setup Guide) is
designed for adjusting the control loop parameters in SP memory initialization.

4.3.3. Loading Applications, Variables and SP Data

4.3.3.1. Loading The Whole User Application (#LOAD)

NOTE
In SPiiPlus MMI and SPiiPlus MultiDebugger, the #LOAD command
can not be executed from the Terminal window- only from the Tools
menu or the Communication Viewer window.

The command
#LOAD

loads a set of data from the nonvolatile memory, that makes up the whole user application.
The following data is loaded:
ƒ ACSPL+ programs into all buffers.
ƒ The values of all configuration variables.
ƒ SP data into all SPs.
The result of the #LOAD command is equivalent to the result of the following three commands:
#LOADPROG

#LOADPAR

#LOADSP

Using the #LOAD command the user can restore the initial state of the application.
Note that the #LOAD command does not restart the controller. Therefore, the specific
initialization sequence executed on power-up is not run. For example, report variables like FPOS,
which shows the current motor position, are zeroed at power-up, but are not reset and retain their
current values when the #LOAD command is executed. For full initialization, use the #HWRES
command.
This command also stops all programs and disables all drives.

4.3.3.2. Loading Programs Into Buffers (#LOADPROG)

The command
#LOADPROG

without parameter specification loads all the ACSPL+ programs from the nonvolatile memory
into all buffers.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-41

The command
#LOADPROG "buffer number"

loads an ACSPL+ program from the nonvolatile memory into the specified buffer.
If a buffer was not previously saved, the command loads the factory default for that buffer, which
is typically an empty program).
#LOADPROG with a specific buffer number affects only the specified buffer. Other buffers
remain unchanged.
This command also stops all programs and disables all drives.

4.3.3.3. Loading Configuration Variables (#LOADPAR)

The command
#LOADPAR

without parameter specification loads the values of all configuration variables from the
nonvolatile memory.
The command
#LOADPAR "axis number"

loads the values of the configuration variables for the specified axis from the nonvolatile memory.
The #LOADPAR command with an axis number affects only the specified axis. All other axes are
unaffected.
This command also stops all programs and disables all drives.

4.3.3.4. Loading SP Data (#LOADSP)

The command
#LOADSP

without parameter specification loads the SP data into all SPs from the nonvolatile memory, and
starts up all the SPs.
The command
#LOADSP "SP number"

loads the SP data into the specified SP from the nonvolatile memory and starts up the SP.
SP data consists of the SP program and SP memory initialization. Memory initialization includes
the control loop parameters, such as gains and PID coefficients.
The #LOADSP command with a specified SP number affects only the specified SP.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

4- 42 T e r min al C o mman d s

4.3.4. Clearing Buffers (#CLEAR)

The command
#CLEAR

clears all ACSPL+ programs in all buffers.

4.3.5. Resetting the controller (#RESET)

NOTE
In SPiiPlus MMI and SPiiPlus MultiDebugger, the #RESET command
can not be executed from the Terminal window- only from the Tools
menu or the Communication Viewer window.

The command
#RESET

clears all previously saved data in the nonvolatile memory and restarts the controller. As a result,
the controller resets to the factory default state.
The #RESET command deletes the user application stored in the nonvolatile memory and the
result of any previous save command will be lost.
The following data in the nonvolatile memory is cleared:
ƒ All ACSPL+ programs in all buffers.
ƒ Values of all configuration variables.
ƒ SP data of all SPs.
The #RESET command restarts the controller. Since the nonvolatile memory is erased, the
controller resets to factory defaults.
This command also stops all programs and disables all drives.
Caution
The #RESET deletes all previously stored applications. Deleted applications
are irrecoverable.

4.3.6. Restarting The Controller (#HWRES)

New configuration parameters become valid only upon restart, you may therefore occasionally
need to restart the controller.
The command
#HWRES

restarts the controller, and launches the power-up initialization.

During the power-up initialization the controller loads the application saved in the nonvolatile
memory, or loads the factory defaults if no application was saved yet.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Te r m ina l C o m m a n ds 4-43

This command also stops all programs and disables all drives.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-1

5. ACSPL+ MULTIPROGRAMMING
LANGUAGE

5.1. Executing ACSPL+ Programs

5.1.1. Immediate Execution vs. Stored Program

The controller provides three options for executing ACSPL+ commands:
ƒ Execute a command immediately
ƒ Store a sequence of commands in a buffer and then execute the sequence as an ACSPL+
program
ƒ Execution in a dynamic buffer
If the controller prompt is : no program buffer is open for editing, and an ACSPL+ command,
transmitted to the controller through any communication channel, is executed immediately.
If the prompt contains a line number like 2:00001>, a program buffer is open for editing, and an
ACSPL+ command, transmitted to the controller through any communication channel, is stored in
the open buffer. ACSPL+ commands stored in a buffer constitute an ACSPL+ program.
The most convenient method for managing the program is by using the SPiiPlus MultiDebugger.
See the MultiDebugger Guide for further details. For an explanation of executing ACSPL+ in a
dynamic buffer see page 3-9)
Note
The SPiiPlus MultiDebugger and SPiiPlus MMI provide convenient tools for
storing and editing a program in a buffer.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-2 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

5.1.2. Program Buffers

The controller provides 10 program buffers.
Each buffer provides:
ƒ Separate storage for each ACSPL+ program
ƒ An isolated environment for program editing/execution
ƒ Separate thread for concurrent execution
ƒ Independent autoroutine execution
Each buffer is managed independently of the other buffers. For example, the user can edit a
program in one buffer while the program in another buffer is executing.
All labels and local variables in a program are local in the encapsulating buffer. Programs in other
buffers do not have access to these label and variables. Even if two programs in different buffers
both define a local variable with the same name, the variables are considered as two different
variables, each local in the corresponding buffer.
A program in a buffer can be executed independently of any other program. The program
executed in a buffer does not affect the program executed in other buffer, unless the user has
provided for synchronization through the global variables or common resources.
If a program in a buffer includes one or more autoroutines, the buffer manages the autoroutines
independently of other buffers. If an autoroutine condition is satisfied, only the program executed
in the enclosing buffer is interrupted. No other buffer is affected.
Processing of empty lines in ACSPL+ program In previous firmware versions each ACSPL+ line
took a time for its execution – by default, one controller cycle. In the new version
The time allotted to processing non-executable lines is controlled by the S_FLAGS.1 bit. An non-
executable line could be a comment, a new line, a label, etc.
If the bit is 0 (default), the non-executable line will be skipped during execution. If the bit is 1, the
line will be allotted a controller cycle. executed as before taking a standard time for execution.
The bit affects the program compilation. Therefore, if the bit is changed, the results will be visible
only after a program is recompiled.

5.1.3. Execution of a Single Program

Assume a compiled ACSPL+ program containing no errors is stored in buffer 0. The user
executes command
#0X Execute the program in buffer 0
The controller starts execution from the first line.
The controller executes the problem according to this simple model:
ƒ One program line is executed each controller cycle. If a line contains several ACSPL+
commands, all them are executed in one controller cycle. See also Execution Rate below.
ƒ If a program is linear, meaning that it contains no program-flow commands, like goto, and
no autoroutines, the program lines are executed sequentially: the first line in the first
controller cycle, the second – in the second controller cycle, and so on. A program-flow

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-3

command redirects execution and defines another line to be executed in the next controller
cycle.
ƒ A number of commands can delay program execution. For example, the command
wait 50

will execute for 50 milliseconds instead of one controller cycle. The command
till ^MST.#MOVE

provides a delay of execution time until the motion ends.

Commands that use the controller resources, like motion commands, also can be delayed if the
resource is busy.
After a command that caused a delay has finished, the controller continues executing one line
per one cycle.

5.1.4. Concurrent Execution

Assume the programs in buffers 0,1,2 are linear and include no commands that can delay
execution. After starting simultaneously, the programs execute in a simple and predictable way;
one line of each running program per one controller cycle.
In the first controller cycle the controller executes line number 1 from buffer 0, line number 1
from buffer 1 and line number 1 from buffer 2. In the second controller cycle the controller
executes line number 2 from buffer 0, line number 2 from buffer 1 and line number 2 from buffer
2, in progression.
If a program contains a program-flow command or a command that delays execution, this strict
synchronization vanishes, but the general principle remains the same: one line of each running
program per each controller cycle.
The rule does not depend on the number of concurrent programs. If all 10 programs run
concurrently, the controller executes 10 ACSPL+ lines in each controller cycle– one from each
running program.
Delay in one executed program has no effect on other executed programs. Each buffer provides an
isolated thread for program execution.
Within a controller cycle, the order of executing the program lines follows the buffer numbers:
first, a line from buffer 0 is executed, then a line from buffer 1, and so on.

5.1.5. Immediate Execution

What happens if while one or more programs are running at the same time the controller accepts
an immediate ACSPL+ command through a communication channel?
The controller executes the terminal command in an additional thread not connected with any
buffer. Therefore, the controller provides 9 + 1 threads for ACSPL+ execution. Nine threads are
assigned to the program buffers and one thread is reserved for immediate execution.
All rules of the execution model also apply to immediate execution. For example, if several
commands are combined in one line for immediate execution, all of them are executed in one
controller cycle in parallel with the lines from each running program.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-4 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Within a controller cycle, the immediate line is executed after all lines from the running programs.
Therefore, in one cycle the controller executes a line from buffer 0, then a line from buffer 1, 2,
up to 9, and then executes an immediate line (If any have been received).

5.1.6. Autoroutines
An autoroutine is a part of ACSPL+ program and can be placed in any program buffer. Each
ACSPL+ program can contain from zero to unlimited autoroutines. An autoroutine placed in a
buffer shares with other autoroutines in the same buffer and with the rest of ACSPL+ program,
the local variables and the same thread for execution.
If a buffer contains one or more autoroutines, the execution model described is slightly modified.
Each controller cycle, the controller examines the conditions of all autoroutines in the buffer,
before executing the next line in a buffer. If a condition is satisfied, the controller does not
execute the next line but executes the first line of the body of the corresponding autoroutine.
Therefore, the autoroutine interrupts the program executed in the same buffer. An autoroutine in
one buffer has no effect on the program or autoroutines in another buffer.
Autoroutines provide an interrupt-like response to external or internal events. For more
information about autoroutines see page 5-90.

5.1.7. Synchronization and Mutual Exclusion

Though the controller provides independent execution of concurrent programs, applications can
often require that their component programs be synchronized at certain points.
The controller provides a simple and flexible approach to solving synchronization problems. In
addition to an ACSPL+ line serving as a unit for concurrent execution, the same ACSPL+ line
serves as a unit of mutual exclusion. Namely:

Execution of an ACSPL+ line cannot be interrupted by a concurrent program or by an

autoroutine.
Therefore, an ACSPL+ line provides an atomic unit of execution. Given that a single ACSPL+
line can contain any number of ACSPL+ commands, various synchronization tasks can be
resolved using global variables.

5.1.7.1. Mutual Exclusion

Mutual exclusion is the most frequently-used synchronization task. As the execution of an
ACSPL+ line is atomic, mutual exclusion of the lines in concurrent programs is automatic and
does not require any intervention from the user. If a critical section requiring mutual exclusion
comprises only a few commands, then simply place these commands in one line.
However, if a critical section is long, or combining it in one line is undesirable for any reason,
another solution must be found. The following construction implements a simple semaphore,
which is ON (one) while the program is inside the critical section, and is OFF (zero) otherwise.
global int Mutex Variable Mutex implements semaphore

. . . . . Any program actions

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-5

till ^Mutex; Mutex = 1 Enter critical section

. . . . . Critical section

Mutex = 0 Exit critical section

The Enter and Exit lines enclose the critical section. If the program contains several critical
sections, each section must be enclosed with the same Enter and Exit lines as shown in the
example above.
All programs that require mutual exclusion must include the same declaration of the Mutex
variable and the same embracing of each critical section.
This construction guarantees that only one of the concurrent programs may be inside a critical
section. If the second program tries to enter the critical section, the command till ^Mutex delays
the program execution until the first program zeroes Mutex on exit from critical section.
Note, the solution is based on automatic one-line mutual exclusion. Therefore, the two commands
till ^Mutex; Mutex = 1

must be in one line. If they are placed in two sequential lines, they cannot provide mutual
exclusion.

5.1.7.2. Synchronization
Assume two programs that run mostly asynchronously must execute certain commands at the
same time. There is a point in each program that whichever program comes to the point first, it
must wait for the second program to come to its synchronization point. Then the next lines in both
programs will be executed in the next controller cycle.
The problem is solved by the following construction:
global int Sem Variable Sem implements a
general semaphore
. . . . . Asynchronous part of the
program
Sem = Sem+1; till Sem = 2; Sem = 0 Synchronization point

. . . . . The line will be executed

synchronously
. . . . .

The same definition of the Sem variable and the same line of synchronization point must be in the
second program.
Whichever program comes to its synchronization point first, command till Sem = 2 provides
waiting for the second program. The assignment Sem = 0 provides reuse of the construction if
necessary.
The solution can be also be extended to three or more concurrent programs.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-6 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

5.1.8. Execution Rate

In the execution model described above, the controller executes one line from each running
program per each controller cycle. The execution rate in each buffer is the same.
The user can modify the execution model by specifying how many lines in each buffer the
controller must execute in one controller cycle.
Standard variables PRATE and ONRATE contain one element per each program buffer. Each
element of PRATE specifies how many lines in the corresponding buffer the controller must
execute in one controller cycle, except the case if an autoroutine is executed. Each element of
ONRATE specifies the same when an autoroutine is executed.
For both variables, the default value is 1 - one line per each controller cycle. The user can increase
the value up to 10 - ten lines per each controller cycle.
In a typical case the user increases PRATE and ONRATE in one buffer, providing the higher
execution rate in this buffer. The program in this buffer runs faster, than the programs in either
buffers, as if the buffer has a higher priority.
Caution
Exercise caution while simultaneously increasing the execution rate in buffers.
Increasing execution rate increases usage of the controller real-time cycle and
may cause a Time Overuse fault. Use command #U to monitor the present
usage. If maximum usage value approaches 90%, the application places an
excessive load on the controller. Decrease execution rates, simplify your
application, or use a more powerful model of the controller, to solve the
problem.

5.1.9. Dynamic Buffers

Dynamic buffers act as FIFO buffers for ACSPL+ commands. After a dynamic buffer is activated,
a command inserted into the buffer joins the execution queue. As soon as all the previously
inserted commands have finished their execution, the newly inserted command is executed and
then removed from the buffer. Commands are sent to dynamic buffers via the Terminal or through
a host-based program.

5.1.9.1. Activating a Dynamic Buffer

Bit 2 in standard variable PFLAGS defines if a buffer works as a dynamic buffer. To access the
bit, use symbolic constant #DYNAMIC. For example:
PFLAGS1.#DYNAMIC = 1 Use buffer 1 as dynamic.

PFLAGS7.#DYNAMIC = 1 Use buffer 7 as dynamic.

PFLAGS6.#DYNAMIC = 0 Use buffer 6 as a regular buffer.

Several buffers can work as dynamic buffers simultaneously.
Use command #SAVE to save the present value of PFLAGS in the nonvolatile memory. If bit
PFLAGSn.#DYNAMIC was saved as 1, the n-th buffer will be dynamic immediately after power-
up.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-7

5.1.9.2. Reporting the Status of a Dynamic Buffer

Status query of a dynamic buffer provides a different type of report than a query from a regular
buffer. The following information is displayed:
?0 Query status of buffer 0

Buffer 0: dynamic, 875 bytes are used, 14485 bytes are free

The controller response indicates that the buffer is dynamic and displays the number of used and
free bytes in the buffer. The number of used bytes increases each time when a new command is
inserted into the buffer and decreases each time when a command finishes its execution and is
removed from the buffer. The number of free bytes changes accordingly.
A dynamic buffer stores the compiled code of a command. The number of bytes occupied by a
specific command is a complex function of the command complexity, the functions used in the
command, and other factors. Therefore, the number of used and free bytes gives only an overall
evaluation of the buffer state, and it is impossible to determine the exact number of commands
waiting for execution in a dynamic buffer.

5.1.9.3. Adding Commands to a Dynamic Buffer

Adding commands to a dynamic buffer is similar to adding commands to a regular buffer.
To add new commands from the Terminal, use terminal commands ‘open buffer’ – ‘close buffer’.
For example:
#1 Open buffer 1

PTP X,40000 Add command ptp X,40000 to the buffer

TILL ^X_MST.#MOVE Add command till ^X_MST.#MOVE to the buffer

… Add any other commands to the buffer

# Close the buffer

To add new commands from a host-based program, use SPiiPlus C Library function
acsc_DownloadBuffer. For example:
char Prog[] = Definition of the string that contains ACSPL+
commands

“PTP X,40000\n” ACSPL+ lines must be separated by the new-line

character

“TILL ^X_MST.#MOVE\n”;

acsc_DownloadBuffer(

Handle, Communication handle

1, Add the commands to buffer 1

Prog, Address of the string that contains ACSPL+

commands
strlen(Prog), Length of the string

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-8 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

0); Waiting mode

New commands in a dynamic buffer are always appended to the end of the buffer, after any
command that is currently in the buffer.
A new command can be inserted only if the dynamic buffer has enough free space for storing the
command. If the space is not enough, the insertion fails due to error 2078. The error does not
affect execution of the commands inserted in the buffer before. When a command finishes its
execution, it is removed from the dynamic buffer and the number of free bytes increases.
Therefore, a command that failed to be inserted, can be inserted after one or more previous
commands have finished.
As stated above, there is no way to know exactly how many bytes in a dynamic buffer are
required for a specific command. Therefore, the recommended procedure for working with a
dynamic buffer is as follows:
1. Insert the first command.
2. Continue inserting the next commands until error 2078 occurs.
3. Wait a several seconds, and try inserting the last command again. Repeat this step until the
command is successfully inserted.
4. Repeat steps 2 and 3 as required.

5.1.9.4. Executing Commands in a Dynamic Buffer

Neither the Compile or Execute commands are required to start execution in a dynamic buffer. A
command inserted into a dynamic buffer is compiled automatically. Immediately after
compilation the command is ready for execution. If the buffer is empty when the command is
inserted, the command starts execution immediately. If a number of commands are still in the
buffer when the command is inserted, the command is appended to the end of the existing
commands and will be executed after all previously inserted commands.
As soon as a command is executed, it is removed from the dynamic buffer. Therefore, dynamic
buffers serve as a FIFO buffer for ACSPL+ commands. A command inserted into a dynamic
buffer is executed after all commands that were inserted before.
In all other aspects, execution in a dynamic buffer is very similar to execution in a regular buffer.
Commands grouped in one program line are executed in one controller cycle. Commands till and
wait provide delay in program execution just as they do in a regular buffer.
However, because of the dynamic approach to command storage, when the program flow requires
jump, the destination commands may be already removed from the buffer. Therefore, the
program-flow commands if, while, loop, goto, call, ret are not allowed in a dynamic buffer:

5.1.9.5. Error Processing in a Dynamic Buffer

There are three kinds of errors that may appear in a dynamic buffer:
• Command insertion failure, code 2078 (Current empty space in the dynamic buffer is not
enough for the command).
• All other insertion and compile-time errors, codes less than 3000.
• Run-time errors, codes more than 3000.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-9

As explained above (page 5-7) error 2078 may frequently occur when working with a dynamic
buffer. If a command cannot be inserted (error code 2078), the application must attempt inserting
again until the command will be inserted successfully.
All other insertion and compile-time errors with codes less than 3000 indicate an error in the
inserted command. The command must be corrected to be inserted successfully. This error does
not affect execution of the commands inserted into the buffer before. The commands already
inserted into the buffer continue normally executing.
Conversely, if a run-time error (codes more than 3000) occurs in a dynamic buffer, all commands
currently stored in the buffer are aborted and will not be executed. However, the buffer remains
ready for insertion. Therefore, the next inserted command will be stored and executed as usual.

5.1.9.6. Limitations of Dynamic Buffers

The following is a summary of the limitations of dynamic buffer as compared to regular buffers:
• Commands if, while, loop, goto, call, ret are not allowed in a dynamic buffer
• Autoroutines (command on) are not allowed in a dynamic buffer
• Declaration of local variables is not allowed in a dynamic buffer
• Commands #C (Compile), #X (Execute), #L (List) #D (Delete) have no effect on a
dynamic buffer
• Variables PCHARS, PEXL, PERL are meaningless in a dynamic buffer

5.2. ACSPL+ Syntax

5.2.1. Key words

Keywords are reserved words that have specific meanings. They cannot be used as names in a
program. The following keywords are reserved for ACSPL+:
abs ceil edge getdsp jog
acos connect else getdspini kill
all cos elseif global killall
arc1 dc enable go ldexp
arc2 deadzone enableon goto lag
asin disable end group let
atan disableall ends halt line
atan2 disableon extin hypot local
avg disp extout if log
binp do exp imm log10
break dsign floor int loop
call dynamic getsp intgr map

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-10 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

mapby1 mref read setdsp stopall

mapby2 mseg real setdspini stopdc
map2 on resume sign stopper
map2free path ret sin tan
master pause roll slave till
max peg sat split vsp
min point save splitall wait
monsp pow send sqrt while
mpoint projection set start write
mptp ptp setsp stop

5.2.2. Names: Variable and Label

A name is a sequence of alphanumeric characters used to denote one of the following:
ƒ variable (standard or user-defined)
ƒ label
The first character of a name must be a letter.
The controller defines a set of standard variables. The names of these variables are predefined and
cannot be changed. For a full list of standard variables see Chapter 9.2.
The controller also defines a standard label: AUTOEXEC. If this label is used in a program, then
execution will start there at controller power-up (see page 4-37).
You can declare user variables and user labels as required in the application. The number of user-
defined names and the length of each name are essentially unlimited. However, you may not
declare variable names that coincide with the following:
• Keywords (if, wait, sin, etc.)
• Names of standard variable (FPOS, MST, etc.)
• AUTOEXEC (standard label)
• Axis designation (X, Y, Z, T, A, B, C, D, or all)
• Prefix- or postfix- indexed form of a standard variable

5.2.3. Case Sensitivity

All keywords are case-insensitive, i.e. the words if, IF, If or iF all have identical meaning in a
program.
Axis designations are case-insensitive, i.e. x or X have identical meaning in a program.
Variable and label names are case-sensitive, i.e. the names FPOS and Fpos designate two
different variables.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-11

5.2.4. Commands, Lines, and Command Aggregates

A Command is the smallest executable unit of ACSPL+.
One program line may contain one or several commands. If a line contains several commands, the
commands must be separated by a semicolon (;). A semicolon after the last (or single) command
in a line is not required.
Examples:
The following is an example of a program line that contains one assignment command:
V0 = V1 + 2*(V2 – V3)

The following is an example of a program line that contains two assignment commands:
V0 = V1 + 2*(V2 – V3) ; V4 = 0

White spaces (spaces and tabs) may be inserted arbitrarily inside or between commands.
However, white spaces must not be inserted within a keyword or variable name.
A Command aggregate consists of several commands. It starts with a specific command and
terminates with the end command. For example, a loop structure starts with the loop command
followed by an arbitrary number of commands and terminates with the end command. The
commands of a structure may reside in one or more program lines.

5.2.5. Axis Designations

Many ACSPL+ commands (page 5-71) take one or more axes as arguments. This applies
particularly for motion commands (page 6-1).
Axes can be designated as one or a sequence of letters, like X, XYZ, ZAD, or as a list of values
enclosed in parentheses: for example: (0, 2, 4) is equivalent to XZA. The values can be
represented with variables.
Some commands all support the keyword all, to designate all the axes supported by the controller.
In the command descriptions (page 5-71), it is noted whether a command supports the keyword
all.
The following examples are equivalent:
enable XY Axes designated as letter sequence.
ptp XY, 100, 200

enable (0,1) Axes designated as list of values.

ptp (0,1), 100, 200

int first_axis, second_axis Variable declarations.

first_axis = 0 Variable assigned value.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-12 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

second_axis = 1 Variable assigned value.

enable (first_axis, second_axis) Axes designated as list of variables.
ptp (first_axis, second_axis), 100, 200

5.2.6. Comments
A comment is text in a program that the controller stores along with the program but ignores
while executing the program. Comments are normally used to annotate a program.
A comment starts with an exclamation mark (!). An exclamation mark encountered in a line
designates all subsequent characters in the line as part of a comment. If the exclamation sign is the
first character in a line, the whole line is a comment.
! This entire line is a comment.

V0 = V1 !This comment starts from the exclamation mark.

5.2.7. Syntax Conventions

Example
element {+f | –f} arguments . . . [options]

Element Language element that must be entered exactly as shown (keyword,

command, function, etc.).
{} Indicates a set of choices from which to choose one.
| Separates two mutually exclusive choices. Select one of them.
Italic Variables and other placeholders that must be provided by the user.
... An argument that can appear more than once..
[] Optional item(s)

5.3. Variables

5.3.1. Variable Attributes

Variables have the following attributes:
ƒ Name
ƒ Class (standard or user variable)
ƒ Scope (global or local)
ƒ Lifetime
ƒ Accessibility (read-write, read-only, protected)
ƒ Type (integer or real)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-13

ƒ Size
ƒ Value

5.3.2. Name
Variable names follow the general syntax rules (page 5-9).
The controller has a set of standard variables with predefined names. The user cannot change
these names. Standard variables can be used in ACSPL+ commands without explicit declaration.
User variable names must be specified by explicit declaration. For example:
int Var1, Var2 Declare local variables Var1 and Var2

global real RealVar Declare global variable RealVar

5.3.3. Class: Standard or User

Standard variables are predefined in the controller. Standard variables can be used in ACSPL+
commands without explicit declaration.
Standard variables are mentioned throughout this guide where they relate to a particular element
or feature of ACSPL+. See also the Standard Variable Reference (Chapter 11).
User variables are defined by explicit declarations. A declaration can appear as:
ƒ A part of an ACSPL+ program. The declared variable becomes available when the program
is inserted into one of the program buffers and is compiled. Any attempt to query a variable
in a buffer window that has not been compiled will result in an error.
ƒ An immediate ACSPL+ command. Only global variables can be used as a terminal
command. The declared variable becomes available immediately after the controller executes
the command.

5.3.4. Scope
Variables have either global or local scope.

5.3.4.1. Global Scope

A variable with global scope can be used in any program buffer and also in terminal commands.
All standard variables have global scope. A user variable can be declared as either global or local.
Declaration of user global variable starts with the keyword global. For example:
global real GlobVar Declare global variable GlobVar
This declaration may appear in several program buffers. However, all these declarations refer to
the same variable.
Using a standard variable in a program does not require explicit declaration of the variable.
However, a global user variable must be declared before it can be used in a program. Terminal
commands can use any global variable without explicit declaration.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-14 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

5.3.4.2. Local Scope

A variable with local scope can be used only in the program buffer where it is declared. Only user
variables can be local.
By default, if a declaration does not contain the keyword global, the variable is declared as local.
However, it is recommended that the user include the keyword local for clarity. For example, the
declaration
real LocVar

is identical to the declaration

local real LocVar

Both of them define local variable LocVar.

A local variable is valid only within the buffer where it is declared. If a local variable with the
same name is declared in another buffer, the controller considers them as two different variables.
The name of a local variable may also be the same as the name of a global variable. The controller
considers them as different. The program where the local variable is declared has access to the
local variable only.

5.3.5. Lifetime
All standard variables are valid as long as the controller firmware is active; from power-up to
power-down.
A user local variable is valid as long as the containing program is compiled. Therefore, a local
variable becomes active when the program it is contained in is inserted into one of the buffers and
is successfully compiled. After compilation, the variable is assigned its value and is available for
terminal command #V (list of variables) and queries.
Local variables are erased when the program they belong to returns to non-compiled state.
Programs may enter a non-compiled state as a result of:
ƒ Explicit #SR command (Stop and Reset)
ƒ Editing or inserting another program in the buffer
When a program terminates normally it remains in a compiled state and local variables therefore
remain valid. In addition, if a controller-executed program causes an error, the controller
terminates the program, but the buffer remains in a compiled state. Any user variable in the buffer
therefore remains valid.
A user global variable declared in one or more ACSPL+ programs is valid as long as at least one
of the programs that contains it is compiled. After compilation, the global variable is assigned its
value and is available for terminal command, #V (list of variables) and queries.
A user global variable disappears when the last program that it is contained in returns to a non-
compiled state. The conditions when a program may return to non-compiled state are discussed
above.
A special case of user global variable is the persistent global variable. A global variable is
defined as persistent when the variable declaration is not a part of any program but is issued as an
immediate ACSPL+ command.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-15

Assume, that the user executes the following commands via the Terminal:
global real PersistentVar Declaration
: Controller’s prompt
?PersistentVar Query
0 Initial value
: Controller’s prompt
The controller immediately accepts the declaration and creates the persistent global variable
PersistentVar. The variable is now valid and can be queried as illustrated by the following query
command.
The lifetime of a persistent global variable is not connected with any program. A persistent
variable survives any change in the program buffers and may be erased only by the explicit
terminal command #VGV (Clear Global Variables).

5.3.6. Accessibility
All user variables have read-write access and are not protected. Any ACSPL+ command located
in the scope of a variable can use or assign the variable’s value at any time.
A standard variable can belong to any of three access classes:
ƒ read-write
ƒ read-only
ƒ protected
Read-write standard variables such as user variables can be used or assigned at any time.
Examples of read-write standard variables are VEL (Velocity) and IST (Index State).
Many standard variables are read-only. These variables cannot be assigned. The read-only
variables provide readout of the controller state. Examples include RPOS (Reference Position),
FPOS (Feedback Position), MST (Motor Status).
Protected standard variables define the configuration of the controller, and are therefore called
configuration variables. The values of configuration variables can be read at any time.
Assignment to configuration variables is allowed only in configuration mode (5.10). Examples of
configuration variables are ENTIME (Enable Time), and XACC (Maximal Acceleration).
In most applications, the user sets the values of configuration variables during the application
development process by using the special tools provided for this purpose in the Protected
Function window of the SPiiPlus MMI (See the SPiiPlus MMI User’s Guide or Help).

5.3.7. Type: Integer and Real

ACSPL+ supports integer and real variables.
Each standard variable has a predefined type. For a user variable the type is specified in the
declaration.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-16 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

The controller provides automatic conversion from integer to real and from real to integer if
required. Therefore the user is not restricted in using variables of both types in ACSPL+
commands.
For example in the following fragment:
int Var1 Declare Var1 integer variable

real Var2 Declare Var2 real variable

Var1 = Var2 Controller automatically converts real to integer

Var2 = Var1 Controller automatically converts integer to real

The types differ by internal presentation and behavior in arithmetical operation.

ƒ An integer value occupies 4 bytes, 32 bits, numbered from 0 to 31. The sign is located in bit
31, bit 0 is the least significant bit of the mantissa.
ƒ A real value occupies 8 bytes, 52 bits of mantissa and 12 bits of exponent. The format
corresponds to the standard double format of PC.

5.3.8. Size
A variable can be a scalar, one-dimensional or two-dimensional array. A two-dimensional array is
called a matrix.
The size of each standard variable is predefined in the controller. For example, the S_FAULT
(System Faults) variable is a scalar variable, and the FAULT (Motor Faults) variable is an array
of 8 elements.
Many standard variables are sized according to the number of axes, with one element per each
axis. For example, each element of the FAULT array displays faults for one axis.
The size of user variables is defined in the variable declaration. For example:
int ScalarVar Declare scalar variable ScalarVar

global real Ar1(100) Declare array Ar1 of 100 elements

int Ar2(10)(200) Declare matrix Ar2 of size 10x200 elements

The maximum size of a user array is 30000 elements.

5.3.9. Value
Value is the only variable attribute that can change during a variable lifetime. In most
applications, a value is changed explicitly, as a result of assignment.
Read-only variables change their values implicitly. For example, the controller updates the
elements of variable FPOS (Feedback Position) each controller cycle, so that each element
displays the actual position of the corresponding motor.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-17

5.4. Variable Declaration

Standard variables are predefined in the controller and do not require explicit declaration.
Each user variable, whether local or global, must be declared in the program where it is used.
Variable declarations obey the following syntax:
variable-declaration:
[scope-specification][type-specification] name [size-specification]

scope-specification:
local
global

type-specification:
int
real

size-specification:
( constant )
( constant ) ( constant )
Any of the parts of either the scope-specification or the type-specification can be omitted, but not
both. If scope-specification is omitted, local specification is implied. If type-specification is
omitted, int specification is implied.
If no size-specification is specified, the variable is scalar.
If size-specification contains one constant in parenthesis, the variable is a one-dimensional array
with the specified number of elements. If size-specification contains two constants in parenthesis,
the variable is a two-dimensional array.
Generally user variables are created in RAM. However, to create a global variable in DPRAM
there is an alternative declaration syntax, which is described in Section 10.3.2.
Examples:
local int Var1 Local integer variable Var1

int Var1 The same as above

local Var1 The same as above

global real Var2(1000) Global real array Var2 of 1000 elements

global real Var3(2)(1000) Global real array Var3 of 2x1000 elements

5.4.1. Declaration of Local Variables

A local variable is valid only in the program where it is declared. You may declare a local
variable by using the local keyword. However, it is not necessary to use the local keyword,
because if a declaration does not contain the keyword global, by default the declared variables are
local.
A local variable becomes active when the program containing it is compiled in one of the program
buffers. The variable is valid as long as the program containing it remains compiled.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-18 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

Local and global variables are initialized to zero during compilation.

Examples of local variable declarations:
local int LocVar1 Local integer LocVar1

real LocVar2 Local real LocVar2

int Var1, Var2 Local integer Var1 and Var2

int Var3, Var4(2)(100) Local integer scalar Var3 and array Var4 of
size 2x100

5.4.2. Declaration of Global Variables

A global variable is common for all programs in all program buffers.
To have access to a global variable, a program must declare it. Without explicit declaration a
global variable is invalid in a program. Therefore declaration of a global variable may appear in
several programs, but all these declarations refer to the same variable.
Declarations of a global variable in different programs must be identical. Declaring a global
variable in two buffers with the same name, but different type or size, causes a compile error.
A global variable becomes active once the first program containing it is compiled in one of the
program buffers. The variable remains valid as long as at least one of the programs containing it
remains compiled.
To create a global variable in DPRAM there is an alternative declaration syntax, which is
described in Section 10.3.2.
Local and global variables are initialized to zero during compilation.
Examples of the local variable declarations:
global int GVar1 Global integer GVar1

global real Var1, Var2 Global real Var1 and Var2

global int Var3, Var4(2)(100) Global integer scalar Var3 and array Var4 of
size 2x100

5.4.3. Persistent Global Variables

A persistent global variable is a global variable that is declared by terminal command. Immediate
execution of ACSPL+ commands is described in Immediate Execution, Section 6.2.5. A command
executed immediately is not included in a program or stored in a buffer.
A global command executed immediately declares a persistent global variable, whose lifetime is
not dependent on any buffer. A persistent variable becomes active immediately when the
command executes. The variable remains valid throughout any buffer manipulations. The only
way to erase a persistent variable is by executing the #VGV (Vanish Global Variables) command.
The command erases all persistent global variables that are not referred in any compiled buffer.
A program in any buffer can access a persistent global variable. Like a regular global variable, a
persistent variable must be re-declared in each buffer where it must be used. The declaration in a

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-19

buffer does not affect the persistency of the variable. Once declared in a terminal command, the
variable remains persistent irrespective of all re-declarations.
A local variable cannot be declared by terminal command.
For example:
Assume that the user communicates with the controller through the Terminal and wants to start
data collection without preparing a special ACSPL+ program. The following dialog occurs:
Declare persistent global array of size
global Data(2)(1000)
2x1000
: Controller’s prompt

dc Data,1000,1,X_FPOS,X_PE Collect Feedback Position and Position Error

of X motor, 1000 samples, 1 millisecond
sampling period
: Controller’s prompt

?S_ST Query the System State variable

3 ON Data Collection (#DC) Data collection is in progress
:

?S_ST Query the System State variable

1 OFF Data Collection Data collection has finished
:

?Data Query the Data array

5.5. Arrays and Indexing

5.5.1. Scalars and Arrays

A variable can be either scalar or array. A scalar variable contains a single value. An array
contains a set of values. The arrays are subdivided into one-dimensional arrays and two-
dimensional arrays or matrices.
Before an arraye is used, its size must be declared. The size of a one-dimensional array is the
number of elements in the array. The size of a two-dimensional array is determined by
multiplying each dimension, for example 2x2000.
Access to the value of a scalar variable is provided by its name. For example:
int Scalar1 Declare local integer Scalar1

Scalar1 = 4 Assign 4 to Scalar1

disp Scalar1 Display a value of Scalar1

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-20 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

A typical use of an array requires access to a specific element of the array. To specify an element
of an array the array name must be followed by index specification. For example:
Declare local integer Ar1 of size 100 and
int Ar1(100),Ar2(3)(100)
local integer Ar2 of size 3x100
Ar1(4) = 3000 Assign 3000 to element 4of Ar1

Ar2(0)(99) = 20 Assign 20 to the element of Ar2

disp Ar2(0)(99) Display the element of Ar2

Indexing of arrays starts from zero. In the example above the first element of Ar1 has index 0, the
last element has index 99.
For information on saving user arrays in the nonvolatile memory, see Nonvolatile Memory
Management Commands, page 4-38.

5.5.2. Standard Arrays

Standard variables include both scalar and one-dimensional arrays. For example, variable S_ST
(System State) is scalar, while variable FPOS (Feedback Position) is an array of size 8.
Standard arrays are predefined in the controller as other standard variables. Therefore the size of a
standard array is fixed and cannot be defined in a declaration. Use the #VS and #VSF terminal
commands to have the controller provides a list of standard variables
Many standard arrays are sized according to the axis number (eight elements). Such arrays contain
one element per each controlled axis or motor. For example, each element of read-only variable
FPOS reads a feedback position of the corresponding motor. FPOS(0) provides the position of
the X motor, FPOS(1) – position of Y motor, and so on.
Other standard variables are related to the program buffers and therefore are sized according to
the number of buffers. For example, each element of PRATE specifies a program rate of the
corresponding buffer.
There are no two-dimensional arrays among the standard variables. Only user arrays can be
declared as two-dimensional.

5.5.3. Explicit Indexing

Explicit indexing is applicable to both standard and user arrays. To access a specific element of an
array, the array name must be followed by one or two indexes. Each index must be enclosed in
parenthesis. A one-dimensional array requires one index and two-dimensional array requires two
indexes.
The following is the syntax of index specification:
indexing :
( expression )
( expression ) ( expression )

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-21

For example:
Declare local real Ar1 of size 100 and local
real Ar1(100),Ar2(2)(8)
integer Ar2 of size 2x8
int J Declare local integer scalar J

Ar1(0) = 0 Assign 0 to the element 0 of Ar1

J = 0 Assign 0 to J

loop 99 Repeat 99 times

Ar1(J+1) = Ar1(J) + 1 Fill Ar1 with sequential numbers 0..99

J = J + 1 Increment

end End of loop

J = 0 Assign 0 to J

loop 8 Repeat for each axis

Ar1(0)(J) = FPOS(J) Store current FPOS in Ar1

Ar1(1)(J) = PE(J) Store current PE in Ar1

J = J + 1 Increment

end End of loop

5.5.4. Axis-Like Indexing of Standard Arrays

Axis-like indexing uses a two-character prefix, consisting of an axis letter and underscore,
attached to a standard array name. For example, X_FPOS is equivalent to FPOS(0) and reads the
feedback position of the X motor, and Y_ERRI is equivalent to ERRI(1) that specifies a tolerable
position error for the Y motor.
Axis-like indexing is applicable only to standard arrays that contain axis- or motor-related values.
User variables cannot accept axis-like indexing.
Any element of the axis- or motor-related standard array can be accessed with an axis-like index.
For example:
X_VEL corresponds to VEL(0)
Y_VEL corresponds to VEL(1)
Z_VEL corresponds to VEL(2)
T_VEL corresponds to VEL(3)
A_VEL corresponds to VEL(4)
B_VEL corresponds to VEL(5)
C_VEL corresponds to VEL(6)
D_VEL corresponds to VEL(7)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-22 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Note that explicit index can be either constant or expression, while axis-like index is always
constant.

MODEL
DEPENDENT The number of axes depends on the controller model. For example,
a four-axis model would support only X, Y, A, B as axis-like
indexes (or 0, 1, 4, 5 as the corresponding explicit indexes).

Axis-like indexes and explicit indexes can be used interchangeably in one program. However, it is
recommended to select one style and to use it throughout the application.

5.5.5. Postfix Indexing of Standard Arrays

Postfix indexing consists of a number appended to a standard array name without parenthesis. For
example, FPOS0 is equivalent to FPOS(0) and X_FPOS; all three read the feedback position of
the X motor. ERRI1 is equivalent to ERRI(1) and Y_ERRI that specifies a tolerable position
error for the Y motor.
Postfix indexing is applicable to any standard array. User variables cannot accept postfix
indexing.
Postfix indexing is convenient if an element of a standard array is used in an application as a
separate variable. For example, elements of standard arrays V and I are often used as counters and
temporary variables. Postfix indexes allow using the elements as separate variables such as V0,
V22, I99.
Arrays IN and OUT (Digital Inputs and Digital Outputs) are also often used with postfix
indexing. The typical access to a digital input looks like
IN0.4

where the first number after name IN is a postfix index and selects a group of 32 inputs. The
number after the period is a bit specifier used to select one of the 32 bits.
Note that explicit indexing can be either constant or expression, while postfix indexing is always
constant.
Postfix indexing and explicit indexing can be used interchangeably in one program. However, it is
recommended to select one style and to use it throughout the application. If an application
requires non-constant indexing of axis-related variables, neither axis-like or post-fix indexing can
be used.

5.6. Using Variables

5.6.1. Querying Variables

The value of any variable can be displayed in response to a query command. See on page 5-65 for
a description of query commands.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-23

Examples:
?FPOS Query feedback positions of all motors
1003 4001 233000 1 0 -1 0 1
: Controller’s prompt
?X_FPOS Query feedback positions of the X motors
1003
:
?X_FPOS,Z_FPOS Query feedback positions of the X and Z motors
1003
233000
:
?GlobVar Query global user variable GlobVar
23.35
:
?0:LocVar Query local user variable LocVar from buffer 0
100
:
?0:LocVar,5:LocVar Query two local user variables from different
buffers
100
233.7
:

5.6.2. Variable as Operands in Expressions

Variables can be used as operands in expressions.
An array, as a unit, cannot be an operand in an expression. Only the array elements can be used.
Therefore the array name must be fully indexed to provide access to a specific element.
In addition, a bit specifier can be added to an integer variable to provide access to a specific bit
(See the fourth example below).
An expression is calculated each time that a command that includes the expression is executed.
During calculation of the expression each variable is substituted with its current value.
Examples:
X_RPOS - X_FPOS An arithmetical expression which produces
the position error of the X motor
RPOS(0) < FPOS(0) A logical expression which produces:
0 if the X position error is positive,
1 if the X position error is negative

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-24 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

2*(VEL(3) – LocVar) An expression that combines standard and

user variables
(IN0.3|IN0.4)^IN0.6 A logical expression that uses bit specifiers to
access specific digital inputs
V0 An expression that contains only one variable
with no operations

5.6.3. Variables as Arguments in Command or Function

Variables can be used as arguments in commands and functions.
Arguments used to specify commands and functions have specific requirements.. In a typical
example, an argument is required to be an expression. In this case a single variable can be used as
a simplest case of expression. Use of variables in expressions is discussed in Variable as Operands
in Expressions, page 5-23.
A number of commands and functions require a variable or an array as one of their arguments.
For example, the first argument of the dc command (Data Collection) is an array that accumulates
the collected data. Other examples are statistical functions max, min, avg that process the whole
array specified as an argument. Unlike their use in expressions, an array name without indexes
specifies the array as a whole.
For example, the following fragment collects data 1000 times on the FPOS for the X axis at
intervals of V0:
dc Data,1000,V0,FPOS(0)

Explanation: The first argument of the dc command is required to be an array. The user array
Data is specified without indexes, as a whole.
The second argument is an expression that defines the number of samples to be collected.
Constant 1000 is a simple expression.
The third argument is an expression that defines the sampling period. Variable V0 is a simple
expression. Using a variable instead of constant provides changing the sampling period, based on
V0, from one execution of this data collection to another.
The fourth argument must be a variable or an array element. The values of the variable (in this
case V0) will be collected in the array. The syntax of DC requires that the fourth element be a
variable or an array element. Neither a general expression nor an array without indexes can be
specified. An array without indexes neither can be specified. FPOS(0) addresses element 0 of the
array FPOS that corresponds to the X feedback position.

5.6.4. Assignment to Variable

A variable can be specified in the left part of an assignment command.
The controller executes assignment in the following order:
1. Calculate right-side expression.
2. Convert the type of the result to the type of the left-side variable.
3. Assign the result to the left-side variable.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-25

After assignment, the previous value of the variable is erased and the variable stores the new
value.
The left side of an expression can appear in several forms:
ƒ Standard or user variable
ƒ One element of standard or user array
ƒ One bit of integer variable or integer array element
Assigning to a standard variable is limited by the following rules:
ƒ Assignment to read-only variable (for example, FPOS) is prohibited
ƒ Assignment to a protected variable (for example, ERRI) is allowed in configuration mode
(see Section 5.10).
Examples:
VEL(0) = 1000 Assign 1000 to X default velocity - explicit indexing

X_VEL = 1000 The same as above - axis-like indexing

VEL0 = 1000 The same as above - postfix indexing

Var1 = FPOS(0) Assign to user variable

Var2(0)(5) = 200 Assign to element of user array

OUT0.5 = 1 Assign to digital output 5

5.6.5. Variables in ACSPL+ Terminal Commands

Immediate execution of the ACSPL+ commands is described in 4.4.7.3 Immediate Execution of
Motion Command. A command executed immediately is not included in a program or stored in a
buffer.
Use of variables in immediate ACSPL+ commands is limited to standard and global variables.
Local variables cannot be referenced in immediate ACSPL+ commands.

5.7. Functions
The ACSPL+ variable declaration types (page 5-17) are also used for function arguments and
function return value types (if a function does not return a value, the return type is void).
The following table briefly summarizes each function:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-26 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

5.7.1. List of Functions

TABLE 5-4 Functions

ARITHMETICAL FUNCTIONS
NAME ACTION SEE PAGE
abs Calculates the absolute value 5-28
acos Calculates the arccosine 5-28
asin Calculates the arcsine 5-29
atan Calculates the arctangent 5-29
atan2 Calculates the arctangent of Y/X 5-30
ceil Calculates the ceiling of a value 5-30
cos Calculates the cosine 5-31
exp Calculates the exponential 5-31
floor Calculates the floor of a value 5-32
hypot Calculates the hypotenuse 5-32
idexp Calculates a value of x*2exp 5-33
log Calculates the natural logarithm 5-33
log10 Calculates the base-10 logarithm 5-34
pow Calculates x raised to the power of y 5-34
sin Calculates the sine 5-35
sqrt Calculates the square root 5-35
tan Calculates the tangent 5-35
sign Returns -1, 0 or 1 depending on the sign of x 5-36

STATISTICAL FUNCTIONS

NAME ACTION SEE PAGE

min Finds the minimal value in an array 5-36
max Finds the maximal value in an array 5-37
avg Finds the average of all values in an array 5-37

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-27

SIGNAL PROCESSING FUNCTIONS

NAME ACTION SEE PAGE

deadzone Implements dead-zone routine 5-38
dsign Implements a dynamic version of the 5-39
standard sign function.
edge Returns 1 on positive edge of x 5-39
intgr Implements an integrator with deadzone and 5-42
saturation.
lag Provides delayed switching on argument 5-43
change (anti-bouncing effect)
map Implements a table-defined function with 5-44
constant step
mapby1 Implements a table-defined function with 5-45
variable step.
mapby2 Implements a table-defined function with 5-45
variable step.
map2 Implements a table-defined function with two 5-46
arguments and constant step along each
argument.
map2free Implements a table-defined function with two 5-47
arguments and variable step along each
argument.
roll Calculates a result rolled-over to within one 5-49
pitch.
sat Implements a saturation characteristic 5-49

SERVO PROCESSOR FUNCTIONS

NAME ACTION SEE PAGE

getsp Reads a value from the specified SP address 5-53
setsp Writes a value to the specified SP address 5-54
monosp Initiates monitoring of the specified SP 5-53
address through analog output

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-28 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

MISCELLANEOUS FUNCTIONS

NAME ACTION SEE PAGE

sysinfo Returns a value containing system 5-55
information.
input Receives numerical values from a 5-56
communication channel and assigns them to
variables.
getconf Reads hardware and firmware parameters. 5-66
setconf Writes hardware and firmware parameters. 5-57

5.7.2. Arithmetical Functions

The controller provides for the use of Arithmetical, Statistical, and Signal-processing functions.
NOTE

Angular functions are in radians.

5.7.2.1. abs
Calculates the absolute value.

real abs(real x)
Arguments

x Any real or integer expression.

Return value

real The abs function returns the absolute value of x.

Error conditions
None.
Example
disp abs(-3.14)

Output
3.14

5.7.2.2. acos
Calculates the arccosine.

real acos(real x)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-29

Arguments

x Any real or integer expression.

Return value

real The acos function returns the arccosine of x in the range 0 to π

radians.
Error conditions
Run-time error if the argument is beyond the range –1 to 1.
Example
disp acos(-1)

Output
3.141592654

5.7.2.3. asin
Calculates the arcsine.

real asin(real x)
Arguments

x Any real or integer expression.

Return value

real The asin function returns the arcsine of x in the range –π/2 to π/2
radians.
Error conditions
Run-time error if the argument is beyond the range –1 to 1.
Example
disp asin(-1)

Output
-1.570796327

5.7.2.4. atan
Calculates the arctangent.

real atan(real x)
Arguments

x Any real or integer expression.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-30 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Return value

real The atan function returns the arctangent of x in the range –π/2 to π/2
radians.
Error conditions
None.
Example
disp atan(-1)

Output
-0.7853981634

5.7.2.5. atan2
Calculates the arctangent of Y/X.

real atan2(real X, real Y)

Arguments

Y,X Any real or integer expressions.

Return value

real The atan2 function returns the arctangent value of Y/X. atan2
calculates a value in the range -p to p radians, using the signs of both
parameters to determine the quadrant of the return value. If both
parameters of atan2 are 0, the function returns 0. atan2 is well
defined even if x equals 0.

Error conditions
None.
Example
real XArg, YArg

XArg = -1; YArg = 0

disp atan2(YArg,XArg), atan2(XArg,YArg)

Output
3.1459

5.7.2.6. ceil
Calculates the ceiling of a value.

real ceil(real x)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-31

Arguments

x Any real or integer expression.

Return value

real The ceil function returns a value representing the smallest integer that
is greater than or equal to x.
Error conditions
None.
Example
disp ceil(3), ceil(-3), ceil(2.1), ceil(-2.1)

Output
3 -3 3 -2

5.7.2.7. cos
Calculates the cosine.

real cos(real x)
Arguments

x Any real or integer expression.

Return value

real The cos function returns the cosine value of x in the range –1 to 1.
Error conditions
None.
Example
disp cos(3.141592654)

Output
-1

5.7.2.8. exp
Calculates the exponential.

real exp(real x)
Arguments

x Any real or integer expression.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-32 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Return value

real The exp function returns the exponential value of x. On overflow, the
function returns the largest real number.
Error conditions
None.
Example
disp exp(1)

Output
2.718281828

5.7.2.9. floor
Calculates the floor of a value.

real floor(real x)
Arguments

x Any real or integer expression.

Return value

real The floor function returns a value representing the largest integer that
is less than or equal to x.
Error conditions
None.
Example
disp floor(3), floor(-3), floor(2.1), floor(-2.1)

Output
3 -3 2 -3

5.7.2.10. hypot
Calculates the hypotenuse.

real hypot(real X, real Y)

Arguments

Y,X Any real or integer expression.

Return value

real The hypot function calculates the length of the hypotenuse of a right
triangle, given the length of the two sides x and y. A call to hypot is
equivalent to the square root of x2 + y2.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-33

Error conditions
None.
Example
disp hypot(3,4)

Output
5

5.7.2.11. ldexp
Calculates a value of x * 2exp.

real ldexp(real x, real exp)

Arguments

x,exp Any real or integer expressions.

Return value

real The ldexp function returns the value of x * 2exp. On overflow ldexp
returns the largest real number with sign depending on the sign of x.
Error conditions
None.
Example
disp hypot(3,4)

Output
5

5.7.2.12. log
Calculates natural logarithm.

real log(real x)
Arguments

x Any real or integer expression.

Return value

real The log function returns the natural logarithm of x.

Error conditions
Run-time error if the argument is less or equal to zero.
Example
disp log(2.718281829)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-34 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Output
1

5.7.2.13. log10
Calculates the base-10 logarithm.

real log10(real x)
Arguments

x Any real or integer expression.

Return value

real The log10 function returns the base-10 logarithm of x.

Error conditions
Run-time error if the argument is less or equal to zero.
Example
disp log10(10)

Output
1

5.7.2.14. pow
Calculates x raised to the power of y.

real pow(real x, real y)

Arguments

x,y Any real or integer expressions.

Return value

real The ldexp function returns the value of xy. On overflow ldexp
returns the largest real number with sign depending on the sign of x.
Error conditions
None.
Example
disp pow(2,3)

Output
8

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-35

5.7.2.15. sin
Calculates the sine.

real sin(real x)
Arguments

x Any real or integer expression.

Return value

real The sin function returns the sine value of x in the range –1 to 1.
Error conditions
None.
Example
disp sin(1.570796327)

Output
1

5.7.2.16. sqrt
Calculates the square root.

real sqrt(real x)
Arguments

x Any real or integer expression.

Return value

real The sqrt function returns the square-root of x.

Error conditions
Run-time error if the argument is less than zero.
Example
disp sqrt(4)

Output
2

5.7.2.17. tan
Calculates the tangent.

real tan(real x)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-36 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Arguments

x Any real or integer expression.

Return value

real The tan function returns the tangent value of x.

Error conditions
None.
Example
real Pi

Pi = 3.141592654
disp tan(Pi/4)

Output
1

5.7.2.18. sign
Returns -1, 0 or 1 depending on the sign of x.

real sign(real x)
Arguments

x Any real or integer expression.

Return value

real The sign function returns:

-1 if x < 0
0 if x = 0
1 if x > 0
Error conditions
None.
Example
disp sign(-5),sign(0),sign(5)

Output
-1 0 1

5.7.3. Statistical Functions

5.7.3.1. min
Finds the minimal value in an array.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-37

real min(array x)
Arguments

x Any real or integer array.

Return value

real The sign function returns the minimal element in array x.

Error conditions
None.
Example
real Ar(3)

Ar(0)= 1; Ar(1)= 0.5; Ar(2)= 3;

disp min(Ar)

Output
0.5

5.7.3.2. max
Finds the maximal value in an array.

real max(array x)
Arguments

x Any real or integer array.

Return value

real The max function returns the maximal element in array x.

Error conditions
None.
Example
real Ar(3)

Ar(0)= 1; Ar(1)= 0.5; Ar(2)= 3;

disp max(Ar)

Output
3

5.7.3.3. avg
Finds the average of all values in an array.

real avg(array x)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-38 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Arguments

x Any real or integer array.

Return value

real The avg function returns the average of all elements in array x.
Error conditions
None.
Example
real Ar(3)
Ar(0)= 1; Ar(1)= 0.5; Ar(2)= 3;

disp avg(Ar)

Output
2.25

5.7.4. Signal Processing Functions

See Signal-Processing Function, page 5-50 for examples of implementation of some of these
functions.

5.7.4.1. deadzone
Implements dead-zone routine.

real deadzone(real x, real zone)

Arguments

x,zone Any real or integer expressions.

Return value

real The deadzone function returns:

x+zone, if x<-zone
0, if –zone<x<zone
x-zone, if x>zone
Error conditions
Run-time error if the zone is less than zero.
Example
The command
Fun = deadzone(Arg, 10)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-39

provides the following motion:

Fun

-10 +10
Arg

The command
Fun = deadzone(Arg-5, 10)
Implements an asymmetrical deadzone:

Fun

-5 +15
Arg

5.7.4.2. dsign
Implements a dynamic version of the standard sign function (reflects change over time).

int dsign(real X, real Delay, real Ramp)

Arguments

X Argument of the function. Any real or integer expression.

Delay Anti-bouncing delay (milliseconds). Must be positive number.
Ramp Rate of the result change. Specifies the time in milliseconds that the
function takes to change the result from –1 to +1 and vice versa. Must
be positive number.
Return value

int –1 or +1 (see remarks below).

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-40 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Error conditions
None.
Remarks
The standard sign function returns the following result:
-1 if X < 0
0 if X = 0
+1 if X > 0
The dsign function adds the following:
• If X is zero, the function retains its previous value
• If Delay is positive the function provides anti-bouncing effect
• If Ramp is positive the function restricts the rate of change from –1 to +1 and
vice versa
If X = 0, instead of returning 0 the function retains its previous value. If X = 0 when the
function is called the first time, the function returns +1.
If Ramp is zero, the function returns only two values: –1 or +1.
If Delay and Ramp are both zero, the function immediately returns +1 when X > 0 and
immediately returns –1 when X < 0.
If Delay is positive, the function provides an anti-bouncing effect, namely:
• The function changes its result to +1 if X becomes positive and remains positive
for at least Delay milliseconds
• The function changes its result to -1 if X becomes negative and remains negative
for at least Delay milliseconds
Positive Ramp affects the function as follows:
When the function result must change from –1 to +1 or vice versa, it does not change
immediately. Instead, the process of change takes Ramp milliseconds and each millisecond
the result value gets incremented by ±2/Ramp.

5.7.4.3. edge
Returns 1 on positive edge of x (see discussion below).

int edge(real x)
Arguments

x Any real or integer expression.

Return value

real The edge function returns:

1, if the current value of x is non-zero and the previous value
was zero,
0 in all other cases

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-41

Error conditions
None.
Remarks
Unlike most functions, the edge function is dynamic; it depends not only on the present value of
argument, but also on the previous values.
Although the function accepts any real or integer argument, the typical use implies the logical
argument; an integer variable or expression that can supply only the values 0 or 1. For arguments
that supply only the values 0 or 1, the positive edge is defined as the moment when the argument
changes from 0 to 1. For an argument that supplies values other than 0 and 1, the function
considers positive edge as the moment when the argument changes from zero to a non-zero value.
The exact operation of the function follows the algorithm:
ƒ On each call of the function the current value of x is stored in the internal storage.
ƒ On each call except the first, the function returns 1 if the current value of x is non-zero and
the stored previous value is zero. Otherwise the function returns 0.
ƒ On the first call the function always returns 0.
The following diagram shows the results of the edge function that is called in a program
periodically with period T:

Argument 1

Result 1

0 0 0 0 0
T 2T 3T 4T 5T

The edge function returns 1 only once after the positive edge of argument.
If the argument reaches 1 only for the brief period between successive calls of the edge function,
and then returns to zero, the edge function may miss the edge. An example is shown in the next
diagram where the first positive edge (A) of the argument is missed.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-42 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Argument 1
A
0

Result 1

0 0 0 0 0

T 2T 3T 4T 5T

Time

The edge function is used primarily in PLC programs if an action must be taken only once when a
condition becomes true.
The edge function is rarely used in autoroutine conditions, because the autoroutine facility
includes built-in edge detection.

5.7.4.4. intgr
Implements an integrator with deadzone and saturation.

real intgr(real X, real Deadzone, real Min, real Max)

Arguments

X Argument of the function. Any real or integer expression.

Deadzone Dead zone.
Min Low saturation value.
Max High saturation value.
Return value

real The value in the range from Min to Max.

Error conditions
None.
Remarks
The function implements integration of the argument.
If the Deadzone argument is non-zero, the function also implements input dead zone. If the
X argument falls into the range from –Deadzone to +Deadzone the function retains its
previous value as if the X is zero.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-43

The Min and Max arguments define a working range of the integrator so that the result of
the function is always within the range from Min to Max.

5.7.4.5. lag
The function provides delayed switching on argument change (anti-bouncing effect).

int lag(real X, real UpDelay, real DownDelay)

Arguments

X Input signal represented by any real or integer expression.

UpDelay Delay on positive edge. Must be positive number.
DownDelay Delay on negative edge. Must be positive number.
Return value

int The lag function returns:

1 if X remains non-zero for at least UpDelay milliseconds,
0 if X remains zero for at least DownDelay milliseconds,
or retains its previous value in all other conditions.
Error conditions
None.
Remarks
The lag function is dynamic; it depends not only on the present value of the X argument, but also
on the previous values returned by lag.
Although the lag function accepts any real or integer argument for X, the typical use implies a
logical X argument: an integer variable or expression that can supply only 0 or 1. If X supplies
values other than 0 or 1, the function treats any non-zero value as 1.
The function implements the following algorithm each time that it is called:
• the current value of X and the function return are stored internally.
• the function detects if the current X has changed from zero to non-zero or vice versa. If the
change has occurred, the function also stores the current system time as the last transition
time.
• the function calculates the time interval between the current system time and the stored last
transition time and returns one of the following:
♦ 0, if X is zero and the interval is at least DownDelay milliseconds
♦ 1, if X is non-zero and the interval is at least UpDelay milliseconds
♦ the stored previous return if none of above is true.
The following diagram shows the results of the lag function, given that the function is called
periodically at T intervals.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-44 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Argument
1

0
Time
Result 1 1 1 1 1

0 0 0 0 0 0
T

1 2 3 4

The following table describes what lag does at points 1, 2, 3, and 4:

POINT EXPLANATION

1 The function detects the change of argument and stores the current system time as
the last transition time, Ts = TIME.
2 The time interval between the current system time and the last transition time
becomes more than UpDelay: TIME – Ts >= UpDelay. As the argument is
non-zero, the function returns 1.
3 The function detects the change of argument and stores the current system time as
the last transition time, Ts = TIME.
4 The time interval between the current system time and the last transition time
becomes more than DownDelay: TIME – Ts >= DownDelay. As the
argument is zero, the function returns 0.

5.7.4.6. map
Implements a table-defined function with constant step.

real map(real X, real Table, real Base, real Step)

Arguments

X Argument of the table-defined function. Any real or integer

expression.
Table One-dimensional array that specifies the equally spaced function
values.
Base Argument base, the value of the argument that corresponds to the first
value in the table. Only constant values are allowed.
Step Argument step, the time interval between the table values. Only
positive constant values are allowed.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-45

Return value

real The value of the function interpolated linearly.

Error conditions
None.
Remarks
The Table argument is a one-dimensional array that specifies the function values. The 0th
element of the array corresponds to the argument value Base, the second – to Base+Step,
the n-th – to Base+(n-1)*Step.
If the array contains N elements, the range of definition of the function is from Base to
Base+(N-1)*Step.
If the value of argument X falls within the range of definition, the function provides linear
interpolation between the specified points.
If the value of argument X falls beyond the range of definition, the function returns 0.

5.7.4.7. mapby1
Implements a table-defined function with variable step. The first row of the table defines
argument values, the second – function values.

real mapby1(real X, real Table)

Arguments

X Argument of the table-defined function. Any real or integer

expression.
Table Two-dimensional array that contains two rows. The first row defines
argument values, the second – function values.
Return value

real The value of the function interpolated linearly.

Error conditions
None.
Remarks
The Table argument is a two-dimensional array that contains two rows (Nx2). The first row
defines argument values, the second – function values. Each column contains a pair of
argument-function values.
Using the same Table array, the function implemented by mapby1 is inverse relating to the
function implemented by mapby2.
The values of argument in the first row must follow in strictly ascending order.
If the array contains N columns, the range of definition of the function is from Table(0)(0)
to Table(0)(N-1).

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-46 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

If the value of argument X falls within the definition range, the function provides linear
interpolation between the specified points.
If the value of argument X falls beyond the definition range, the function returns value of
argument X.

5.7.4.8. mapby2
Implements a table-defined function with variable step. The second row of the table defines
argument values, the first – function values.

real mapby2(real X, real Table)

Arguments

X Argument of the table-defined function. Any real or integer

expression.
Table Two-dimensional array that contains two columns. The second row
defines argument values, the first – function values.
Return value

real The value of the function interpolated linearly.

Error conditions
None.
Remarks
The Table argument is a two-dimensional array that contains two rows. The second row
defines argument values, the first – function values. Each column contains a pair of
argument-function values.
Using the same Table array, the function implemented by mapby1 is inverse relating to the
function implemented by mapby2.
The values of argument in the second column must follow in strictly ascending order.
If the array contains N columns, the range of definition of the function is from Table(1)(0)
to Table(1)(N-1).
If the value of argument X falls within the definition range, the function provides linear
interpolation between the specified points.
If the value of argument X falls beyond the definition range, the function returns value of
argument X.

5.7.4.9. map2
Implements a table-defined function with two arguments and constant step along each argument.

real map(real X, real Y, real Table, real Base1, real

Step1, real Base2, real Step2)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-47

Arguments

X First argument of the table-defined function. Any real or integer

expression.
Y Second argument of the table-defined function. Any real or integer
expression.
Table Two-dimensional array that specifies the equally spaced function
values.
Base1 First argument base, the value of the argument that corresponds to the
first column in the table. Only constant values are allowed.
Step1 First argument step, the time interval between the table values. Only
positive constant values are allowed.
Base2 Second argument base, the value of the argument that corresponds to
the first row in the table. Only constant values are allowed.
Step2 Second argument step, the time interval between the table rows. Only
positive constant values are allowed.
Return value

real The value of the function interpolated linearly.

Error conditions
None.
Remarks
The Table argument is a two-dimensional array (matrix) that specifies the function values.
The values in the matrix correspond to the points of plane. Argument X corresponds to
horizontal direction in the plane and in the matrix, Argument Y corresponds to vertical
direction in the plane and in the matrix.
The 0th column of the array corresponds to the X argument value Base1, the second – to
Base1+Step1, the n-th – to Base1+n*Step1.
The 0th row of the array corresponds to the Y argument value Base2, the second – to
Base2+Step2, the n-th – to Base2+n*Step2.
If the array contains M rows and N columns, the range of definition of the function is
Base1 <= X <= Base1+(N-1)*Step1 and Base2 <= Y <= Base2+(M-1)*Step2.
If the values of arguments X, Y fall within the definition range, the function provides linear
interpolation between the specified points.
If at least one of the values of arguments X, Y falls beyond the definition range, the
function returns zero.

5.7.4.10. map2free
Implements a table-defined function with two arguments and variable step along each argument.

real map(real X, real Y, real Table)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-48 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Arguments

X First argument of the table-defined function. Any real or integer

expression.
Y Second argument of the table-defined function. Any real or integer
expression.
Table Two-dimensional array that specifies function values and values of
arguments (see Remarks).
Return value

real The value of the function interpolated linearly.

Error conditions
None.
Remarks
The Table argument is a two-dimensional array (matrix) that specifies the function values
and values of arguments. The values of arguments are added to the matrix of function
values as the 0th row and 0th column.
The function values in the matrix correspond to the points of plane. Argument X
corresponds to horizontal direction in the plane and in the matrix, Argument Y corresponds
to vertical direction in the plane and in the matrix.
The Table defines the values on a grid of points spaced non-equally. If the array contains
M rows and N columns, the grid contains (M-1)x(N-1) points. The X coordinate of each
vertical in the grid is specified by the elements Table(0)(1), Table(0)(2),…, Table(0)(N-1).
The Y coordinate of each horizontal in the grid is specified by the elements Table(1)(0),
Table(2)(0),…, Table(M-1)(0).
Element Table(0)(0) is not used.
A general matrix element Table(m)(n) has the following meaning:
ƒ m=0, n=0: the element is not in use
ƒ m=0, 1<=n<=N-1: the element specifies an X coordinate in the grid of points
ƒ 1<=m<=M-1, n=0: the element specifies an Y coordinate in the grid of points
ƒ 1<=m<=M-1, 1<=n<=N-1: the element specifies a function value in the
corresponding point
The range of definition of the function by the X argument is from Table(0)(1) to
Table(0)(N-1).
The range of definition of the function by the Y argument is from Table(1)(0) to
Table(M-1)(0).
The values of arguments in the 0th row and 0th column must follow in strictly ascending
order.
If the values of arguments X, Y fall within the definition range, the function provides linear
interpolation between the specified points.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-49

If at least one of the values of arguments X, Y falls beyond the definition range, the
function returns zero.

5.7.4.11. roll
Calculates a result rolled-over to within one pitch. The function is a real-number equivalent of the
integer modulo operation.

real roll(real X, real Pitch)

Arguments

X Argument of the function. Any real or integer expression.

Pitch One-pitch value. The result is rolled-over to within the range from 0
to Pitch. Only positive constant values are allowed.
Return value

real The rolled-over value in the range from 0 to Pitch.

Error conditions
None.
Remarks
The function is a real-number equivalent of the integer modulo operation.
If the argument falls within the range from 0 to Pitch, the function simply returns the value
of the argument. In the range from Pitch to 2*Pitch the result is the argument minus Pitch,
in the range from –Pitch to 0 the result is the argument plus Pitch and so on.

5.7.4.12. sat
Implements a saturation characteristic.

real sat(real X, real Min, real Max)

Arguments

X Argument of the function. Any real or integer expression.

Min Low saturation value.
Max High saturation value.
Return value

real The value in the range from Min to Max.

Error conditions
None.
Remarks
The function returns the following result:
Min if X < Min

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-50 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

X if Min <= X <= Max

Max if X > Max

5.7.4.13. Signal-Processing Function Examples

5.7.4.13.1. Encoder Error Compensation With Constant Step

Assume an axis was calibrated with a laser interferometer. The calibration process includes
positioning to the points equally spaced according to the encoder feedback, and measuring the
exact positions by the laser interferometer. The calibration points start from the coordinate 10000
and follow each 1000 counts. The last calibration point is 20000.
The calibration produced the following table:
Feedback 10000 11000 12000 13000 14000 15000 16000 17000 18000 19000 20000
Actual 10012 10998 11985 12981 13997 15007 16013 17023 18005 18993 19991
Error +12 -2 -15 -19 -3 +7 +13 +23 +5 -7 -9
Only the third row is entered to a controller variable and is stored in nonvolatile (flash) file
X_ERROR. Details of the calibration routine, which can be implemented on ACSPL+, are not
discussed here.
An application that uses the file may provide an initialization routine like this:
real X_ERR(11)

AUTOEXEC: Standard label of initialization routine

read X_ERR,X_ERROR Read calibration table from the nonvolatile (flash)

connect X_RPOS = APOS – map (X_APOS, X_ERR, 10000, 1000)

stop Finish initialization

The connect function specifies that the reference position be calculated by subtracting the
interpolated error from the desired position so that the actual value will be closer to the desired
value.

5.7.4.13.2. Encoder Error Compensation With Arbitrary Step

Assume in the above example that the calibration routine does not calculates an error, but writes
the first two lines from the above table to nonvolatile (flash) file X_CALIBR. The table is stored
as an array with 2 rows and 11 columns.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-51

In this case the application can implement an initialization routine like this:
real X_CAL(2)(11)

AUTOEXEC: Standard label of initialization routine

read X_CAL,X_CALIBR Read calibration table from the nonvolatile (flash)

connect X_RPOS = mapby2(X_APOS, X_CAL)

stop Finish initialization

And the file X_CALIBR can contain also a table with non-uniform points.

5.7.4.13.3. Backlash Compensation

Assume that the X axis has a backlash of 20 counts. The following connect command
compensates for the backlash:
connect X_RPOS = X_APOS + 10*dsign(X_RVEL, 0, 0)

By using this connect, the value added to desired position changes immediately when the
direction of the motion changes. In many cases such jumps in the desired position are harmful. In
this case the third parameter in the dsign function can be used to gradually implement the
backlash compensation. In the following example the backlash compensation is introduced by
small steps, so that the compensation growth to the entire value by 20 milliseconds:
connect X_RPOS = X_APOS + 10*dsign(X_RVEL, 0, 20)

If the X axis executes master-slave motion slaved to some physical value like encoder feedback,
the RVEL value contains noise that can cause undesirable switching of the backlash sign. In this
case the second parameter of the dsign function can be used to introduce antibouncing effect. In
the following example the backlash compensation changes its sign only if RVEL holds its new
sign for more than 10 milliseconds:
connect X_RPOS = X_APOS + 10*dsign(X_RVEL, 10, 20)

5.7.4.13.4. Compensation of Encoder Error and Backlash

An arbitrary expression can be used as an argument in the dsign function and in the map-
functions. It ensures combining different compensation function and other required
transformations in one connect command. The following example combines error and backlash
compensations from the above examples:
real X_CAL(2)(11)

AUTOEXEC: Standard label of initialization routine

read X_CAL,X_CALIBR Read calibration table from the nonvolatile (flash) memory

connect X_RPOS = mapby2(X_APOS+10*dsign(X_RVEL, 10, 20), X_CAL)

stop Finish initialization

5.7.4.13.5. Cam Motion

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-52 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Assume that the Y axis must provide a cam motion following the X axis. File CAMTABLE in the
nonvolatile (flash) memory contains 2 rows and 1000 columns. Each column contains an X
coordinate in the first row and the corresponding Y coordinate in the second row. The X
coordinates in the first row can be spaced either equally or non-equally.
The following fragment initializes the cam motion:
real CAMTABLE(2)(1000)

read CAMTABLE,CAMTABLE Read calibration table from the

nonvolatile (flash) memory
master Y_MPOS = mapby1(X_FPOS, CAMTABLE) Define master value via cam table

slave Y Start master-slave motion

5.7.4.13.6. Joystick
Assume that a joystick that controls the motion of an XY table is connected to analog inputs
AIN0, AIN1. The velocity of each coordinate must be proportional to the corresponding analog
input. Analog input lower than 20 counts must be ignored to avoid motion due to analog drift or
bias. The X motion is limited in the range from –500 to 100000 counts. The X motion is limited
in the range from –500 to 500000 counts.
The following program fragment initializes the joystick motion:
real JK

JK = 10 Joystick factor

master X_MPOS = intgr(AIN0, 20, -500, 100000) Define X master

master Y_MPOS = intgr(AIN1, 20, -500, 500000) Define Y master

slave Y; slave Y Start master-slave motion

5.7.5. Servo Processor Functions

ADVANCED
These functions are for users who work with SP programs, (see page 3-
5).

Use Servo Processor functions to read, write and monitor SP values.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-53

MODEL
DEPENDENT
The quantity of Servo Processors is model-dependent. Check the
controller Hardware Guide.

5.7.5.1. getsp
Reads a value from the specified SP address.

int getsp(int SP, int Address)

Arguments

SP SP number in the controller. Legal values range from zero to 3,

depending on the controller model.
Address Address within the SP. Look up addresses using either:
• SPiiPlus MMI | Tools | SP Monitor or
• SPiiPlus MMI | Tools | SPiiScope | Set | Change | Select –
choose Name, then select a variable in the list: its address
will be displayed.
Return value

int The current value read from the specified SP address.

Error conditions
The function causes an error if an SP number is specified other than 0, 1, 2 or 3.
The function causes an error if an illegal address is specified.
Remarks
The read value is treated as a signed integer number.
The function returns immediately if the address lies in an area accessible directly from MPU.
Otherwise the function provides delay by one controller cycle.

5.7.5.2. monsp
Initiates monitoring of the specified SP address through an analog output.

void monsp(int AOut, int SP, int Address, int Shift)

Arguments

Aout Index of the analog output to be used for monitoring.

SP SP number in the controller. Legal values range from 0 to 3,
depending on the controller model.
Address Address within the SP. Look up addresses using either:
• SPiiPlus MMI | Tools | SP Monitor or

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-54 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

• SPiiPlus MMI | Tools | SPiiScope | Set | Change | Select –

choose Name, then select a variable in the list: its address
will be displayed.
Shift Scaling shift of the monitored value. Positive number specifies left
shift, negative number specifies right shift.
Return value

none
Error conditions
The function causes an error if:
• the specified analog output is illegal or cannot be used with the specified SP
• the SP number specified isn't legal
• the address specified is illegal
Remarks
An address from a specific SP can be monitored only through analog output belonging to the
same SP. This rule applies limitations to possible values of arguments AOut and SP. Two
addresses from one SP can be monitored simultaneously.

Correspondence between the SP processor and analog outputs

depends on the number of SP processors in the controller:
MODEL
AOut SP
DEPENDENT
1, 3 0
5, 7 1
9, 11 2
13, 15 3

The function overwrites the value stored in the corresponding AOUT standard variable with a
special monitoring code. Once SP the receives the monitoring code, it starts transferring the value
from the specified address to the analog output. The SP also provides the required scaling shift of
the monitored variable.
The next assignment to the corresponding AOUT element overwrites the monitoring code and the
analog output returns to displaying the AOUT value.

5.7.5.3. setsp
CAUTION
The setsp function is for advanced users only. Misuse of this
function may damage your controller

Writes a value to the specified SP address.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-55

void setsp(int SP, int Address, int Value)

Arguments

SP SP number in the controller. Legal values range from 0 to 3,

depending on the controller model.
Address Address within the SP. Look up addresses using either:
• SPiiPlus MMI | Tools | SP Monitor or
• SPiiPlus MMI | Tools | SPiiScope | Set | Change | Select –
choose Name, then select a variable in the list: its address
will be displayed.
Value Value to write to the address.
Return value

none
Error conditions
The function causes an error if an illegal SP number is specified.
The function causes an error if an illegal address is specified.
Remarks
SP addresses can be looked up in the SPiiPlus MMI | Tools | SP Monitor. Some are accessible
from SP only, others from MPU only and the dual-port area from both SP and MPU. The function
writes a value to any of these areas. The only thing that the function cannot do is writing to a
write-only register – in this case the function does nothing.
The function returns immediately if the address lies in an area accessible directly from MPU.
Otherwise the function provides delay by one controller cycle

5.7.6. Other Functions

5.7.6.1. sysinfo
Provides access to system information.

int sysinfo(int key)

Arguments

key The following keys are supported:

1 – Model index.
2 – Version number
3 – Buffer number
6 – Available DPRAM size in bytes.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-56 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Return value
The meaning of the return integer depends on the calling argument.

key Returned value

1 Model index:
0 – Simulator
1 – Demo simulator
200 – SPiiPlus PCI-8
1000 – SPiiPlus PCI-DDM4A
2 Firmware version number – a four byte integer representing the
version number according to the format xx.yy.zz.tt, where x, y, z,
t stand for digits:
Byte 3 (most significant) contains numerical value of xx
Byte 2 contains numerical value of yy
Byte 1 contains numerical value of zz
Byte 0 contains numerical value of tt.
3 Buffer number. The function returns the number of the buffer in
which the function is executed.
4 The function returns the analog input range in millivolts.
5 The function returns the analog output range in millivolts.
6 Available DPRAM size on the card.
SPiiPlus PCI-8 card revision D and SPiiPlus PCI-DDM4A
card revision B contain 1024 bytes of DPRAM.
All previous revisions contain 512 bytes of DPRAM.

Error conditions
None.
Remarks
The sysinfo function accepts an integer argument and returns an integer value relating to that
argument.

5.7.6.2. input
int input(arg)
Arguments

arg Any integer or real array or scalar variable.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-57

Return value

int The number of inserted elements.

Error conditions
None.
Remarks
The input function accepts as an argument a scalar or array variable. The function delays program
execution until the host provides input.
The input from the host is expected to consist of one or more numbers separated by spaces or
commas and followed by a carriage return. The input function scans the numbers in the input and
stores them in the argument variable.
If the argument variable is scalar, the input function takes the first number in the input and stores
it in the argument variable.
If the argument is an array, the input function fills argument the array with the values from the
input.
The function execution is completed when the scalar is stored or the array is filled or a carriage
return is encountered.
Example:
int Ar(10)
. . .
input (Ar)

Program execution halts until input is received from the host.

Assume that a user enters: 20 30 40 <cr>
The program stores the three values in Ar(0), Ar(1), and Ar(2)and resumes
execution.
If the input array contains a function key code (zero character followed by an integer from 1 to
12), it is stored separately in the standard variable FK (Function Key, see page 11-30).

5.7.6.3. getconf

Use the getconf function to read system configuration data.

int getconf (key, index)

Arguments

Key Specifies the configured feature.

Index Specifies axis or buffer number

See setconf description below for detailed description of key argument.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-58 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Return value

Int Returns value of specified key.

Error conditions
None.

5.7.6.4. setconf
Use the setconf to write system configuration data.

setconf (key, index, value)

Arguments

Key Specifies the configured feature.

Index Specifies axis or buffer number
Value Value to write to specified key.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-59

MODEL SPiiPlus PCI-DDM4A: Drive alarms generated by this integrated

DEPENDENT model can be read with getconf (13, 0).
Constant current mode is supported only in this model and only for
axes Y and B. The mode can be turned on and off using setconf
(133,1,1) and setconf (133,1,0).

The following table lists supported values for key:

Key Index Comments

1 Ignored getconf retrieves configuration word 1.

setconf sets configuration word 1.
Configuration word 1 includes the following bits:
Bit 6 - HSSI connection: 0 - to user interface, 1: to X/Y
Bit 7 - Source for interrupt generation: 1 - PEG, 0 - SP output
3 Ignored getconf retrieves configuration word 3.
setconf sets configuration word 3.
Configuration word 3 includes the following bits:
Bit 3 – Interrupting edge of X PEG: 0 – positive, 1 – negative
Bit 4 – Interrupting edge of Y PEG: 0 – positive, 1 – negative
Bit 5 – Interrupting edge of Z PEG: 0 – positive, 1 – negative
Bit 6 – Interrupting edge of T PEG: 0 – positive, 1 – negative
Bit 7 – Interrupting edge of X MARK1: 0 – positive, 1 – negative
Bit 8 – Interrupting edge of X MARK2: 0 – positive, 1 – negative
Bit 9 – Interrupting edge of Y MARK1: 0 – positive, 1 – negative
Bit 10 – Interrupting edge of Y MARK2: 0 – positive, 1 – negative
Bit 11 – Interrupting edge of Z MARK1: 0 – positive, 1 – negative
Bit 12 – Interrupting edge of Z MARK2: 0 – positive, 1 – negative
Bit 13 – Interrupting edge of T MARK1: 0 – positive, 1 – negative
Bit 14 – Interrupting edge of T MARK2: 0 – positive, 1 – negative
Bit 15 – Interrupting edge of E-stop: 0 – positive, 1 – negative

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-60 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Key Index Comments

4 Ignored getconf retrieves configuration word 4.

setconf sets configuration word 4.
Configuration word 4 includes the following bits:
Bit 1 - Encoder X: 0 – A&B, 1 – analog (not supported in this
version)
Bit 2 - Encoder A: 0 – A&B, 1 – analog (not supported in this
version)
Bit 3 - Encoder Y: 0 – A&B, 1 – analog (not supported in this
version)
Bit 4 - Encoder B: 0 – A&B, 1 – analog (not supported in this
version)
Bit 5 - Encoder Z: 0 – A&B, 1 – analog (not supported in this
version)
Bit 6 - Encoder C: 0 – A&B, 1 – analog (not supported in this
version)
Bit 7 - Encoder T: 0 – A&B, 1 – analog (not supported in this
version)
Bit 8 - Encoder D: 0 – A&B, 1 – analog (not supported in this
version)
13 0 - Model Dependent – this key applies only for integrated
models (internal drives)
The drive fault status can be read at any time by calling getconf,
which stores the fault code in bits 0 – 3 of the returned value.
In a case where a drive alarm occurs and the controller's default
response is to disable the motor, then the fault status is also stored
in the MERR standard variable (page 11-43). See also fault
processing, (page 8-17)
getconf bits 0 – 3 Equivalent
Drive Fault status MERR
3 2 1 0 value

No fault 0 0 0 0 5060

Drive Alarm: Short circuit. 0 0 0 1 5061

Drive Alarm: External 0 0 1 0

5062
protection activated.

Drive Alarm: Power supply 0 0 1 1

5063
too low.

Drive Alarm: Power supply 0 1 0 0

5064
too high.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-61

Key Index Comments

Drive Alarm: Temperature

0 1 0 1 5065
too high

Drive Alarm: Power supply 0 1 1 0

5066
24VF1.

Drive Alarm: Power supply 0 1 1 1

5067
24VF2.

Drive Alarm: Emergency 1 0 0 0

5068
Stop

Drive Alarm: Power down 1 0 0 1 5069

Drive Alarm: Digital drive 1 1 1 1

5075
interface not connected.

21 0–3 getconf retrieves the Index Counter. The Index Counter is an up-
The down counter. The counter increments each time when the motor
function is crosses the index in positive direction and decrements each time
valid for when the motor crosses the index in negative direction.
axes
X,Y,Z,T setconf zeroes the Index Counter (the value argument is ignored).
only
22 0–3 getconf retrieves the Mark Counter. The Mark Counter is an up-
The down counter. The counter increments or decrements on each pulse
function is of the Mark signal. The direction of a count corresponds to the
valid for direction of motion at the counting moment.
axes
X,Y,Z,T setconf zeroes the Mark counter (the value argument is ignored).
only
26 Ignored getconf retrieves the mask that determines for each digital input, the
signal edge (leading or trailing) that will trigger an interrupt.
setconf sets the mask that determines for each digital input, the
signal edge (leading or trailing) that will trigger an interrupt.
The mask contains a bit for each available input signal. The location
of bits in the mask corresponds to the location of bits in the IN0
variable.
If a bit is 0, the controller generates an interrupt on the rising edge
of the corresponding input signal.
If a bit is 1, the controller generates an interrupt on the falling edge
of the corresponding input signal.
After power-up the mask contains 0 in all bits.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-62 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Key Index Comments

29 0-11, setconf assigns the specified output bit to one of the following
Specifies an functions according to the value argument:
output
0 – OUT0 (the output follows the corresponding bit of OUT0)
number
1 – PEG (the output is controlled by the PEG function)
2 – Brake (the output supplies the brake control signal)
getconf returns 0, 1 or 2 according to the current assignment of the
specified output.
Model Specific - Not required for the SPiiPlus CM control
module, which has dedicated brake hardware outputs.
See also mechanical braking, page 7-21.

101 0–7 getconf only.

Specifies
one of the Reports which features are supported for the specified axis. Returns
axes. a mask that contains the following bits (the bit is one if the feature
is supported):
Bit 1 - Open-loop operation (use MFLAGS.1 bit to enable open-
loop mode)
Bit 4 - Support of stepper motor (use MFLAGS.4,5 bits to
configure stepper motor)
Bit 6 - Support of stepper feedback loop (use MFLAGS.6 bit to
enable connecting stepper outputs to encoder inputs)
Bit 8 - Support of brushless motor (use MFLAGS.8,9 to configure
brushless motor)
Bit 12 - Support of changing the encoder direction (use
MFLAGS.12 to change the direction of encoder)
Bit 13 - Support of changing the drive output direction (use
MFLAGS.13 to change the polarity of drive output)
Bit 14 - Support of notch filter (use MFLAGS.14 to enable the
notch filter)
102 0–7 This key applies only for brushless motors.
Specifies
one of the getconf retrieves the origin of commutation phase converter
axes. (absolute position where the phase shift is zero) in encoder units.
setconf sets the origin of commutation phase converter in encoder
units.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-63

Key Index Comments

130 1or 5 getconf retrieves the present value of the constant current level for
the specified axis (Y or B only, represented by the index value 1 or
5 respectively). The default maximum value that can be set is 16%
for axis Y and 30% for axis B (this value can be changed, see
description of key 131 below).
setconf defines the constant current level as a percentage of the
maximum current for the specified axis.
131 1 or 5 getconf retrieves the present maximum allowable constant current
level (as a percentage of the maximum current) for the specified
axis (Y or B only, represented by the index value 1 or 5
respectively).
setconf sets the maximum allowable value for the constant current
level for the specified axis.
133 1 This key applies for integrated modules (SPiiPlus PCI-DDM4A)
only:
getconf retrieves the constant current mode status for axes Y and B:
returns zero if the mode is on, nonzero if the mode is off.
setconf disables/enables constant current mode for axes Y and B.
Value 0 disables the mode, value 1 enables the mode.
203 0–7 getconf retrieves the value of MFLAGS.1 (Open Loop).
Specifies setconf sets the value of MFLAGS.1.
one of the
axes.
204 0–7 getconf retrieves the value of MFLAGS.9 (Commutation OK).
Specifies setconf sets the value of MFLAGS.9.
one of the
axes.
205 0–3 The Value argument specifies the output mask that defines the
The source of the digital outputs. The mask defines whether a digital
function is output is allocated to the corresponding bit of the OUT array (for
valid for general purpose use) or allocated for PEG function use.
axes
The PEG can control up to four outputs for each axis. Both
X,Y,Z,T
incremental and random PEGs produce pulse output. In order to use
only
this pulse the user must configure the output mask so that the PEG
controls the corresponding output. Additionally, the random PEG
can produce up to three state outputs. In order to use these states the
user must configure the output mask so that the PEG controls the
corresponding outputs.
getconf retrieves the value of output mask.
setconf sets the value of output mask.
Only the following bits of the output mask are meaningful:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-64 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Key Index Comments

Axis X (Index 0)
Bit 0 assigns pin OUT0.0: 0 – OUT0.0, 1 – X PEG state 0
Bit 1 assigns pin OUT0.1: 0 – OUT0.1, 1 – X PEG state 1
Bit 2 assigns pin OUT0.2: 0 – OUT0.2, 1 – X PEG state 2
Bit 3 assigns pin X_PEG_3: 0 – undefined, 1 – X PEG state 3
Bit 8 assigns pin OUT0.3: 0 – OUT0.3, 1 – X PEG pulse
Axis Y (Index 1)
Bit 0 assigns pin OUT0.4: 0 – OUT0.4, 1 – Y PEG state 0
Bit 1 assigns pin OUT0.5: 0 – OUT0.5, 1 – Y PEG state 1
Bit 2 assigns pin OUT0.6: 0 – OUT0.6, 1 – Y PEG state 2
Bit 3 assigns pin Y_PEG_3: 0 – undefined, 1 – Y PEG state 3
Bit 8 assigns pin OUT0.7: 0 – OUT0.7, 1 – Y PEG pulse
Axis Z (Index 2)
SPiiPlus PCI-4/8 assigns pin Z_PEG_PULSE: 0 – undefined, 1
– Z PEG pulse
Axis T (Index 3)
SPiiPlus PCI-4/8 assigns pin T_PEG_PULSE: 0 – undefined, 1
– T PEG pulse
See also PEG, page 7-6.
206 0–3 getconf only.
The
function is The low 9 bits of the returned value display the actual state of the
valid for output pins of the specified SP. The pins are shared between the
axes low 9 bits of the SP output register and the PEG outputs.
X,Y,Z,T See also PEG, page 7-6.
only
214 0–7 Only valid for brushless motors (MFLAGS.8 = 1).
Specifies
one of the getconf retrieves the commutation phase (degrees) at the current
axes. point.
setconf adjusts the commutation offset so that the commutation
phase at the current point will be equal to the specified value
(degrees).

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-65

Key Index Comments

215 0–7 Only valid for brushless motors (MFLAGS.8 = 1) and where the
Specifies index has been encountered (IND contains a valid value).
one of the
axes. getconf retrieves commutation phase (degrees) at the point of the
last index stored in the IND variable.
setconf adjusts commutation offset so that commutation phase at
the point of last index will be equal to the specified value (degrees).
216 0–7 getconf retrieves commutation state (bit 9 of MFLAGS):
Specifies 0 - Commutation is not OK (not initialized)
one of the 1 - Commutation is OK.
axes.
setconf executes the following actions:
If value = 0:
• clears bit 9 of MFLAGS (state ‘Commutation is not OK’);
• clears bits 1, 4, 5, 6 of MFLAGS;
• sets bit 8 of MFLAGS;
• resets DCOM to zero.

If value = 1:
Same as when value = 1 but also adjusts RPOS value so that
RPOS = FPOS.
217 0–7 The functions work correctly only if the motor is brushless
Specifies (MFLAGS.8 = 1) and the index was encountered (IND contains a
one of the valid value).
axes.
getconf is not supported.
setconf combines actions of setconf (215…) and
setconf (216,…,1):
• adjusts commutation offset so that commutation phase at the
point of last index will be equal to the specified value
(degrees);
• sets bit 9 of MFLAGS (state ‘Commutation is OK’);
• clears bits 1, 4, 5, 6 of MFLAGS;
• sets bit 8 of MFLAGS;
• resets DCOM to zero;
• adjusts RPOS value so that RPOS = FPOS.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-66 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Key Index Comments

229 0-7, setconf controls the brake output. The function activates the brake
specifies a if value is zero and deactivates the brake if value is one. The
motor function can be executed only if the motor is disabled.
getconf returns 0 if the corresponding brake is active and returns 1
if the corresponding brake is inactive.
See also mechanical braking, page 7-21.

301 Ignored getconf retrieves the size of the segment queue in segmented
motions (mptp, mseg, path, pvspline).
setconf is not supported.
Return value

none
Error conditions
None.

5.8. Expressions

5.8.1. General
An expression is a sequence of operators and operands that specify a calculation.
Expressions serve as building blocks for many ACSPL+ commands. For example, assignment
commands include expressions to the right of the equal sign:
V0 = V1 + 2*(V2 - V3)

When the controller executes a command that includes an expression, the expression is calculated
and the result is used as required by the command.
Complexity of expression ranges from the simplest expressions that include only one constant or
variable name, to extended formulae containing multiple operators and functions with several
levels of brackets. For example:
I99 = 5 5 is a simple expression

I98 = V0 V0 is a simple expression

I97 = ((I1-1)*sin(I2)+2)/5 Complex expression

5.8.2. Calculation Order

In a complex expression the following factors, listed below in priority order, determine the order
of calculation:
9. Brackets in the expression

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-67

10. Operator precedence

11. Order of operators in the expression (left-to-right order)
If the brackets do not unambiguously define the calculation order, then the operator precedence is
taken into account, and if the calculation order is still ambiguous then the left-to-right calculation
order is applied.
The following table summarizes the operator precedence, of, summarizing them in order of
precedence from highest to lowest.

Symbol Operation

. (dot) Bit selection

– ~ ^ Unary minus, Inversion, Logical not
* / Multiplication, Division
+ – Addition, Subtraction
= <> < > <= >= Compare
& | ~ Logical and bitwise AND, OR, XOR

If several operators appear on the same line or in a group, they have equal precedence.

5.8.3. Expression Type

The controller uses two types of numerical values;
ƒ Integer values that are 4-bytes (32-bits) long and range from -2147483648 to 2147483647
ƒ Real values that are 8-bytes long, 53-bits of mantissa and 11-bits of exponent with a range of
±10-1023
Expression calculations produce either integer or real values.
Within the group of expressions that produce integer values, there is a subset, called logical
expressions, that is comprised of expressions that produce only two values: 0 or 1.
According to the type of result, an expression is defined as integer, real or logical. The controller
provides automatic type conversion of the result so that expression type required does not restrict
expression use. For example:
V0 = 0.01 * V1

In this assignment command, the integer variable V0 is left of the equals sign, while a real
expression is to the right of the equal sign. The controller automatically uses rounding type
conversion of the result obtained on the right side, so that the real value can be converted to an
integer variable and stored.
The types of operands and operators used in the expression define the expression type. Each
operator has an associated rule that defines the type of result according to the types of operands.
The rules are summarized in the following tables. Integer (0,1) is specified for the operators that
produce only two values: 0 or 1 (logical result).
Unary operators:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-68 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Operator Type of operand

integer real
– (unary minus) integer real
~ (inversion) integer integer
^ (logical not) integer (0,1) integer (0,1)
Binary operators:
Operator Type of operands (left-right)
integer-integer integer-real real-integer real-real
+ (addition) integer real real real
- (subtraction) integer real real real
* (multiplication) integer real real real
/ (division) real real real real
& (and), | (or), ^ (xor) integer integer integer integer
= <> < > <= >= integer (0,1) integer (0,1) integer (0,1) integer (0,1)
(compare)
. (bit selection) integer (0,1) integer (0,1) integer (0,1) integer (0,1)

5.8.4. Operands
An operator requires one or two operands.
An operator that requires one operand is called a unary operator. A unary operator is placed
before its operand.
An operator that requires two operands is called a binary operator. A binary operator is placed
between its operands.
Each operand can be either integer or real. If the operator requires, the controller automatically
converts the operand to the required type.
Operands can be one of the following:
ƒ Constant
ƒ Symbolic constant
ƒ Scalar variable name
ƒ Array name with indexing
ƒ Function call
ƒ Expression
A constant can consist of any integer or real number. Integer constants can be presented in
decimal, hexadecimal and binary notation. Real constants can include a decimal point and/or
exponent.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-69

Symbolic constants are predefined in the controller. Each symbolic constant presents an integer
number.
A variable name is a name of any standard or user-defined variable. If a user-defined name is
used, it must be declared before being used in the program. If the variable presents an array, the
name must be fully indexed to specify one element of the array.
Any ACSPL+ function can be used in an expression. Using expression as an operand of other
expression provides unlimited variety of expressions. In many cases expression used as operand
must be enclosed in brackets. For example:
(V0+5)*7 Expression V0+5 is the left operand of multiplication

(V0+5)*(I88+3) Both operands of multiplication are expressions

V1*3 + I2*6 Operands of addition are expressions V1*3 and I2*6

5.8.5. Arithmetical Operators +, -, *, /

Arithmetical operators provide four arithmetical operations.
The operators + (addition), - (subtraction), * (multiplication) calculate an integer result if both
operands are integers, and a real result if at least one operand is real.
Operator / (division) always calculates real results. For example, the following command
real Var Declare real variable Var

Var = 5/4

assigns 1.25 to variable Var.

5.8.6. Compare Operators =, <>, >, >=, <, <=

Compare operators include = (equal), <> (not equal), > (greater), >= (greater or equal), < (less),
<= (less or equal).
Compare operators work with any combination of integer and real operands. Compare operator
results are always the integers 0 or 1. A positive result of a comparison provides value 1, while a
negative result provides value 0.
Compare operators are typically used in a variety of contexts, for example:
if V0 > 5 ...

while I99 <> 0 ...

on IN0.5 = 1 ...

Because they always produce a result as an integer, compare operators can be used in arithmetical
calculations, for example:
V1 = (V0 = 5) * V4

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 5-70 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

The expression in parenthesis (V0 = 5) calculates to 1 if V0 is equal to 5 and calculates to 0 if V0

is not equal to 5. Therefore, this command assigns V1 with the current value of V4 if V0 equals 5,
and assigns V1 with 0 if V0 has any other value.

5.8.7. Bitwise And Logical Operators & (and), | (or),

~ (exclusive or (xor))
Bitwise operators include & (and), | (or), ~ (xor – exclusive or).
The result of a bitwise operator must always be an integer. If an operand of a bitwise operator is
real, the controller automatically converts it to an integer before the operation.
Bitwise means that the operation is executed separately on each bit of the operand. Each integer
operand is considered as a set of 32-bits. Bit 0 of the left operand is combined with bit 0 of the
right operand to produce bit 0 of the result.
The following example illustrates the AND operator. Both operands and the result are considered
as sets of 32-bits.
First 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0
operand
Second 0 0 1 1 1 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1 0 0
operand
Result 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0
If both operands are logical, i.e. have only values of 0 or 1, the result is also logical. In this case
the operators can be treated as logical AND, OR and XOR. For example, the following condition
(V0 = 5) & (I30 = 0)

is satisfied only if V0 is 5 and I30 is 0 simultaneously.

5.8.8. Unary Operators -, ~, ^

Unary minus (-) negates its operand, either integer or real. The type of result follows the type of
operand.
Inversion (~) provides bitwise inversion of its operand. If the operand is real, the controller
provides automatic conversion to integer before the operation. The result is always an integer.
Logical not (^) accepts either integer or real operand and calculates an integer result. The result is
1 if the operand equals to 0, and is 0 if the operand is non-zero.

Type Example Explanation

Unary minus (-) V0 = -V1 V0 is assigned with the negative value of V1

The following two examples illustrates the difference between the ~ and ^ operations:
Bit number 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-71

Bit number 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Operand X 0 0 1 1 1 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1 0 0

Result of ~X 1 1 0 0 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0 1 1

Result of ^X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Bit number 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Operand X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Result of ~X 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Result of ^X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

Note
Inversion is a bitwise operator, while logical not is not.

5.8.9. Bit Selection Operator (Dot)

Bit selection operator (dot) extracts one bit from an integer number. The result is always an
integer and can yield only two values: 0 or 1.
The operands can be integer or real. The controller converts a real operand to integer before the
operation.
The left operand supplies a number from which a bit will be extracted. The number is treated as a
set of 32 bits numbered from 0 to 31. Bit 0 is the least significant bit.
The right operand supplies the ordinal number of the bit to be extracted. The value of the right
operand must be in the range from 0 to 31.
Typical use of the bit selection is for the flag variables like MST, which are treated as a collection
of one-bit flags. For example, the following command
till ^X_MST.#MOVE

provides waiting for the end of the X axis motion. The symbolic constant #MOVE (5) provides
selection of bit 5 of the MST variable (Motor State). The 5th bit of MST reflects the state of the
motion: it is 1 while the axis is in motion, and is 0 while the axis is idle.

5.9. Commands
A command is the smallest executable unit of ACSPL+.
See also how axes are designated in commands, page 5-11.

5.9.1. Introduction to Commands

One program line can contain one or several commands. If a line contains several commands, the
commands must be separated by a semicolon (;). A semicolon after the last (or single) command
in a line is not required.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-72 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Examples:
The following is an example of a program line that contains one assignment command:
V0 = V1 + 2*(V2 – V3)

The following is an example of a program line that contains two assignment commands:
V0 = V1 + 2*(V2 – V3); V4 = 0

White spaces (spaces and tabs) may be inserted arbitrarily inside or between commands.
However, white spaces must not be inserted within keywords and variable names.
A control structure consists of several commands. Control structures start with a specific
keyword and terminate with the end command.
For example, a loop control structure starts with the loop command followed by an arbitrary
number of commands and terminates with the end command. The commands of a control
structure may reside in one or more program lines.
Examples:
The following two loop control structures are logically equivalent:
loop 5 Execute the loop body 5 times

V0 = V0 + 1 Increment V0

end End of the loop body

and
loop 5; V0 = V0 + 1; end

5.9.2. List of Commands

TABLE 5-5 Commands

Command Action Reference

Assignment Command
= Assigns right side of expression to variable on left
side.

Program-Flow Commands
if, elseif, else, end If control structure. 5-79
while, end While control structure. 5-80
loop, end Loop control structure. 5-82
call, ret Implements subroutine. 5-83
goto Transfers program execution to another point in the 5-86
program.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-73

Command Action Reference

Synchronization Command
wait Delays program execution for a specified number of 5-88
milliseconds.
till Delays program execution until a specified 5-88
expression produces a non-zero (true) result.

Autoroutine Command
on Specifies autoroutine header. 5-90

Program Management Commands

start Activates program execution in a buffer. 5-94
stop Terminates program execution in a buffer. 5-94
stopall Terminates all currently executed programs, except 5-94
the program that issued the command.
pause Suspends program execution in a buffer. 5-95
resume Resumes program execution in a buffer. 5-95
enableon Enables autoroutine activation in a buffer. 5-96
disableon Disables autoroutine activation in a buffer. 5-96

Interaction Commands
disp Builds a string and sends it to a communication 5-97
channel.
send Same as disp, but also specifies which 5-99
communication channel.
interrupt Causes an interrupt that can be intercepted by the 5-100
host.
copytodpr Instructs the controller to copy a variable to an 5-101
address in the DPRAM.
stopcopytodpr Invalidates all previously executed copytodpr 5-101
commands.

Axis/Motor Management Commands

enable Activates one or more drives and motors. 5-102
disable Shuts off one or more drives and motors. 5-102
kill Causes one or more motors to terminate motion 5-103
using second order deceleration profile (KDEC
deceleration).
killall Provides kill operation for all motors. 5-103

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-74 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Command Action Reference

fclear Clears a fault. 5-106
set Appoints a current value of the feedback, reference 5-106
or axis position.
group Creates a coordinate system for multi-axis motion. 5-108
split Breaks apart an axis group. 5-108
splitall Breaks apart all axis groups. 5-108
connect Defines a connection between a motor and axes. 5-109
depends Specifies a logical dependence between a motor and 5-109
axes.
go Starts a motion that was created using the w suffix. 5-113
halt Terminates one or more motions using a third-order 5-114
deceleration profile (DEC deceleration).
break Terminates a motion without deceleration and 5-115
provides smooth transition to the next motion.
imm Provides on the fly change of motion parameters. 5-116
commut Performs autocommutation for DC brushless (AC 5-116
servo) motors.

Motion Management Commands

ptp Creates a point-to-point motion. 6-1
jog Creates a jog motion. 6-9
mptp Creates a multipoint motion. 6-10
point Adds a point to mptp, path or pvspline motion. 6-10
mpoint Adds a set of points to mptp, path or pvspline 6-10
motion.
path Creates an arbitrary path motion (linear 6-20
interpolation).
pvspline Creates an arbitrary path motion (spline 6-24
interpolation).
master Defines a formula for master value calculation. 6-30
slave Creates a master-slave motion. 6-31
mseg Creates a segmented motion. 6-33
line Adds a linear segment to mseg motion. 6-33
arc1, arc2 Adds a circle segment to mseg motion. 6-33
stopper Adds a segment separator to mseg motion. 6-33

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-75

Command Action Reference

ends Finishes adding points or segments to mptp, path, 6-10, 6-20,
or pvspline, or mseg motion. 6-24, 6-33

Miscellaneous Commands
dc Activates data collection. 7-1
stopdc Terminates data collection prematurely. 7-1
assignpeg Assigns outputs to PEG and sets the initial state of 7-7
PEG state outputs.
peg_i Activates incremental PEG™, where pulses are 7-9
generated at predefined position intervals.
peg_r Activates random PEG, where predefined pulses are 7-10
generated upon position events.
read Reads an array from a file in the nonvolatile (flash) 5-119
memory.
safetyconf Configures a fault for a group of axes. 5-120
safetygroup Groups axes into a safety group, wherein the fault 5-121
configuration of the first axis is applied to the
others and a kill or disable operation on any axis in
the group affects all axes in the group.
setprotection Changes protection attribute for a variable. 5-120
stoppeg Terminates PEG operation prematurely. 7-11
write Writes an array to a file in the nonvolatile (flash) 5-119
memory.

5.9.3. Assignment Command

Assignment obeys the following syntax:
assignment-command :
left-term = expression
left-term :
variable-name
variable-name indexing
variable-name bit-specifier
variable-name indexing bit-specifier
indexing :
(expression)
(expression) (expression)
bit-specifier :
. expression
Each assignment command consists of three elements:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-76 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

ƒ Left-term
ƒ Equal sign
ƒ Expression.
The controller executes assignment commands in the following order:
1. Calculate right-side expression
2. Convert the type of calculated value to the type of left-term (if the types differ)
3. Assign the result to the left-term
The right side expression can be of integer or real type.
By using different operators and parenthesis, you can construct an unlimited number of
expressions.
The left-term may consist of several elements. Only variable-name is obligatory. Variables that
are specified on the left side may be standard or user variables.
Different variants of left-term provide assignment to the following objects:
ƒ Standard or user variable
ƒ One element of standard or user array
ƒ One bit of integer variable or integer array element
The following sections explain assignment for specific types of the left-term.

5.9.3.1. Standard Variable Assignment

Standard variables can be used in the left side with the following restrictions:
The variable must not be read-only. Using read-only standard variable in the left side causes a
compile-time error.
If it is a protected variable, protection is checked when the command is executed. In protected
mode (see Section 5.10), the assignment fails, producing a run-time error (3077).
Examples:
The following command tries to assign a read-only variable, and will cause a compilation error:
X_FPOS = 0

The following command assigns the protected variable FMASK

X_FMASK = 0

It is a legal command. However, when the command executes, if the controller is in protected
mode, the assignment fails and produces a run-time error.
• If a standard variable is scalar, no indexing is required.
• If a standard variable is an array, explicit or implicit indexing is required. For indexing of
standard variables on page 5-20.
Examples:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-77

The following three assignments are equivalent:

X_VEL = 1000 Indexing by axis specification

VEL0 = 1000 Postfix indexing

VEL (0) = 1000 Explicit indexing

5.9.3.2. User Variable Assignment

User local and global variables must be declared before they can be used in an assignment
command.
ƒ Explicit indexing only is allowed for user array variables.
ƒ If a user variable is scalar, no indexing is required.
ƒ If a user variable is one-dimensional array, it requires one index. Two-dimensional arrays
require two indexes.
Examples:
global int Int_Scalar Int_Scalar is declared as
a global integer variable
local real Real_Array1(20) , Real_Array2(10)(10) Real_Array1 is a local
real array of 20 elements.
Real_Array2 is a local
real array of size 10x10.
Int_Scalar = 5 Assign 5 to Int_Scalar

Real_Array1(2) = 5 * Int_Scalar Calculate 5* Int_Scalar

and assign the result to
the second element of
Real_Array1
Real_Array2(Int_Scalar)(Int_Scalar+2) = 1000 Assign 1000 to the
element of Real_Array1
with first index equal to
Int_Scalar and the
second index equal to
Int_Scalar+2

5.9.3.3. Bit Assignment

Use a bit specifier, added to an integer variable or integer array element, to provide assignment to
a single bit. The syntax of bit specifier is
bit-specifier :
. expression
The expression calculates to an integer number that provides an ordinal bit number. Typically the
expression is simply a constant that specifies the ordinal bit number as explained below.
However, an arbitrary expression can be specified that provides calculation of the bit number in
run time.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-78 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

In the controller, an integer number is presented by 32 bits. The bits are numbered from 0 to 31.
The least significant bit is bit 0. The expression in a bit specifier must calculate to integer number
in the range 0..31.
A bit can have only two possible values: 0 (false) or 1 (true), while the right-side expression
result, which defines the bit value, can be any value. Assignments convert the value as follows:
ƒ If the value is zero, the bit is set to zero
ƒ If the value is non-zero, the bit is set to one
Although bit assignments are applicable to any integer variable or array element, they are mainly
used for changing flag variables and output bits.
Examples:
OUT0.13 = 1 Set output 13 to one.

X_IST.#IND = 0 Reset index flag of X axis.

X_FMASK.#DRIVE = 1 Enable Drive Fault exception. The

command is allowed only in
configuration mode.

5.9.3.4. Type Conversion

Left-side terms and right-side expressions may be of different types: integer or real in any
combination. (The special case of Bit assignment is handled differently, as is described in Bit
Assignment, page 5-77)
If the types differ, the type of calculated right-side expression is automatically converted to the
type of left-side term. There are two possible conversions:
ƒ Integer to real; conversion is exact.
ƒ Real to integer; conversion is not always exact. A real number is rounded to the closest
integer.

5.9.4. Program-Flow Commands

In normal program flow the command lines are executed sequentially in the order of appearance.
Program-flow commands change the order of command line execution.
The following program flow commands are available:
if expression
elseif expression
else
end
while expression
loop expression
call label-or-number
ret
goto label-or-number

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-79

The commands if, while, loop open a control structure that may include a number of commands:
control-structure :
if-control-structure
while-control-structure
loop-control-structure

5.9.4.1. if-else if-else-end Control Structure

Commands if, elseif, else, end are building blocks of if-control-structure:
if-control-structure :
if expression command-list end
if expression command-list else command-list end
if expression command-list elseif-sequence end
if expression command-list elseif-sequence else command-list end
elseif-sequence :
elseif expression command-list
elseif expression command-list elseif-sequence
The expression after if specifies the condition that controls the execution of an if-aggregate. The
expression can be of any type, and is interpreted as follows:
ƒ If the result is non-zero, the condition is true
ƒ If the result is zero, the condition is false
The if expression command-list end form executes in the following order:
4. Calculate the expression.
5. If the result is non-zero (true), execute the command-list.
6. If the result is zero (false), skip the command-list.
7. Continue execution at the first command that follows the end command.
The if expression command-list else command-list end form provides two command-lists, only
one of which executes, depending on the result of expression.
The if expression command-list elseif-sequence end, and if expression command-list elseif-
sequence else command-list end forms provide validation of a sequence of conditions;
One if-control-structure may contain any number of elseif clauses. Each elseif clause specifies its
own condition. The condition are validated in the following order:
8. Condition after if
9. Condition after first elseif
10. Condition after second elseif
If any condition is satisfied, the command-list in the corresponding clause executes. All
subsequent conditions are not validated and all other command-list’s are skipped. Afterwards,
execution continues from the command that follows the end command.
If no condition is satisfied, the command-list after the else executes (if else clause exists).
Examples:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-80 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

The following program fragment activates either output 5 or 6 and shuts off the other, depending
on the state of input 3:
if IN0.3 Check if the third bit of IN0 is raised

OUT0.5 = 1 Set the 5th bit of OUT0 to 1

OUT0.6 = 0 Set the 6th bit of OUT0 to 0

else Execute the next commands only if the if condition was false

OUT0.5 = 0 Set the 5th bit of OUT0 to 0

OUT0.6 = 1 Set the 6th bit of OUT0 to 1

end End of the if body

The same fragment can be combined in one line:

if IN0.3 OUT0.5 = 1 ;OUT0.6 = 0 ; else OUT0.5 = 0 ; OUT0.6 = 1;end

The result of the two fragments is identical, but the execution time is different. The second
executes faster, because the controller executes one program line per each controller cycle.
However, packing too many commands in one line is not recommended, because it increases the
calculation load and may cause a Time Overuse exception.
Note, that the same result can be achieved without if command:
OUT0.5 = IN0.3 ; OUT0.6 = ^IN0.3

The following fragment implements saturation effect by limiting variable V0 to the range of-256
to +256:
if V0 < -256 Check if V0 is less than -256

V0 = -256 Assign -256 to V0 (low saturation)

elseif V0 > 256 If V0 is not less than -256, check if it is greater than 256

V0 = 256 Assign 256 to V0 (high saturation)

end End of the if body (no saturation if -256 ≤ V0 ≤ 256)

5.9.4.2. while-end Control Structure

The while and end commands are the building blocks of the while-control-structure:
while-control-structure :
while expression command-list end
The control structure provides repetitive execution of the command-list as long as the expression
is satisfied. If the expression is not satisfied when checked for the first time, the command-list is
skipped, and execution continues from the command that follows the end command.
Examples:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-81

The following fragment waits for motion termination, and calculates how long the controller
waits:
V0 = 0 Assign V0 to zero

while X_MST.#MOVE V0 = V0 + 1; end While the motor is in motion

increment V0

Note, that the same result can be achieved without while command:
V0 = TIME Store the current time in V0

till ^X_MST.#MOVE Wait until the X motor is no longer moving

V0 = TIME – V0 Calculate the time difference

The following fragment activates Jog motion for Z axis and then monitors the position error, to
achieve maximum velocity while holding the position error within desired limits:
Z_VEL = 1000 Assign 1000 to Z_VEL

jog Z Start jog motion

till ^Z_MST.#ACC Wait until the motion

acceleration segment finishes
while Z_MST.#MOVE Repeat the external loop while
the motion is in progress
while ( Z_PE > 50 ) Repeat the first internal loop
while the absolute value of
position error is greater than
50
imm Z_VEL = Z_VEL – 10 Reduce the velocity by 10
counts
wait 20 Wait 20 milliseconds to give
time to the new velocity to
take effect
end End of the second internal
loop body
while ( abs(Z_PE) < 10 ) Repeat the first internal loop
while the absolute value of
position error is less than 10
imm Z_VEL = Z_VEL + 10 Increase the velocity by 10
counts
wait 20 Wait 20 milliseconds to give
time to the new velocity to
take effect

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-82 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

end End of the second internal

loop body
end End of the external loop body

The purpose of the till command after the jog command is to prevent the loop execution during
the acceleration segment of the motion profile because it is a transient process. The external while
loop does nothing as long as the position error falls into the allowed interval 10-50. If the error is
greater than 50, the first internal loop slows down the motion until the error returns to the interval.
If the error is smaller than 10, the second internal loop increases the velocity until the error returns
to the allowed interval. The imm command provides for changing Z_VEL in the current motion,
and is necessary because a simple Z_VEL command without imm would become effective for the
next motion and not the current motion.

5.9.4.3. loop-end Control Structure

The loop and end commands are the building blocks of loop-control-structure:
loop-control-structure :
loop expression command-list end
Unlike the while loop that verifies its condition each time before executing the command-list,
loop provides a fixed number of the command-list repetitions.
The loop command executes in the following order:
11. Calculate expression.
12. If the expression result is zero or negative, the command-list is not executed, and execution
continues from the command that follows the end command.
13. If the result is not integer, round the result to the closest integer.
14. Execute command-list as many times as defined by the expression result.
15. Continue execution continues from the command that follows the end command.
Examples:
The following loop calculates V1 as factorial of V0 (given V0 >= 0):
V1 = 1 Assign 1 to V1

V2 = 0 Assign 0 to V2

loop V0 Start loop

V2 = V2 + 1 V2 = V2 + 1

V1 = V1 * V2 V1 = V1 x V2

end End loop

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-83

The following fragment starts point-to-point motions individually for X, Y and Z axes, waits for
termination of all three motions, checks the reason for the termination and provides error
messages:
V0 = 0 Assign 0 to V0

loop 3 Execute the loop 3 times

ptp/r (V0), 1000 Start positioning of the axis

specified by the V0 variable
(0 – X, 1 – Y, 2 – Z) to
point 1000.
V0 = V0 + 1 Increment V0

end End of the loop body

till ^X_MST.#MOVE & ^Y_MST.#MOVE & ^Z_MST.#MOVE Wait until all motions finish

V0 = 0 Assign zero to V0

loop 3 Execute the loop 3 times

if AERR(V0) >= 5010 Check termination code of

the axis specified by the V0
variable (0 – X, 1 – Y, 2 –
Z). Termination codes
greater than or equal to
5010 means that the motion
was terminated due to an
error.
disp “Motion of axis “, V0, “ failed. Error code: “, AERR(V0)

Display a message
describing the axis and the
reason (error code) for
termination
end End of the if body

V0 = V0 + 1 Increment V0

end End of the loop body

Standard variable AERR contains the termination code of the motion. Code values greater than or
equal to 5010 indicate abnormal termination.

5.9.4.4. call and ret Commands

Commands call and ret provide implementation of subroutines.
Command call obeys the following syntax:
call-command :
call label-name
The command specifies the start of the called subroutine.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-84 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

label specified in the label-name argument must be defined somewhere in the same buffer. The
subroutine starts after the label and spans all commands up to the subsequent ret command.
The call command transfers execution to the start of the subroutine and stores the return point in
the stack. When the subsequent ret executes, the return point is extracted from the stack and
execution continues from the command that follows the call command.
Subroutine calls can be nested, i.e. a subroutine can call another one and so on.
You must enter a subroutine with the call command and exit a subroutine with the ret command.
Otherwise, the stack will be left in an improper state, resulting in program termination due to the
stack violation error.
Examples:
The following program defines and uses subroutine Factorial that calculates Fact as factorial of
Arg (given Arg >= 0):
local int Fact, Arg, In; Declare local variables

Arg = 1 Assign 1 to Arg

call Factorial Go to the Factorial subroutine

disp Fact Display the value of Fact

Arg = 5 Assign 5 to Arg

call Factorial Go to the Factorial subroutine

disp Fact Display the value of Fact

Arg = 10 Assign 10 to Arg

call Factorial Go to the Factorial subroutine

disp Fact Display the value of Fact

stop

Factorial: Label that opens the subroutine

Fact = 1 Assign 1 to Fact

In = 0 Assign 0 to In

loop Arg Repeat Arg times

In = In + 1 Increment In

Fact = Fact * In Accumulate result in Fact

end End of loop

ret Exit subroutine, Fact stores result

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-85

The program provides the following output:

1 When Arg=1
120 When Arg=5
3628800 When Arg=10

The following example demonstrates ACSPL+ feature of referencing an axis by number.

Subroutine Step activates point-to-point motion, waits for the motion completion and examines
the motion result. The involved axis is defined by the Axis variable.
local int Axis; Define local variable Axis

Axis = 0 Assign 0 to Axis

call Step Activate subroutine Step

(initiates movement on the
X axis)
Axis = 1 Assign 0 to Axis

call Step Activate subroutine Step

(initiates movement on the
Y axis)
stop

Step: The start of the Step

subroutine
ptp/r (Axis), 1000 Perform point to point
movement to point 1000.
When Axis=0 movement is
on the X axis. When Axis
=1 movement is on the Y
axis.
till ^MST(Axis).#MOVE Wait until the motion stops

if AERR(Axis) >= 5010 If the error code is equal to

or greater than 5010
(indicating motion failure)
disp "Motion failed. Axis ", Axis, “, Error code “, AERR(Axis)
Display a message stating
on which axis motion
failed, and the code of the
error that caused the failure
end End of loop

ret Exit subroutine

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-86 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

Standard variable AERR stores termination code of the last motion. Codes greater than or equal
to 5010 indicate motion failure.

5.9.4.5. goto Command

The goto command transfers program execution to a specified point in the program.
The goto command obeys the following syntax:
goto-command :
goto label-name
The command specifies the command that will be executed next.
The label specified in the label-name argument must be defined somewhere in the same buffer.
The next executed command is located after the label.
The goto command transfers execution to the next executed command.
Avoid using the goto command to enter or exit a subroutine. If the program enters a subroutine
without the call command, or exits a subroutine without the ret command, the stack remains in
improper state, resulting in program termination due to a stack violation error.
Examples:
The following example demonstrates a typical use of goto command for directing the program to
the error processor when an error occurs:
till ^X_MST.#MOVE Wait until the motion on the X
axis stops
if X_MERR >= 5010 | X_AERR >= 5010 goto ErrorProc end

If variable MERR (stores the

last motor disable code) or
variable AERR (stores the last
termination code) on the X
axis are equal to or greater
than 5010
till ^Y_MST.#MOVE Wait until the motion on the Y
axis stops
if Y_MERR >= 5010 | Y_AERR >= 5010 goto ErrorProc end

If variable MERR or variable

AERR on the Y axis are equal
to or over 5010
stop

ErrorProc: Error processing section

V0 = 0 Set V0 to 0

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-87

loop 4 Perform the loop four times, to

check for errors in axes X, Y,
Z, and T
if MERR( V0 ) >= 5010 If the error code is equal to or
greater than 5010 (indicating
motion failure)
disp “Axis “, V0, “ was disabled. Error code “, MERR( V0 )
Display an error message
stating in which axis the
motion was disabled, and the
code of the error that caused
the failure.
end End of loop

if AERR( V0 ) >= 5010 If the termination code of the

last message is equal to or
greater than 5010 (indicating
motion failure)
disp “Motion of axis “, V0, “ failed. Error code “, AERR( V0 )
Display an error message
stating in which axis the
motion failed, and the code of
the error that caused the
failure.
end

end

stop

Standard variable MERR stores the reason for the last motor disable. Standard variable AERR
stores termination code of the last motion. Codes greater than or equal to 5010 indicate motion
failure.

5.9.5. Synchronization Commands

Synchronization commands provide delay in program execution for a specified number of
milliseconds or until a specified condition is satisfied.
The following synchronization commands are available:
synchronization-command :
wait expression
till expression [, timeout]

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-88 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

5.9.5.1. wait Command

Command wait delays program execution for a specified number of milliseconds.
Command wait obeys the following syntax:
wait-command :
wait expression
The wait command executes in the following order:
Calculate expression. The result is the required delay time in milliseconds.
Delay the program for the calculated amount of time.
Typically the expression is specified as a constant that provides a constant delay time. However,
in some cases variable delay time may be needed as shown in the example below.
If the wait command is located in a separate line, the total execution time of this line is the delay
time plus the standard one line execution time as defined by the PRATE variable.

Examples:
The following example is a program that tests the wait command:
V0 = 0 Assign 0 to V0

loop 100

V1 = TIME

wait V0

disp TIME – V1

V0 = V0 + 1

end Exit the loop

stop

If the controller cycle is 1 millisecond and PRATE is one, the program displays a list of numbers
from 2 to 101. The first number 2 corresponds to the standard execution time of two lines,
because the first time the additional delay provided by the wait command is zero. Each loop
executed adds one to the requested delay, therefore the displayed time grows correspondingly.

5.9.5.2. till Command

The till command delays program execution until a specified expression produces non-zero (true)
result.
Syntax: till expression [, timeout]
The optional timeout argument specifies a timeout for the till command in milliseconds.
The till command executes in the following order:
Calculate expression.
If the expression result is non-zero, go to the next command.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-89

If the expression result is zero, wait one controller cycle and repeat the till command
execution.

Examples:
The following fragment demonstrates a typical use of till command that provides waiting for a
specific state before the execution of the next command:
ptp X, 2000 Start positioning of the X axis to absolute point
2000
till ^X_AST.#MOVE Wait until the motion finishes

Bit X_AST.#MOVE is raised as long as the X axis is involved in a motion. Inversion of the bit
(^X_AST.#MOVE), causing the bit to becomes non-zero, occurs when the motion ends for any
reason. Therefore the above till command provides delay of execution of the next command, until
the motion is over.
In the following example, the program starts a data collection and then a motion. The feedback
position is sampled with a period of 1 millisecond and stored in the data array. After the data
collection finishes, the data array contains a transient process of ptp motion. Synchronous data
collection used in the example displays its state in bit Y_AST.#DC which is raised as long as the
data collection is in progress. The collected data can be safely used only after the data collection
process has terminated. The till command below validates that both the motion and the data
collection are over:
global real Data( 1000 ) Declare global real array Data of
1000 elements
dc/s Y, Data, 1000, 1, Y_FPOS Start data collection of Y_FPOS to
array Data, 1000 samples, 1ms period
ptp Y, 2000 Start positioning of the Y axis to
absolute point 2000
till ^Y_AST.#MOVE & ^Y_AST.#DC Wait until both the motion and the
data collection finish

The following example provides Z axis motion in negative direction until a general purpose input
becomes active and then terminates the motion:
jog Z, - Start jog motion in negative direction

till IN0.5 Wait until input 5 is activated

halt Z Terminate the motion

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-90 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

In the following example a general purpose output must be activated 25 millisecond before the
motion end. Standard variable GRTIME displays the estimated time that remains to the motion
end.
ptp X, 10000 Start positioning of the X axis to
absolute point 10000
till X_GRTIME <= 25 ; OUT0.4 = 1 Activate output 4 25 milliseconds
before the motion ends.
Output activation OUT0.4 = 1 is placed in the same line that the till command in order to avoid
one controller cycle delay between program lines.

5.9.6. Autoroutine Management Command

The technique of autoroutines is similar to hardware interrupts. When a specific condition is
satisfied, the autoroutine interrupts the currently executed program, executes the commands
specified in the autoroutine body and returns control to the interrupted program.

5.9.6.1. Autoroutine Condition (on Command)

Command on specifies the autoroutine header.
Autoroutine header obeys the following syntax:
autoroutine-header :
on expression
The expression defines the autoroutine condition. The condition is considered true if the
expression calculates non-zero result. Zero result corresponds to the false condition.
The controller never executes the on command directly. If the program execution flow comes to
the on command, the controller asserts a run time error and aborts the program.
Instead of direct execution, the controller registers an autoroutine when the program containing
the autoroutine is compiled. Then the controller calculates the expression each controller cycle in
parallel to executing ACSPL+ programs. Once the expression calculates to non-zero value, the
controller interrupts the ACSPL+ program executed in the same buffer as the autoroutine is
located, and transfers execution point to the autoroutine. If no ACSPL+ program is executed in
the buffer, the controller does not interrupt any program and simply starts the autoroutine
execution.
The controller implements edge-detection in autoroutine condition verification. If a condition
becomes true, the controller activates the autoroutine only once. If afterwards the condition
remains true, the controller does not activate the autoroutine again. The condition must become
false and then become true again in order to activate the autoroutine again.

5.9.6.2. Autoroutine Body and Executing the Autoroutine

Autoroutine body is a sequence of ACSPL+ commands that starts from the command following
the autoroutine header. Autoroutine body continues until it reaches a ret command.
The ret command terminates the autoroutine execution and transfers execution control back to the
interrupted program. If no program was interrupted, the ret command simply terminates the
autoroutine.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-91

As explained above, an autoroutine interrupts the program in the host buffer, but is executed in
parallel with programs that are executed in other buffers.
The user can specify different execution rates (number of lines executed per one controller cycle)
for regular program and for autoroutines in the same buffer. Standard array PRATE that contains
elements for each program buffer, specifies the execution rate for regular program. Standard array
ONRATE specifies the execution rate for autoroutines.
For example, the user configured the controller so that PRATE(2) is one, but ONRATE(2) is
four. Therefore, the program in buffer 2 will be executed one line per one controller cycle, and
any autoroutine specified in buffer 2 that interrupts the program will be executed four lines per
one controller cycle. When the ret command that terminates the autoroutine is executed, the
controller switches back to the rate of one line per one cycle.

5.9.6.3. Autoroutine and the Host Buffer Interactions

An autoroutine can reside in any program buffer. For all compiled autoroutines in all buffers the
controller examines the conditions each controller cycles.
There are, however, specific autoroutine - host buffer interactions:
ƒ The buffer’s local variables can be used in the autoroutine condition as well as in the
autoroutine body only in an autoroutine defined in the host buffer. However, all standard and
user global variables can be used in any buffer.
ƒ When the condition is satisfied, the autoroutine interrupts only the program executed in the
host buffer. Programs that are concurrently executing in other buffers continue executing in
parallel to the autoroutine. When activated, the autoroutine prevents activation of other
autoroutines in the same buffer. A program that is executed in any other buffer can be
interrupted by an autoroutine specified in its own host buffer.
The user defines a set of autoroutines when creating an application and assigns them to one or
more buffers. The following approaches are available:
ƒ A specific autoroutine occupies a separate buffer with no other program or autoroutine in
the buffer. Activating and executing the autoroutine has no direct effect on other
programs/autoroutines. This approach is the most suitable for an autoroutine that takes a long
time to execute, because a large autoroutine that shares a buffer with another
program/autoroutines, would prevent the activity of other programs/autoroutines during its
execution.
ƒ Several autoroutines are specified in one buffer with no regular program in the same
buffer. Activating an autoroutine does not interrupt any program, all programs executed in
other buffers continue executing concurrently. An activated autoroutine prevents activating
another autoroutine in the same buffer until its termination.
ƒ One or more autoroutines are specified in a buffer along with a regular program.
Activating the autoroutine interrupts the program execution. This approach is the most
suitable if the program and the autoroutine are closely related and must use the same local
variables. For example, the autoroutine processes the failure conditions for the program, and
must interrupt the program if a failure occurs.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-92 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

5.9.6.4. Examples
The following fragment demonstrates a typical use of autoroutine for processing the controller
faults. The autoroutine provides an error message when the Drive Alarm of X drive occurs:
on X_FAULT.#DRIVE Activate autoroutine when bit
X_FAULT.#DRIVE changes from 0 to
1
disp “X Drive Alarm” Display an error message

ret End of autoroutine

The following autoroutine responds when either the Left Limit and Right Limit are activated:
on Y_FAULT.#LL | Y_FAULT.#RL Activate autoroutine when the
right or left limit switch is
activated on the Y axis
disp “Y Limit Switch activated” Display an error message

ret End of autoroutine

The following example assumes that an extra ventilator must be activated when the motor
Overheat input signal is activated. The ventilator is controlled by output bit OUT0.4. The
ventilator must be disabled when the signal returns to inactive state.
on Z_FAULT.#HOT Activate autoroutine when bit
Z_FAULT.#HOT changes from 0 to 1.
OUT0.4 = 1 Set output 4 to 1

ret End of autoroutine

on ^Z_FAULT.#HOT When Z changes from 1 to 0

OUT0.4 = 0 Set output 4 to 0

ret End of autoroutine

All bits, not only faults, can be used in autoroutine conditions. Assuming that output OUT0.6 is
connected to an LED indicator, the following autoroutines signals the motion state bit to activate
the indicator, and deactivate it when the axis is no longer in motion:
on X_MST.#MOVE When the X_MST.#MOVE X bit changes from 0
to 1 (signaling that the axis is moving)
OUT0.6 = 1 Set output 6 to 1 (turn on the LED)

ret End of autoroutine

on ^X_MST.#MOVE When the X_MST.#MOVE X bit changes from 1

to 0 (signaling that the axis is no longer moving)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-93

OUT0.6 = 0 Set output 6 to 0 (turn off the LED)

ret End of autoroutine

An autoroutine condition can be any type of expression, not only bit verification. The following
autoroutine provides an alarm message if a fault occurs in the controller:
1 on S_FAULT When a fault occurs

2 disp "Something happened" Display an error message

3 ret End of autoroutine

The above autoroutine displays the alarm message only on the first fault. If one fault bit is already
raised, and another fault occurs, the second fault does not cause the alarm message. For further
discussion, see Chapter 9: Safety Control.
Standard array MERR (motor error) can be used for motor failure processing. While a motor is
enabled, the corresponding element of MERR is zero. If a motor is disabled, the element stores
the reason why the motor was disabled. Codes greater than or equal to 5010 correspond to fault
conditions. The following autoroutine displays a message when the controller disables the X
motor due to any fault.
on X_MERR >= 5010 When the X motor
is disabled
disp “Motor X was disabled. Error code: Display a message
“, X_MERR stating that the
motor was disabled,
and the error code
of the fault
ret End of autoroutine

The standard array AERR can be used to detect abnormal motion termination.
Variables MERR, AERR expose only those faults that cause motor disable or abnormal motion
termination.

5.9.7. Program Management Commands

Program management commands include the following:
program-management-commands :
start-command
stop-command
stopall-command
pause-command
resume-command
enableon-command
disableon-command

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-94 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

As any other command, a program management command can be either executed immediately
from the command prompt, or stored in a buffer. Using program management commands within a
program provides the ability to create a master program that manages execution of other
programs.

5.9.7.1. start Command

The start command activates program execution in a buffer.
The start command syntax:
start-command :
start buffer-number, label-name
The command specifies a target buffer (buffer-number) that contains the program that must be
activated. The buffer-number can be a constant or expression that calculates to integer number.
The controller contains 10 program buffers numbered from 0 to 9. The specified or calculated
buffer number must fall into the range 0 to 9. If the number is out of range, error 3052 is
generated.
The label-name argument is a label in the program. Execution starts from that label.
If the start command is executed from a program, the specified buffer number must be different
from the buffer that contains the current program because a program cannot start itself. It will be
aborted, generating error 3044.
The start command executes successfully if the target buffer is loaded with a program, compiled,
but not running. Otherwise, the start command causes run-time error and aborts the current
program.
The program activated by the start command executes concurrently with the program containing
the start command, and other active programs.
Examples:
The following fragment starts the program in buffer 2 from label PStart:
start 1, 1

start 2, Pstart

The following terminal command displays change in buffer state after the start command was
executed:
?2

Buffer 2: 192 lines, running in line 153

5.9.7.2. stop and stopall Commands

The stop command terminates program execution in a buffer. The stopall command terminates all
currently executing programs except the program that issued the command.
The commands syntax:
stop-command :
stop
stop buffer-number

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-95

stopall-command :
stopall
The stop command without buffer-number the program in the buffer is the normal method of
program termination.
The stop command with buffer-number terminates a program in the specified buffer. A master
program that manages the whole application can use this command in order to terminate a certain
activity.
The stopall command executed by a program terminates all other concurrently executed
programs, but the program itself continue executing.
After termination by the stop or stopall command a program remains in compiled state.
Therefore, if the program contains autoroutines, an autoroutine can be activated after the program
termination as soon as its condition is satisfied.
Examples:
The following command terminates the current program:
stop

The following command terminates the program only if the X axis is disabled:
if ^X_MST.#ENABLED stop; end

The following command terminates the program executed in buffer 3:

stop 3

The following command executed in buffer 0 terminates the programs currently executed in all
buffers except buffer 0:
stopall

The following terminal command displays change in buffer state after executing the stop
command:
?3

Buffer 3: 35 lines, compiled, not running

5.9.7.3. pause and resume Commands

Command pause suspends program execution in a buffer. Command resume resumes execution
of a suspended program.
The commands syntax:
pause-command :
pause buffer-number
resume-command :
resume buffer-number
The pause command suspends the program executed in the specified buffer. If no program is
executed in the buffer, the command has no effect.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-96 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

The resume command resumes execution of the program suspended in the specified buffer. If the
program was not suspended, the command has no effect.
Examples:
The following command suspends the program currently executed buffer 0:
pause 0

The following terminal command displays change in buffer state after executing the pause
command:
?0

Buffer 0: 97 lines, suspended in line 69

The following command resumes program execution in buffer 0:
resume 0

The following terminal command displays change in buffer state after executing the resume
command:
?0

Buffer 0: 97 lines, running in line 83

5.9.7.4. enableon and disableon Commands

The enableon command enables autoroutine activation in a buffer. The disableon command
disables autoroutine activation in a buffer.
The commands syntax:
enableon-command :
enableon buffer-number
disableon-command :
disableon buffer-number
The commands alter the NOAUTO bit in standard variable PFLAGS that controls autoroutines
activation.
If the bit is reset, the controller starts verifying an autoroutine condition and can activate the
autoroutine as soon as the buffer is compiled. Setting the bit prevents autoroutine activation even
if the buffer is compiled and the condition is true.
Examples:
The following dialog shows the effect of the commands on the buffer state:
disableon 0

:
?0

Buffer 0: 97 lines, compiled, not running, autoroutines disabled

:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-97

enableon 0

:
?0

Buffer 0: 97 lines, compiled, not running

:

5.9.8. Interaction Commands

Interaction commands support communication with the host initiated by the controller.
Interaction commands include the following:
disp-command
send-command
interrupt-command
copytodpr-command
copyfromdpr-command
stopcopytodpr-command

5.9.8.1. disp Command

The disp command builds an ASCII output string and sends it to a communication channel.
Syntax: disp argument [, argument. . .]

Syntax Element Description

argument expression | “string“

expression ACSPL+ expression (can be a single variable)
input string "[text] [escape-sequence] [format-specifier] . . ."
String must be enclosed with double quotation marks.

The disp command takes as its argument(s) one or more expressions and/or input strings.
An input string argument can include one or more of the following:
ƒ Text.
ƒ Escape sequence - replaced in output string with a non-printing character or other specified
character (\xHH).
ƒ Formatting specification - determines how the results of an expression that follows the
input string is formatted in output string.

Escape- Adds this character to output string . . .

Sequence

\r Carriage return 0x0d

\n New line 0x0a
\t Horizontal tabulation 0x09

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-98 A C SP L+ M u lt ip r o gr a m min g L a ng u a g e

\xHH Any character. The two hexadecimal digits HH represent the

character's ASCII code.

The format specification syntax adheres to a restricted version of the C language syntax.
The format specification syntax is: % [width] [.precision] type
width
Optional number that specifies the minimum number of characters output.
precision
Optional number that specifies the maximum number of characters printed for all or part of the
output field, or the minimum number of digits printed for integer values
type
Required character that determines whether the associated argument is interpreted as a character, a
string, or a number. The following types are supported:

Character Output Format

d Signed decimal integer.

I Signed decimal integer.
o Unsigned octal integer.
u Unsigned decimal integer.
x Unsigned hexadecimal integer, using “abcdef.”
X Unsigned hexadecimal integer, using “ABCDEF.”
e Signed value having the form [ – ]d.dddd e [sign]ddd where d is a
single decimal digit, dddd is one or more decimal digits, ddd is
exactly three decimal digits, and sign is + or –.
E Identical to the e format except that E rather than e introduces the
exponent.
f Signed value having the form [ – ]dddd.dddd, where dddd is one or
more decimal digits. The number of digits before the decimal point
depends on the magnitude of the number, and the number of digits
after the decimal point depends on the requested precision.
g Signed value printed in f or e format, whichever is more compact for
the given value and precision. The e format is used only when the
exponent of the value is less than –4 or greater than or equal to the
precision argument. Trailing zeros are truncated, and the decimal
point appears only if one or more digits follow it.
G Identical to the g format, except that E, rather than e, introduces the
exponent (where appropriate).

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g La n g u a ge 5-99

If an input string argument contains n format specifiers, the specifiers apply to the n subsequent
expression arguments.
The disp command processes the arguments from left to right. The processing is as follows:
ƒ Expressions: The expression is evaluated and the ASCII representation of the result is
placed in the output string. The format of the result is determined by a formatting
specification (if any) in the input string.
ƒ Input strings: Text is sent as-is to the output string. Escape sequences are replaced by the
ASCII codes that they represent. Formatting specifications are applied to the results of any
expressions that follow the string.
Examples with descriptions:
disp “%15.10f”,X_FPOS

Format X_FPOS in 15 positions with 10 digit after the decimal point

disp “%1i”,IN0.2

Output the current state of IN0.2 as one digit 0 or 1

Examples with resulting output strings:

disp “X_FVEL=%15.10f”,X_FVEL

Output: X_FVEL= 997.2936183303

disp “IN0 as hex: %04X”,IN0

Output: IN0 as hex: 0A1D

disp “IN0.0-3 as binary: %1u%1u%1u%1u”, IN0.0,IN0.1,IN0.2,IN0.3

Output: IN0.0-3 as binary: 0110

The output string is sent to a communication channel. The channel is specified by the current
value of standard variable DISPCH (default channel). The following values are available:
1 – serial communication channel COM1.
2 – serial communication channel COM2.
10 – Ethernet network.
-1 – no default channel is specified, the disp command uses the last channel activated by the host.

5.9.8.2. send Command

The send command is the same as the disp command but also specifies the communication
channel for the output string. The communication channel is the first argument.
Syntax: send channel-number, disp-arguments
Channel-number is an integer identifying the communication channel that the message will be
sent to.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-100 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

Channel number SPiiPlus PCI-4/8

1 Serial port 1
2 Serial port 2
10 Not available
12 Communication through PCI
bus

The disp-arguments are the same as those for the disp command (see page 5-97).

5.9.8.3. Differences Between Query Commands and the disp/send

Commands
ƒ Query commands are executed immediately and cannot be stored in a program buffer. The
disp and send commands can be executed either immediately or can be stored in a buffer and
executed as a part of program.
ƒ Query commands can address any variable: standard, global or local. The disp and send
commands can address any standard or global variable. Among the local variables, only the
local variables defined in the same buffer where the command is located are accessible to the
disp command.
ƒ Query commands can address whole arrays or sub-arrays. The disp and send commands
must specify a calculable expression i.e. only single elements of array may be involved.
ƒ Query commands cannot contain expressions. The disp and send commands can contain
expressions.
ƒ The controller sends the reply to a query command to the same channel where the
command was received. Results of the disp command are sent to the communication channel
defined by the DISPCH variable. Results of the send command are sent to the
communication channel defined by the communication channel argument (channel-number).
Examples:
The following are several examples of disp command with the corresponding printouts:
disp 0

Printout: 0

disp “This is a disp command”

Printout: X_FPOS = 4900

disp “X_FPOS = “, X_FPOS

Printout: X_FPOS = 4900

5.9.8.4. interrupt Command

The interrupt command causes an interrupt that can be intercepted by the host.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-101

For details about interrupts see page 7-17.

5.9.8.5. Dual-Port RAM (DPRAM) commands: copytodpr, copyfromdpr,

stopcopytodpr
The copytodpr command instructs the controller to continuously copy the values of standard
variables from the controller RAM to the DPRAM.
The copyfromdpr command instructs the controller to continuously copy values from the
DPRAM to standard variables.
The stopcopytodpr command cancels all previously executed copytodpr and copyfromdpr
commands, stopping the copying of variables to/from the DPRAM.
See DPRAM support, page 10-1.

5.9.9. Axis/Motor Management Commands

Axis/motor management commands comprise various operations that change the state of the
motors and the axes, establish relations between the motors and the axes, and manage executed
motion.
Axis/motor management commands include the following:
enable-command
disable-command
kill-command
killall-command
fclear-command
set-command
group-command
split-command
splitall-command
connect-command
depends-command
master-command
go-command
halt-command
break-command
imm-command
commut command
The enable command activates one or more motors and drives. After the enable command, the
motor starts following the reference and physical motion is available.
The disable command shuts off one or more drives and motors. After the disable command the
motor cannot follow the reference and remains idle.
The kill command causes one or more motors to terminate motion using second-order
deceleration profile. The deceleration value is specified by the KDEC variable.
The killall command provides kill operation for all motors.
The fclear command clears the current faults and the result of the previous fault stored in the
MERR variable.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-102 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

The set command determines a current value of the feedback, reference or master position.
The group, split and splitall commands manage grouping of the axes in coordinate systems for
multi-axis motion.
The connect command defines the relation between motors and axes.
The master command defines a master value for an axis.
The go command starts a motion that was created using the w (wait) suffix. A motion that has
been created without this suffix starts automatically after creation and does not require the go
command.
The halt command terminates a motion using a deceleration profile. The deceleration value is
specified by the DEC variable.
The break command provides premature termination of a motion with smooth transition to the
next motion.
The imm command provides on the fly change of the motion parameters; velocity, acceleration,
deceleration, jerk, kill deceleration.

5.9.9.1. enable and disable Commands

The enable command activates one or more drives and motors. After the enable command the
motor starts following the reference and physical motion is available.
The disable command shuts off one or more drives and motors. After the disable command the
motor cannot follow the reference and remains idle.
The commands syntax for enable and disable is:
enable-command :
enable motor-specification
disable-command :
disable motor-specification [, reason]
In simple cases motor-specification is single axis letter like X or Z, or a string consisting of axis
letters like XZ, or keyword all (specifies all available non-dummy axes).
Commands enable and disable affect all specified axes.
Optional second parameter of the disable command (reason) must be an integer constant or
expression and specifies a reason why the motor was disabled. If the parameter is specified, its
value is stored in the MERR variable. If the parameter is omitted, MERR stores zero after the
disable operation.
A reason stored in the MERR variable is cleared by the fclear or enable command.
As long as the motor is enabled, the controller provides the following:
• Holds output ENA (enable drive) in active state.
• Calculates PE (position error).
• Performs closed loop control (for servo motors).
• Examines conditions of position error and other faults and raises the corresponding fault bits
if required.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-103

The following variables/bits can modify execution of the enable command:

ENTIME Defines the time (or maximum time) of enable execution
MFLAGS.#ENMOD Defines the mode of enable execution
FMASK.#DRIVE Defines if the drive alarm fault is processed
SAFINI.#DRIVE Defines an active level of the drive alarm safety signal

If the MFLAGS.#ENMOD bit is 1, the ENTIME value defines the time of enable execution.
Executing the enable command, an ACSPL+ program always waits for ENTIME milliseconds. If
then the drive alarm fault is zero, the enable command is considered successful; otherwise the
enable command fails.
If the MFLAGS.#ENMOD bit is 0, the ENTIME value defines the maximum time allotted for
enable execution. Executing enable, an ACSPL+ program monitors the drive alarm input signal.
As soon as the drive alarm becomes inactive, the enable command finishes execution with
success. If the drive alarm signal does not change to inactive state within ENTIME milliseconds,
the enable command fails.
Examples:
enable X Enable motor X

enable ZT Enable motors Z and T

disable Y,5011 Disable motor Y, store 5011 as a disable reason. Code 5011
corresponds to left limit error, therefore the Y motor will be
reported as disabled due to fault involving left limit.
disable XT Disable motors X and T

5.9.9.2. kill and killall Commands

The kill command causes one or more motors to terminate motion using second-order
deceleration profile.
The killall command provides kill operation for all motors.
The commands obeys the following syntax:
kill-command :
kill motor-specification [, cause]
killall-command :
killall [, cause]
In simple cases motor-specification is single axis letter like X or Z, or a string consisting of axis
letters like XZ, or keyword all (specifies all available non-dummy axes).
Optional argument cause must be an integer constant or expression and specifies a cause why the
motor was killed. If the parameter is specified, its value is stored in the MERR variable. If the
parameter is omitted, the MERR stores zero after the kill operation.
If several sequential kill operations specify different causes for the same motor, only the first
cause will be stored in MERR and all subsequent causes will be ignored.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-104 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

A cause stored in the MERR variable is cleared by the fclear or enable command.
Each motor specified in a kill operation decelerates individually using its KDEC deceleration
value.
Any motion related to the killed motors is terminated. If a motion involves several motors and
only some of the motors are specified in a kill command, all other motors decelerate
synchronously using a third-order profile and the DEC deceleration value (same behavior as with
the halt command, see halt command, page 5-114).
The following examples illustrate kill execution under different conditions. (Some of the
examples involve a default connection. This is a condition where a motor depends only on the
corresponding axis and the difference between motor and axis can be ignored. For more
information about default and non-default connections, see connect and depends commands, page
5-109.)

5.9.9.2.1. kill command with motor idle

Assume, none of the currently executed motions involves the Z motor.
Command kill Z does not affect the motor in any way.
Command kill Z,6100 does not affect the motor, but stores code 6100 (user-defined cause) in the
Z_MERR variable. The code is stored only if at this moment the variable is zero, otherwise the
command does not overwrite the previously stored code and the cause specified in the command
is ignored.

5.9.9.2.2. kill command with single-axis motion, default connection

Assume, axis Y executes motion ptp/v Y,6000,20000.
Once kill Y is executed, the motor starts decelerating from its instant velocity using constant
deceleration value specified by the Y_KDEC variable. Deceleration time is
VY / Y_KDEC
where VY is instant velocity at the moment of kill command. VY is not necessary 20000 as
specified in the motion command, it can be lower if the kill command falls in acceleration or
deceleration phases of the motion.
Typically, the motor finishes kill process and stops before it reaches the final motion point of
6000. However, if Y_KDEC < Y_DEC (not recommended in most applications) the motor can
overrun the final point.
The motion is considered to continue execution as long as the kill process is executed. Bit
Y_AST.#MOVE remains 1 while the motor is decelerating and drops to 0 once the motor reaches
zero reference velocity. Bit Y_MST.#MOVE also remains 1 while the motor is decelerating but
drops to 0 only when the motor reference velocity is zero and the motor position error Y_PE
remains less than Y_TARGRAD for more than Y_SETTLE milliseconds.

5.9.9.2.3. kill command with several single-axis motions, default connection

Assume, each of the axes X, Z, A executes independent single-axis motion.
Command kill XZA,6088 is equivalent to kill X,6088; kill Z,6088; kill A,6088 and acts on each
motion independently. Each motor uses its own component of KDEC and the time of the kill
process is different for the motors.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-105

Kill cause 6088 (user-defined code) is stored in X_MERR, Z_MERR and A_MERR. However,
if at the moment one of these variables contains a non-zero value, the value is not overwritten and
the previously stored cause is retained.
Command kill A (again with default connection) kills the A motor and terminates the A motion,
but does not effect motors and motions X and Z.

5.9.9.2.4. kill command with multi-axis motion, default connection

Assume, motion mptp XYA is executed.
Command kill Y causes the Y motor to start decelerating from its instant velocity using constant
deceleration value specified by the Y_KDEC variable. The deceleration continues until the motor
reaches zero velocity.
The behavior of X and A axes is different. Once the kill Y is executed, the motion starts third-
order deceleration process just as a halt command was executed. The X and A axes continue
moving in the common motion. The vector deceleration of the motion is X_DEC and the vector
jerk is X_JERK.
If command kill YA is executed, the kill process applies to Y and A motors. Each motor
decelerates independently from its instant velocity to zero using the constant decelerations
Y_KDEC and A_KDEC. In the same time the X motor decelerates using the third-order profile
and the X_DEC deceleration value, just as a halt command was executed.
If command kill XYA is executed, each motor decelerates independently from its instant velocity
to zero using the constant decelerations X_KDEC, Y_KDEC and A_KDEC.
In all cases bits AST.#MOVE and MST.#MOVE of axes X,Y,A remain 1 as long as any of the
motor continues decelerating. Once all motors reach zero velocity, bits X_AST.#MOVE,
Y_AST.#MOVE and A_AST.#MOVE drop to zero. Bit X_MST.#MOVE drops to zero as soon
as position error X_PE remains less than X_TARGRAD for more than X_SETTLE
milleseconds. So do bits Y_MST.#MOVE and A_MST.#MOVE.

5.9.9.2.5. kill command with non-default connection

If a motor is in non-default connection but depends only on the corresponding axis the effect of
the kill command is similar to the case of default connection. For example, if the connection was
specified as
connect X_RPOS = 0.5*X_APOS*X_APOS

depends X,X

(in this case the depends command is not necessary), the kill X command starts the same kill
process on the X motor and the halt process on the motion that involves the X axis. All above
considerations about the idle motor, single-axis motion and multi-axis motion remain the same.
The result is a little different if a motor depends on another axis or on several axes, for example
connect Z_RPOS = X_APOS + Z_APOS – A_APOS

depends Z,XZA

(in this case the depends command is required). The difference is that the kill Z command applies
the halt operation to all executed motions involving any of the axes X, Z, or A. Correspondingly,

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-106 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

bits Z_AST.#MOVE and Z_MST.#MOVE remain 1 as long as any of these motions continues
its termination process.
Note that a killall (or kill all) command always terminates all executed motions and therefore
makes no difference between the default and non-default connection.

5.9.9.3. fclear Command

The fclear command clears the FAULT variable and the results of the previous fault stored in the
MERR variable.
The command syntax is:
fclear-command :
fclear [motor-specification]
In simple cases motor-specification is single axis letter like X or Z, a string consisting of axis
letters like XZ, or keyword all for all axes.
If motor-specification is omitted the command clears the system faults. If motor-specification is
specified, the command clears the FAULT and MERR components for the specified axes.
However, if a reason for a fault is still active, the controller will set the fault again immediately
after the fclear command.
If one of the cleared faults is encoder error, the command also resets the feedback position to zero.

5.9.9.4. set Command

The set command appoints a current value of the feedback, reference or axis position.
The command syntax is:
set-command :
set assignment-command
Only the following variables can be specified in the left side of the assignment-command:
FPOS Feedback Position
F2POS Secondary Feedback Position
RPOS Reference Position
APOS Axis Reference Position
Although the set command resembles assignment, execution of the set command is different from
assignment. The set command induces a complex operation in the controller instead of a simple
assignment.
Regardless of the left-side variable, execution of the set command starts with calculation of the
right-side expression. The result of the calculation provides the right-side value. Then the
execution depends on the variable specified on the left side.

5.9.9.4.1. set RPOS and set FPOS

The set command that contains RPOS or FPOS, shifts the origin of an axis. For example,
command

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-107

set X_FPOS = 0

places the origin of the X axis to the point where the motor is located this moment.
FPOS and RPOS provide a reference and a feedback value for a motor. If a control loop works
properly, FPOS follows RPOS with small or zero error.
If the error is zero, both set FPOS and set RPOS provide the same result: both FPOS and RPOS
become equal to the right-side value. This is not a simple assignment, and the command adjusts
the controller offsets so that the periodic calculation of FPOS and RPOS will provide the
required results.
If the error is non-zero, the result of set FPOS and set RPOS may differ slightly. Consider the
following example:
?X_RPOS, X_FPOS Query X_RPOS and X_FPOS

6000 The RPOS and FPOS differ by 2 counts due to,

for instance, the bias in the amplifier
6002

set X_RPOS = 0 Set X_RPOS to 0

?X_RPOS, X_FPOS Query X_RPOS and X_FPOS

0 RPOS is set to exact zero

2 FPOS is set to 2 in the current point in order to

retain the offset between RPOS and FPOS
:

set X_FPOS = 0 Set X_FPOS to 0

?X_FPOS, X_RPOS Query X_RPOS and X_FPOS

0 FPOS is set to zero in the current point

-2 RPOS is set to -2 in order to retain the offset

between RPOS and FPOS
:

Note, in both set commands no physical motion occurs. The X axis remains in the same position,
only the internal offsets in the controller are adjusted to shift the origin as required.
Note, that even if a motor is idle, several identical set FPOS commands may place the origin at
slightly different points due to the jitter in feedback.
If a motor is flagged by Default Connection bit (MFLAGS.#DEFCON), variables RPOS and
APOS are conjugate. Therefore, any command that changes RPOS, also changes the
corresponding APOS to the same value.

5.9.9.4.2. set F2POS

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-108 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

The command set F2POS shifts the origin of secondary axis feedback. For example, command
set X_F2POS = 0
places the origin of the X axis secondary feedback to the point where the motor is currently
located.
As a result of the command execution, F2POS becomes equal to the right-side value. This is not a
simple assignment, as the command adjusts the controller offsets so that the periodic calculation
of F2POS will provide the required result (The specified value in the current point).
Note, that even if a motor is idle, several identical set F2POS commands may place the origin in
slightly different points due to the jitter in feedback.

5.9.9.4.3. set APOS

If a motor is flagged by Default Connection bit (MFLAGS.#DEFCON), variables RPOS and
APOS are conjugate, and always keep the same value. In this case, the set APOS command is
identical to the set RPOS command for the same axis.
For non-default connection a motor and the corresponding axis are separated. Variables RPOS
and APOS may have different values. In this case, command set APOS shifts the origin of the
axis but has no effect on the origin of the motor. The controller adjusts offsets so that the
command causes no jerk in the motor.
Note
In the case of non-default connection the controller adjusts offsets only for
the motors that depend on the specified axis. Therefore, the depends
command is significant in a connection specification. If dependence is
specified incorrectly, one or more motors can jump once set APOS=… is
executed.

5.9.9.5. group, split and splitall Commands

Note
The controller automatically creates and splits apart groups. For most
applications, there is no need for the group commands.
Remarks:
• The group command creates a coordinate system for multi-axis motion.
• The split command breaks down an axis group previously created with a group command.
• The splitall command breaks down all axis groups previously created with a group
command.
The commands syntax is:
group-command :
group axes-specification
split-command :
split axes-specification

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-109

splitall-command :
splitall
In simple cases axes-specification consists of axis letters like XZ. After power-up each controller
axis is a single axis, no one axis group exists. One-axis motion does not require any axis group.
One-axis motion can be activated immediately after power-up, assuming that the motor is
enabled. Several one-axis motions can be activated in parallel, and do not require any axis group
definition.
An axis can belong to only one group at a time. If the application requires restructuring the axes,
it must split the existing group and only then create the new one.
For example, the command
group XZT

creates an axis group that includes axes X, Z and T.

The first axis in the axes-specification (X in the above command) is the leading axis. The motion
parameters of the leading axis become the default motion parameters for the group. For example,
for the above group XZT the values of standard variables X_VEL, X_ACC, X_DEC, X_JERK,
X_KDEC becomes the default values of velocity, acceleration, deceleration, jerk and kill
deceleration for all motions executed in this group. If for example, a group was defined as ZXT,
the Z axis is leading and the values of Z will be used as the default motion parameters.
In all other aspects the leading axis has no preference, and the order of axis letters in group
definition is not important. The motion commands referencing a group are not required to specify
all axes of the group or in the same order. However, an axis can belong to only one group, so all
specified axes must belong to the same group. Motion command that references axes from
different groups will fail.
The split command must specify the same axes as the group command that created the group.
After the split command the group no longer exists.
The splitall command breaks down all existing groups. An ACSPL+ program that starts in
unknown environment (not just after power-up) can execute the splitall command in order to
ensure that no axes are grouped.

5.9.9.6. connect and depends Commands

The connect command defines the connection between a motor and axes.
The depends command complements the connect command, specifying dependence between a
motor and axes.
NOTE
The connect and depends commands cannot be executed as long as the
default connection bit (MFLAGS.#DEFCON) is raised.

5.9.9.6.1. connect Command

Syntax: connect assignment-command
assignment-command syntax: axis RPOS = expression

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-110 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

where axis RPOS is an axis RPOS variable(for example, X_RPOS), which receives the value
of the expression.
For more information about RPOS and other common motion variables, see motion overview,
page 3-16.
The connect command is not an assignment command (see , assignment commands page 5-75). It
does not simply assign the result of the formula on the right side to the axis RPOS.
The formula not evaluated when the connect command is executed (which would be the case for
an assignment command). Instead, the formula is stored and then evaluated by the controller
every controller cycle to calculate the corresponding RPOS.
After power-up the controller always starts with the default connection. The default connection
means the following for each axis:
• Bit MFLAGS.#DEFCON is raised.
• The default connect formula is defined as connect RPOS = APOS.
• APOS and RPOS are linked, i.e., explicit (through the set command) or implicit change of
one of these variables causes the same change in the other one.
Once an application resets MFLAGS.#DEFCON, it can then execute a connect and (typically) a
depends command. At that point, the motor is considered to be in non-default connection.
Consider the following examples:
The commands
Y_MFLAGS.#DEFCON = 0

connect Y_RPOS = X_APOS

depends Y, X

connect the Y motor position to the X axis reference. If the X motor is also connected to the X
axis reference, this provides gantry-like motion of two motors.
The command
ptp X, 1000

will provide synchronous motion of both X and Y motors.

The command:
connect X_RPOS = X_APOS + AIN1

connects the X motor position to the X axis reference plus analog input 1. In this case the X axis
provides a motion and the analog input (for example, an external sensor) supplies a correction for
the X motor.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-111

The following commands

Z_MFLAGS.#DEFCON = 0

connect Z_RPOS = Z_APOS + T_APOS

depends Z, ZT

connects the Z motor to the sum of axes Z and T. The axes can each execute an independent
motion, with the Z motor following the sum of the two motions. Or the axes can participate in a
single multi-axis motion.

5.9.9.6.2. depends Command

Syntax: depends motor,axes-specification
The motor argument specifies a motor. The axes-specification argument specifies one or more
axes on which the motor depends.
Typically, a depends command will follow a connect command. Whereas a connect command
can define a mathematical correspondence between a motor’s reference position (RPOS) and one
or more axis positions (APOS), a depends command specifies logical dependence between a
motor and axes.
The depends command is necessary because generally the controller is not capable of deriving
the dependence information from the connect formula alone. For this reason, once a connect
command is executed, the controller resets the dependence information of the motor: the motor
depends only on the corresponding axis.
The connect command is used to define a mathematical formula for calculating an axis's RPOS.
The depends command is used to define the dependence between a motor and one or more axes.
Dependence information, as specified using a depends command, is required in the following
cases. If the dependence information is not provided correctly, the controller may display strange
behavior.
• A motor/axis query (for example, ?X) returns the non-default dependence for that motor.
• When initiating a motion, the controller verifies if each motor dependent on the axes
involved is enabled. If one or more motors are disabled, the motion does not start.
• If in the process of motion a motor is disabled or killed due to a fault or due to a disable/kill
command, the controller immediately terminates all motions involving the axes that the
motor depends on.
• Once a set APOS=… command is executed, the controller adjusts offsets in the connection
formulae of the motors that depend on the specified axis.

5.9.9.6.3. Using a Non-default Connection

Listed below are some of the tasks that can be resolved using the appropriate connect formulae:
• Introduce a gear ratio between a logical axis and a physical motor.
• Compensate for encoder errors and backlash.
• Compensate for non-orthogonality of machine slides.
• Compensate for undesired mutual interference between machine coordinates.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-112 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

• Implement gantry axes

• Define the physical motion as a sum of a logical motion and a compensating signal.
• Define the physical motion as a sum of two or more logical motions.
• Inverse kinematics, such as programming in Cartesian coordinates a machine that actually
has polar kinematics .
Typically, the connect command for a specific motor is executed only once in an ACSPL+
application.
A typical location for a connect command is after the homing process in the code that follows an
AUTOEXEC label (see more about AUTOEXEC label, page 5-10). The following pseudocode
executes homing of X and Y axes and configures them as a gantry pair that follows the motion on
the X axis:
AUTOEXEC: The controller automatically starts the
program from the AUTOEXEC label after
power-up.
. . . Execute homing of X and Y axes.

Y_MFLAGS.#DEFCON=0 Reset the #DEFCON bit.

connect Y_RPOS=X_APOS Set gantry-like connection (Y motor follows

X axis).
depends Y,X Specify dependence (Y motor depends on X
axis).
set X_APOS=0,X_RPOS=0,Y_RPOS=0 Set origin.

. . . Continue.

A more sophisticated application may require changing the connection in the middle of
operations. The controller applies no limitations regarding when a connection can be changed. In
a typical case, changing connection requires three commands:
connect X_RPOS=… Specify connection of X motor.

depends X,… Specify dependence of X motor.

set X_APOS=…,X_RPOS=… Set origin of X axis and X motor.

To return to default connection use the following commands:

connect X_RPOS=X_APOS X motor will follow the X axis.

X_MFLAGS.#DEFCON=1 Set #DEFCON bit.

set X_RPOS=… Set origin of X motor (if #DEFCON=1 the

APOS is set to the same value).

5.9.9.6.4. Offset in Connect Formula

If a motor is in non-default connection, the APOS and RPOS variables are not linked and may
contain different values.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-113

The connect command specifies a basic formula that the controller uses to calculate the RPOS.
However, in the process of RPOS calculation the controller also adds an implicit offset which is
not specified in the connect formula.
The controller calculates the offset automatically and recalculates it in the following
circumstances:
• Execution of connect RPOS=… command for the motor.
• Execution of set RPOS=… or set FPOS=… command for the motor.
• Execution of set APOS=… command for any axis that the motor depends on.
• Execution of enable command for the motor.
When a connect command is executed, the offset is adjusted so that the RPOS specified on the
left side of the connect formula and any APOS specified on the right side retain their current
values. For this reason the connect command can be executed while the motor is enabled and
does not cause a motor jump. Using this implicit offset the controller ignores any explicit offset
specified in the connect formula. For example, the following commands have exactly the same
effect:
connect X_RPOS = 0.5*X_APOS + 1000

and
connect X_RPOS = 0.5*X_APOS + 2000

because the explicit offset is ignored.

When an enable command is executed, the offset is adjusted so that the connection formula
calculation yields the desired value (RPOS retains its value).
The set RPOS=… or set FPOS=… command immediately changes the values of RPOS and
FPOS. The offset is recalculated so that the connection formula calculation yields the new desired
value.
The set APOS=… command immediately changes the value of axis position APOS. In order to
retain the current values of all RPOS components, the controller recalculates the offsets of all
motors that depend on the axis.
For more connect command examples, see also signal processing examples on page 5-50.

5.9.9.7. go Command
The go command starts a motion that has been created using the w (wait) suffix. A motion that
has been created without this suffix starts automatically after creation and does not require the go
command.
The command syntax is:
go-command :
go axes-specification
In simple cases motor-specification is single axis letter like X or Z, or a string consisting of axis
letters like XZ, or keyword all.
There following possibilities are available:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-114 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

Starting single-axis motion.

A go command specifies one axis that is not included in any group. The command starts the last
created motion for the same axis. If the motion was not created, or has been started before, the
command has no effect.
Example:
Starting common motion.
A go command specifies a leading axis in a group. The command starts the last created motion for
the same axis group. If the motion was not created, or has been started before, the command has
no effect.
Example:
1 ptp/w X, 1000 Create the motion, but do not start it

2 till IN0.1 Wait until input 1 is activated

3 go X Start the motion

Synchronous start of several motions.
A go command specifies several axes. Each axis in the specification must be either a single axis
not included in any group or a leading axis in a group. The command synchronously starts the last
created motions for all specified axes and groups. If any of referenced motions was not created, or
has been started before, the command does not affect this axis/group but does affect all other
specified axes/groups.
Example:
1 ptp/w XY, 1000,1000 Create the motion, but not start it

2 ptp/w Z, 8000 Create the motion, but not start it

3 go XZ Start both motions synchronously

5.9.9.8. halt Command

The halt command terminates a motion using a deceleration profile. The deceleration value is
specified by the DEC variable.
The command syntax is:
halt-command :
halt axes-specification
In simple cases motor-specification is single axis letter like X or Z, or a string consisting of axis
letters like XZ, or keyword all for all axes.
The following possibilities are supported:
Terminating single-axis motion.
A halt command specifies one axis that is not included in any group. The command terminates
the currently executed motion for the same axis. If no motion is executed, the command has no
effect.
Terminating common motion.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-115

A halt command specifies a leading axis in a group. The command terminates the currently
executed motion in the same axis group. If no motion is executed, the command has no effect.
Terminating several motions.
A halt command specifies several axes. Each axis in the specification must be either a single axis
not included in any group or a leading axis in a group. The command terminates currently
executed motions in all specified axes and groups. If any of referenced axes are idle, the
command does not affect this axis/group but does affect all other specified axes/groups.

5.9.9.9. break Command

The break command terminates a motion without building deceleration profile. The command
executes differently in the following two cases:
1. The next motion already waits in the motion queue. The break command terminates the
current motion and starts the next motion immediately. The controller provides smooth
velocity profile of transition from motion to motion.
2. There is no next motion in the motion queue. The break command has no immediate effect.
The current motion continues until the next motion appears in the motion queue. At that
moment the controller breaks the current motion and starts the next as described above. If the
current motion finishes before the next motion comes to the queue, the command has no
effect.
The command obeys the following syntax:
break-command :
break axes-specification
In simple cases axes-specification is single axis letter like X or Z, a string consisting of axis
letters like XZ, or the keyword all (specifies all available non-dummy axes).
The break command is not intended for use with master-slave or path motion.
The following possibilities exist:
Terminating single-axis motion.
A break command specifies one axis that is not included in any group. The command terminates
the currently executed motion for the same axis. If no motion is executed, the command has no
effect.
Terminating multi-axis motion.
A break command specifies a leading axis in a group. The command terminates the currently
executed motion in the axis group. If no motion is executed, the command has no effect.
Caution
In multi-axis motion, smooth vector velocity profiles do not always assure
smooth motion of the coordinates. The user application must provide nearly
tangent motion trajectories in the junction point to avoid jumps in coordinate
velocity, which may cause damage to equipment.
Terminating several motions.
A break command specifies several axes. Each axis in the specification must be either a single
axis not included in any group or a leading axis in a group. The command terminates currently

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-116 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

executed motions in all specified axes and groups. If any of referenced axes are idle, the
command does not affect this axis/group but does affect all other specified axes/groups.
NOTE

The break command is not supported in path or master-slave motion.

5.9.9.10. imm Command

The imm command provides on the fly change of motion parameters.
The command obeys the following syntax:
imm-command :
imm assignment-command
The following variables only can be specified in the left side of the assignment-command:
VEL Velocity
ACC Acceleration
DEC Deceleration
JERK Jerk
KDEC Kill deceleration

Although the imm command resembles assignment, execution of the imm command differs from
normal assignment to the same variables.
As in conventional assignment, execution of the imm command starts from calculation of the
right-side expression. The calculated right-side value is assigned to the left-side variable.
Execution of flat assignment finishes at this point.
The difference between conventional assignment and the imm command becomes apparent when
the command executes while a motion is in progress. The assignment command does not affect
the motion in progress or any motion that was already created and waits in a motion queue. Only
the motions created after the assignment will use the motion parameters changed by the
assignment. The imm command, on the other hand, not only changes the specified variable, but
also affects the motion in progress and all motions waiting in the corresponding motion queue. To
change a motion on the fly, the imm command must change a variable of the axis that is a single
axis of the motion or a leading axis if the motion is in axis group.

5.9.9.11. commut Command

The commut command performs autocommutation and may be used when the following
conditions hold true:
• motor is DC brushless (AC servo)
• motor is enabled
• motor is idle
The commut command is used in autocommutation-based startup programs.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-117

The command will operate properly only after the SPiiPlus MMI Adjuster has been used to:
• perform initial commutation adjustment
• adjust the motor properly
• save the adjustment parameters to the controller’s flash memory.
Commutation using the SPiiPlus MMI Adjuster is described in depth in the SPiiPlus Setup
Guide.
Motor movement during commutation very much depends on the servo settings.
The commut command will not operate properly if variable SLPKP is set to zero, or the
integrator is very low.
The command has the following syntax:
commut-command :
imm-command :
commut axis, excitation-current, settle-time, slope
If one of the parameters is omitted then default values are used.
The excitation-current is given as a percentage of the full command. Its default value is set to
98% of the XRMS variable, which indicates the nominal current of the system. Note:
• In air bearing systems a lower excitation current may be required.
• In high friction systems a higher excitation value is required.
The excitation current should be the same as that determined by the user in the initial
commutation adjustment process.
The settle-time parameter determines settling time (default: 500 msec) for the autocommutation
process initiated by the commut command. The entire autocommutation process lasts
approximately three times longer, since the command executes the algorithm three times for
verification. Note:
• In low-bandwidth systems (high inertia, etc.) a higher value may be required.
The settling time should be the same as that determined by the user in the initial commutation
adjustment process.
The slope parameter is optional, and used only in special cases. If a value is assigned to this
parameter then the excitation current command builds up with some slope. The parameter sets the
duration of the current build-up process in milliseconds. It is usually recommended to omit this
parameter, in which case the excitation current is built instantly.

5.9.10. Motion Commands

A motion command creates a motion of specific type and specifies parameters for the motion.
The following motion commands are available:
ptp Creates a point-to-point motion. 6-1
jog Creates a jog motion. 6-9
mptp Creates a multipoint motion. 6-10

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-118 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

point Adds a point to mptp, path, or pvspline motion. 6-10

mpoint Adds a set of points to mptp, path or pvspline 6-10
motion.
path Creates an arbitrary path motion (linear 6-20
interpolation).
pvspline Creates an arbitrary path motion (spline 6-24
interpolation).
master Defines a formula for master value calculation. 6-30
slave Creates a master-slave motion. 6-31
mseg Creates a segmented motion. 6-33
line Adds a linear segment to mseg motion. 6-33
arc1, arc2 Adds a circle segment to mseg motion. 6-33
stopper Adds a segment separator to mseg motion. 6-33
ends Finishes adding points or segments to mptp, path 6-10, 6-20,
or pvspline, or mseg motion. 6-24, 6-33

For details about motion commands see Motion(Chapter 6).

5.9.11. Miscellaneous Commands

The miscellaneous commands include:
• data collection commands:
dc, stopdc
• PEG™ commands:
peg_i, peg_r
• nonvolatile memory commands:
write, read
• variable protection command:
setprotection

5.9.11.1. Data Collection Commands: dc, stopdc

Data collection is a feature that enables collecting samples of one or more controller variables in a
user-defined array.
The following commands support data collection:
dc Start data collection
stopdc Stop data collection prematurely

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-119

For details about data collection see Section 7.2.5.

5.9.11.2. Position Event Generation (PEG) Commands: peg_i, peg_r

PEG is a hardware-supported feature that generates a pulse on a digital output and when the
encoder position matches a predefined value. For a detailed description of PEG, see Section 7.2.
There are two PEG commands: peg_i and peg_r.
peg_i activates incremental PEG, where pulses are generated at predefined position intervals. For
details about peg_i, see Section 7.2.3.
peg_r activates random PEG, where predefined pulses are generated upon position events. For
details about peg_r, see Section 7.2.4.
stoppeg immediately terminates PEG. For details about stoppeg, see Section 7.2.5.

5.9.11.3. Nonvolatile Memory Commands: write, read

5.9.11.3.1. write Command

Writes an array to a file in the nonvolatile (flash) memory.

write array-name, file-name

Arguments

array-name Name of any standard or user array.

file-name Name of file in the nonvolatile (flash) memory.
Remarks
If a user array is specified for the array-name argument, the user array name must be declared in
the buffer where the command is executed. If the command is executed as a terminal command,
the array name must specify an array with global scope, i.e., any standard or user global variable.
The file name must contain only the name without an extension. Quotation marks are not
required. The name cannot include spaces. If a file with the specified name does not exist, it is
created. If the file already exists, it is overwritten.
The value saved by the write command can be retrieved by the read command. The arrays
specified in the corresponding write and read command must have the same type and dimension.

5.9.11.3.2. read Command

Reads an array from a file in the nonvolatile (flash) memory. The file must already have been
written by a write command.

read array-name, file-name

Arguments

array-name Name of any standard or user array.

file-name Name of file in the nonvolatile (flash) memory.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-120 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

Remarks
If a user array is specified for the array-name argument, the user array name must be declared in
the buffer where the command is executed. If the command is executed as a terminal command,
the array name must specify an array with global scope, i.e. any standard or user global variable.
The file name must contain only the name without an extension. Quotation marks are not
required. The name cannot include spaces. If a file with the specified name does not exist, it is
created. If the file already exists, it is overwritten.
If a file with the specified name does not exist, or the size of the saved variable does not
correspond to the size of the specified variable, the function causes a run-time error.

5.9.11.4. safetyconf Command

configures a specified fault for a specified group of axes.

safetyconf axis-list, fault, conf-string

Arguments

axis-list List of axes for the group. Fault configuration of first axis in
list is applied to all the axes.
fault A fault constant, (example: #LL).
conf-string String enclosed in double quotation marks. The string contains
one or more of the following characters:
K: enables kill response
D: enables disable response
Both K and D: enable kill-disable response
+: provides fault generalization
-: disables fault detection
If an empty string is specified, fault detection is enabled, but
the controller has no response to the fault. However, an
autoroutine can intercept the fault and provide a response.
Remarks
The safetyconf command overwrites any previous configuration for the specified fault for the
specified axes. However, the command does not invalidate any active safety groups.
The following examples illustrate fault configuration:

safetyconf X,#PE,”K” X motion will be killed if the X Position Error fault occurs.
safetyconf ZA,#LL,”KD” X motion will be killed and then the X motor will be disabled
if the X Left Limit fault occurs.
A motion will be killed and then the A motor will be disabled
if the A Left Limit fault occurs.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-121

safetyconf all,#DRIVE,”D+” All axes will be disabled if a Drive Alarm fault occurs on any
axis.
safetyconf all,#VL,”-” The Velocity Limit fault will not apply for any axis.

5.9.11.5. safetygroup Command

Executes the following actions:
• Copies the fault configuration from the first axis in the axis-list to all subsequent axes in the
list
• Determines that the axes respond as a block to kill and disable operations applied to any axis
in the group.

safetygroup axis-list
Arguments

axis-list List of axes for the group. Fault configuration of first

axis in list is applied to all the axes.
Remarks
After the command is executed, all the axes in the group respond similarly and simultaneously to
a kill or disable operation, even if the operation was directed to only one of the axes.
Therefore:
• A fault that causes a kill or disable of one of the grouped axes, affects equally all other axes
in the group.
• A kill or disable command applied to one of the grouped axes, has the same affect on all
other axes in the group.

5.9.11.6. setprotection Command

The setprotection command sets a standard variable's protection attribute.
To set a variable's protection, the syntax is:
setprotection variable = 1
To remove a variable's protection, the syntax is:
setprotection variable = 0
If a variable represents an array, all elements of the array share the same protection attribute.
Therefore the array as a whole can be protected or not protected. Protection cannot be specified
for individual elements in the array.
For related information about application protection see 5.10.

5.10. Protection
Application protection does the following:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-122 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

• Protects the user application from unintentional modification.

• Prevents harmful operator intervention while the application is running.
• Restricts erroneous changes to critical data and execution of potentially dangerous
operations while the application is running.
NOTE
Protection does not prevent a user from viewing an ACSPL+ program
and copying the program code.

At any time the user can enable or disable application protection. When application protection is
disabled, none of the protections specified above apply.
When application protection is enabled, the controller is said to be in protected mode. When
application protection is disabled, the controller is said to be in configuration mode.
At any time the user can intentionally delete the application in the controller. This operation
brings the system to factory default state and disables all protections.

5.10.1. Protected Features

In protected mode the following operations are disabled:
• Assignment to any protected variable.
• Editing, or opening, an ACSPL+ buffer (also require that the
PFLAGS(buffer).#NOEDIT bit for the buffer be set).
• Commands #C, #X, #S, #P, #SR, #XS, #XD, #BR, and #BS (also require that the
PFLAGS.#DEBUG bit for the affected buffer be set).
• Working with SPiiPlus SPiiDebugger.
• All memory management commands, for example, #SAVE, #LOAD, etc.
• All operations that change the flash memory.
• Changing SP program or adjustment data.
• SETSP function.
• connect command.
• Any command received via any communication channel if the Communication Shutdown
bit is set.

Protected mode affects all controller commands, including:

• Any command sent to the controller for immediate execution.
• Any command executed in a controller buffer (unless the Privileged bit is set).
• Any operation initiated by SPiiPlus C Library or by an SPiiPlus Tools.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-123

Any command that involving a prohibited action will be rejected with the error “Protection
violation.”
Protection does not affect power-up operations of the controller. Therefore, the user application
stored in the flash memory will be loaded on power-up, including the saved values of all protected
variables and all saved ACSPL+ programs. If one or more programs contains an AUTOEXEC
label, the program will automatically start executing from this label.

5.10.2. Switching Between Protected and Configuration Modes

The following commands switch between protected mode and configuration mode:
#PROTECT
#UNPROTECT
The #PROTECT command applies application protection (puts the controller in protected mode).
The #UNPROTECT command disables application protection (returns the controller to
configuration mode).
While executing the #PROTECT command, the controller reloads from the flash memory all
elements of the user application, including configuration parameters, ACSPL+ programs, SP
programs and data.
The #PROTECT command also stops all programs and disables all drives. This is done for safety
reasons.
Typically, the user executes a #SAVE command before the #PROTECT command in order to
store the application in the flash memory.
After reloading ACSPL+ programs from the flash, the controller compiles the programs. If a
compilation error occurs, the #PROTECT command fails and the controller remains in
configuration mode.

5.10.3. CFG Variable

The standard controller variable CFG (Configuration) indicates whether the controller is in
protected or configuration mode. The variable is read-only.
In configuration mode, CFG is 1. In protected mode, CFG is 0.

5.10.4. Protection of Variables

When the controller is in protected mode, any assignment to a protected variable is prohibited.
By default the controller defines a set of protected variables. These are:

AFLAGS BAUD CERRA CERRI CERRV CTIME DCOM

DELI DELV E_FREQ E_SCMUL E_TYPE E2_TYPE EFAC
E2FAC ENTIME ERRA ERRI ERRV FDEF FMASK
FVFIL IMASK LOWD LOWV MFF MFLAGS ONRATE

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

5-124 A C SP L+ M u lt ip r o gr a mm in g L a ng u a g e

PFLAGS PRATE RVFIL S_FDEF S_FMASK S_SAFINI SAFINI

SETTLE SLLIMIT SRLIMIT STEPF STEPW SYNV TARGRAD
TCPIP XACC XCURI XCURV XRMS XSACC XVEL

The user is able to change the protection attribute for each variable individually. The following
command specifies the variable to be protected:
setprotection variable = 1
The following command specifies the variable to be not protected:
setprotection variable = 0
The variable is any standard variable name except the read only variables.
Only standard variables can be protected. Assignment to a user variable is allowed in any
controller mode.
If a variable represents an array, all elements of the array share the same protection attribute.
Therefore the array as a whole can be protected or not protected. Protection cannot be specified
for individual elements of the array.
The setprotection command can be executed only in configuration mode.
The state of protection attribute for each variable is stored in the flash memory when the
controller executes the #PROTECT command.

5.10.5. Protection of ACSPL+ Programs

When the controller is in configuration mode, program buffers are accessible for both viewing
and editing.
However, when the controller is in protected mode, edit-access to a buffer can be prevented
(view-access is always allowed).
Each row in the PFLAGS array applies to one of the buffers. For example, PFLAGS(0) deals
with buffer 0. Raising variable PFLAGS(buffer).#NOEDIT (bit 1) disables editing of the
corresponding buffer when the controller is in protected mode (bit default value is 0).
The PFLAGS variable itself cannot be changed in protected mode.

5.10.6. Privileged Buffer

One or more buffers can be marked as privileged. The program in a privileged buffer is executed
irrespective of the protection mode. In other words, the program is executed as if there is no
protection.
Raising variable PFLAGS(buffer).#PRIVILEGE (bit 4) marks the corresponding buffer as
privileged (bit default value is 0).
The program in the privileged buffer can change the values of protected variables, write to SP
variables, start and stop other ACSPL+ programs, and execute any other action that in a regular
buffer would cause a protection violation.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A C S PL + M u lt ip r og r a mm in g L an g u a ge 5-125

5.10.7. Communication Shutdown

The user can disable executing commands and queries received via communication channels
while the controller is in protected mode.
The following bits of the COMMFL variable control the communication shutdown:
Bit 7, Disable Commands: controls the communication in protected mode. If the bit is
raised, the controller ignores any command received via communication channels except
the queries that start from ‘?’ character. The bit is not effective if the controller is in
configuration mode. The default of the bit is 0.
Bit 8, Disable Queries: controls the communication in protected mode. If the bit is raised,
the controller ignores any query received via communication channels. The bit is not
effective if the controller is in configuration mode. The default of the bit is 0.
If both bits are raised, the controller in protected mode ignores any commend or query received
via any communication channel.
The only exception is the #UNPROTECT command: A valid #UNPROTECT command is
accepted even if the communication shutdown is in effect. This provides transfer to configuration
mode and enables the communication.
Communication shutdown does not affect executing the ACSPL+ programs in the buffers.
Communication shutdown does not prevent sending unsolicited messages from the controller as a
result of executing the disp or send command. Also communication shutdown does not affect
executing the input command, i.e., the controller accepts from a communication channel
messages that are in response to the input command.
Therefore, if communication shutdown is in effect, the communication with the controller is
restricted to messages sent by the disp or send command and messages accepted by the input
command.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 M o t io n 6- 1

6. MOTION

See also the list of motion-related standard parameters, page 11-2.

See also how axes are designated in commands, page 5-11.

6.1. Point To Point Motion

Point to point (PTP) motion provides positioning to a specified target point.

6.1.1. ptp Command

Command ptp
Associated commands go, halt, kill, break, imm
Suffixes e – Wait for motion termination before executing
next command.
f – Allow specification of non-zero final velocity
m – Use the maximum motion profile values in the
axis group as a whole rather than those of the leading
axis
r – Consider the target point value as relative to the
start point.
v – Use the specified velocity instead of the default
velocity
w – Create the motion, but do not start until the go
command.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 2 M o t io n

In the simplest case the ptp command looks like this

ptp X, 1000

If the axis is moving when the command is executed, the controller creates the motion and inserts
it into the axis motion queue. The motion waits in the queue until all motions before it finish, and
only then starts.
This command creates a motion of the X-axis to the absolute target point of 1000. If the axis is
idle when the command is executed, the motion starts immediately.
If the e suffix is specified, the controller will wait until the motion terminates before executing the
next command. The e suffix is a convenient substitute for following the ptp command with
another command that waits for motion termination.
For example, the command:
ptp/e Y,1000

is equivalent to
ptp Y,1000

till ^Y_AST.#MOVE

Append the w suffix to the command to prevent the motion from starting immediately even if the
axis is idle.
The command:
ptp/w X, 1000

creates a motion to the absolute target point 1000, but the motion will not start until the go X
command is executed.
In the two examples above the value 1000 is an absolute target point. Use the r suffix to specify a
relative value:
ptp/r X, 1000

This command creates a motion to relative target point, which will be defined exactly only when
the motion starts. When the motion starts, the target point is calculated as instant axis position
plus the specified value.
For example, the following two commands
ptp X, 1000

ptp/r X, 1000

are equivalent to
ptp X, 1000

ptp X, 2000

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 3

In the previous examples the motion executed using the default velocity X_VEL for the specified
axis. Use the v suffix to override the default velocity, as shown in the following example:
ptp/v X, 1000, 15000

The motion created will ignore the default velocity X_VEL and execute at a velocity of 15000.
The default value X_VEL remains unchanged.
Several suffixes can be combined in one command. For example, the command
ptp/rv X, 1000, 15000

creates a motion to relative target point 1000 using velocity 15000.

6.1.2. Multi-Axis Point to Point Motion

The examples shown above specified a single-axis motion. However, the axis, as specified in the
ptp command, can be either a single axis or an axis group, which means that it defines a multiaxis
move.
The command
ptp XYT, 1000,2000,3000

creates a temporary axis group that includes axes XYT and executes motion in one group.
Temporary axis groups are automatically created and split-up by the controller. A group is
automatically split-up if the following motion does not address all the axes in the group.
As mentioned in Section 3.4.2, in multi-axis PTP move the controller normally takes the motion
parameter values from the leading axis. However this can be overridden by using the M suffix,
which causes the controller to calculate the maximum allowed common motion velocity,
acceleration, deceleration and jerk.
The calculation examines the VEL, ACC, DEC, JERK parameters of the axes involved and the
projections of the motion vector to the axes.
Example:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 4 M o t io n

FIGURE 6-1 Multi-axis move used in ptp /m example

For the XY move shown in FIGURE 6-1, executed with ptp /m, the controller determines the
maximum common velocity (Vc), where
x and y are the projections of the motion vector on the x axis and y axis respectively.
Vx is the maximum common velocity allowed by the X axis
Vy is the maximum common velocity allowed by the Y axis

X _ VEL × x 2 + y 2
Vx =
x
Y _ VEL × x 2 + y 2
Vy =
y
as follows:
If V x < V y then Vc = Vx else Vc = V y

This applies irregardless of the order in which the axes appear. Vc will be the same for
ptp/m XY, 1000, 2000

as it is for
ptp/m YX, 2000, 1000

The calculation works the same way where more than two axes are in the group. For example, if
there are four axis moving, the maximum common velocity allowed for each axis is calculated
and compared, with the lowest of them assigned to Vc.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 5

If the m suffix is combined with the v suffix, the m suffix is ignored for the velocity and the
velocity specified in the command is used. However, common acceleration, deceleration, and jerk
are still calculated.

6.1.3. Advanced Topics

6.1.3.1. Target Point as Expression

Target point in the ptp command can be specified by expression. Consider the following program
fragment:
int J Declare integer
variable J
J = 0 Set J to zero

loop 30 Execute the loop

30 times
enable XY Enable motors

ptp XY, 30*cos(2*3.14159/30*J), Perform a point-to-

20*sin(2*3.14159/30*J)
point motion
according to the
formula specified

wait 100 Wait 100 msec

J = J + 1 Increment J

end

stop

The program executes the ptp command 30 times. Each time, the command defines a new target
point in the XY plane with a dwell of 100 msec. at each point. The motion trajectory between the
specified points is straight, and the target points are spread equally along the ellipse as shown in
the following figure:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 6 M o t io n

FIGURE 6-2 An example of target point as expression

6.1.3.2. Axis as Expression

Axis in the ptp command can also be specified by expression. The expression calculates to an
integer number that should be in the range 0 to 7, corresponding to the eight axes. Value 0
corresponds to the X axis, 1 to Y, and so on. Consider the following program fragment:
int J Declare integer variable J

J = 0 Set J to zero

loop 8 Perform the loop eight times

ptp (J), 0 Move axis J to point 0

J = J + 1 Increment J

end

When ptp executes the first time J = 0, which corresponds to the X axis. Therefore, the command
starts motion of X to point 0. The second time J = 1 and the ptp command starts motion of the Y
axis to point 0. The third time the ptp command starts motion of the Z axis, and so on. When the
program finishes, all axes are positioned at their origin.
Note that each ptp command creates a motion, without waiting for the previous motion to finish
before the next motion starts. The program executes at a default rate of one command line per
controller cycle, and the default is one millisecond. The Y axis will therefore start moving a few
milliseconds after the X axis starts moving, and the Z axis will start moving a few milliseconds
after the Y axis. Thus, all axes will simultaneously be in motion

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 7

6.1.3.3. Registration Mark Movement

NOTE
Mark input is only available for stepper motors if at least one of the
following bits is set: MFLAGS.5 or MFLAGS.6.

The controller provides position latch facility with extra fast response.
When the MARK1 input signal is activated, the instantaneous position is automatically latched
into the MARK variable. Simultaneously, the corresponding bit IST.#MARK is raised indicating
that the MARK variable contains a valid value. Additional occurrences of the MARK1 input
signal are not latched as long as the corresponding bit IST.#MARK remains raised. The MARK
variable therefore retains the position of the first occurrence until the application explicitly resets
the IST.#MARK bit. The latched position accuracy is ±1 encoder count at any velocity up to
5,000,000 counts/sec.
Assume that the following motion must be built:
1. Move to the mark position
2. Latch the exact mark position and continue moving
3. Stop the motion smoothly at the position calculated as mark position plus 15000 units
The following program fragment performs the task:
X_IST.#MARK = 0 Enable MARK1 signal latching
jog X, + Start jogging in the positive direction
till X_IST.#MARK Wait for MARK1 signal
ptp X, X_MARK + 15000 Start positioning to the point X_MARK+15000

Assignment X_IST.#MARK = 0 in the first line, resets the status bit of MARK1. The reset is
required, in case the MARK1 signal previously occurred, which would have raised
X_IST.#MARK and prevent further latching. To approach the mark position, a jog motion is
used (line 2). Mark position is assumed to be located in the positive direction.
The till command provides waiting for MARK1 signal to change from zero to one. When the till
command terminates, the X_IST.#MARK is raised and the X_MARK contains a valid value of
mark position. The value is used in the ptp command to specify the target point. The controller
automatically provides smooth transition from jog to PTP motion without deceleration to zero.

6.1.3.4. PTP Command With Non-Zero Final Velocity

By default, PTP motion approaches the final point with zero velocity.
Some applications require combining two motions so that the velocity at the transition point does
not drop to zero. The first motion in this sequence must come to the final point with a specified
non-zero velocity.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 8 M o t io n

Suffix f attached to the ptp command allows specification of a user-defined final velocity. The
value of the final velocity is specified as an additional argument after all other required
arguments.
Caution
Your application must create the next motion before the motion with non-
zero final velocity finishes. If the motion with non-zero final velocity reaches
the final point and no further motion is created, the motion stops
immediately, which may damage the mechanical parts of the system.
If the motions are multi-axis, a smooth vector velocity profile does not always
assure smooth motion of the coordinates. The user application must provide
nearly tangent motion trajectories at the transition point, to avoid jumps in
coordinate velocity.
Motion with non-zero final velocity is often required in registration mark motion. Assume that the
required motion profile is as follows:

2000
2

3
5

4
6
600

FIGURE 6-3 Graphical representation of motion with non-zero final velocity

1. Move towards a sensor at velocity 2000.
2. Decelerate.
3. Reach velocity 600 exactly at position 30000.
4. Jog towards sensor at velocity 600.
5. Point of sensor activation.
6. Continue motion at velocity 600.
7. Stop exactly at position 2500 beyond the sensor.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 9

The following program fragment performs the task:

X_IST.#MARK = 0 Enable MARK1 latching

ptp/vf X,30000,2000,600 Move to position 30000, velocity 2000, final

velocity 600
jog/v X,600 Jog in positive direction, velocity 600

till X_IST.#MARK Wait for MARK1 signal

ptp/v X,X_MARK+1500,600 Move to point X_MARK+15000, velocity 600

6.2. Jogging Motion

Jog motion is a motion with constant velocity and no defined end point. The motion continues
until the next motion command stops it, or the motion fails because of limit switch activation or
other condition.

6.2.1. jog Command

Command jog
Associated commands go, halt, kill, break, imm
Suffixes w – Create the motion, but do not start until the go
command has been executed.
v – Use the velocity specified in the command
instead of the default velocity
The simplest form of the jog command is:
jog X

This command creates a jog motion of the X axis in positive direction using the default velocity
X_VEL.
Motion direction may be specified in the command:
jog X, –

This command creates a jog motion of the X axis in negative direction using the default velocity
X_VEL.
The command:
jog X, +

is equivalent to:
jog X

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 10 M o t io n

The v suffix allows a specific velocity to be used instead of the default velocity VEL. The
command
jog/v X, 30000

Ignores the default velocity and creates a jog motion with a velocity of 30000.
As with other types of motion, jog motion may be terminated by the halt, kill, or break
commands. Unlike any other motion, jog motion also terminates when the next motion command
for the same axis executes. For example, the following program fragment:
jog X, +

wait 500

jog X, –

provides jogging in positive direction for 500msec and then switches to negative direction. The
controller automatically ensures a smooth transition from motion to motion.

6.2.2. Multi-Axis Jogging

Jogging can also occur in an axis group. For example, the following program fragment
jog XYZ, –++

creates jogging in three axes: X in the negative direction, and Y and T in the positive direction.
The motion uses the default velocity X_VEL as a vector velocity for the three-axis motion.

6.3. Track motion

Track motion enhances throughput by generating a move automatically if the target position is
changed.
MODEL
DEPENDENT SPiiPlus PCI-4/8: The dual port RAM (page 10-1) of these
controllers can be used to speed up throughput for PTP and track
motions.

Additional commands (copy from DPRAM to standard variable, stop copy from DPRAM to
standard variable) are added to enhance the effectiveness of the tracking mode.
The track command initiates a track motion. In a track motion, a new move is generated to a new
target position whenever the TPOS (target position) variable changes. (See also TPOS, page 11-
69.)
The track command accepts the following suffix:
w – Create the motion, but wait to start until the go command

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 11

6.3.1. Single-Axis Track motion

The following command creates tracking motion of the X axis:
track X Create track motion of X axis
If the axis is idle, the track motion is activated immediately. If the axis is moving, the controller
creates the motion and inserts it into the axis motion queue. The motion waits in the queue until
all previous motions in the queue are executed, and then starts.
When the track motion starts, the controller copies the current value of the reference position
(RPOS) element to target position (TPOS) element. For example, when the command
track X Create track motion of X axis
is issued, X_RPOS is copied to X_TPOS. No change of RPOS and no physical motion occur at
this time.
Afterwards, the axis waits until the TPOS element is assigned a different new value. As soon as
the user executes
X_TPOS = NewTarget Assign a value to the TPOS element
the controller generates a PTP motion to the point designated by the value of the NewTarget
user variable. After the X axis reaches NewTarget, the axis waits for the next change of TPOS.
The next assignment to X_TPOS automatically activates the next PTP motion and so on.
Therefore, track motion is executed as a sequence of PTP motions.
The motion state bits AST.#MOVE, AST.#ACC, MST.#MOVE, MST.#ACC reflect the state of
each PTP motion in the track sequence exactly as they do for ptp motion. Between PTP motions,
while the axis waits for the next TPOS assignment, the motion bits are zero (with the exception of
the MST.#MOVE bit, which can be one if the position error exceeds the TARGRAD limit). The
following ACSPL+ program fragment defines sequential positioning to points 1000, 2000, 10000,
11000:
track Z Create track motion of Z axis
Z_TPOS = 1000 Move to point 1000
till ^Z_AST.#MOVE Wait till the motion ends
Z_TPOS = 2000 Move to point 2000
till ^Z_AST.#MOVE Wait till the motion ends
Z_TPOS = 10000 Move to point 10000
till ^Z_AST.#MOVE Wait till the motion ends
Z_TPOS = 11000 Move to point 11000
till ^Z_AST.#MOVE Wait till the motion ends
halt Z Terminate track motion

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 12 M o t io n

The result is similar to the following fragment:

ptp Z,1000 Move to point 1000

ptp Z,2000 Move to point 2000

ptp Z,10000 Move to point 10000

ptp Z,11000 Move to point 11000

While the code with ptp commands looks shorter and simpler, there are applications where track
motion is preferable to PTP motion. See for example, Starting PTP motion from the host (page
10-11).
Track motion is not terminated automatically. If the TPOS is not changed, the axis at the last
target point until TPOS is assigned a new value, and then the motion continues.
Use a halt or kill command to terminate track motion.
Any subsequent motion command (except another track command) for the same axis also
terminates the tracking motion. In this respect track motion is similar to the jog motion.
The motion profile while in track mode, like in a standard PTP motion, is defined by the standard
variables VEL, ACC, DEC and JERK. The track command accepts the values of these variables
at the beginning of each component PTP motion within the track motion. Therefore, if an
application assigns a new value to VEL, ACC, DEC or JERK, while track mode is in effect, then
the new value will be used the next time that the application initiates a motion (by assigning a
new value to TPOS).
The following ACSPL+ program fragment sets a specific velocity for each PTP motion:
track Y Create track motion of Y axis

Y_VEL = 20000 Set motion velocity 20000 units/sec

Y_TPOS = 1000 Move to point 1000

till ^Y_AST.#MOVE Wait till the motion ends

Y_VEL = 5000 Set motion velocity 5000 units/sec

Y_TPOS = 2000 Move to point 2000

till ^Y_AST.#MOVE Wait till the motion ends

Y_VEL = 10000 Set motion velocity 10000 units/sec

Y_TPOS = 110000 Move to point 11000

till ^Y_AST.#MOVE Wait till the motion ends

halt Y Terminate tracking motion

In the example above the application updates TPOS only after the previous PTP motion ends.
In the following example the application updates the TPOS while the motion is still in progress:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 13

track X Create tracking motion of X axis

X_TPOS = 2000 Move to point 2000

till X_GPHASE >= 6 Wait till the motion comes to phase 6

(deceleration to final point)

X_TPOS = 2500 Correct the final point

till ^X_AST.#MOVE Wait till the motion ends

halt X Terminate tracking motion

In this case, the controller does not execute two separate motions. As soon as the TPOS is
changed to 2500 (before the controller reaches 2000), the controller changes the move on the fly
to the new target position of 2500. The change on the fly is done smoothly, similar to end-point
correction on the fly (see also changes on the fly, page 3-27).
The same result is provided by the following fragment:
ptp X, 2000 Move to point 2000

till X_GPHASE >= 6 Wait till the motion comes to phase 6

(deceleration to final point)

break X Terminate the current motion and provide

smooth transition to the next motion

ptp X,2500 Move to point 2500

6.4. Multipoint Motion

Multipoint motion provides sequential positioning to a set of points, optionally with dwell in each
point.

6.4.1. mptp, point, mpoint, and ends Commands

Command mptp - Create multipoint motion
point - Add the next point to the point sequence
mpoint - Add an array of points to the point
sequence
ends - Terminate the point sequence
Associated commands go, halt, kill, break, imm

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 14 M o t io n

Suffixes w – Create the motion, but do not start until the go

command has been executed.
v – Use the velocity specified in the command
instead of the default velocity
c – Use the point sequence as a cyclic array: after
positioning to the last point do positioning to the first
point and continue

Use the mptp command to specify axis and dwell time:

mptp X, 1000

This command creates a multipoint motion of the X axis and specifies dwell of 1000 msec at each
point. If dwell is not required, the second argument and the comma may be omitted. The mptp
command itself does not specify any point, so the created motion starts only after the first point is
specified. The points of motion are specified by the point or mpoint commands that follow the
mptp command.
Consider the following program fragment:
mptp XY Create multipoint motion in group XY with no dwell

point XY, 0, 100 Add first point

point XY, 100, 200 Add second point

point XY, 200, 100 Add third point

point XY, 100, 0 Add fourth point

ends XY End the point sequence

The mptp command in line 2 creates the multipoint motion. However, the motion does not start
until a point is defined. After the first point command (line 3) the motion starts if all involved
axes are idle (not involved in some previous motion), or waits until a motion that is in progress
ends, and then starts. The four point commands (lines 3, 4, 5 and 6) specify the following
sequence:

Y
(100,200)

Start
(200,100)
(0,100)

(100,0) X

FIGURE 6-4 Example of multipoint motion

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 15

The controller performs sequential positioning to each point. The ends command informs the
controller, that no more points will be specified for the current motion. The motion cannot finish
until the ends command executes. If the ends command is omitted, the motion will stop at the last
point of the sequence and wait for the next point. No transition to the next motion in the queue
will occur until the ends command executes.
Normally, multipoint motion starts with the first point command, and the next point command
executes while the motion is already in progress. However, sometimes you may need to delay
starting the motion until all points are defined. Append the w suffix, to the command, to prevent
the motion from starting until a go command executes. The motion, created by the command:
mptp/w X, 1000

will not start until the go X command executes.

Append the r suffix to the mptp command to cause all points to be treated as relative. The first
point is relative to the position when the motion starts, the second point is relative to the first, and
so on. The previous example, using the mptp/r command, will look like this:
ptp XY, 0, 100 Create PTP motion to the first point

mptp/r XY Create multipoint motion in group XY with no

dwell
point XY, 100, 100 Add point

point XY, 100, -100 Add point

point XY, -100, -100 Add point

ends XY End the point sequence

The mptp command uses the default velocity VEL for positioning to each point. The v suffix
allows using specific velocity for each positioning. The desired velocity must be specified in the
point command after the point coordinates. The previous example is modified for using different
velocities:
mptp/v XY Create multipoint motion in group XY

point XY, 0, 100, 30000 Move to first point at velocity 30000

point XY, 100, 200, 10000 Move to second point at velocity 10000

point XY, 200, 100, 5000 Move to third point at velocity 5000

point XY, 100, 0, 10000 Move to fourth point at velocity 10000

ends XY End the point sequence

Several suffixes can be appended to one command. For example, the command
mptp/rv X, 1000

creates a multipoint motion with dwell of 1000msec. The points will be specified by relative
coordinates, and velocity will be specified for each point.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 16 M o t io n

The point command does not require a specific value for all axes involved in a multipoint motion.
If an axis is not specified in a point command, the axis remains idle and retains the previous
value. Similarly, if a multipoint motion is created with the v suffix, the velocity argument in a
point command can be omitted, and the velocity of the previous segment will be used. If velocity
is omitted for the first point, the default velocity VEL will be used.
Consider the following example:
mptp/v XY Create multipoint motion in group XY with no dwell

point XY, 100, 0, 30000 Move to first point at velocity 30000

point Y, 100 Move to second point at velocity 30000

point X, 200 Move to third point at velocity 30000

point Y, 0, 10000 Move to fourth point at velocity 10000

ends XY End the point sequence

The four point commands specify the following sequence:

(100,100) (200,100)

(200,0) X
(100,0)

FIGURE 6-5 Example of the use of the Point command

6.4.2. Advanced Topics

6.4.2.1. Target Point as Expression

Target point in a point command can be specified by expression. Consider the following program
fragment:
int J Declare integer variable J

mptp XY, 100 Add an array of points in

the XY plane
J = 0 Set J to zero

loop 30 Perform the loop 30 times

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 17

point XY, 30*cos(2*3.14159/30*J), 20*sin(2*3.14159/30*J) Add motion points to the

XY planes according to
the following expression
J = J + 1 Increment J

end

ends XY

The program executes the point command 30 times. Each time the command adds a new point in
the XY plane. The points are spread equally along the ellipse, as shown in the following figure:

FIGURE 6-6 Example of target point as expression

The motion trajectory between the points is straight.

6.4.2.2. Axis as expression

Axis in the mptp, point, ends command can be specified by expression, similar to the ptp
command. The expression should calculate to a whole number from 0 to 7, corresponding to the
eight axes. Value 0 corresponds to the X axis, 1 to Y, and so on. This allows writing a program
that may be executed for any axis or axis group.

6.4.2.3. Cyclic motion

Use the c suffix to produce cyclic execution of multipoint motion. The mptp/c command creates a
motion that after positioning to the last point of sequence, returns to the first point and continues
through the same sequence. Cyclic multipoint motion does not finish automatically, and one of
the commands halt, kill, or break must be used in order to stop cyclic motion.
The following program fragment starts a reciprocal motion between the points 1000 and –1000 of
the X axis:
mptp/c X, 100 Create multipoint motion for axis X, dwell is 100msec

point X, 1000 Move to first point

point X, -1000 Move to second point

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 18 M o t io n

ends X End the point sequence

6.4.2.4. point and mpoint Commands

The point command adds one point to either multi-point or arbitrary path motion. The mpoint
command adds an array of points to either multi-point or arbitrary path motion.
The mptp command itself does not specify any point, so the created motion starts only after the
first point is specified. The points of motion are specified by the point or mpoint commands that
follow the mptp command.
Before the mpoint command can be executed an array must be declared and filled with the point
coordinates. Each raw of the array contains coordinates of one point. If the mptp command was
specified with the v suffix, each raw contains also the required velocity for positioning to the
point. Therefore, the number of columns in the array must be equal to the number of axes
specified in the mptp command, or to the number of axes plus one if the v suffix is specified.
The following advanced example illustrates how the mpoint command can be used for adding
points on the fly. The example also shows a simple approach to synchronization between the host
computer that calculates the points and the controller that executes the motion.
The host computer calculates the desired points and transmits the coordinates via the Ethernet
link. The motion involves 6 axes. Therefore, each point specification contains 6 real numbers.
Because transmitting each point separately would be very ineffective in the Ethernet, the host
calculates the desired points in advance and transmits them in batches of 50 points. The controller
executes the motion. As soon as the controller is ready to accept the next batch of points and the
host is ready to send the batch, the next transmission occurs, and so on. The pace of the host and
the controller may be very different. However, the host is assumed fast enough to calculate the
next 50 points before the controller has moved through the previous 50 points.
The controller executes the following program:
1 real Points(50)(6) Declare an array of 50 points. The
host will write the coordinates to
the array.
2 int Sync Declare synchronization variable.

3 mptp XYZTAB Create mptp motion for axes

XYZTAB.
4 while Sync >= 0 Continue until the host writes
negative number to Sync.
5 till Sync Wait until the points are received
Once the host has filled the Points
array, it writes the Sync variable
with a number of points written to
the Points array.
6 if Sync > 0 Sync <0 indicates that the host
has finished the point generation.
7 mpoint XYZTAB, Points, Sync Add points from the Points
matrix.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 19

8 Sync = 0 The controller informs the host

that the next batch is expected. At
this moment the motion through
the accepted points has not
finished, but the controller is
ready to receive more points.
9 end

10 end

11 ends XYZTAB No more points will be added.

12 stop

The program running in the host looks like this:

double HPoints(50)(6);
int N, HSync;
HANDLE Com;

open communication, start program in buffer NBuf of the controller;

while (Continue)
calculate N (<= 50) points in array HPoints;

zl_WriteReal(Com, NBuf, “Points”, 0, N-1, 0, 6, HPoints, 1000) ;

acsc_WriteInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &N, 0);

do
acsc_ReadInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &HSync, 0);
while HSync;

reset Continue to zero if all points have been calculated;

end;

N = -1
acsc_WriteReal(Com, NBuf, “Points”, 0, N-1, 0, 6, HPoints, 0) ;

Synchronization between the host and the controller is provided by Sync variable. When the host
has finished transmitting the next batch of points to the controller, it writes to Sync the number of

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 20 M o t io n

points in the batch. The controller waits for non-zero Sync and then adds the points to the motion.
When the controller has added the points, it writes zero to Sync, that signals to the host to
transmit the next batch of points.
When the host comes to the end, it writes –1 to Sync, to indicate the end of the motion.

6.5. Arbitrary Path Motion

6.5.1. path Command

The path command creates an arbitrary path motion.
The path command accepts the following suffixes:
Command path – Create an arbitrary path motion
Associated commands point, mpoint, ends
Suffixes r –The point coordinates are relative to the previous
point
w–Create the motion, but do not start until the go
command
t–Non-uniform time interval: time interval is
specified for each point along with the point
coordinates
c–Use the point sequence as a cyclic array: after
positioning to the last point do positioning to the first
point and continue.

Points for arbitrary path motion are defined by point and mpoint commands (See point and
mpoint Commands, page 6-21).
The ends command terminates the point sequence. After the ends command, no point or mpoint
commands for this motion are allowed.
The trajectory of the motion follows through the defined points. Each point presents the instant
desired position at a specific moment. Time intervals between the points are uniform, or non-
uniform as defined by the t suffix.
Motion generated by the path command does not use motion profile generation. Typically, the
time intervals between the points are short, so that the array of the points implicitly specifies the
desired velocity in each point. For this reason, variables VEL, ACC, DEC, JERK have no effect
on this motion.
If the time interval does not coincide with the controller cycle, the controller provides linear
interpolation of the points.
Commands halt, kill, killall are executed in a specific way with this type of motion; as with other
motion types, the controller provides a smooth deceleration profile using DEC (halt command) or

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 21

KDEC (kill, killall commands) for the leading axis. However, unlike other motions types, the
controller does not provide following the motion trajectory during deceleration.
Arbitrary path motion created without the t suffix implies uniform intervals between the points.
Command path, specified without the t suffix, must have time-interval specification as its last
argument. The argument defines time interval between the motion points in milliseconds.
Command path, specified with the t suffix, must not have time-interval specification. Instead, the
time interval must be specified for each point as additional argument for the point command or as
additional array column in the mpoint command.
NOTE

The break command is not supported in path motion.

6.5.2. point and mpoint Commands

The point command adds one point to either multi-point or arbitrary path motion. The mpoint
command adds an array of points to either multi-point or arbitrary path motion.
The path command itself does not specify any point, so the created motion starts only after the
first point is specified. The points of motion are specified by the point or mpoint commands that
follow the mptp command.
The mpoint command syntax is:
mpoint-command :
mpoint axes-specification, point-matrix, number-of-points
The axes-specification must specify the same axes in the same order as in the axes-specification
of the corresponding mptp or path command.
The number-of-points specifies how many points are added to the motion by the command.
The point-matrix is a two-dimensional array. Each column of the matrix contains specification of
one point. The matrix must contain at least number-of-points columns. If the matrix contains more
columns, the extra columns are ignored.
If the corresponding motion command is mptp without the v suffix or path without the t suffix, a
column of the matrix must contain the coordinates of the point. Therefore, if the axes-
specification includes M axes, the matrix must contain exactly M rows.
If the corresponding motion command is mptp/v, the matrix must contain M+1 rows. An
additional value in each column specifies the desired velocity for transition from the previous to
the current point. The velocity is specified in position units per second.
If the corresponding motion command is path/t, the matrix must contain M+1 rows. An
additional value in each column specifies the time interval between the previous and the current
point. The time is specified in milliseconds.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 22 M o t io n

6.5.2.1. Arbitrary Path Motion Example

The following example illustrates how the mpoint command can be used for adding points on the
fly. The example also shows a simple approach to synchronization between the host computer that
calculates the points and the controller that executes the motion.
The host computer calculates the desired points and transmits the coordinates via Ethernet link.
The motion involves 6 axes. Therefore, each point specification contains 6 real numbers.
Because transmitting each point separately would be very ineffective in the Ethernet, the host
calculates the desired points in advance and transmits them in batches of 50 points. The controller
then executes the motion. As soon as the controller is ready to accept the next batch of points and
the host is ready to send the batch, the next transmission occurs, and so on.
The pace of the host and the controller do not have to be identical. However, the host is assumed
to be fast enough to calculate the next 50 points before the controller has moved through the
previous 50 points.
The controller executes the following program:
1 real Points(6)(50) Declare an array of 50 points. The host will
write the coordinates to the array.
2 int Sync Declare synchronization variable.

3 path XYZTAB, 1 Create arbitrary path motion for axes

XYZTAB. Points are given at millisecond
intervals.
4 while Sync >= 0 Continue until the host writes negative
number to Sync.
5 till Sync Wait until the points are received. Once the
host has filled the Points array, it writes the
Sync variable with a number of points
written to the Points array.
6 if Sync > 0 Sync <0 indicates that the host has finished
the point generation.
7 mpoint XYZTAB, Points, Sync Add points from the Points matrix.

8 Sync = 0 The controller informs the host that the next

batch is expected. At this moment the
motion through the accepted points has not
finished, but the controller is ready to
receive more points.
9 end

10 end

11 ends XYZTAB No more points will be added.

12 stop

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 23

The program running in the host looks like the following pseudo code:
double HPoints(6)(50);
int N, HSync;
HANDLE Com;

open communication, start program in buffer NBuf of the controller;

while (Continue)
calculate N (<= 50) points in array Hpoints;

zl_WriteReal(Com, NBuf, “Points” , 0, 5, 0, N-1, HPoints, 1000) ;

zl_WriteInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &N, 1000);

do
zl_ReadInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &HSync, 1000);
while HSync;

reset Continue to zero if all points have been calculated;

end;

N = -1
zl_WriteInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &N, 1000);

Synchronization between the host and the controller is provided by Sync variable. When the host
has finished transmitting the next batch of points to the controller, it writes to Sync the number of
points in the batch. The controller waits for non-zero Sync and then adds the points to the motion.
When the controller has added the points, it writes zero to Sync, which signals to the host to
transmit the next batch of points.
When the host comes to the end, it writes –1 to Sync, to indicate the end of the motion.

6.6. PV and PVT Spline Motion

PV (position-velocity) and PVT (position-velocity-time) refer to a motion mode that constructs
the motion trajectory from spline segments. The user specifies the end position (P) and the end
velocity (V) for each segment of motion. The difference between PV and PVT is that PVT motion
also requires specification of the time interval for each segment, whereas PV motion uses a
predefined constant time interval.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 24 M o t io n

In PV/PVT mode the controller provides cubic spline interpolation between the specified points.
As a spline mode, it minimizes the amount of data that the host-based program (or ACSPL+
program) needs to generate to produce the multi-axis arbitrary profile and provides precise
trajectory generation.
The generated profile between the specified points is characterized by a constant jerk, a linear
acceleration profile, a parabolic velocity profile, and cubic position profile.
Between each two specified points the controller constructs a curve known as a Hermit
polynomial. The following formulae explain the process:
Assume P0, V0 are the position/velocity at the beginning of a segment, PT, VT are the
position/velocity in the end of the segment and T is the time of the segment. Values P0, V0, PT, VT
and T are supplied (usually by a host-based program) as segment data. The controller constructs
the segment motion as a cubic polynomial:
p = a0 + a1t + a2t2 + a3t3
where t is a relative time within the segment, t = 0 at the beginning of the segment and t = T at
the end of the segment. The controller calculates coefficients a0, a1, a2, a3 to satisfy the boundary
condition.
In case of multi-axis motion a host-based program (typically) supplies position and velocity data
for each axis involved. The P0, V0, PT, VT are vectors, and the controller calculates coefficients
a0, a1, a2, a3 as vectors that contain a component for each axis involved.

6.6.1. pvspline Command

The pvspline command creates a spline motion.
The pvspline command accepts the following suffixes:
Command pvspline – Create a PV or PVT motion
Associated commands point, mpoint, ends
Suffixes r –The point coordinates are relative to the previous
point
w–Create the motion, but wait to start for a go
command
t–Nonuniform time interval: time interval is
specified for each point along with the point
coordinates
c–Use the point sequence as a cyclic array: after
positioning to the last point do positioning to the first
point and continue.

Points for PV and PVT motion are defined by point and mpoint commands.
The ends command terminates the point sequence. After the ends command, no point or mpoint
commands for this motion are allowed.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 25

The trajectory of the motion follows through the defined points. Time intervals between the points
are uniform, or non-uniform as defined by the t suffix.
Motion generated by the pvspline command does follow the standard motion profile. Variables
VEL, ACC, DEC, JERK have no effect on this motion. The motion profile is defined
exclusively by the positions and velocities specified by point and mpoint commands.
The halt command is executed in a specific way with this type of motion; as with other motion
types, the controller provides a smooth deceleration profile with the DEC value of the leading
axis. However, unlike other motions types, the controller does not follow the motion trajectory
during deceleration.
Spline motion created without the t suffix implies uniform intervals between the points.
Command pvspline, specified without the t suffix, must have time-interval specification as its last
argument. The argument defines time interval between the motion points in milliseconds.
Command pvspline, specified with the t suffix, must not have time-interval specification. Instead,
the time interval must be specified for each point as additional argument for the point command
or as additional array row in the mpoint command.

6.6.2. Interpolation Between the Points

The point command for the spline interpolation specifies two values per axis involved: the first
value defines the coordinate of the end point of the segment; the second value specifies the
velocity at the end point. The coordinate is specified in the user units of the axis; the velocity is
specified in user units per second.
The following fragment illustrates adding a point with PV spline motion.
1 pvspline XYT,10 Create PV spline motion for axes XYT.
Points are given at 10 millisecond
intervals.
2 point Add a point with coordinates X=200,
XYT,200,100,300,1000,2000,1500 Y=100, T=300; velocities at the point are
VX=1000, VY=2000, VT=1500.

For each segment the controller constructs a third-order polynomial known as a Hermit spline or
PV-spline and calculates the reference coordinates using the polynomial.
The spline provides exact following through the specified points and exact specified velocity at
the points. The spline also provides continuous velocity at all intermediate points.
In general the spline does not guarantee acceleration continuity at the connection points.
However, the acceleration can be continuous if the proper velocity values are specified, and many
host-based programs that prepare data for PV-interpolation actually calculate velocity values that
will provide continuous acceleration.
The time interval between the points may be either uniform or non-uniform. In both cases the time
interval is not required to be an integer or to be equal to an integer number of controller cycles.
The controller uses the exact specified time interval to calculate the interpolated reference
positions.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 26 M o t io n

The following drawing illustrates the PV spline interpolation:

T 2T 3T 4T 5T 6T 7T 8T
T – the controller cycle,
– the specified motion points,
Æ – the specified velocity values,
– the interpolated reference points

6.6.3. point Command

The point command adds one point to PV or PVT spline motion. (The point command is also
used in Arbitrary Path motion, section 0.)
The pvspline command itself does not specify any point, so the created motion starts only after
the first point is specified. The points of motion are specified by the point or mpoint commands
that follow the pvspline command.
The point command syntax is:
point-command :
point axes-specification, list-of-values
The axes-specification must specify the same axes in the same order as in the axes-specification
of the corresponding pvspline command.
The list-of-values contains different values depending on corresponding pvspline command.
If the related motion command is a pvspline without the t suffix for M axes, the list-of-values
must contain 2*M values: 2 values per axis involved. The values in the list specify the end point
coordinates and the coordinate velocities at the end point in the following order:
• the end point coordinate for each axis involved (M values)
• the velocity at the end point for each axis involved (M values)
Each coordinate is specified in user units of the corresponding axis, each velocity is specified in
user units per second.
If the related motion command is a pvspline/t for M axes, the list-of-values must contain 2*M+1
values: 2*M values specify the end point coordinates and velocities, and the last value specifies
the time interval between the previous and the current point. The time is specified in milliseconds.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 27

6.6.4. mpoint Command

The mpoint command adds an array of points to PV or PVT spline motion. (The mpoint
command is also used in Arbitrary Path motion, section 0.)
The pvspline command itself does not specify any point, so the created motion starts only after
the first point is specified. The points of motion are specified by the point or mpoint commands
that follow the pvspline command.
The mpoint command syntax is:
mpoint-command :
mpoint axes-specification, point-matrix, number-of-points
The axes-specification must specify the same axes in the same order as in the axes-specification
of the corresponding pvspline command.
The number-of-points specifies how many points are added to the motion by the command.
The point-matrix is a two-dimensional array. Each column of the matrix contains specification of
one point. The matrix must contain at least number-of-points columns. If the matrix contains more
columns, the extra columns are ignored.
If the related motion command is a pvspline without the t suffix for M axes, the matrix must
contain 2*M rows, 2 rows per axis involved. The values in each column specify:
• in row 1: the end point coordinate for each axis involved (M values)
• in row 2: the velocity at the end point for each axis involved (M values)
Each coordinate is specified in user units of the corresponding axis, each velocity is specified in
user units per second.
If the related motion command is a pvspline/t for M axes, the matrix must contain 2*M+1 rows:
M rows for end point coordinates, M rows for end point velocities, plus additional row for the
time interval between the points. The time is specified in milliseconds.

6.6.5. Use of Standard Variables

As mentioned, the spline motion does not use the values of variables VEL, ACC, DEC, JERK
for motion profile construction. The motion profile is constructed using the coordinates and
velocities specified in the segment end points.
While the motion is in progress the controller updates the following read-only variables every
controller cycle.
• APOS and RPOS are updated as for any other motion and read the motion result.
• Bits in AST, MST are updated as for any other motion and read the motion state.
• GSEG is updated for the leading axis with the number of the currently executed segment.
• GSFREE is updated for the leading axis with the number of free cells in the segment queue.
If GSFREE is zero, the segment queue is full and the next coming point or mpoint
command will be delayed until the required number of cells will be freed.
• GVEC is updated with the instant velocity for each axis involved. The GVEC values build
up a vector of instant velocity and also can be used for retrieving a tangent vector.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 28 M o t io n

• GPATH, GVEL, GACC, GJERK, GPHASE, GRTIME are not updated while the motion
is in progress.

6.6.6. Spline Motion Example

The following example illustrates how the pvspline command can be used for adding points on
the fly. The example also shows a simple approach to synchronization between the host-based
program that calculates the points and the controller that executes the motion.
The host-based program calculates the desired points and transmits the coordinates via Ethernet
link. The motion involves 6 axes. Therefore, each point specification contains 12 real numbers (6
coordinates and 6 velocities).
Because transmitting each point separately would be a very inefficient use of the Ethernet, the
host calculates the desired points in advance and transmits them in batches of 50 points. The
controller then executes the motion. As soon as the controller is ready to accept the next batch of
points and the host is ready to send that batch, the next transmission occurs, and so on.
The pace of the host and the controller do not have to be identical. However, the host is assumed
to be fast enough to calculate the next 50 points before the controller has moved through the
previous 50 points.
The controller executes the following program:
1 real Points(12)(50) Declare an array of 50 points. The host will
write the coordinates and velocities to the
array.
2 int Sync Declare a synchronization variable (initiated
to zero by default).
3 pvspline XYZTAB, 10 Create PV for axes XYZTAB. Points are
given at 10-millisecond intervals.
4 while Sync >= 0 Continue until the host writes negative
number to Sync.
5 till Sync Wait until the points are received. Once the
host has filled the Points array, it writes the
Sync variable with a number of points
written to the Points array.
6 if Sync > 0 Sync >0 indicates that the host has finished
the point generation.
7 mpoint XYZTAB, Points, Sync Add points to the Points matrix.

8 Sync = 0 The controller informs the host that the next

batch is expected. The motion through the
points already received from the host has
not completed, but the controller is ready to
receive more points.
9 end

10 end

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 29

11 ends XYZTAB No more points will be added.

12 stop

The program running in the host looks like the following pseudo code:
double HPoints(12)(50);
int N, HSync;
HANDLE Com;

open communication, start program in buffer NBuf of the controller;

while (Continue)
calculate N (<= 50) points in array Hpoints;

acsc_WriteReal(Com, NBuf, “Points” , 0, 11, 0, N-1, HPoints, 0) ;

acsc_WriteInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &N, 0);

do
acsc_ReadInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &HSync, 0);
while HSync;

reset Continue to zero if all points have been calculated;

end;

N = -1
acsc_WriteInteger(Com, NBuf, “Sync”, -1, -1, -1, -1, &N, 0);
Synchronization between the host and the controller is provided by Sync user variable. When the
host has finished transmitting the next batch of points to the controller, it writes to Sync the
number of points in the batch. The controller waits for non-zero Sync and then adds the points to
the motion. When the controller has added the points, it writes zero to Sync, which signals to the
host to transmit the next batch of points.
When the host comes to the end, it writes –1 to Sync, to indicate the end of the motion.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 30 M o t io n

6.7. Master-Slave Motion

6.7.1. Basics
Command master – Define master value for the axis
slave – Create multipoint motion
Associated commands go, halt, kill
Suffixes w – Create the motion, but do not start until the go command has
been executed.
t – Stall when approaching interval boundary
p – Use position lock instead of velocity lock (see Advanced
section)

In slaved motion the axis follows a master value. In addition to basic slaved motion there are
more sophisticated forms; the slaved mode of segmented motion and the slaved mode of spline
motion.
NOTE
The break command (Section 5.9.9.9) is not designed to be used with
master-slave and will lead to inaccurate results.

6.7.2. master Command

The master command defines a formula for calculating the axis master value (MPOS). See also
Motion Overview (section 3.4.1).
The command syntax is:
master-command :
master assignment-command
In the assignment-command, only one component of MPOS (master position) variable is allowed
on the left side.
In the simplest case the master value follows the feedback of another axis:
master X_MPOS = Y_FPOS

When the command executes, the controller stores the formula specified to the right of the equals
sign, and then calculates the master value X_MPOS according to this formula (in the example
above, it simply assigns the current Y_FPOS value to X_MPOS). The controller does this
calculation every controller period, independent of program execution. Even if the program that
executed the master command terminates, the controller continues calculating the last specified
master expression, until the another master command for the same axis executes.
The master value can be redefined at any time by the application. If the program that executed the
above command then executes the command.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 31

A more sophisticated use of the master command connects the axis to another axis feedback with
a scale factor:
master X_MPOS = 2.3 * Y_FPOS

The following example defines axis Z to follow the RPOS (reference position) of axis X
translated through a conversion table (cam motion):
master Z_MPOS = mapby1(X_RPOS, Table)

In this example Table is a user-defined array that contains a table for conversion.
Similarly, the master value may be connected to other sources such as the sum of two or more
axes, or to an analog input.

6.7.3. slave Command

The slave command creates a motion slaved to the master value of the specified axis. Only
individual axes are allowed to be used in a slave command. Groups are not allowed. The created
motion starts immediately if the axis is idle; otherwise the motion waits in the motion queue until
all motions created before for the axis finish. The following command creates a slaved motion of
the X axis:
slave X

The motion is always slaved to the master value of the specified axis. Therefore, the master
command must precede the slave command for the same axis.
In slaved motion the APOS axis reference follows the MPOS axis master value strictly or with a
constant offset. The only exception to this rule is for transient processes such as acceleration,
when the motion is asynchronous.
APOS = MPOS + C

Where C is constant in velocity lock mode and is zero in position lock mode (see Advanced
section).
Once started, slaved motion terminates only if a failure occurs, or one of the commands halt, kill,
break is executed. The halt and kill commands provide deceleration to zero and then the next
motion starts. If no next motion was created, the axis becomes idle. The break command provides
smooth transition to the next motion without stopping, if a next motion is waiting in the queue.

6.7.4. Advanced Topics

6.7.4.1. Synchronization
In slaved motion the slave is usually synchronized to the master, meaning that the APOS axis
reference follows the MPOS master value strictly or with a constant offset. However, there are
two cases, when synchronism is not attainable:
ƒ The slaved motion starts, and positions (position lock) or velocities (velocity lock) of the
master and slave differ. The motion starts as asynchronous.
ƒ The motion was synchronized, but the acceleration of the master exceeds the allowed limit
(the XSACC variable of the axis) for the slave. The slave comes out from synchronism.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 32 M o t io n

In both cases, the motion continues asynchronously, and the correspondence between APOS and
MPOS appears broken. The controller tries to regain synchronism by having the slave pursue the
master within the maximal allowed motion parameters. When the slave overtakes the master,
synchronism is re-established and the motion continues as synchronous.
Slave motion is governed by the variables of the slaved axis. These include:
XSACC Maximal allowed acceleration of the synchronous motion. If the
master acceleration exceeds this value, the slave comes out from
synchronism.
SYNV Allowed difference in master and slave velocities. Used in
asynchronous motion to determine if the synchronism can be re-
established.
JERK, ACC, VEL Default jerk, acceleration and velocity. The slave uses these
variables only in asynchronous motion to overtake the master.

6.7.4.2. Velocity Lock vs. Position Lock

In velocity lock the slave velocity follows the master velocity. A constant offset between the
master and slave position is allowed. In position lock the slave position strictly follows the master
position.
The slave command without the p suffix activates a velocity-lock mode of slaved motion. When
synchronized, the APOS axis reference follows the MPOS with a constant offset:
APOS = MPOS + C

The p suffix, attached to the mseg command, activates the position lock mode of slaved motion.
When synchronized, the APOS axis reference follows the MPOS strictly:
APOS = MPOS

When the motion is asynchronous for any reason (see above), the controller tries to regain
synchronism by having the slave pursue the master with the maximal allowed motion parameters.
The difference between position lock and velocity lock manifests itself at the moment of
regaining synchronism:
Velocity lock motion switches in synchronism when the slave velocity reaches the master velocity
(with allowed error defined by the SYNV variable of the slaved axis). At this moment the
difference between the master position and the slave position is latched as the constant offset C,
which then remains unchanged as long as the motion is synchronous.
Position lock motion switches in synchronism when the slave position overtakes the master
position, i.e. when APOS = MPOS.
Note that each time the motion loses and regains synchronism, the velocity lock offset C may
latch a different value. Under the same conditions, the position lock motion each time re-
establishes the strict equality APOS = MPOS.

6.7.4.3. Stalled Motion

When there is no t suffix, the slave command applies no limits to the slaved axis. The axis
follows the master everywhere, unless a failure, such as limit switch activation, occurs.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 33

The slave command with the t suffix requires two additional parameters that define a permitted
interval for the slaved axis motion. For example, the command:
slave/t X, -1000, 2000

allows X axis motion only within the interval (-1000, 2000).

When the APOS axis reference approaches either of the two interval limit points, the slave comes
out from synchronism and stalls at that point until the MPOS master value allows restoration of
synchronism. In velocity lock, synchronism is regained when the MPOS changes its direction.
After regaining the offset, C may have a different value than before approaching the extreme
point. For position lock, synchronism is restored when the MPOS comes back into the permitted
interval. The axis stalls when the master leaves the permitted range and regains synchronism
when the master returns into the permitted range. The controller ensures a smooth approach to the
extreme points and a smooth return to synchronism.

6.8. Segmented Motion

Segmented motion moves axes along a continuous path. The path is defined as a sequence of
linear and arc segments on the plane. Although segmented motion follows a flat path, it may
involve any number of axes, because the motion plane can be connected to the axes at any
projection transformation.

6.8.1. mseg, projection, line, arc1, arc2, stopper, ends Commands

The following commands control segmented motion:
Command mseg – Create segmented motion
projection – Set projection matrix
line – Add linear segment
arc1 – Add arc segment
arc2 – Add arc segment
stopper – Pause the motion at the intermediate point
ends – Terminate the point sequence
Associated commands go, halt, kill, break, imm

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 34 M o t io n

Suffixes w – Create the motion, but do not start until the go command
v – Use the velocity specified for each segment instead of the
default velocity
c – Use the segment sequence as a cyclic array: after the last
segment return to the first segment and so on.
s – Slaved motion: the motion advances in accordance to the master
value of the leading axis (velocity lock).
p – Position lock: slaved motion, strictly conforming to the master
value.
e – Extrapolated: if a master value travels beyond the specified
path, the last or the first segment is extrapolated.
t – Stalled: if a master value travels beyond the specified path, the
motion stalls at the last or first point.

The e and t suffixes are relevant only for slaved motion and must be used with s or p suffix. For
discussion of slaved motion see section 6.7.
Segmented motion can be executed in an axis group with any number of controller axes.
The mseg command specifies axis group and the initial starting point:
mseg XY, 1000, 1000

This command creates a segmented motion of the X axis group and specifies the coordinates of
initial point on the plane. The mseg command itself does not specify any segment, so the created
motion does not start immediately. A line or arc command must follow the mseg command to
specify the segment sequence.
Consider the following program fragment:
mseg XY,1000,1000 Create segmented motion in group X,
coordinates of the initial point are
(1000,1000)
arc1 XY, 1000,0,1000,–1000,– Add arc segment with center (1000,0),
final point (1000,-1000), clockwise
rotation
line XY,–1000,–1000 Add line segment with final point (-1000,-
1000)
arc2 XY,–1000,0,–3.141529 Add arc segment with center (-1000,0)
and rotation angle –π
line XY,1000,1000 Add line segment with final point
(1000,1000)
ends XY End the segment sequence

The mseg command creates the segmented motion. The motion does not start, because no
segment is defined yet. After the first arc1 command the motion starts if the axis group is idle

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 35

(not involved in some previous motion). If the group is not idle, motion will start when the
previous motion stops. The four segment commands specify the following path:

Y
Start
(-1000,1000)
X

(-1000,1000)
(1000,-1000)

FIGURE 6-7 Example of motion with segment commands

The arc1 and arc2 commands differ by the required arguments. The arc1 command specifies the
coordinates of the center point, coordinates of the final point and the direction of rotation (+ for
counter clockwise, – for clockwise rotation). The arc2 command specifies the coordinates of the
center point and rotation angle (positive for counter clockwise, negative for clockwise rotation).
The arc1 and arc2 command may produce the same result, so the user may select one that suits
the available data. If the user knows the coordinates of the center point, coordinates of the final
point and the direction of rotation, arc1 is preferable. If the user knows the coordinates of the
center point and rotation angle, arc2 is preferable. The ends command informs the controller, that
no more segments will be specified for the specified motion. The motion cannot finish until the
ends command executes. If the ends command is omitted, the motion will stop in the last point of
the sequence and wait for the next point. No transition to the next motion in the queue will occur
until the ends command is executed.
Segmented motion usually starts with the first segment command (line, arc1, or arc2). The next
segment command therefore executes while the motion is already in progress. This is generally
not a problem, because the program execution rate is higher than typical motions time. However,
sometimes you may need to delay starting the motion until all points are defined. Append the w
suffix, to the command, to prevent the motion from starting until the go command is executed.
The motion, created by the command
mseg/w XY,1000,1000

will not start until the go XY command is executed.

The r suffix is not allowed with segmented motion. All coordinates in the line, arc1 and arc2
commands are absolute in the plane. However, the whole path is relative to the point, where the
axes are located when the segmented motion starts. In other words, all coordinates are absolute in
the plane, but the plane is relative to the starting point. Note that the initial point, specified in the
mseg command, is also absolute in the plane. Therefore, the initial point does not cause any
motion to that point, but only supplies starting coordinates for the first segment. The motion
program should provide a motion to desired initial point before executing the mseg command.
The following fragment illustrates a typical activation of the segmented motion:
ptp XY, 0, 100 This command causes a physical motion to the point
(0,100) that will be an absolute starting point for the
following segmented motion

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 36 M o t io n

mseg XY, 100, 100 Defines the starting coordinates for the first segment,
which are absolute in the plane. The whole plane is
located in such a way that the starting point in the
plane (100,100) coincide with the present position of
the motors (0,100).
The mseg command uses the default velocity VEL for each segment. The v suffix overrides the
default velocity and allows you to define a specific velocity for each segment. Desired velocity
must be specified in the line, arc1 and arc2 segment commands after all other arguments. If the
velocity argument is omitted in a segment command, the velocity from the previous segment is
used. If the velocity argument is omitted in the first segment, the default VEL is used. The
previous example is modified for using individual velocities:

mseg/v XY,1000,1000 Create segmented motion in group X,

coordinates of the initial point are
(1000,1000)
arc1 XY, 1000,0,1000,–1000,–,30000 Add arc segment with center (1000,0),
final point (1000,-1000), clockwise
rotation, vector velocity 30000
line XY,–1000,–1000 Add line segment with final point (-
1000,-1000). Vector velocity is not
specified, previous value 30000 will be
used.
arc2 XY,–1000,0,–3.141529,10000 Add arc segment with center (-1000,0),
rotation angle–π, vector velocity 10000
line XY,1000,1000,5000 Add line segment with final point
(1000,1000), vector velocity 50000
ends XY End the segment sequence
Several suffixes can be attached to one command. For example, the command
mseg/vw XY, 1000, 1000

creates a segmented motion with individual velocity for each segment. The motion does not start
until the go XY command is executed.

6.8.2. Advanced Topics

6.8.2.1. Projection
As mentioned above, all coordinates, specified in the segment commands, are absolute in the
working plane. Projection is a matrix that connects the plane coordinates and the axis values as
specified in the mseg command. If the axis group contains two axes, and no projection command
is specified, the controller provides a default projection that corresponds to the matrix 2x2:
1 0
0 1

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 37

The matrix directly connects the first coordinate of the working plane to the first axis of the axis
group and the second coordinate to the second axis.
The matrix can also define rotation and scaling. The full transform includes also an implicit offset.
The controller calculates the offset automatically in such a way that the initial coordinates
specified in the mseg command match the desired axis values at the moment when the motion
starts. The offset provides the full path to be relative to the starting point.
If an axis group contains N axes, the controller extends the default matrix to N lines. The
additional lines are filled by zeros:
1 0
0 1
0 0
… …
0 0
The matrix connects only the first two axes to the plane coordinates. Therefore the segmented
motion will involve only the first two axes in the group.
If N = 1, the mseg command applies to a single axis, and the matrix contains the first line only:
1 0
In this case the axis will follow the first coordinate of the working plane.
The user can replace the default matrix with the projection command. The following program
fragment
real M(3)(2)

M(0)(0) = 1; M(0)(1) = 0

M(1)(0) = 0; M(1)(1) = 1.41421

M(2)(0) = 0; M(2)(1) = 1.41421

projection XYZ, M

provides the working plane to be inclined by 45°. In the same way the matrix can define arbitrary
linear transform.
Note, if the group contains N axis, the matrix in the projection command must be of size Nx2.

6.8.2.2. Arguments as Expression

Any argument in the line, arc1, arc2 commands can be specified by expression.
Using an expression instead of axis specification allows the involved axes to be calculated in the
execution time as opposed to the programming time (axis-independent programming) The
calculation must result in an integer between 0 and 7, corresponding to the eight axes. Value 0
corresponds to the X axis, 1 to Y, and so on.
Expression in place of coordinate allows calculating the segments on the fly. Consider the
following program fragment:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 38 M o t io n

real P, K, S Declare the real variables P,

K and S
P = 3.14159; K = 100 / P; S = P / 1000 Calculate P K and S

ptp XY, –100, 0 Perform a point-to-point

motion in the XY plane to
point -100
mseg XY, –100, 0 Create a segmented motion

loop 2000 Perform the loop 200 times

P = P + S

line XY, P*K*cos(P), P*K*sin(P) Execute a linear segment

based on a calculation
end

ends XY

The program executes the line command 2000 times. The line segments build up a curve close to
the Archimedean spiral:

FIGURE 6-8 Example of argument as expression

6.8.2.3. Motion Smoothness and Stoppers

The controller builds the motion so that the vector velocity follows the smooth velocity diagram.
If all segments are connected smoothly, axis velocity is also smooth. However, if the user defined
a path with an inflection point, axis velocity jumps at this point. The jump might cause a motion
failure due to the acceleration limit. Even if a failure does not occur, the abrupt change in velocity
impairs accuracy and may be harmful to the machine.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 39

The stopper command is used to avoid velocity jump in the inflection points. If a stopper is
specified between two segments, the controller provides smooth deceleration to zero before the
stopper and smooth acceleration to specified velocity after the stopper. Consider the following
program fragment:
ptp XY, 1000, 1000 Go to initial point

mseg XY, 1000, 1000 Create a segmented motion

line XY, 1000, –1000 Execute linear segment

stopper XY Slow down to zero

line XY, –1000, –1000 Execute linear segment

stopper XY Slow down to zero

line XY, –1000, 1000 Execute linear segment

stopper XY Slow down to zero

line XY, 1000, 1000 Execute linear segment

ends X End the segment sequence

The program provides a rectangular path without velocity jumps:

FIGURE 6-9 Example of a rectangular path

6.8.2.4. Cyclic Motion

The c suffix provides cyclic execution of segmented motion. The mseg/c command creates a
motion that after executing the last segment executes the first one and continues through the same
sequence. The final point of the last segment is therefore the starting point of the first segment.
Cyclic segmented motion does not automatically finish. One of the commands halt, kill, break
must be used to stop cyclic motion.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 40 M o t io n

6.8.2.5. Understanding Slaved Segmented Motion

Motion generation for segmented motion may be considered as a two-stage process. In the first
stage the controller generates a smooth motion diagram as a function of time
S = F (T)

where S is a distance along the segmented path, T stands for time, and F is a function independent
of the specified segments.
In the second stage the controller separates the S path into the involved axes:
X = FX (S)

Y = FY (S)

The second stage supplies the current values of the involved axes. The functions FX, FY depend
only on the specified segments. Only the second stage builds the shape of the path in the XY
plane. The first stage provides the motion progress along the path. If the function F of the first
stage is modified, this affects the motion velocity and time, but does not alter the final shape of
the path.
The s or p suffix connected to the mseg command affects the first stage of the motion generation
process by causing the distance S to follow the value MPOS (Axis Master) of the leading axis in
the group. For position lock (p suffix), following is strict:
S = MPOS

For velocity lock (s suffix), following allows a constant offset:

S = MPOS + C

In both cases the second stage of the motion generation remains unchanged and depends only on
the specified segment sequence.
Segment commands specify a path on the plane, and the MPOS value of the leading axis defines
motion progress along the path.
Formulas that calculate the MPOS value must be defined before using the master command .

6.8.2.6. Slave Synchronization

Normally, in slaved motion the slave is synchronized to the master and the distance along the
segmented path follows the MPOS master value strictly or with constant offset. However, there
are two cases, when synchronism is not attainable:
ƒ The slaved motion starts, and positions (position lock) or velocities (velocity lock) of the
master and slave differ. The motion starts as asynchronous.
ƒ The motion was synchronized, but the acceleration of the master exceeds the allowed limit
for the slave (the XSACC variable of the axis). The slave comes out from synchronism.
In both cases, the slaved motion continues asynchronously; i.e. the correspondence between the
distance and MPOS appears broken. The controller tries to regain synchronism by moving the
slave after the master within the maximum allowed motion parameters.
When the slave overtakes the master, synchronism is reestablished and the motion continues as
synchronous.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 41

Slave dynamics is governed by the parameters of the leading axis in the group. The following
variables have effect (See also section 6.7):
XSACC Maximal allowed acceleration of the synchronous motion
SYNV Allowed difference in master and slave velocities, used to define
when the slave can be synchronized to the master
JERK, ACC, VEL Default jerk, acceleration and velocity. The slave uses these
variables only in asynchronous motion in order to overtake the
master.

6.8.2.7. Velocity Lock vs. Position Lock

The s suffix, attached to the mseg command, activates velocity lock motion. When synchronized,
the distance along the path follows the MPOS with a constant offset:
S = MPOS + C

The p suffix, attached to the mseg command, activates position lock motion. When synchronized,
the distance along the path strictly follows the MPOS:
S = MPOS

When the motion is asynchronous for any reason (see above), the controller tries to regain
synchronism by having the slave pursue the master within the maximal allowed motion
parameters. The difference between position lock and velocity lock become effective at the
moment of regaining synchronism:
ƒ Velocity lock motion switches in synchronism when the slave velocity reaches the master
velocity (with allowed error defined by the LOWV variable of the leading axis). The
difference between the master position and the slave position at that moment is latched as the
constant offset C, which then remains unchanged as long as the motion is synchronous.
ƒ Position lock motion switches in synchronism when the slave position overtakes the master
position, i.e. when S = MPOS.
Note that each time the motion loses and regains synchronism, the velocity lock offset C may
latch a different value. If a position lock motion loses synchronism, the slave overtakes the exact
master position and reestablishes the strict equality S = MPOS.

6.8.2.8. Slaved Motion at Extreme Points

Additional suffixes define behavior of slaved motion at extreme points, when the motion
approaches the final point of the last segment or the starting point of the first segment. This
occurs, when the MPOS master value falls out of the interval (0, L), where L is the overall length
of the path. There are four possibilities:
c Cyclic motion
e Extrapolated motion
t Stalled motion
No suffixes Bounded motion
ƒ Cyclic motion (c suffix). The path is closed; the motion passes from the last segment to the
first or from the first to the last as if they are adjacent.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 42 M o t io n

ƒ Extrapolated motion (e suffix). If the distance S slaved to the MPOS master value becomes
greater than the overall length of the path, the motion continues along the extrapolated last
segment. If the distance S slaved to the MPOS master value becomes less than zero, the
motion continues along the extrapolated first segment. If the extrapolated segment is a
circular arc, the motion will follow along the extrapolated circle.
ƒ Stalled motion (t suffix). When the motion approaches the extreme point, the slave comes
out from synchronism and stalls in the point until the MPOS master value allows to regain
synchronism. For velocity lock synchronism is achieved when the MPOS changes its
direction; after regaining the offset C may have a different value than before approaching the
extreme point. For position lock synchronism regains when the MPOS falls into the interval
(0, L) again. The controller ensures smooth approaching the extreme points and smooth return
to synchronism.
ƒ Bounded motion (no additional suffixes). The motion finishes when the slave approaches
any extreme point. The controller activates the next motion in the queue (if any). If the
MPOS master value changes only in positive direction, the behavior is very close to non-
slaved motion. The difference is that non-slaved motion is based upon the time value and
slaved motion is based upon the MPOS master value.

6.9. Open-Loop Operation (Torque Control)

The motor mode: open-loop, is often referred as a torque-control mode.
The following table summarizes differences between three motor modes:
Mode Disabled Open-loop Enabled
State of the Drive Off On On
Enable output
Calculation of control No No Yes
loop algorithm
Correspondence of RPOS follows FPOS RPOS follows FPOS RPOS is calculated
Reference Position according to the
(RPOS) and Feedback commanded motion.
Position (FPOS) FPOS follows the
RPOS as provided by
control loop
algorithm.
Position Error PE Zero Zero The control algorithm
calculates
PE = RPOS – FPOS
Voltage at the drive Zero Proportional to As calculated by the
output DCOM control algorithm

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 M o t io n 6- 43

Bit 1 in the MFLAGS variable enables or disables open-loop mode. The following diagram
explains transition between the three modes:

Disabled
Mode

Command Command
DISABLE DISABLE
Command Command
ENABLE if ENABLE if
MFLAGS.1=1 MFLAGS.1=0

Command
MFLAGS.1 = 0
Open-loop Enabled
Mode Mode

Command
MFLAGS.1 = 1

The circles in this diagram represent the motor modes and the arrows with rectangles show the
controller commands that switch the controller from one mode to another.
As shown in the diagram, a motor can be switched from enabled to open-loop mode and back
without changing to disabled state. The controller provides smooth transition between the modes.
Even if the motor experiences uncontrolled move while in open-loop mode, switching back to
enabled mode does not cause any motor jump. However, be careful if you execute a motion while
the controller is in open-loop mode. Once the command switches back to enabled mode, the
controller continues the motion from the point where it finds the motor. No motor jump occurs,
but the motion trajectory and the final point may be shifted by the value of uncontrolled offset in
the open-loop mode.
While in open-loop mode, the controller calculates the drive voltage output based on the DCOM
variable. The DCOM variable sets the drive output as a percentage of the maximum available
drive output voltage. For example, the SPiiPlus PCI-4/8 provides differential drive output in the
range from –10 to +10V. Therefore, assigning 100 to DCOM provides +10V on the drive output,
assigning –100 provides –10V, and assigning 0 provides 0V.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

6- 44 M o t io n

The following program fragment shows an example of torque control implementation through the
open-loop mode.
enable X Enable the X motor.

ptp/f X,400,100 Move to the point where the

contact search begins.
Provide low (search)
velocity of 100 count/sec in
the final point.
jog/v X,100 Move to the contact point
using the search velocity.
till IN0.4; kill X; X_MFLAGS.1=1; X_DCOM=30 Wait for the signal from the
contact sensor. Kill the
motion. Switch to open-loop
mode. Apply 30% of the
maximum torque.
wait 50; X_DCOM=10 Wait 50 milliseconds and
then change torque to 10%
of the maximum torque.
wait 100; X_MFLAGS.1=0; ptp X,400 Wait 100 milliseconds, then
switch off the open-loop
mode and move away from
the contact point.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-1

7. ADVANCED FEATURES

This chapter describes data collection, position event generation (PEG), sin-cos encoder multiplier
option, DPRAM support, interrupts, and mechanical brake support.

7.1. Data Collection

Data collection is useful in the following applications:
ƒ Troubleshooting
ƒ Adjusting servo control loops
ƒ Applications that require detailed information about internal controller processes
ƒ Teach-and-Go applications
The following commands initiate and terminate data collection:
dc Start data collection
stopdc Stop data collection
The dc command accepts the following suffixes:
s Start data collection synchronously to a motion
w Create the synchronous data collection, but do not start until
the go command. w can only be used with the s suffix..
t Temporal data collection: sampling period is calculated
automatically according to collection time
c Start cyclic data collection (can be used with s and w)
Data collection started by the dc command without suffix s is called system data collection. Data
collection started by the dc/s command is called axis data collection. Data collection started by
the dc/c command is called cyclic data collection. Unlike the standard data collection that finishes

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-2 A d va n c e d F e a t ur e s

when the collection array is full, cyclic data collection does not self-terminate. Cyclic data
collection uses the collection array as a cyclic buffer and can continue to collect data indefinitely.
When the array is full, each new sample overwrites the oldest sample in the array. Cyclic data
collection can only be terminated by the stopdc command.
The dc command is used with the following parameters:
axis Axis to which the data collection must be synchronized. The
parameter is required only for axis data collection (suffix s).
array Array that stores collected data. The array must be
previously defined as global, integer or real. The array size
must be compatible with the number of samples and number
of stored variables (See Understanding System Data
Collection, page 7-4).
number of
The number of data samples to collect.
samples
period Sampling period in milliseconds. Actual sampling period
may differ from this value, because the controller rounds it
to an integer number of controller periods. For example if
you set the period to 3.3 milliseconds, the controller will
round it to 3 milliseconds. If suffix t is attached to the
command, the parameter defines a minimal period (see
explanation of temporal data collection below).
list of Up to eight variable names, whose values are to be
variables collected. Each variable can be a scalar variable, or an
element of an array. Both local and global variables can be
specified. Irrespective of the storage array type, any
combination of integer and real variables is allowed – the
controller automatically executes type conversion if
required.

7.1.1. Standard Variables Involved in Data Collection

Data collection uses the following standard variables:
S_ST System State. Bit #DC in this bit-mapped variable is ON while a general
(started without suffix s) data collection, either standard or cyclical, is in
progress. The bit is OFF if no general collection is executed.
AST Axis State. Bit #DC in this bit-mapped variable is ON while an axis (started
with suffix s) data collection for the corresponding axis is in progress. The bit
is OFF if no axis collection for the axis is executed.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-3

S_DCN General DC Number of Samples. While a system data collection is in progress

the variable displays the index of the array element that stores the next sample.
When a system data collection terminates, the variable stores the number of
actually collected samples. If the data collection terminates automatically, the
variable is always equal to the requested number of samples specified in the dc
command. If the data collection terminates due to the stopdc command, the
variable may be less than the requested number of samples. For cyclic data
collection S_DCN displays the current number of collected samples and
changes as follows:
1. At the start of data collection S_DCN is assigned with zero
2. Each sampling tick S_DCN is incremented until it reaches the size of the
sample array
3. S_DCN then remains unchanged (the new sample overwrites the oldest and
the total number of samples remains the same)
As long as the cyclic data collection is in progress, the application cannot use
the sample array. After the cyclic data collection finishes, the controller
repacks the sample array so that the first element represents the oldest sample
and the last element represents the most recent sample.
S_DCP System DC Period. When a system data collection terminates, the variable
stores the sampling period. Unless a temporal data collection was executed, the
variable is always equal (See explanation of period parameter on page 7-1)to
the requested period specified in the dc command, unless it was rounded to the
controller cycle . For temporal data collection (suffix t) the variable may be
greater than the requested minimal period.
DCN DC Number of Samples (axis variable). While an axis data collection is in
progress the variable displays the index of the array element that stores the next
sample. When an axis data collection for the corresponding axis terminates, the
variable stores the number of actually collected samples. If the data collection
terminates automatically, the variable is always equal to the requested number
of samples specified in the dc command. If the data collection terminates due
to the stopdc command, the variable may be less than the requested number of
samples.
DCP DC Period (axis variable). When an axis data collection for the corresponding
axis terminates, the variable stores the sampling period. Unless a temporal data
collection was executed, the variable is always equal to the requested period
specified in the dc command. For temporal data collection (suffix t) the
variable may be greater than the requested minimal period.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-4 A d va n c e d F e a t ur e s

7.1.2. Understanding System Data Collection

NOTE

Data collection is disabled while the MMI Scope is operating.

When the controller executes the dc command, it starts a separate real-time data collection
process that progresses in parallel with ACSPL+ programs and motion execution. Each sampling
period the process latches the values of all specified variables and stores them in the specified
array. The process continues until the specified number of samples is stored, or the command
stopdc is executed. After process termination the array contains a time series of the specified
variables that may then be used for data analysis.
This is shown in the following example:
global real DCA(2)(1000)

dc DCA, 990, 3, FPOS(0), FPOS(1)

ƒ In the first line, a matrix consisting of two columns and 1000 lines is set up for data
collection
ƒ The second line starts the data collection of the Feedback Position values for axes X and Y.
990 samples are to be collected, with a period of three milliseconds. The first step of the data
collection stores the current value of X_FPOS in DCA(0)(0) and Y_FPOS in DCA(1)(0).
The second step stores X_FPOS in DCA(0)(1) and X_FPOS in DCA(1)(1).
Each variable is stored in one line of the array. Therefore the first dimension of the array (the
number of lines) must be equal or greater than the number of variables. If the number of lines is
greater than the number of variables, the extra array lines remain unaffected by the data
collection. If only one variable is specified for data collection, a one-dimensional array is allowed.
Each sample of data collection fills up one column of the array. Therefore the second dimension
of the array (number of columns) must be equal or greater than the requested number of samples.
If the number of columns is greater than the number of samples, the extra array columns remain
unaffected by the data collection.
The following dc command is not allowed, because the number of variables exceeds the number
of array lines:
global int IA, IC(1000)

dc IC,1000, 1, IA, _FPOS(0)

The following dc command is not allowed, because the number of required samples exceeds the
number of array columns:
int IA, IC(1000)

dc IC,1001, 1, IA

If suffix s is not specified, the system data collection process starts immediately after executing
the dc command. Normally, data collection stops automatically after <number of samples> x
<period> milliseconds. If the stopdc command executes while the data collection is in progress,

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-5

the data collection stops prematurely, and the remaining array columns remain unaffected. To
terminate system data collection, the stopdc command must contain no parameters.
Note
The variable S_DCN provides the number of samples stored during data
collection

The following are examples of dc commands:

global int IA, IC(1000) Set up a one-dimensional 1000-line
array for collecting data about a user-
defined integer variable.
global real RA(2)(2000) Set up a two dimensional array with
two columns and 2000 lines for
collecting data about a real user-
defined variable
dc IC, 1000, 1, FPOS(0) Collect 1000 samples of FPOS on the
X axis at a rate of one per
millisecond
dc RA, 2000, 2.5, IA, FPOS(7) Collect 2000 samples of FPOS on
axis D, at a rate of 3 per millisecond
(Note-The command calls for 2.5
milliseconds, but the controller
rounds it up to the nearest whole
number).
dc RA, 500, 1, TIME Collect 500 samples of the standard
variable TIME at a rate of one per
millisecond

7.1.3. Axis Data Collection

When suffix s is attached to the dc command, data collection starts synchronously with a motion.
The first parameter must specify an axis that the data collection is synchronized with.
If the axis is idle at the moment when the dc/s command executes, no synchronization is provided
and the data collection starts immediately just as if the dc command was executed. If the axis or
axis group is in motion when the dc command executes, the data collection lines up in the motion
queue and waits for all motions that were planned before it, to finish. When the motion queue
comes to the data collection, the data collection starts, and immediately the next motion in the
motion queue starts. Data collection therefore introduces no delay in the motion queue and does
not affect motion execution.
Having started, data collection continues in parallel to the executed motion. Data collection
finishes when the specified number of samples is stored, or the stopdc command executes.
Data collection initiated by the dc command with no associated parameters is stopped by the
stopdc command with no associated parameters. To stop synchronous data collection initiated by
the dc/s command, the stopdc command must also include the s suffix and the axis specification.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-6 A d va n c e d F e a t ur e s

The dc/s command synchronizes the data collection start to the motion of an axis, but is not
limited to collecting data only of that axis. Any parameter for any other axis may be specified for
data collection. For example, the command
dc/s X,Array,500,1,X_FPOS,Y_FPOS

Synchronizes data collection to the start of motion of axis X, but collects data on both axis X and
Y.
Only one data collection process, started by the dc command, can execute at a time. The next dc
command can execute only after the data collection started by the previous dc command finishes.
However, data collection, initiated by the dc/s command, may progress in parallel to the data
collection initiated by the dc command. Moreover, several data collection processes initiated by
the dc/s command may progress in parallel, providing they refer to different axes or axis groups.
For example these two commands are executed serially:
dc/s X, Array,500,1,X_FPOS

dc/s X, Array,500,1,Y_FPOS

While these commands are executed in parallel (unless the X and Y axes belong to the same axis
group):
dc/s X,Array,500,1,X_FPOS

dc/s Y,Array,500,1,Y_FPOS

7.1.3.1. stopdc Command

The syntax of stopdc command is also applicable to cyclic data collection.
An additional integer argument can be specified in the stopdc command. The stopdc without
arguments terminates the data collection immediately. The stopdc with an argument creates
delayed termination of the data collection. For example:
stopdc 50 Collect additional 50 samples and then finish

Note: the syntax of stopdc command that terminates synchronous data collection has been
changed. If your application uses synchronous data collection, slight changes may be required. To
terminate a synchronous data collection that was commanded by a dc/s command, the stopdc
command must also attach suffix s. For example:
dc/s X,ARR,50,10,VAR1 Start synchronous data collection by axis X to array ARR of
size 50, sampling period 50, collect global variable VAR1
stopdc/s X Terminate synchronous data collection by axis X

Multiple axis specification as stopdc XYZT is not allowed in the stopdc command.

7.2. Position Event Generation (PEG)

Position Event Generation (PEG) is a hardware-supported feature that provides the ability to
create events based on comparing the encoder position with a set of predefined values. When a

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-7

match occurs, a pulse is generated on a specific digital output (referred to as the PEG pulse
output) and additionally the state of several digital outputs can be set to desired values (referred to
as PEG pulse outputs) . The function is implemented in hardware, therefore, the delay is
extremely short (fraction of a microsecond).
In addition to position-based pulses, the controller is able to generate a specified number of time-
based pulses. The time-based pulses follow each position-based pulse with a specified period.
NOTE
For stepper motors, PEG is only available if at least one of the following
bits is set: MFLAGS.5 or MFLAGS.6.

7.2.1. PEG Initialization

MODEL
DEPENDENT SPiiPlus CM: Unlike other SPiiPlus controllers, SPiiPlus CM has
dedicated PEG outputs that are assigned to PEG by default. (If PEG
is not needed, these outputs can be reassigned for general use.)

In SPiiPlus controllers (except for the SPiiPlus CM), the digital output pins can be configured for
either general use (page 9-1), mechanical braking (page 7-21), or PEG. Each physical pin can be
configured separately.
On power up, all the pins are assigned by default to the general use. The state of the pin is
determined by the state of the corresponding bit of the OUT0 element. PEG commands will
produce no results on the hardware output pins until those pins have been reconfigured for PEG
operation. This is done using the assignpeg command
NOTE
PEG assignment changes the operation of the hardware outputs but has
no effect on the OUT variable.

7.2.1.1. Command assignpeg

Command assignpeg is used for two tasks:
• - Model Dependent – controllers without dedicated PEG hardware outputs: assigns
digital outputs for use as PEG state and PEG pulse outputs
• sets the initial state of PEG state outputs.
The function has the following format:
assignpeg axis, output-mask, init-mask, init-value
where:
axis specifies the axis.
output-mask is a bit mask that specifies whether an output is assigned to PEG.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-8 A d va n c e d F e a t ur e s

• When a bit in the mask is clear, the corresponding digital output is assigned to PEG .
• When a bit in the mask is set, the assignment of the corresponding output remains
unchanged.
The following bits are relevant:
0 - PEG state 0
1 - PEG state 1
2 - PEG state 2
3 - PEG state 3
8 - PEG pulse
All other bits must be cleared.
init-mask is a bit mask that specifies PEG state outputs to be initialized (see init-value).
Pulse output cannot be initialized. Therefore, bit 8 must be zero.
The argument can be omitted, in which case the command only assigns outputs to PEG but
does not initialize the value of any PEG state outputs.
init-value specifies the condition of each output selected with init-mask.
• When a bit is clear, the corresponding hardware output receives low voltage.
• When a bit is set, the corresponding hardware output receives high voltage.
Only bits that correspond to non-zero bits in init-mask take effect.

7.2.1.2. PEG Output Assignment

- Model Dependent: The procedure for PEG output assignment depends on whether the
controller model has dedicated PEG hardware outputs or whether it requires reconfiguration of
digital outputs.
See PEG output assignment (page 010-1).

7.2.2. Synchronous and Asynchronous PEG

If the PEG_I or PEG_R command is specified without a suffix, the PEG starts asynchronously,
i.e. immediately once the command is executed. If suffix S is attached to the command, the PEG
starts synchronously. The following example illustrates synchronous execution:
ptp X,10000 Move to position 10000

ptp X,0 Move to position 0

peg_i/s X,0.2,1000,100,2000 Activate synchronous incremental PEG for X

motor, pulse width 0.2 milliseconds, first point
1000, increment 100, last point 2000
ptp X,3000 Move to position 30000

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-9

Command PEG_I/S specifies a synchronous incremental PEG. The command creates a PEG entry
in the motion queue and the PEG starts synchronously with the motion sequence. In this example
the PEG waits for the termination of the previous motions (PTP X,10000 and PTP X,0). Once
motion PTP X,0 finishes, the controller activates the PEG and at the same controller cycle starts
the next motion PTP X,3000. Therefore, the PEG will be active while motion PTP X,3000 is
executed and has no effect on previous motions.
In the same example, if PEG_I without suffix S is specified, the PEG is activated asynchronously,
immediately when the PEG_I command is executed, and does not wait in the motion queue.
Likely, at this moment the motion PTP X,10000 is in progress. If the position of 1000 has not
been reached when the PEG command is executed, the PEG will generate events that are based on
that motion. In this case there is no strict automatic synchronization between PEG and motion,
therefore the user must define in the program appropriate waiting conditions in order to start the
PEG at the required moment.

7.2.3. Incremental PEG (peg_i Command)

Incremental PEG is defined by the first point P0, last point P1 and interval I. Incremental PEG
generates the first pulse in position P0 and then repeats the pulse in positions P0+I, P0+2*I,
P0+3*I, etc. The interval can be either positive or negative. The software terminates the PEG
when the motor crosses position P1.
If the interval is small and the time between events is less than controller cycle, additional pulses
might be generated at points beyond position P1.
The incremental PEG function has the following format:

peg_i axis,width,first-point,interval,last-point,tb-
number,tb-period
where axis is an axis specification
width is a desired width of generated pulse (milliseconds)
first-point is a position where the first pulse is generated (user units)
interval is a distance between the pulse-generating points (user units)
last-point is a position where the PEG finishes (user units)
tb-number (optional) is a number of time-based pulses generated after each encoder-based
pulse, the range is from 0 to 511
tb-period (optional) is a period of time-based pulses (milliseconds), the range is from
0.000050 to 0.012775
The last two arguments are optional. If they are omitted, the controller generates only the
encoder-based pulses.
The following limitations apply to incremental PEG function:
1. Only axes X, Y, Z, T support the PEG.
PEG command that specifies any other axis (A, B, C, D) has no effect.
2. Pulse width is limited as follows:
In SPiiPlus PCI-4/8 from 0.000025 to 0.75 milliseconds.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-10 A d va n c e d F e a t ur e s

3. PEG function shares the connector pins with the digital outputs. To assign a digital output
to the PEG use the setconf function with key value 205 as described above. The PEG
pulse output has the following destination:
X axis PEG pulse is directed to the pin OUT3.
Y axis PEG pulse is directed to the pin OUT7.
Z axis PEG pulse is directed to the pin Z_PEG_PULSE in SPiiPlus PCI-8.
T axis PEG pulse is directed to the pin T_PEG_PULSE in SPiiPlus PCI-8.
4. Interval must be in the range of –32768 to 32767 encoder counts. If the controller is
configured for user units different from encoder counts, i.e. the EFAC variable is not
equal to one, the argument range is from -32768*EFAC to 32767*EFAC. Specifying the
interval outside the range will cause pulse generation in unexpected positions.
5. If the interval is positive, the last position must be greater than the first position. If the
interval is negative, the last position must be smaller than the first position.
6. The PEG function works correctly if the sign of the interval corresponds to the direction
of motion. If the motor moves oppositely to the sign of the interval, the PEG pulses will
be generated in unexpected positions.

7.2.4. Random PEG (peg_r Command)

Random PEG function specifies an array of points at which position-based events are to be
generated. At the specified points, a pulse is generated and the digital outputs assigned to the PEG
are set to a desired state.
The number of PEG state outputs that a SPiiPlus controller supports is model-dependent. Refer to
the unit's Hardware Guide.The random PEG function has the following format:

peg_r axis,width,point-array,state-array,tb-number,tb-period
where:
axis is an axis specification,
width is a desired width of generated pulse (milliseconds),
point-array is a real array that contains the positions at which the PEG should generate events
(user units),
state-array (optional) is an integer array, that specifies the desired state of the output at each
PEG position,
tb-number (optional) is a number of time-based pulses generated after each encoder-based
pulse, the range is from 0 to 511
tb-period (optional) is a period of time-based pulses (milliseconds), the range is from
0.000050 to 0.012775
The last three arguments are optional. If state-array is omitted, the controller generates the PEG
pulses at each position but does not change the state of any output. If tb-number and tb-period are
omitted, the controller does not generate time based pulses.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-11

The following limitations apply to random PEG function:

• Only axes X, Y, Z, T support the PEG. PEG command that specifies any other axis (A, B, C,
D) has no effect.
• Pulse width is limited as follows:
In SPiiPlus PCI-4/8 from 0.000025 to 0.75 milliseconds.
• PEG function shares the connector pins with the digital outputs. To assign a digital output to
the PEG use the setconf function with key value 205 as described above. The PEG pulse
output has the following destination:
♦ X axis PEG pulse is directed to the pin OUT3
♦ Y axis PEG pulse is directed to the pin OUT7
♦ Z axis PEG pulse is directed to the pin Z_PEG_PULSE in SPiiPlus PCI-4/8
♦ T axis PEG pulse is directed to the pin T_PEG_PULSE in SPiiPlus PCI-4/8
• If state-array argument is specified, the PEG function sets the state of the PEG assigned
outputs. To assign a digital output to the PEG state output, use the setconf function with key
value 205 as described above. Only 4 low bits are meaningful in each element of the state-
array.
The 3 low bits of state-array elements are directed to the pins as follows:
Bit 0 of state- Bit 1 of state- Bit 2 of state- Bit 3 of state-
array array array array
X axis OUT0 OUT1 OUT2 X_PEG_3
PEG (PCI-4/8 only)
Y axis OUT4 OUT5 OUT6 Y_PEG_3
PEG (PCI-4/8 only)

Once a PEG point is compared with the motor position and activates the PEG pulse, the
PEG function transfers the 3 or 4 low bits of the corresponding state-array element to the
corresponding outputs. Only those state-array bits that correspond to the outputs assigned
to PEG are effective.
• The positions in the point-array must follow in the strict ascending or strict descending
order. The direction of motion must correspond to the order in point-array. Otherwise the
function will generate events in unexpected positions.

7.2.5. Terminating PEG Prematurely (stoppeg Command)

Normally, the PEG finishes when the last point is achieved. Sometimes an application may
require terminating the PEG prematurely and releasing all captured outputs. The following
function terminates the PEG immediately:

stoppeg axis
where axis is an axis specification.
The function affects either incremental or random PEG.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-12 A d va n c e d F e a t ur e s

7.2.6. PEG Status

Bit #PEG (2) in AST element displays the status of PEG of the corresponding axis. The bit is
raised as long as the PEG is in progress.
The application can examine the bit in order to retrieve the PEG status or wait for PEG
termination.

7.2.7. Examples
The following example moves the X motor in reciprocated motion between positions 0 and
30000. On each motion in positive direction 11 PEG pulses are generated in points 10000, 11000,
… 20000.
setconf(205,0,0b100000000) Assign output 3 to the PEG pulse output

enable X Enable the X motor

ST: Label

peg_i/s X,0.2,10000,1000,20000 Activate incremental PEG for X motor,

pulse width 0.2 milliseconds, first point
10000, increment 1000, last point 20000
ptp X,30000 Move to position 30000

ptp X,0 Move to position 0

goto ST Repeat motion

In the following example the same behavior is achieved with asynchronous PEG. Because in this
case there is no automatic synchronization with the motion, the required synchronization is
provided by autoroutine condition:
setconf(205,0,0b100000000) Assign output 3 to the PEG pulse output

enable X Enable the X motor

ST: Label

ptp X,30000 Move to position 30000

ptp X,0 Move to position 0

goto ST Repeat motion

stop

on ^X_MST.#PEG & X_RVEL > 0 Activate autoroutine if the PEG is not

active and the motion is in positive
direction
peg_i X,0.2,10000,1000,20000 Activate incremental PEG for X motor,
pulse width 0.2 milliseconds, first point
10000, increment 1000, last point 20000

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-13

ret End of autoroutine

The following example moves the X motor in reciprocated motion between positions 0 and
30000. On each motion in positive direction 5 PEG pulses are generated in points 10000, 12000,
12500, 15000, 20000.
global real ARR(5) Declare array ARR

setconf(205,0,0b100000000) Assign output 3 to the PEG pulse output

ARR(0)=10000 Fill the array with desired positions

ARR(1)=12000

ARR(2)=12500

ARR(3)=15000

ARR(4)=20000

enable X Enable the X motor

ST: Label

peg_r/s X,0.2,ARR Activate random PEG for X motor, use PEG

points from array ARR
ptp X,30000 Move to position 30000

ptp X,0 Move to position 0

goto ST Repeat motion

The following example moves the Y motor in reciprocated motion between positions 0 and 3000.
On each motion in negative direction 3 PEG pulses are generated in points 2000, 1000, 500.
Additionally at each PEG point the corresponding state is set at outputs 4, 5, 6.
global real ARR(3) Declare array of PEG points

global int STAT(3) Declare array of PEG states

setconf(205,1,0b100000111) Assign output 7 to the PEG pulse output and

outputs 4, 5, 6 to the PEG state outputs
ARR(0)=2000 Fill the array with desired positions

ARR(1)=1000

ARR(2)=500

STAT(0)=0b001 Fill the array with desired states

STAT(1)=0b010

STAT(2)=0b100

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-14 A d va n c e d F e a t ur e s

enable Y Enable the Y motor

ST: Label

ptp Y,3000 Move to position 3000

peg_r/s Y,0.01,ARR,STAT Activate random PEG for Y motor, use PEG

points from array ARR and PEG states from
array STAT
ptp Y,0 Move to position 0

goto ST Repeat motion

The following example differs from the previous one in that no state outputs are generated, but
additionally to each encoder-based pulse, five time-based pulses are generated:
global real ARR(3) Declare array of PEG points

setconf(205,1,0b100000000) Assign output 7 to the PEG pulse output

ARR(0)=2000 Fill the array with desired positions

ARR(1)=1000

ARR(2)=500

enable Y Enable the Y motor

ST: Label

ptp Y,3000 Move to position 3000

peg_r/s Y,0.01,ARR,,5,0.01 Activate random PEG for Y motor, use PEG

points from array ARR, generate 5 time-based
pulses with period 100 microsecond per each
encoder-based pulse
ptp Y,0 Move to position 0

goto ST Repeat motion

7.3. Sin-Cos Encoder Multiplier (Option) Configuration

MODEL
DEPENDENT
Sin-cos encoder multiplier is supported only by the SPiiPlus
PCI-4/8.

The SPiiPlus PCI-4/8 supports the use of sin-cos encoders, which are encoders with analog
outputs.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-15

NOTE
For convenient modification of encoder related variables, use the
SPiiPlus MMI (from the Tools menu, select Configurator, then click
Encoder Parameters).

7.3.1. Sin-Cos Encoder Multiplier

The sin-cos encoder multiplier provides a combination of high speed and high resolution that
cannot be achieved with an external encoder multiplier producing a digital quadrature signal.
Sin-cos encoder multiplier is an optional feature. You need to specify the number of sin-cos
encoder multipliers when you order the controller.

7.3.1.1. Technical Data

Maximum multiplication factor: 65536 counts per encoder sine signal period.
Maximum velocity: 42*109 counts/sec or 641*103 sine periods/sec.
Maximum acceleration: 65536*108 counts/sec2 or 108 sine periods/sec2.
The encoder-related controller features: index, Mark, and PEG, do not support the full resolution
of the multiplier. Resolution for these features is limited to 4 counts per encoder sine signal
period.

7.3.1.2. Configuring the Sin-Cos Multiplier

The user specifies the sin-cos encoder multiplier as a feedback source with the E_TYPE standard
variable (see also page 11-26). The variable is an array sized according to the number of axes. If
an element in E_TYPE is set to 4, the corresponding axis will use the sin-cos encoder multiplier
as a feedback source. The user can select any axis to use the sin-cos encoder multiplier, but the
total number of multipliers is limited to the number ordered with the controller (the allowed
number is hardwired in the PAL). If the user tries to select more multipliers than allowed, the
controller issues error 1148.
The standard variable E_SCMUL (see also page 11-24) specifies the desired value of
multiplication as a power of 2. The maximum value of 16 corresponds to a multiplication of
65536 = 216. The minimum value of 2 corresponds to a multiplication of 4 = 22.
An axis that uses the sin-cos encoder multiplier is not different from any other axis in the
controller. Any motion can involve the multiplier axis. The multiplier and non-multiplier axes can
be used simultaneously in one multi-axis motion.
The following example shows how the encoder multiplier affects the EFAC calculation:
Assume the encoder has 250 lines per mm. The user assigns E_SCMUL the value 10,
which provides multiplication x1024 (i.e., 210). The desired programming unit is millimeter.
In this case the user must specify EFAC (see also page 11-26) as
1/(250*1024) = 0.00000390625
Encoder-related features: index, Mark, PEG use the same user unit. However, actual resolution of
these functions is lower than the resolution of encoder feedback. As mentioned above, the

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-16 A d va n c e d F e a t ur e s

resolution of index, mark and PEG corresponds to 4 counts per encoder sine period. In the former
example the resolution will be 1/(250*4) = 0.001mm.
The controller continuously checks the integrity of the encoder multiplier feedback. If any error
occurs, the controller activates the Encoder Error fault.

7.3.2. Sin-Cos Filter

The sin-cos filter reduces the electrical noise level of the encoder signal, thereby reducing jitter at
standstill position.
WARNING
Change this parameter only with the motor disabled.

The variable SLEMOS sets the order of the filter. The range is 0 to 4 (default is 0). When
SLEMOS = 0, the filter is not active.

7.3.2.1. Filter Limitations:

1. The filter is active only when the motor is not moving (GPHASE=0).
2. The filter may be used only when the encoder counter is in the range of ±231counts. (If the
motor moves in one direction for a long time, causing the counter to overflow, the position
reading will be incorrect.)

7.3.2.2. Test Results:

FIGURE 7-10 shows the position error at standstill of a rotary motor with sin-cos encoder.
Encoder resolution is 2000 lines per revolution.
(A) shows the position error with a multiplier of 8192 and the filter inactive (SLEMOS=0).
(B) shows the position error with a multiplier of 8192 and with the filter active (SLEMOS=4).
It can be seen that jitter has been reduced by almost one half and a jitter of ±2 counts is achieved.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-17

(A) E_SCMUL=13, SLEMOS=0 (B) E_SCMUL=13, SLEMOS=4

FIGURE 7-10 Jitter without (A) and with (B) Enhanced-Resolution Filter

7.4. Interrupts
Typically, the user works with the SPiiPlus interrupts using the SPiiPlus C Library and does not
need the low-level details specified in this section. See the description of SPiiPlus C Library for
explanation of interrupt managing functions.
Reading any interrupt status register also resets the bits in the register. For hardware interrupts
this enables the interrupt to be generated again. For software interrupts this is not enough: the host
drive must write zero also to an interrupt tag in order to enable the corresponding software
interrupt to be generated again.

7.4.1. Hardware Interrupts

The PCI card generates interrupts through an interrupt line.
To find out the exact source of the interrupt the host drive must read two interrupt status registers.
Because one interrupt may be caused by two or more sources, the host drive must always read
both registers.
The hardware interrupt status registers reside at address Offset+0x1000 and contain the following
bits:

Bit Description
3 PEG X
4 PEG Y
5 PEG Z

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-18 A d va n c e d F e a t ur e s

Bit Description
6 PEG T
7 MARK 1 X
8 M2ARK X
9 MARK 1 Y
10 M2ARK Y
11 MARK 1 Z
12 M2ARK Z
13 MARK 1 T
14 M2ARK T
15 Emergency Stop

7.4.2. Software Interrupts

The software interrupt status register resides at address Offset+0x1002 and contains the following
bits:

Bit Description
0 Physical motion end
1 Logical motion end
2 Motion failure (Motion interruption due to a fault)
3 Motor failure (Motor disable due to a fault)
4 Program termination
5 Command execution
6 ACSPL+ interrupt (by INTERRUPT command)
7 Digital input
14 Controller cycle (the controller raises this interrupt in the beginning
of each controller cycle)
15 Communication interrupt (the controller raises this interrupt after
sending a complete message to the FIFO)
Reading any interrupt status register also resets the bits in the register. For hardware interrupts
this enables the interrupt to be generated again. For software interrupts this is not enough: the host
drive must write zero also to an interrupt tag in order to enable the corresponding software
interrupt to be generated again.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-19

Software interrupt tags occupy the first 8 words of the DPR, addresses from Offset+0x2000 to
Offset+0x2007. When a software interrupt occurs, the corresponding tag contains detailed
information about the interrupt source. For example, the tag of the Physical motion end interrupt
specifies the axes that caused the interrupt. When a specific software interrupt has occurred, the
next interrupt of the same type can be generated only after the host drive reads both interrupt
status register and writes zero to the corresponding tag.

7.4.3. Software Interrupt Tags

The following tags are available:

Bit Description
0 Details of Physical motion end interrupt.
Bit 0 specifies that axis X has finished, bit 1 – axis Y, and so on.
1 Details of Logical motion end interrupt.
Bit 0 specifies that axis X has finished, bit 1 – axis Y, and so on.
2 Details of Motion failure interrupt.
Bit 0 specifies that axis X has failed, bit 1 – axis Y, and so on.
3 Details of Motor failure interrupt.
Bit 0 specifies that axis X has failed, bit 1 – axis Y, and so on.
4 Details of Program termination interrupt.
Bit 0 specifies that buffer 0 has finished, bit 1 – buffer 1, and so on.
5 Details of Command execution interrupt (dynamic buffer only).
Bit 0 specifies event in buffer 0, bit 1 – buffer 1, and so on.
6 Details of ACSPL+ interrupt (by INTERRUPT command).
Bit 0 specifies interrupts from buffer 0, bit 1 – buffer 1, and so on.
7 Details of Digital input interrupt.
Bit 0 specifies interrupts from input 0, bit 1 – input 1, and so on.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-20 A d va n c e d F e a t ur e s

7.4.4. Interrupt Configuration Variables

The following standard variables enable/disable interrupts from a specific source:

IENA Scalar variable that enables/disables all interrupts that belong to a

specific interrupt status bit
ISENA Array that enables/disables interrupts within a specific interrupt status
bit. Each elements corresponds to one interrupt status bit and specifies
which axes or buffers or inputs are enabled to cause interrupt.

7.4.4.1. IENA Variable

The IENA variable contains the following bits:

Bit Description
3 Enable PEG X interrupt
4 Enable PEG Y interrupt
5 Enable PEG Z interrupt
6 Enable PEG T interrupt
7 Enable MARK 1 X interrupt
8 Enable M2ARK X interrupt
9 Enable MARK 1 Y interrupt
10 Enable M2ARK Y interrupt
11 Enable MARK 1 Z interrupt
12 Enable M2ARK Z interrupt
13 Enable MARK 1 T interrupt
14 Enable M2ARK T interrupt
15 Enable Emergency Stop interrupt
16 Enable Physical motion end interrupt
17 Enable Logical motion end interrupt
18 Enable Motion failure (Motion interruption due to a fault) interrupt
19 Enable Motor failure (Motor disable due to a fault) interrupt
20 Enable Program termination interrupt
21 Enable Dynamic buffer interrupt
22 Enable ACSPL+ interrupt (by INTERRUPT command)
23 Enable Digital input interrupt

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-21

7.4.4.2. ISENA Variable

The ISENA variable is an array containing the following elements:

Element Description

0 Controls Physical motion end interrupt.

Bit 0 enables interrupts from axis X, bit 1 – axis Y, and so on.
1 Controls Logical motion end interrupt.
Bit 0 enables interrupts from axis X, bit 1 – axis Y, and so on.
2 Controls Motion failure interrupt.
Bit 0 enables interrupts from axis X, bit 1 – axis Y, and so on.
3 Controls Motor failure interrupt.
Bit 0 enables interrupts from axis X, bit 1 – axis Y, and so on.
4 Controls Program termination interrupt.
Bit 0 enables interrupts from buffer 0, bit 1 – buffer 1, and so on.
5 Controls Command execution interrupt (dynamic buffer only).
Bit 0 enables interrupts from buffer 0, bit 1 – buffer 1, and so on.
6 Controls ACSPL+ interrupt (by INTERRUPT command).
Bit 0 enables interrupts from Buffer 0, bit 1 – buffer 1, and so on.
7 Controls Digital input interrupt.
Bit 0 enables interrupts from input 0, bit 1 – input 1, and so on.

7.5. Mechanical Brake Support

SPiiPlus controllers can activate and release mechanical brakes. Depending on the controller
model, this is done either via the digital outputs or via dedicated brake outputs.

7.5.1. Brake Output Assignment

- Model Dependent: See mechanical brake output assignment per controller type (page 10-3).

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-22 A d va n c e d F e a t ur e s

7.5.2. Brake Operation

7.5.2.1. Preconditions
Before a mechanical brake can be controlled by an output, the following conditions must be met:
• The brake control signal is wired to the corresponding controller digital output (page 7-
21) or, in the case of the SPiiPlus CM, to the dedicated brake output. The wiring
arrangement must provide zero (low voltage) output state to activate the brake and one
(high voltage) output state to deactivate the brake.
• - MODEL DEPENDENT (SPiiPlus PCI-4/8 and SPiiPlus PCI-DDM4): The digital
output must be assigned to the brake function using setconf(29) (see brake outputs, page
7-21).
• Bit MFLAGS.#BRAKE for the corresponding axis must be set (see MFLAGS, page 11-
45).

7.5.2.2. Retrieving the Current State of the Brake

At any time the current state of the brake can be retrieved using function getconf(229). The
function returns the state of the brake output. For example, the following function
getconf(229,1) Retrieve state of the Y brake

returns 0 if the Y brake is active and returns 1 if the Y brake is not active.
See also the reference information for setconf/getconf(229), page 5-66.

7.5.2.3. Operating the Brake Manually

While the motor is disabled, the brake can be operated using function setconf(229). For example:
setconf(229,2,1) Deactivate the Z brake
setconf(229,5,0) Activate the B brake

If the motor is enabled, attempting to execute the function causes an error.

7.5.2.4. Execution of enable Command

The brake is deactivated automatically when the enable command is executed. (See also enable
command, page 5-102.)
The enable command is executed in the following steps:
• Preparatory operations. The operations are different for different models of the SPiiPlus
controller. The duration can be as low as several milliseconds (SPiiPlus PCI-8) and as
high as 200 milliseconds (SpiiPlus DDM-4).
• The Enable output (to the drive) is set to one and the servo loop is closed.
• If bit MFLAGS.#ENMOD is 1, wait ENTIME milliseconds.
If bit MFLAGS.#ENMOD is 0, wait till the Drive Alarm signal becomes zero.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A d va nc e d F e a t u re s 7-23

• If bit MFLAGS.#BRAKE is 1, set the Brake output to one (deactivate the brake) and
wait BOFFTIME milliseconds.
The following diagram illustrates the enable process timing for MFLAGS.#ENMOD = 1 and
MFLAGS.#BRAKE = 1.

Start of End of
enable enable
process process

Preparatory ENTIME BOFFTIME

operations msec msec

Enable output

Brake output

7.5.2.5. Execution of disable Command

The brake is activated automatically when the disable command is executed.
If bit MFLAGS.#BRAKE is zero (no brake control), the disable command sets the Enable output
to zero (disables the drive) immediately and opens the servo loop.
If bit MFLAGS.#BRAKE is one (brake control), the disable command process is executed in
following steps:
• The Brake output is set to zero (activate the brake)
• Wait for BONTIME milliseconds.
• The Enable output is set to zero (disable the drive) and the servo loop is opened.
An example of the timing of the disable process for MFLAGS.#BRAKE = 1, is shown in
FIGURE 7-11.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

7-24 A d va n c e d F e a t ur e s

Start of End of
disable disable
process process

BONTIME
msec

Enable output

Brake output

FIGURE 7-11 Timing of Disable Process

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-1

8. SAFETY CONTROL

Safety features are necessary to protect both the equipment and the user from potential injury.
SPiiPlus controllers include numerous safety-related features, but the final responsibility for the
safe use of the controller in a particular application lies with the user. Before you create your
application make sure that you thoroughly read and understand this chapter.
A list of safety-related parameters described in this chapter can be found on page 11-4.

8.1. Introduction to Safety Control

WARNING Some alarms, limits, and errors involve protection against
potentially serious bodily harm and equipment damage. Be aware
of the implications before changing or disabling any alarm, limit,
or error.

8.1.1. Safety Control as a Controller Task

Safety control is one of the highest-priority tasks of the controller. The controller continually
monitors safety conditions each controller cycle, in parallel to its other activities.
The controller sets one of the fault bits (FAULT standard variable) when it detects a malfunction.
The response to a fault may vary from sending a fault message to a complete termination of all
activities. For each fault type you can enable/disable the default controller response or define your
own autoroutine response.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-2 S a f e t y C o n t ro l

8.1.2. Types of Malfunctions

The controller monitors numerous safety conditions that may indicate different hardware or
software malfunctions (faults). The most frequent causes of faults are the following:

Type of Fault Examples

User error Defining a required velocity that is invalid or
beyond the limits.
Improper or broken wiring A loose connection in the feedback encoder wiring
Power amplifier malfunction The power amplifier malfunctions and sends a fault
signal to the controller
Motor malfunction A motor overheats
Controlled plant malfunction The Emergency Stop input is activated
Controller hardware malfunctions The Main Processor Unit (MPU) and the Servo
Processors (SPs) work together to detect
malfunctions in the controller. Examples include the
servo processor alarm and the servo interrupt.

8.1.3. How the Controller Detects Malfunctions

To detect malfunctions the controller monitors safety inputs, such as limit switches, and internal
safety conditions. such as comparing the reference position with the software limits.
Internal safety conditions may consist of static formulae such as checking the acceleration limit,
or may include time dependencies such as measuring the time interval between two interrupts to
detect servo interrupt faults.
Some safety conditions are a mixture of both techniques. For example, position error control is
based on both a static condition, whether a motor is positioned at a certain location, and a time
dependency, how long the motor is positioned at the location.

8.1.4. Faults
When the controller detects a malfunction, it raises a specific fault bit. Fault bits are grouped into
standard variables FAULT and S_FAULT.
In certain cases, you may want to define which fault conditions are examined in a specific
application. The standard variables FMASK and S_FMASK specify which fault conditions must
be examined in a particular application.

8.1.4.1. The FAULT Variable

The FAULT variable is an integer array containing eight elements (corresponding to the number
of motors), where each element is made up of a set of bits. Each bit indicates a motor fault. Motor
faults are related to a specific motor, power amplifier, or Servo Processor. Examples include
tracking error and motor overheat.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-3

8.1.4.2. The S_FAULT Variable

S_FAULT is a scalar variable, where each bit represents the aggregate status of a particular fault.
The bits of S_FAULT are divided into two categories:
• Aggregated motor faults. Once the controller raises a bit in any element of FAULT, it
immediately raises the corresponding bit of S_FAULT. Therefore, each bit of S_FAULT is
an OR aggregate of the corresponding bits in all elements of FAULT.
• System faults such as Emergency Stop and Time Overuse that are not related to any specific
motor.

8.1.5. Controller Response

The controller response to a fault can vary, according to the requirements of your application:
• No response.
• Default response – One or more predetermined actions. You can disable the default response
for any fault.
• Autoroutine response - User-defined actions implemented in an autoroutine. In the
autoroutine you select a controller fault and controller responses to the fault. An autoroutine
can replace the default response or supplement it with additional actions.

8.2. Safety Control Summaries

A fault is a critical error for which the controller provides a default response. The user can control
the response: deactivating it or changing it.

8.2.1. Summary of Faults and Default Responses

A fault can be either a motor or system fault. Motor faults refer to a specific motor, power
amplifier, or Servo Processor and affect the state of the corresponding bit for that element of the
FAULT variable. System faults do not refer to a specific motor. The corresponding bits are
located in the S_FAULT variable.
For most controller-detected faults there is a default response, which is normally executed
automatically when the fault occurs. Your ACSPL+ application can simply allow the default
response for a fault or you can do either or both of the following:
• Disable the default response by using standard variables FDEF and S_FDEF.
• Create an autoroutine (implementing your preferred response) activated by the occurrence of
the fault. If desired, you can leave the default response enabled so that it will execute
together with the autoroutine.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-4 S a f e t y C o n t ro l

NOTE
The right limit restricts the motion in the positive direction and the left
limit in the negative direction.

TABLE 8-6 Faults and the Controller's Default Response

Bit Fault Type Fault Description Default response

0 #RL Motor RIGHT LIMIT. The controller The controller kills the violating
raises the fault bit when the right motor.
limit switch is activated.
As long as the fault is active, the
controller kills any motion that tries
to move the motor in the direction
of the limit. Motion to return to the
allowed range of motion is allowed.
1 #LL Motor LEFT LIMIT. The controller raises Same as for #RL.
the fault bit when the left limit
switch is activated.
5 #SRL Motor SOFTWARE RIGHT LIMIT. The The controller kills the violating
controller raises the fault bit, motor. As long as the fault is active,
when the motor reference the controller kills any motion that
position (RPOS) is greater than tries to move the motor in the
the software right limit margin direction of the limit. Motion in the
(SRLIMIT). direction out of the limit is allowed.
6 #SLL Motor SOFTWARE LEFT LIMIT. The Same as #SRL.
controller raises the fault bit,
when the motor reference
position (RPOS) is less than the
software left limit margin
(SLLIMIT).
7 #ENCNC Motor ENCODER NOT CONNECTED. The The controller disables the violating
controller raises the fault bit motor.
when the primary encoder is not
connected.
8 #ENC2NC Motor ENCODER 2 NOT CONNECTED. No default response.
The controller raises the fault bit
when the secondary encoder is
not connected.
9 #DRIVE Motor DRIVE ALARM. The controller The controller disables the violating
raises the fault bit, when the motor.
signal from the drive reports a
failure.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-5

Bit Fault Type Fault Description Default response

10 #ENC Motor ENCODER ERROR. The controller The controller disables the violating
raises the fault bit, when the motor. The faults remain active
primary encoder malfunctions. until the user resolves the problems
and enables the motor again or
executes the fclear command.

11 #ENC2 Motor ENCODER 2 ERROR. The Same as #ENC.

controller raises the fault bit,
when the secondary encoder
malfunctions.
12 #PE Motor POSITION ERROR. The controller None.
raises the fault bit, when the
position error (PE) limit is
exceeded. The limit depends on
the motor state and is defined by
the following variables:
ERRI if the motor is idle (not
moving)
ERRV if the motor is moving
with constant velocity
ERRA if the motor is
accelerating or decelerating
13 #CPE Motor CRITICAL POSITION ERROR. The The controller disables the violating
controller raises the fault bit, motor.
when the position error (#PE)
exceeds the value of the critical
limit. Whereas #PE errors occur
during normal operation, #CPE is
assumed to occur outside normal
operation parameters and #CPE >
#PE.
The critical limit depends on the
motor state and is defined by the
following variables:
CERRI if the motor is idle
(not moving)
CERRV if the motor is
moving with constant
velocity
CERRA if the motor is
accelerating or decelerating

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-6 S a f e t y C o n t ro l

Bit Fault Type Fault Description Default response

14 #VL Motor VELOCITY LIMIT. The controller The controller kills the violating
raises the fault bit, when the motor.
absolute value of the reference
velocity (RVEL) exceeds the
limit defined by the XVEL
parameter.
15 #AL Motor ACCELERATION LIMIT. The The controller kills the violating
controller raises the fault bit motor.
when the absolute value of the
reference acceleration (RACC)
exceeds the limit defined by the
XACC parameter.
16 #CL Motor CURRENT LIMIT. The controller The controller disables the violating
raises the fault bit, when the motor.
RMS current calculated in the
Servo Processor exceeds the limit
value defined by the XRMS
parameter.
17 #SP Motor SERVO PROCESSOR ALARM. The The controller disables the violating
controller raises the fault bit motor and kills the motion that
when the axis Servo Processor involves the motor.
loses its synchronization with the
main processor. The fault
indicates a fatal problem in the
controller.
20 #HSSINC Motor HSSI NOT CONNECTED. The None.
controller raises the fault bit if
the HSSI expansion module is
not connected. See also page 9-7.
25 #PROG System PROGRAM FAULT. The controller The controller kills all motors.
raises the fault bit when a run
time error occurs in one of the
executing ACSPL+ programs.
26 #MEM System MEMORY FAULT. The user The controller kills all motors.
application requires too much
memory.
27 #TIME System TIME OVERUSE. The user No default response.
application consumes too much
time in the controller cycle.
28 #ES System EMERGENCY STOP. The The controller disables all motors.
controller raises the fault bit
when the ES signal is activated.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-7

Bit Fault Type Fault Description Default response

29 #INT System SERVO INTERRUPT. The servo The controller disables all motors.
interrupt that defines the
controller cycle is not generated.
The fault indicates a fatal
controller problem.
30 #INTGR System INTEGRITY VIOLATION. The No default response
controller raises the fault bit
when an integrity problem is
detected.

8.2.2. Summary of Safety Inputs

Safety inputs and internal safety conditions are the building blocks for safety control. Safety
inputs receive binary signals (low or high voltage), from external sources such as a switch or a
relay. Unlike general-purpose inputs that have no predefined function, each safety input is
dedicated to specific function.
There are six different motor safety inputs and one system safety input. The controller provides a
complete set of safety inputs for each motor. For example there are eight left limit inputs: one per
motor.
The state of the motor safety inputs is stored in the standard variable SAFIN, while the current
state of the Emergency Stop input is stored in the standard variable S_SAFIN. A high level of a
physical signal (voltage) raises the corresponding bit and a low level drops the corresponding bit.
The safety inputs occupy the same bit numbers in SAFIN and S_SAFIN as the corresponding
faults in FAULT and S_FAULT. Therefore, the same constants are used for bit addressing.
The physical signal connected to a safety input may indicate a safety violation with either high or
low level. For instance on one axis, the right limit switch may indicate a safety violation with high
voltage, and the left limit switch with low voltage. Use the standard variables SAFINI and
S_SAFINI to define which level is active, thereby eliminating the need for hardware inverters.

TABLE 8-7 Safety Inputs

Bit Fault Fault Fault explanation

category

0 #RL Motor RIGHT LIMIT SWITCH

1 #LL Motor LEFT LIMIT SWITCH
9 #DRIVE Motor DRIVE ALARM – alarm signal from a drive.
28 #ES System EMERGENCY STOP – alarm signal from the
controlled plant.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-8 S a f e t y C o n t ro l

8.2.3. Summary of Safety-Related Variables

The FAULT, S_FAULT, SAFIN, S_SAFIN variables are read-only (SAFIN, S_SAFIN can be
assigned values but these apply only when the Simulator is used). The SAFINI, S_SAFINI,
FMASK, S_FMASK, FDEF, S_FDEF variables are protected and can be assigned only in
protected mode (see Section 5.10).

Name Size Access Remarks

FAULT 8 (one per Read-only MOTOR FAULTS. Each motor fault occupies one bit.
axis) Not all bits are occupied by faults. Only those bits
that correspond to motor faults are meaningful.
FDEF 8 (one per Read- FAULT DEFAULT MASK. The variable bits control
axis) write availability of the default responses to motor faults.
(protected The default value for all the bits, 1, enables the
mode) default response. If a bit is 0, the default response is
disabled.
Only those bits that correspond to motor faults are
meaningful.
FMASK 8 (one per Read- MOTOR FAULT MASK. The variable bits control
axis) write whether the controller checks for motor faults. The
Protected default value 1 causes the controller to check for
the fault associated with that bit. Only those bits
that correspond to motor faults are meaningful.
S_FAULT Scalar Read-only SYSTEM FAULTS. Each system fault and each
aggregated motor fault occupies one bit. Only those
bits that correspond to the faults are meaningful.
S_FDEF Scalar Read- SYSTEM FAULT DEFAULT MASK. The variable bits
write control availability of the default responses to
(protected system faults. The default value for all the bits, 1,
mode) enables the default response. If a bit is 0, the
default response is disabled.
S_FMASK Scalar Read- SYSTEM FAULT MASK. The variable bits control
write whether the controller checks for system faults. The
(protected default value 1 causes the controller to check for
mode) the fault associated with that bit. Only those bits
that correspond to system faults are used.
S_SAFIN Scalar Read-only SYSTEM SAFETY INPUTS. Bit #ES reads the current
(read/writ state of the Emergency Stop input. Other bits are
e for meaningless.
Simulator)
S_SAFINI Scalar Read- SYSTEM SAFETY INPUTS INVERSION. Bit #ES
write defines which value of S_SAFIN.#ES bit causes a
(protected fault. Other bits are not used.
mode)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-9

Name Size Access Remarks

SAFIN 8 (one per Read-only MOTOR SAFETY INPUTS. Each meaningful bit reads
axis) (read/writ the current value of a motor safety input. Only
e for those bits that correspond to the motor safety inputs
Simulator) are meaningful.
SAFINI 8 (one per Read- MOTOR SAFETY INPUTS INVERSION. A bit of the
axis) write variable defines which value of the corresponding
(protected SAFIN bit causes a fault.
mode)
Only those bits that correspond to the meaningful
SAFIN bits are used.

8.3. Working with Faults

8.3.1. Addressing the Fault Bits

Faults are represented as bits in the standard variables FAULT and S_FAULT.
FAULT is an integer array containing eight elements (corresponding to the number of motors),
where each element is made up of a set of bits. Each bit indicates one motor fault. Motor faults are
related to a specific motor, power amplifier, or Servo Processor. Examples include Tracking
Error, and Motor Overheat.
To address a specific motor fault bit, start with the specification of the FAULT element, followed
by the bit selection operator (dot) and then the corresponding fault literal constant.
For example:
Z_FAULT.#LL Addresses the left limit fault bit of axis Z. The bit is raised if
the Z left limit switch is activated.
T_FAULT.#DRIVE Addresses the drive fault bit of axis T. The bit is raised if the T
drive safety input is active.

S_FAULT is a scalar variable with two categories of bits:

ƒ Aggregated motor faults. Once the controller raises a bit in any element of FAULT, it
immediately raises the corresponding bit of S_FAULT. Therefore, each bit of S_FAULT is
an OR aggregate of the corresponding bits in all elements of FAULT.
ƒ System faults that are not related to any specific motor, such as Emergency Stop and Time
Overuse.
The aggregated motor fault bits occupy the same bit positions as the corresponding motor fault
bits in the FAULT variable., Use the literal constants of the Motor faults to address the
aggregated Motor fault bits.
Examples:
S_FAULT.#LL Addresses the aggregated Left Limit fault bit. The bit is
raised if the Left Limit switch of any motor is activated.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-10 S a f e t y C o n t ro l

S_FAULT.#DRIVE Addresses aggregated Drive fault bit. The bit is raised if the
Drive safety input of any motor is active.

Use the literal constants of the system faults to address the system fault bits.
Examples:
S_FAULT.#ES Addresses the Emergency Stop fault bit. The bit is raised when
the Emergency Stop safety signal is active.
S_FAULT.#PROG Addresses the Program fault bit. The bit is raised when any
program has failed due to a run-time error.

8.3.2. Querying Faults

The variables FAULT and S_FAULT are queried like any other variable (See page 4-21). The
controller reports the status of each meaningful bit.
Example:
?S_FAULT

0 OFF Right Limit

1 ON Left Limit
2 OFF Preliminary Right Limit
3 OFF Preliminary Left Limit
4 OFF Overheat
5 OFF Software Right Limit
6 OFF Software Left Limit
7 OFF Encoder Not Connected
8 OFF Encoder 2 Not Connected
9 OFF Drive Alarm
10 OFF Encoder Error
11 OFF Encoder 2 Error
12 OFF Position Error
13 OFF Critical Position Error
14 OFF Velocity Limit
15 OFF Acceleration Limit
16 OFF Overcurrent
17 OFF Servo Processor Alarm
25 OFF Program Error
26 OFF Memory Overuse

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-11

27 OFF Time Overuse

28 OFF Emergency Stop
29 OFF Servo Interrupt

The number in the left column is the bit number, followed by an ON/OFF indicator and the fault
description. In the above example all the faults are off except for the Left Limit fault of one or
more axes.
Note that the S_FAULT variable indicates that there is a motor fault, but does not specify which
motor has failed. To determine which motor has failed, query the FAULT variable, or use ?$ to
query the state of all motors.
Fault bits can be queried individually:
?S_FAULT.#LL

1
?X_FAULT.#LL , Y_FAULT.#LL

0
1
The controller answers a query of an individual bit by showing the numerical value of the bit:
either 0 or 1.

8.3.3. Using the Fault Bits in Commands: if, while, till

Using the fault variables in the condition of commands if, while, or till provides a decision
making mechanism that is based on the present state of the faults.
Examples:
if X_FAULT.#HOT OUT0.6 = 1 Activate an output (OUT6) if
X motor is overheated
if X_FAULT.#LL | X_FAULT.#RL Display a warning if any limit
disp "X limit switch" switch of X motor is active
till ^X_FAULT.#LL Wait until the X Left limit
switch is released
if S_FAULT disp "Failure" Display a warning if any fault
is active
The condition if S_FAULT is satisfied if S_FAULT is non-zero, i.e. if any bit of S_FAULT is
raised. Any fault, either system or motor, raises a bit in S_FAULT. Therefore non-zero
S_FAULT indicates that one or more faults are active.
The variables FAULT and S_FAULT display the current state of the faults. A conditional
command based on these variables uses the fault state at the instant when the command is
executed. For example, if the X left limit was activated but then released, X_FAULT.#LL is zero,
and the command if X_FAULT.#LL considers the condition unsatisfied.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-12 S a f e t y C o n t ro l

8.3.4. Creating Fault-Processing Autoroutines

To create an autoroutine that processes a fault, specify the fault bit in the autoroutine header.
Example:
on X_FAULT.#LL Start the autoroutine when an X Left Limit fault occurs

A fault-processing autoroutine can reside in any program buffer. When the buffer is compiled, the
controller checks the autoroutine condition each controller cycle. When the condition is satisfied,
the controller interrupts the program that is currently executing in the buffer that the autoroutine
resides in, and starts the autoroutine execution.
A fault-processing autoroutine can supplement or replace the default response to a fault. If the
corresponding FDEF or S_FDEF bit enables the default response, the autoroutine starts and
executes in parallel with the default response. If the corresponding FDEF or S_FDEF bit is zero,
the default response is disabled, and the autoroutine is the only controller response.

8.3.4.1. Notes On Fault Processing In Autoroutines

The controller examines all autoroutine conditions each controller cycle. However, if an
autoroutine is executing in a buffer, and a condition of the second autoroutine in the same buffer
is satisfied, the second autoroutine will start only after termination of the subroutine currently
executing. Therefore, if an application includes a time-consuming autoroutine, avoid placing
safety autoroutines that require short response time in the same buffer with the time-consuming
autoroutine.

8.3.4.2. Examples
The following autoroutine displays a message when the Drive Alarm signal becomes active for
the X motor:
1 on X_FAULT.#DRIVE

2 disp "X Drive Alarm"

3 Ret

In the following autoroutines, the X and Z motors must be disabled simultaneously. Therefore, if
one of the drives fails, the second must be disabled as well. The default response disables the X
motor if the X Drive Alarm occurs and disables Z motor if the Z Drive Alarm occurs. The
following pair of autoroutines supplements the default response, by disabling a motor if the other
motor fails:
1 on X_FAULT.#DRIVE disable Z; ret

2 on Z_FAULT.#DRIVE disable X; ret

When an X drive fault occurs, the following autoroutine terminates the controller activity for all
motors:
1 on X_FAULT.#DRIVE When X drive fault occurs

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-13

2 disableall Disable all motors

4 stopall Stop all other programs

5 stop Stop the current program

6 ret End of autoroutine

The S_FAULT variable contains the bits of the aggregated motor faults. These bits provide a
convenient alternative to the motor faults if an application requires common processing of a motor
fault irrespective of which motor caused the fault.
For example, the following autoroutine displays a message when the Left Limit switch of any
motor is activated:
1 on S_FAULT.#LL

2 disp "One of the Left Limit Switches is Activated"

3 ret

Autoroutine conditions can contain more than one fault bit, as is shown in the first line of the
example below:
1 on S_FAULT.#LL | S_FAULT.#RL

2 disp "Some Limit Switch Activated"

3 ret

The S_FAULT variable (used without a bit extension) indicates whether a fault has been detected
by the controller. The following example shows an autoroutine that provides an alarm message if
any fault occurs in the controller:
1 on S_FAULT

2 disp "Something happened"

3 ret

The controller activates an autoroutine when the condition of the autoroutine changes from false
to true. If the condition remains true the autoroutine is not activated again until the condition
becomes false, and then true again. Therefore the above autoroutine displays the alarm message
only on the first fault. If one fault bit is already raised, and another fault occurs, the second fault
does not generate an alarm message.
The following autoroutine displays a fault message each time a fault occurs:
1 int LastFault

2 on LastFault <> S_FAULT

3 if (LastFault ^ S_FAULT) & S_FAULT

4 disp "Something happened"

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-14 S a f e t y C o n t ro l

5 end

6 LastFault = S_FAULT

7 ret

In the above example the local variable LastFault stores the current value of S_FAULT (line 6).
The exclusive OR of LastFault and S_FAULT detects the bits of S_FAULT that changed. The
AND with S_FAULT retains only the bits that changed from zero to one, and not from one to
zero (line 3).

8.3.5. Disabling Fault Processing

Warning
Certain safety variables provide protection against potential serious bodily
injury and damage to equipment. Be aware of the implications before disabling
any alarm, limit or error.
The standard variables define which faults are examined and processed. If a bit of FMASK or
S_FMASK is zero, the corresponding fault is disabled and the bit of FAULT or S_FAULT is not
raised.
FMASK, and S_FMASK are queried like any other variable, and the controller reports the status
of each meaningful bit.
Example:
?X_FMASK

0 ON Right Limit
1 ON Left Limit
2 OFF Preliminary Right Limit
3 OFF Preliminary Left Limit
4 OFF Overheat
5 ON Software Right Limit
6 ON Software Left Limit
7 ON Encoder Not Connected
8 OFF Encoder 2 Not Connected
9 ON Drive Alarm
10 ON Encoder Error
11 OFF Encoder 2 Error
12 ON Position Error
13 ON Critical Position Error
14 OFF Velocity Limit

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-15

15 ON Acceleration Limit
16 ON Overcurrent
17 ON Servo Processor Alarm
?S_FMASK

25 OFF Program Error

26 ON Memory Overuse
27 ON Time Overuse
28 ON Emergency Stop
29 ON Servo Interrupt

In the above example the user disabled exceptions #RL2, #LL2, #HOT, #ENC2NC, #ENC2, and
#VL of axis X, and system exception #PROG.
Normally, the user enables or disables fault detection through the Safety Window of the SPiiPlus
MMI (See the SPiiPlus Setup Guide) when initially configuring the controller. The configured
values of FMASK and S_FMASK are then stored in nonvolatile memory and left unchanged
during the application lifetime.
Changes to safety variables after initial controller configuration may affect your application. The
following section is relevant only if you need to enable or disable faults after initial configuration.
Example:
?X_FAULT.#DRIVE , X_SAFIN.#DRIVE Display the status of the drive
alarm fault, and the safety signal
1 Drive Alarm fault bit is raised.
1 Drive Alarm safety signal is
: high.

X_FMASK.#DRIVE = 0 Disable Drive Alarm fault

:
?X_FAULT.#DRIVE , X_SAFIN.#DRIVE

0 Drive Alarm fault is now zero.

1 Drive Alarm safety signal
: remains high.

8.3.6. Defining the Active Level Of Safety Input

Safety inputs receive physical signals from various sources, such as limit switches and relays.
Each safety signal is sent in one of two forms (binary):
ƒ High voltage level, no current in the controller input circuit.
ƒ Low voltage level, outflowing current in the controller-input circuit.
By default, the high voltage level is defined as the active state of the signal, i.e. the state that
triggers a fault. This is called the normal polarity.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-16 S a f e t y C o n t ro l

By using SAFINI and S_SAFINI you can change the default, defining the low voltage level as
active for a specific safety input. The low voltage level will now trigger a fault. This is called
inverse polarity.
The standard variables SAFINI, and S_SAFINI define which level is active for each safety input.
If a bit of SAFINI or S_SAFINI is zero (default value), the corresponding input accepts the high
level as active.
Note that the bits of SAFIN, S_SAFIN reflect the physical states of the signals, while the bits of
SAFINI, S_SAFINI define the logical processing of the signals. SAFINI and S_SAFINI
variables have no effect on the physical signal, and the bits of variables SAFIN, S_SAFIN, which
display the raw values of the safety inputs are unaffected by the bits of SAFINI, S_SAFINI
The variables SAFINI, and S_SAFINI are queried like any other variable. The controller reports
the status of each meaningful bit that corresponds to a safety signal.
Example:
?X_SAFINI

0 ON Right Limit
1 ON Left Limit
2 OFF Preliminary Right Limit
3 OFF Preliminary Left Limit
4 OFF Overheat
9 OFF Drive Alarm
?S_SAFINI

28 OFF Emergency Stop

In the above example, the fact that the response to the SAFINI query shows that RL and LL are
ON (lines 0 and 1) indicates that the user has defined inverse polarity (low active level) for
signals #RL, #LL of axis X.
Normally, the user defines signal polarity through the Safety Window of the SPiiPlus MMI (See
the SPiiPlus Setup Guide) when initially configuring the controller. The configured values of
SAFINI and S_SAFINI are then stored in the nonvolatile memory and are not changed during the
application’s lifetime.
Example:
?X_FAULT.#LL , X_SAFIN.#LL Display the status of left limit and the left
limit safety signal
1 Left Limit fault bit is raised.
1 Left Limit safety signal is high.
:
X_SAFINI.#LL = 1 Set inverse polarity
:
?X_FAULT.#LL , X_SAFIN.#LL

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-17

0 Left Limit fault bit changes to zero.

1 Left Limit safety signal remains high.
:

8.3.7. Fault Processing Modes

The controller defines two modes of behavior after a failure: regular mode and strict mode.
Bit #FCLEAR of the S_FLAGS variable selects the fault processing mode:
if S_FLAGS.#FCLEAR = 0 (default) the controller is in regular mode,
if S_FLAGS.#FCLEAR = 1 the controller is in strict mode.
The difference between the modes manifests when a fault occurs that kills a motor:
• In regular mode the next motion command simply clears the reason for the previous kill for
all involved motors and starts the new motion.
• In strict mode the next motion command cannot activate the motion and fails. The motion
cannot be activated as long as the reason for the previous kill is non-zero for any involved
motor.
The reason for a kill operation is stored in the MERR variable. In strict mode as long as a MERR
element is non-zero the corresponding motor cannot be put in motion. Commands enable and
fclear clear the MERR elements for the specified motors and enable the next motion.
The same rules apply to the result of a kill command with non-zero second argument (reason).
The reason is stored in the MERR element and in strict mode the next motion cannot be activated
until the reason is cleared.
In regular mode the behavior is simple and totally compatible with previous versions. However,
you may prefer the strict mode, especially for development time. The following example gives a
hint why the strict mode may be preferable:
Consider the following program fragment that executes a simple reciprocated motion:
Reciprocated:

ptp/r X,10000

ptp/r X,-10000

goto Reciprocated

In normal case the motor infinitely moves forward and back by 10000 units.
Assume, however, that the first motion brings the motor to the right limit switch. The first motion
terminates prematurely, because the motor is killed. However, the program continues running and
executes the second motion command. In regular mode the second motion starts successfully,
because it is directed out of the limit. Then the first motion command again brings the motor to
the limit. Therefore, in regular mode the reciprocated motion continues and there is no clear
indication of abnormal condition.
Assume further, for the same application, that a broken connection to the right limit switch causes
the controller to mistakenly continuously detect that the right limit has been passed. The first

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-18 S a f e t y C o n t ro l

motion fails immediately after start, but the second one executes. The result is that the motors
moves in negative direction by steps of 10000 units.
In strict mode, the behavior is more predictable. After the first motion failed, the second one
cannot start and the program itself terminates with error. The user can check the information in
MERR and PERR to disclose the reason for the failure.
If at any point of application a fault is an expected condition and the program must continue, the
program in strict mode must analyze the MERR element and execute the fclear command before
activating the next motion.

8.4. Detailed Description Of Faults

This section provides a detailed description of each fault, including a description of the bits
involved, the default response, and examples of autoroutines.

8.4.1. Limit Switches: #LL, #RL

The exact usage of limit switches depends on the application. A specific axis may require only
one pair of limit switches or no limit switches at all. The following diagram illustrates a typical
use of two pairs of limit switches:

LEFT HARD WORK AREA RIGHT HARD

= Hazardous Area

= Prohibited Area

=Preliminary Limit Switch

=Limit Switch

FIGURE 8-1 The use of limit switches

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-19

Fault bits FAULT.#LL, FAULT.#RL (in each element of

FAULT)

Mask bits FMASK.#LL, FMASK.#RL (in each element of

FMASK)

Based upon safety signals SAFIN.#LL, SAFIN.#RL (in each element of

SAFIN)

Inversion bits SAFINI.#LL, SAFINI.#RL (in each element of

SAFINI)

Internal safety condition None

Default response bits FDEF.#LL, FDEF.#RL (in each element of FDEF)

Default response The controller kills the violating motor.

As long as the fault is active, the controller kills any
motion that tries to move the motor in the direction
of the limit. Motion to return to the allowed range of
motion is allowed.
Autoroutine examples:
The first example supplements the default processing of X limit faults with alarm messages:
1 on X_FAULT.#LL When a left limit fault occurs in
motor X
2 disp "X Left Limit switch activated" Display the message: X Left Limit
switch activated
3 ret

4 on X_FAULT.#RL When a right limit fault occurs in

motor X
5 disp "X Right Limit switch activated" Display the message: X Right
Limit switch activated
6 ret

The example below implements an autoroutine that disables the motor rather than the default
response of killing the motion, in case of a right limit or left limit fault. This response may be
superior to the default response if the motor is equipped with a brake that is activated by the
disable command, because the brake may stop the motor faster than a kill command.
1 on Z_FAULT.#RL | Z_FAULT.#LL. When there is a right limit or left limit fault in
motor Z
2 disable Z Disable motor Z

3 ret

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-20 S a f e t y C o n t ro l

8.4.3. Software limit switches: #SLL, #SRL

Fault bits FAULT.#SLL, FAULT.#SRL (in each
element of FAULT)

Mask bits FMASK.#SLL, FMASK.#SRL (in each

element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition See explanation below.

Default response bits FDEF.#SLL, FDEF.#SRL (in each element

of FDEF)

Default response The controller kills the violating motor. As

long as the fault is active, the controller kills
any motion that tries to move the motor in the
direction of the limit. Motion in the direction
out of the limit is allowed.

Software limit switches use the following standard variables:

SLLIMIT Software Left Limit (Lower limit of working area)
SRLIMIT Software Right Limit (Upper limit of working area)

The condition for software limit switches is based on the motor reference RPOS, not the motor
feedback FPOS. Therefore, the fault provides protection against errors in the ACSPL+
application, not against hardware malfunctions.
The controller monitors the reference position RPOS and reference velocity RVEL and
implements the following verifications:
• If RPOS < SLLIMIT, the controller detects #SLL fault.
• If RPOS > SRLIMIT, the controller detects #SRL fault.
• If RPOS is within the range and RVEL is non-zero, the controller calculates the distance
required to decelerate RVEL to zero using KDEC deceleration. If the final point of the
calculated deceleration process < SLLIMIT, the controller detects #SLL fault. If the final
point of the calculated deceleration process > SRLIMIT, the controller detects an #SRL
fault.
This logic provides the moving edge of the software limit fault, depending on the instant velocity.
As the controller kills the motor when the fault is detected, the termination point of the kill
process will be very close to the corresponding software limit point.
The termination point is not exactly the software limit point because the controller checks the
condition every controller cycle, i.e., at discrete time points. The termination point complies with
the following conditions:
• The termination point lies beyond the corresponding software limit.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-21

• Overrun is not more than 2*Vel*Cycle,

where Vel is an instant velocity and Cycle is the controller cycle.
For example, if the X_FAULT.#SRL fault is detected, the requested velocity of X axis is 10000
count/sec and the controller cycle is 1 msec. the controller will overrun the software right limit for
not more than 2*10000*0.001 = 20 counts.
Autoroutine examples
The following autoroutines supplement the default processing of X software limit faults with an
alarm messages:
1 on X_FAULT.#SLL

2 disp "X Software Left Limit violated"

3 ret

4 on X_FAULT.#SRL

5 disp "X Software Right Limit violated"

6 ret

8.4.4. Position Error: #PE

Fault bits FAULT.#PE (in each element of FAULT)

Mask bits FMASK.#PE (in each element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition See remarks below

Default response bits FDEF.#PE (in each element of FDEF)

Default response None

Use the #PE fault to detect non-critical violation of position accuracy, and the #CPE (See 8.4.5)
fault to detect uncontrolled, excessive error that indicates loss of control.
The following standard variables are associated with position errors:
ERRI Maximum position error while the motor is idle (not moving)
ERRV Maximum position error while the motor is moving with constant
velocity
ERRA Maximum position error while the motor is accelerating or
decelerating
DELI Delay on transition from ERRA to ERRI
DELV Delay on transition from ERRA to ERRV

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-22 S a f e t y C o n t ro l

The controller raises the FAULT.#PE bit if the position error exceeds the maximum specified
value, which is equal to ERRI, ERRV or ERRA depending on the motion state.
The variables DELI and DELV are used in a similar manner with the #CPE fault (page 8-23).
The following diagram illustrates the use of these variables for a typical motion profile that
includes acceleration, constant velocity and deceleration:

V
PE > ERRI PE > ERRA PE > ERRV PE > ERRA PE > ERRI

DELV DELI

FIGURE 8-2 Example of the use of variables in a typical motion profile

The allowed position error limit is:
ERRI if the motor is idle
ERRV if the motor is moving with constant velocity
ERRA if the motor is accelerating or decelerating
DELV defines delay on transition from ERRA to ERRV.
DELI defines delay on transition from ERRA to ERRI.
Autoroutine examples:
The following autoroutine supplements the default response to a position error with an alarm
message.
1 on Y_FAULT.#PE

2 disp "Accuracy violation – the motion was killed"

3 ret

The next example corrects the motion conditions by reducing the velocity (Y_VEL) until the
error returns to within limits, instead of killing the motion.

1 on Y_FAULT.#PE When there is a position error fault

in motor Y

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-23

2 while Y_FAULT.#PE As long as there is a position error

2 imm Y_VEL = 0.9 * Y_VEL Reduce the velocity of motor Y by

10%.

3 wait 10 Delay.

2 end

3 ret

The controller automatically provides a smooth transition to the new velocity.

An application that incorporates the above autoroutine must satisfy the following conditions:
ƒ All motions of Y axis are single-axis, or Y is a leading axis in a group. If another axis is
leading, all motions will use the velocity of that axis, and the command Y_VEL = … will
have no effect.
ƒ All motions of the Y axis use the default velocity Y_VEL and do not specify individual
velocity.
ƒ The specific error monitored is the position error only while the motor is moving with
constant velocity. To avoid the fault while the motor is idle or moves with acceleration, the
user must initialize the variables Y_ERRI and Y_ERRA to sufficiently large values.
ƒ The above autoroutine executes an undefined number of loops with delays in each loop.
Therefore, the execution time may be significant. As long as the autoroutine executes, no
other autoroutine in the same buffer can be activated. Do not place this autoroutine in the
same buffer that contains any time-critical autoroutine.

8.4.5. Critical Position Error: #CPE

Fault bits FAULT.#CPE (in each element of FAULT)

Mask bits FMASK.#CPE (in each element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition See explanation below

Default response bits FDEF.#CPE (in each element of FDEF)

Default response The controller disables the violating motor.

Use #PE fault to detect non-critical violations of position accuracy, and the #CPE fault to detect
uncontrolled, excessive error that indicates loss of control. #CPE should be greater than #PE.
The following standard variables are associated with critical position error :
CERRI Critical position error if the motor is idle (not moving)
CERRV Critical position error if the motor is moving with constant velocity

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-24 S a f e t y C o n t ro l

CERRA Critical position error if the motor is accelerating or decelerating

DELI Delay on transition from CERRA to CERRI
DELV Delay on transition from CERRA to CERRV

The variables DELI and DELV are used also in the condition for the #PE fault.
The controller raises the fault bit if the position error exceeds the critical value. The critical value
is equal to CERRI, CERRV or CERRA depending on the motion stage. The following diagram
illustrates the use of these variables for a typical motion profile that includes acceleration,
constant velocity and deceleration:

V
CPE > CERRI CPE > CERRA CPE > CERRV CPE > CERRA CPE > CERRI

DELV DELI

The Critical limit for position error is:

ƒ CERRI if the motor is idle
ƒ CERRV if the motor is moving with constant velocity
ƒ CERRA if the motor is accelerating or decelerating.
ƒ DELV defines delay on transition from CERRA to CERRV.
ƒ DELI defines delay on transition from CERRA to CERRI.
A #CPE fault implies a serious problem in motor control. Do not disable the default response
unless it is absolutely necessary in your application, i.e. keep FDEF.#CPE = 1.
Autoroutine examples
The following autoroutine supplements the default response with an alarm message:
1 on T_FAULT.#CPE

2 disp "T axis shows abnormal error. The motor was disabled."

3 ret

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-25

8.4.6. Encoder Error: #ENC, #ENC2

Fault bits FAULT.#ENC, FAULT.#ENC2 (in each
element of FAULT)

Mask bits FMASK.#ENC, FMASK.#ENC2 (in each

element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition The controller latches fault #ENC if the

phase shift between the signals of the primary
encoder is lost, indicating a faulty encoder or
noisy environment.
The controller latches fault #ENC2 if the
phase shift between the signals of the
secondary encoder is lost, indicating a faulty
encoder or noisy environment.

Default response bits FDEF.#ENC, FDEF.#ENC2 (in each

element of FDEF)

Default response The controller disables the violating motor.

The faults remain active until the user
resolves the problems and enables the motor
again or executes the fclear command.

Unlike most faults, #ENC and #ENC2 faults are latched. The fault bits remain raised even after
the cause of the fault has been eliminated. Only the next enable command resets the fault bits.
Occurrence of #ENC fault indicates a serious problem in motor control. Do not disable the default
response unless it is absolutely necessary in your application, i.e. keep FDEF.#CPE = 1.
Autoroutine examples
The following autoroutine supplements the default response with an alarm message:
1 on Z_FAULT.#ENC

2 disp "Encoder Error in Z axis. The motor was disabled."

3 ret

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-26 S a f e t y C o n t ro l

8.4.7. Encoder Not Connected: #ENCNC, #ENC2NC

Fault bits FAULT.#ENCNC, FAULT.#ENC2NC (in each
element of FAULT)

Mask bits FMASK.#ENCNC, FMASK.#ENC2NC (in each

element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition The controller raises fault bit #ENCNC if a primary
encoder is not connected. The controller raises fault bit
#ENC2NC if a secondary encoder is not connected.

Default response bits FDEF.#ENCNC, FDEF.#ENC2NC (in each element of

FDEF)

Default response The controller disables the violating motor.

If the controller detects a pair of differential encoder inputs that are not in opposite states (high
and low level), it raises the fault, because this may indicate a problem such as a short circuit or
unconnected wire.
An #ENCNC fault indicates a serious problem in motor control. Do not disable the default
response unless it is absolutely necessary in your application, i.e. keep FDEF.#CPE = 1.
Autoroutine examples
The following autoroutine supplements the default response with an alarm message:
1 on X_FAULT.#ENCNC

2 disp "X axis: Encoder Not Connected. The motor was disabled."

3 Ret

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-27

8.4.8. Drive Alarm: #DRIVE

Fault bits FAULT.#DRIVE (in each element of FAULT)

Mask bits FMASK.#DRIVE (in each element of FMASK)

Based upon safety signals SAFIN.#DRIVE (in each element of SAFIN)

Inversion bits SAFINI.#DRIVE (in each element of SAFINI)

Internal safety condition The controller never sets the fault bit while the
motor is disabled. The controller starts monitoring
the fault condition when the period of time defined
by variable ENTIME elapses after the motor has
been enabled.

Default response bits FDEF.#DRIVE (in each element of FDEF)

Default response The controller disables the violating motor.

The condition involves the following standard variable:

ENTIME Motor’s enable time in milliseconds

Even if the SAFIN.#DRIVE bit is in an active state, the controller never raises the fault bit while
the motor is disabled. When the enable command is executed, the controller waits for the period
of time defined by variable ENTIME, and only then starts monitoring the SAFIN.#DRIVE bit. If
the Drive Alarm signal is still active at that time, the fault condition is satisfied.

The controller continues monitoring the fault condition until the motor is disabled by a disable
command or a fault that disables the motor.
Occurrence of #DRIVE fault indicates a serious problem in the motor control. Do not disable the
default response unless it is absolutely necessary in your application, i.e. keep FDEF.#CPE = 1.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-28 S a f e t y C o n t ro l

Integrated module controllers (SPiiPlus PCI-DDM4A) provide

MODEL extended information about the cause of a drive alarm.
DEPENDENT
When a drive alarm occurs, the user can retrieve the reason for the
fault using the getconf function (see section 5.7.6.3) or the MERR
(see page 11-43) variable.
Autoroutine example for SPiiPlus PCI-DDM4A
1 on Z_FAULT.#DRIVE

2 reason = getconf (13, 0)& 0x0F

3 if reason = 1

4 disp “Drive Alarm: Short circuit”

5 elseif reason = 2

6 disp “Drive Alarm: External protection activated

7 end

8 ret

General autoroutine example

The following autoroutine supplements the default response with an alarm message:
1 on Z_FAULT.#DRIVE

2 disp "Z Drive Alarm. The motor was disabled"

3 ret

8.4.10. Velocity Limit: #VL

Fault bits FAULT.#VL (in each element of FAULT)

Mask bits FMASK.#VL (in each element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition if abs(RVEL) > XVEL raise FAULT.#VL

Default response bits FDEF.#VL (in each element of FDEF)

Default response The controller kills the violating motor.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-29

Velocity limit uses the following standard variable:

XVEL Maximum allowed velocity for each motor

#VL uses the motor reference velocity RVEL, not the motor feedback velocity FVEL. Therefore,
the fault bit is raised if an application command calls for excessive velocity, even if the motor has
not reached this velocity. The fault can also be used for program testing without physical motion,
while motors are disabled.
Autoroutine examples
The autoroutine informs the user about the violation.
1 on Z_FAULT.#VL

2 disp "Z Velocity limit was exceeded"

3 ret

8.4.11. Acceleration Limit: #AL

Fault bits FAULT.#AL (in each element of FAULT)

Mask bits FMASK.#AL (in each element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition if abs(RACC) > XACC raise FAULT.#AL

Default response bits FDEF.#AL (in each element of FDEF)

Default response The controller kills the violating motor.

Acceleration limit uses the following standard variable:

XACC Maximum allowed acceleration for each motor

#AL uses the motor reference acceleration RACC, not the motor feedback acceleration FACC.
Therefore, the fault bit is raised if an application command calls for excessive acceleration, even
if the motor has not reached this acceleration. The fault also can be used for a program testing
without motion, while motors are disabled.
Autoroutine examples
The following autoroutine supplements the default response with an alarm message:
1 on X_FAULT.#AL

2 disp "X Acceleration limit exceeded. The motor was disabled."

3 ret

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-30 S a f e t y C o n t ro l

8.4.12. Current Limit: #CL

Fault bits FAULT.#CL (in each element of FAULT)

Mask bits FMASK.#CL (in each element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition if RMS current > XRMS raise FAULT.#CL

Default response bits FDEF.#CL (in each element of FDEF)

Default response The controller kills the violating motor.

The current limit fault is based upon the Servo Processor algorithm that calculates the RMS value
of the motor current. When the calculated RMS current exceeds the allowed value the Servo
Processor reports an error that the MPU translates into a current limit fault.
Current limit processing uses the following variables:
XRMS Maximum allowed RMS current for each motor
XCURI Maximum instantaneous current if the motor is idle (not
moving)
XCURV Maximum instantaneous current if the motor is moving
To configure the specified variables use the Configurator in SPiiPlus MMI.
Autoroutine examples
The following autoroutine kills the motion (and displays an alarm message) instead of the motor.
(The default response can be disabled by adding FDEF.#CL = 0 to the ACSPL+ program).
1 on Y_FAULT.#CL

2 kill Y

3 disp "RMS current limit exceeded"

4 ret

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-31

8.4.13. Servo Processor Alarm: #SP

Fault bits FAULT.#SP (in each element of FAULT)

Mask bits FMASK.#SP (in each element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition If the Servo Processor lost synchronization

with MPU, raise FAULT.#SP

Default response bits FDEF.#SP (in each element of FDEF)

Default response The controller disables all motors

#SP indicates that communication between the MPU and one of the servo processors failed.
Occurrence of the #SP fault indicates a serious hardware problem.
Do not disable the default response unless it is absolutely necessary in your application, i.e. keep
FDEF.#SP = 1.
This fault may be caused by a problem in the SP program. If SP program hangs, the fault remains
permanent. If the SP program time exceeds the tick time (50 microseconds), the fault is
intermittent.
The disable reason reported by the controller is 5027 'Servo Processor Alarm'.
Autoroutine examples
The following autoroutine supplements the default response with an alarm message:
1 on Y_FAULT.#SP

2 disp "Y Servo Processor Alarm"

3 ret

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-32 S a f e t y C o n t ro l

8.4.14. HSSI Not Connected: #HSSINC

Fault bits FAULT.#HSSINC(in each element of FAULT)

Mask bits FMASK.#HSSINC (in each element of FMASK)

Based upon safety signal None

Inversion bits None

Internal safety condition The controller raises fault bit #HSSINC if HSSI is not
connected.

Default response bits FDEF.#HSSINC (in each element of FDEF)

Default response None

See also high-speed synchronous serial interface (HSSI), page 9-7.

The following autoroutine displays an alarm message:
1 on X_FAULT.#HSSINC

2 disp "X axis: HSSI not connected."

3 Ret

8.4.15. Emergency Stop: #ES

Fault bit S_FAULT.#ES

Mask bit S_FMASK.#ES

Based upon safety signal S_SAFIN.#ES

Inversion bit S_SAFINI.#ES

Internal safety condition None

Default response bit S_FDEF.#ES

Default response The controller disables all motors.

Autoroutine example:
The following autoroutine kills all motions but does not disable the motors (this assumes that the
default response has been disabled by S_FDEF.#ES = 0).
1 on S_FAULT.#ES

2 killall

3 ret

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-33

8.4.16. Program Error: #PROG

Fault bit S_FAULT.#PROG

Mask bit S_FMASK.#PROG

Based upon safety signal None

Inversion bit None

Internal safety condition The controller latches the fault when any
ACSPL+ program encounters a run-time
error.

Default response bit S_FDEF.#PROG

Default response The controller kills all executed motions.

Unlike most faults, the #PROG fault is latched. Once raised, the bit remains raised until the
controller resets it on execution of any command that compiles or starts a program in any buffer.
Autoroutine examples
The following autoroutine supplements the controller's default response, terminating all
concurrent programs and displaying an alarm message.
1 on S_FAULT.#PROG

2 stopall

3 disp "Run-time error"

4 ret

Note that a run time error in a buffer stops all activity in the buffer. Therefore, the above
autoroutine cannot intercept an error that occurred in the buffer where the autoroutine is located.
However, it intercepts an error in any other buffer.
This autoroutine can supplement the default response (S_FDEF.#PROG = 1) or can replace it
(S_FDEF.#PROG = 0).
The following autoroutine does the same (stops all programs) and also provides a diagnostic
message:
1 on S_FAULT.#PROG

2 stopall

3 I0 = 0

4 loop 10

5 if PERR(I0) >= 3020

6 disp "Program ", I0, " failed. Error ", PERR(I0)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-34 S a f e t y C o n t ro l

7 end

8 end

9 ret

The standard variable PERR contains the termination codes of the ACSPL+ programs. Each
element of PERR contains termination code for a different buffer. At power-up all elements of
PERR are reset to 0. When a program in any buffer finishes or terminates for any reason, the
corresponding element of PERR is assigned with a code that specifies the termination reason. The
element resets to zero again once the corresponding buffer is compiled or program execution
starts.
Termination codes from 3000 to 3020 indicate normal termination. Codes greater than or equal to
3020 indicate run-time errors (see page 12-2).

8.4.17. Memory Overflow: #MEM

Fault bit S_FAULT.#MEM

Mask bit S_FMASK.#MEM

Based upon safety signal None

Inversion bit None

Internal safety condition The controller latches the fault bit when the
user application requires more memory than
is available in the controller.

Default response bit S_FDEF.#MEM

Default response The controller kills all motors.

Unlike most faults, the #MEM fault is latched. Once raised, the bit remains raised until the
controller resets it on execution of any command that compiles or starts a program in any buffer.
Because the controller uses dynamic memory handling, the amount of the memory available for a
specific user application cannot be exactly determined. If an application shows the fault, the user
needs to reduce the size of application or to add memory.
The following recommendations may be useful in eliminating the error:
ƒ Reduce the length of ACSPL+ programs.
ƒ Reduce the volume of user local and global variables. Pay special attention to arrays.
ƒ Limit the length of commands that are sent to the controller. Do not use commands that
exceed 2032 characters.
ƒ Simplify the formulae used with the connect and master commands.
Autoroutine examples
The following autoroutine terminates all executing programs and displays an error message when
the fault occurs:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-35

1 on S_FAULT.#MEM

2 stopall

3 disp "Memory overflow"

4 ret

This autoroutine can supplement the default response (S_FDEF.#PROG = 1) or can replace it
(S_FDEF.#PROG = 0).

8.4.18. Time Overuse: #TIME

Fault bit S_FAULT.#TIME

Mask bit S_FMASK.#TIME

Based upon safety signal None

Inversion bit None

Internal safety condition The user application demands too much

processing time.

Default response bit S_FDEF.#TIME

Default response None

The controller raises the fault bit when the user application consumes too much processing time
and S_FMASK.#TIME bit is raised.
The structure of the controller’s real-time cycle is discussed in Chapter 3: SPiiPlus .
As the real-time processing time varies between cycles, the fault may occasionally occur and
requires no special attention. However, frequent or permanent occurrence of the fault requires
measures to correct the situation.
The controller has no default response to the fault. To monitor this fault, you must define your
own autoroutine.
The following recommendations may be useful in reducing real time processing time, thereby
eliminating the fault:
ƒ Reduce the number of concurrently executed programs.
ƒ Reduce the program execution rates (parameters PRATE, ONRATE).
ƒ Reduce the number of command specified in one program line.
ƒ Reduce the number of autoroutines.
ƒ Simplify the conditions in autoroutine headers.
ƒ Reduce the number of concurrently executed motions.
ƒ Avoid short-time motions.
ƒ Use segmented motion instead of a series of short PTP motions.
ƒ Simplify the formulae used in the connect and master commands.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-36 S a f e t y C o n t ro l

Autoroutine example:
The following autoroutine accumulates statistics on the fault. The autoroutine measures a time of
1000 fault occurrences and then displays the average time between faults. The autoroutine relies
on zero initialization of the local variables.
1 Local int N Declare local variable for
counting the number of
faults

2 Local real ATIME Declare local variable that

will show the time of 1000
faults

3 on S_FAULT.#TIME Activate autoroutine when

the TIME fault occurs

4 N = N + 1 Increment the number of

faults

5 If N >= 1000 If 1000 faults were

accumulated…

6 disp "#TIME occurs once per ", (TIME – Display average time
ATIME) / N, " ms" between faults

7 ATIME = TIME Prepare for the next

accumulation

8 N = 0 Zero to prepare for the next

accumulation

9 end

10 ret

8.4.19. Servo Interrupt: #INT

Fault bit S_FAULT.#INT
Mask bit S_FMASK.#INT
Based upon safety signal None
Inversion bit None
Internal safety condition The controller raises the fault bit when the
servo interrupt is not generated or is irregular
Default response bit S_FDEF.#INT
Default response The controller disables all motors.

The fault indicates a serious failure. Do not disable the default response unless it is absolutely
necessary in your application., i.e., keep FDEF.#INT = 1

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-37

The MPU sets the fault 'Servo Interrupt' if the 1ms interrupt is not received. The probably cause is
a hardware problem.
The controller response to the fault is to disable all motors. The disable reason reported by the
controller is 5029 'Servo Interrupt'.
Autoroutine examples
The following autoroutine supplements the default response with termination of all ACSPL+
programs and an alarm message:
1 on S_FAULT.#INT

2 stopall

3 disp "Main interrupt is missing"

4 ret

8.5. Detailed Description of Fault Processing

This section explains the details of safety control implementation in the controller software. Read
this section if you want a deeper understanding of how the controller analyzes safety inputs,
examines safety conditions and processes faults.
Note
The SAFIN and S_SAFIN variables are normally read-only. However,
they can be written to when working with the Simulator, to simulate
safety inputs.

The upper part of the diagram shows how motor faults are examined. The list of faults is identical
for each motor and the controller repeats the process for each motor. The end product is the
variable FAULT.
The lower part of the diagram shows the elements that go into constructing the S_FAULT
variable. Part of its bits are set as the OR-aggregate of the FAULT elements, and other bits are
determined by examining the system faults.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-38 S a f e t y C o n t ro l

8.5.1. Examining Fault Conditions - Flow Chart

FIGURE 8-3 illustrates how the controller examines fault conditions:

Axis Safety Inputs

X axis
Variable SAFINI Variable SAFIN

Internal Safety
Conditions
XOR

Variable FMASK

AND

Variable FAULT

System Safety Inputs

OR

Variable S_SAFIN Variable S_SAFINI

Internal Safety
Conditions XOR
Variable S_FMASK

AND

Variable S_FAULT

FIGURE 8-3 Fault examination flow chart

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-39

8.5.2. Examining Motor Fault Conditions

The controller monitors motor fault conditions each controller cycle for each axis. There are two
sources of motor faults:
ƒ Motor safety inputs
ƒ Internal safety conditions
The controller samples motor safety inputs each controller cycle and stores the values in the
SAFIN variable. High voltage of a signal is stored as one in the corresponding bit of SAFIN.
Low voltage is stored as zero. Only the following bits of SAFIN are meaningful:
#LL Left Limit
#RL Right Limit
#LL2 Preliminary Left Limit
#RL2 Preliminary Right Limit
#HOT Overheat
#DRIVE Drive Fault
For example the command:
if X_SAFIN.#DRIVE V0 = 1 else V0 = -1 end

assigns a value of one to variable V0 if the Drive Alarm signal of the X motor is high and minus
one if low.
The configuration variable SAFINI defines which level of motor safety input causes a fault. In
the above diagram XOR is a bit-wise operation. Therefore, if a bit of SAFINI is zero, high
voltage of the corresponding signal causes fault. If a bit of SAFINI is one, low voltage causes
fault. Only those bits of SAFINI that correspond to the meaningful bits of SAFIN are used in
fault processing. Other bits have no effect.
In addition to the safety inputs, the controller examines a number of internal safety conditions for
each motor each controller cycle. The faults caused by the motor safety inputs and the faults
detected by internal conditions provide a set of motor faults.
A detected motor fault is stored in a bit of variable FAULT only if the corresponding bit of
variable FMASK is one. If a bit of FMASK is zero, the controller does not raise the
corresponding fault bit even if the fault condition or safety input is true. If a bit of FMASK is set
to one, the corresponding bit of FAULT is immediately set when the fault occurs. The bit rises to
one or drops to zero in the same controller cycle as the corresponding safety input or internal
safety condition shows change in the fault state.
Only those bits of FAULT that correspond to the motor faults are meaningful.
When a bit is raised, it activates the default response to the fault. An autoroutine that processes
the fault must use the bit of FAULT in the header condition.

8.5.3. Examining System Fault Conditions

System safety inputs and internal system safety conditions are monitored similarly to motor fault
conditions.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

8-40 S a f e t y C o n t ro l

There are three sources of S_FAULT bits:

ƒ Aggregated motor faults
ƒ System safety inputs
ƒ Internal system safety conditions
Aggregated motor faults are implemented as a combination of motor faults for all axes. For
example, if bit Y_FAULT.#LL is one, bit S_FAULT.#LL also rises to one. Bit S_FAULT.#LL
drops to zero only if bits #LL in all FAULTs for all motors are zero. Each meaningful bit of
FAULT has its counterpart in S_FAULT.
Emergency Stop is the only system safety input. The controller samples the input each controller
cycle and stores the value in the S_SAFIN variable. Therefore, only one bit, S_SAFIN.#ES, is
meaningful. High voltage of the signal is stored as one in the bit, low voltage is stored as zero. An
application uses S_SAFIN if a raw immediate value of Emergency Stop input is required.
The configuration variable S_SAFINI defines which level of Emergency Stop input causes a
fault. In the above diagram XOR is a bit-wise operation. Therefore, if bit S_SAFINI.#ES is zero,
high voltage of Emergency Stop causes a fault. If bit S_SAFINI.#ES is one, low voltage causes
fault. Only one bit of S_SAFINI is used in fault processing. Other bits have no effect.
Each controller cycle the controller examines a number of internal system safety conditions. The
aggregated motor faults, the Emergency Stop fault and the faults detected by internal conditions
provide a set of system faults.
A system fault is stored in a bit of variable S_FAULT only if the corresponding bit of variable
S_FMASK is one. If a bit of S_FMASK is zero, the controller does not raises the corresponding
S_FAULT bit even if the fault is detected. If a bit of S_FMASK is one, the corresponding bit of
S_FAULT follows the current state of the fault. The bit rises to one or drops to zero in the same
controller cycle as the corresponding fault changes its state.
Only those bits of S_FAULT that correspond to the aggregated motor faults and to the system
faults are meaningful.
When a bit of S_FAULT is raised, it activates the default response to the fault. A user's
autoroutine that processes the fault must use the bit of S_FAULT in the header condition.

8.6. Extended Fault Configuration

WARNING The controller's default safety configuration and responses fit the
needs of most applications.
Only an experienced user should make modifications to the safety
configuration. Improper configuration may result in unsafe
operation, may damage the equipment, and may be dangerous.

As mentioned earlier in this chapter, the controller response to a fault can be modified with the
standard variables FDEF/S_FDEF and with autoroutines.
The terminal command #SC reports the current safety system configuration. See page 4-22.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S a f e t y C o n t ro l 8-41

There are several other options for safety system configuration:

Safety groups. Two or more axes can be combined in a safety group. All axes belonging to the
safety group respond to any fault synchronously. If a fault affects one axis in the group, it
immediately affects all the other axes in the group. See safetygroup command.
Kill-disable response. In response to a fault, the controller executes kill, decelerates the motor to
zero velocity, and then disables the motor. See safetyconf command.
Changing response without autoroutine. An axis can respond to a fault in one of the following
basic ways:
- No response
- Kill response
- Disable response
- Kill-disable response
For each type of fault, the controller defines a default response, which can be overridden with an
autoroutine. The safetyconf command switches an axis between the four basic fault responses. An
autoroutine is only required if the desired response is not one of the these. See safetyconf
command.
Fault generalization. The fault response for a specific fault and a specific axis can be generalized
to affect all the axes. For example, by default the X Drive Alarm fault disables motor X, but has
no effect on motor Y or any other motor. However, if the user generalizes the Drive Alarm fault
for axis Y, the Y motor will be affected by a Drive Alarm fault on any axis. See safetyconf
command.
Specific motor configuration. The default configuration for all axes is identical. For example,
the default response to a Limit Switch fault is to kill motion. However, the response can be
modified individually for each motor. For example, if a Limit Switch fault occurs, the X motor
can be killed while the Y motor is disabled. See safetyconf command.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 In p ut s a n d O u t p ut s 9-1

9. INPUTS AND OUTPUTS

For digital I/O specifications, refer to the controller's Hardware Guide.

See also the list of I/O related parameters, page 11-4.

9.1. Digital I/O

In addition to general purpose output functionality, SPiiPlus controllers support PEG and
mechanical braking. In some controller models, these functions are implemented via the digital
outputs. In other models they are implemented via dedicated outputs. Refer to the controller's
hardware guide for model-specific programming information about these features and refer to this
guide for detailed information that is common to all models.
PEG, position event generation (page 7-6), creates events based on comparing the actual encoder
position with a set of predefined values.
Mechanical Braking, page 7-21 engages or releases a brake.
In addition to general purpose input functionality, SPiiPlus controllers provide Registration Mark
Movement (page 6-7): dedicated inputs that latch the current encoder position (save the position
to a register).

9.1.1. General
A digital input is a pin in the controller connector that accepts a binary signal, in the form of low
or high voltage from an external source such as a switch or a relay. A digital output is a pin in the
controller connector that provides a binary signal to an external acceptor such as an LED or
actuator.
The controller provides a set of general-purpose inputs and outputs that have no predefined
function. You can assign a function to any input/output as required by your application.
The exact number of digital inputs and outputs depends on the controller configuration.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

9-2 I np u t s a n d O ut p u t s

For example, the basic I/O configuration of the SPiiPlus PCI-8 controller is:
• 8 digital inputs (5Vdc) for general purpose or position capture (Mark).
• 8 digital outputs (5Vdc) for general purpose or PEG
• 4 digital outputs (5Vdc) for general purpose or additional PEG states
• 16 analog outputs +/-10Vdc for general purpose or drive command
• 16 analog inputs +/-1.25Vdc for general purpose or SIN COS encoder feedback

9.1.2. I/O Designation

Before they can be addressed, inputs and outputs must first be designated in terms of whether they
are input or output, to which port they belong, and which bit within the port. After designation,
I/Os may be used as variables, queried, used as operands in expressions, assigned (outputs only),
used in autoroutines, and implemented through Programmable Logical Controller (PLC)
Programs. The following rules and definitions apply when designating I/O:

9.1.2.1. Input Designation

The controller's digital input ports are numbered from 0 to N, where N = number of ports - (see
the controller's Hardware Guide). Each port is divided into 32 bits that are numbered from 0 to
31.
Input designation starts with the letters IN, followed by the port number and bit number separated
by a dot. For example:
IN0.1 – input 1 of port 0
IN3.19 – input 19 of port 3
If the controller provides only 32 inputs or less, all inputs are located in port zero. In this case the
port number can be omitted, and input is referred as IN0, IN22, etc.

9.1.2.2. Output Designation

Output designation is similar to input designation.
The controller's digital input ports are numbered from 0 to N, where N = number of ports - (see
the controller's Hardware Guide). Each a port is divided into 32 bits that are numbered from 0 to
31.
Output designation starts with the letters OUT, followed by the port number and bit number
separated by a dot. For example:
OUT0.5 – output 5 of port zero
OUT3.19 – output 19 of port 3
If the controller provides 32 outputs or less, all outputs are located in port number zero. In this
case the port number can be omitted, and output is referred as OUT0, OUT22, etc.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 In p ut s a n d O u t p ut s 9-3

9.1.3. IN and OUT Variables

Within the controller the digital inputs are represented by integer array IN and the digital outputs
are represented by integer array OUT. Array IN is read-only and array OUT is read-write. IN and
OUT are standard variables in the controller and may be used in any command without
declaration.
Generally, inputs are represented by bits 0..15 of IN(0) and outputs by bits 0..15 of OUT(0). All
other elements of IN and OUT arrays are not functional in the basic configuration. The exact
number of elements in the arrays depends on the controller configuration (see the controller's
Hardware Guide).
Each digital input/output is treated as one binary bit. The low voltage level corresponds to zero
(or "clear") and high voltage level corresponds to one (or "set").
IN and OUT arrays can be used like any other variable in the controller. To access one element of
the array notation with or without brackets can be used. For example:
Both IN(0) and IN0 address element number zero in the IN array
Both OUT(2) and OUT2 address element number two in the OUT array
OUT (ind) addresses the element with the index supplied by a user-defined variable called ind
and has no counterpart in bracket free notation
Like other integer variables, IN and OUT arrays use dot notation to address a specific bit.
For example:
IN (0).0 and IN0.0 address input IN0.0
OUT (2).19 and OUT2.19 address output OUT2.19
OUT (0).I1 and OUT0.I1 address output, specified by variable I1, from port 0
OUT (I0).I1 addresses output, specified by variable I1, from the port specified by variable I0.
The IN and OUT arrays are used in operations like other variables.

9.1.3.1. Querying I/O

The IN and OUT arrays can be queried like any other variable. Each element of the array is read
as a 32-bit binary number.
Examples:
: ?IN0 !What is the status of input 0
10111001,00011010,00000100,00000000

: ?IN0.1 , IN0.2 !What is the status of bits 1 and 2 of input 0

0

: ?OUT (0,3) !What is the status of outputs 0 and 3

10111001,00011010,00000100,00000000 00000000,00000000,00000000,00000000
00000000,00000000,00000000,00000000 00000000,00000000,00000000,00000000

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

9-4 I np u t s a n d O ut p u t s

9.1.3.2. I/O In Expressions

The IN and OUT arrays can be operands in arithmetical and logical expressions. Expressions of
any complexity are allowed, using brackets and ACSPL+ functions. You have two options for
handling inputs/outputs as expressions:
• Reference individual bits using dot notation. In this case operators & (AND), | (OR), ~
(Exclusive OR), ^ (NOT) provides logical operations.
OR
• Use the whole port unit as an integer number. For example, IN0, OUT0, IN1. Using the
whole port as an integer number provides direct handling of up to 32 bits. In this case the
operators & (AND), | (OR), ~ (Exclusive OR), ~ (bitwise NOT) provide bitwise operations
(See Bitwise And Logical Operators & (and), | (or), , page 5-70).
The following examples show different possibilities:
IN0.13 & OUT0.2 Logical AND of signals IN0.13 and OUT0.2.

IN0.0 ~ IN0.1 Exclusive OR of signals IN0.0 and IN0.1.

edge ( IN0.1 ) Positive edge of signal IN0.1.

edge ( ^IN0.1 ) Negative edge of signal IN0.1.

IN0 & 0x0101 The expression addresses IN0 as 32-bit integer.

Hexadecimal constant 0x0101 contains one in bits 0
and 8 and zero in all other bits. The result is an integer
value that contains bits 0 and 8 from IN0 and zeros in
all other bits.
3.14 * IN0.2 If signal IN0.2 is one, the result is 3.14. If signal IN0.2
is zero, the result is zero.

9.1.3.3. Assignment to Outputs

The IN array is read-only. Therefore, IN elements cannot be assigned.
Examples of assignment to the elements of an OUT are shown below:
OUT0.1 = 0 Set output OUT0.1 to zero.

OUT0.1 = 1 Set output OUT0.1 to one.

OUT0.1 = V0 If V0 = 0, set OUT0.1 to zero. Otherwise,

set OUT0.1 to 1.
OUT0.15 = IN0.10 Copy state of input IN0.10 to output
OUT0.15.
OUT0.15 = ~ IN0.10 Copy inverse state of input IN0.10 to
output OUT0.15.
OUT6.1 = IN0.0 & IN0.1 Set OUT6.1 to logical AND of inputs
IN0.0 and IN0.1

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 In p ut s a n d O u t p ut s 9-5

OUT0 = 0x0101 Set signals OUT0.0 and OUT0.8 to one.

Set all other bits of OUT0 to zero.
OUT0 = OUT0 | 0x0101 Set signals OUT0.0 and OUT0.8 to one.
Do not alter other bits of OUT0.
OUT0 = OUT0 & ~0x0101 Set signals OUT0.0 and OUT0.8 to zero.
Do not alter other bits of OUT0.
OUT0 = (OUT0 & ~0x0101) |(V1 & Copy bits 0 and 8 from V1 to OUT0. Do
0x0101) not alter other bits of OUT0.

9.1.3.4. I/O In Conditional Commands: if while and till

Commands if, while and till are always followed by a logical expression. Using I/O in the logical
expression provides program branching options that are I/O state-dependent.
Examples:
if ^IN0.1 goto L Go to label L only if IN0.1 is zero.

while IN0.1 & IN0.2 Execute the subsequent commands up to command end
while both IN0.1 and IN0.2 are one.
till IN0.10 Wait until IN0.10 becomes one.

till IN0 & 0x0101 Wait until at least one of IN0.0 and IN0.8 becomes
one.

9.1.3.5. Autoroutines
Autoroutine headers include logical expressions. Using I/O in the logical expression provides
autoroutine activation based on the I/O state. The expression in the autoroutine header is verified
each controller cycle, therefore the controller can respond to I/O changes very quickly.
For example:
till IN(0) & 0x0101 Wait until at least one of IN(0).0 and IN(0).8
become one.

9.1.3.6. I/O in Autoroutine Condition

Autoroutine header includes logical expression. Inputs and outputs can be used in this expression.
The expression in autoroutine header is verified each controller cycle and if it is valid the
autoroutine is executed. Autoroutines can provide very fast response to changes in I/O state.
Examples:
on IN0.1 Start autoroutine when IN0.1 changes from 0 to 1. To
start the autoroutine again, IN0.1 must return to 0 and
then change to 1.
on IN0.0 & IN0.8 Start autoroutine when both IN0.0 and IN0.8 become 1.
To start the autoroutine again, at least one of IN0.0 and
IN0.8 must return to 0 and then both them must change
to 1.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

9-6 I np u t s a n d O ut p u t s

on IN0.0 | IN0.8 Start autoroutine when at least one of IN0.0 and IN0.8
becomes 1. To start the autoroutine again, both IN0.0
and IN0.8 must return to 0 and then at least one of
them must change to 1.
on IN0 & 0x0101 The same as above. Start autoroutine when at least one
of IN0.0 and IN0.8 becomes 1. To start the autoroutine
again, both IN0.0 and IN0.8 must return to 0 and then
at least one of them must change to 1.
See the example in the next section for an application of I/O to implement an emergency-induced
shutdown of all motion.

9.1.4. PLC Implementation

Programmable Logic Controller or PLC is often used to manage digital inputs/outputs. SPiiPlus
controllers provide implementation of PLC without separate PLC hardware. The techniques
described in this chapter provide implementation of PLC functionality by the controller. This
approach provides an easy integration of PLC program with motion control. For example, a
motion can be started when a condition calculated by the PLC program is satisfied, and an output
can be activated when a motion starts or terminates.
There are several options for implementing a PLC program:
ƒ Implement the PLC program in a separate buffer. This is the most suitable approach if the
PLC program must not interfere with motion, and has few connections to motion programs.
The PLC program runs in parallel with motion programs in other buffers, and any desired
connections are provided via global variables.
ƒ Mix motion programs and PLC program in the same buffers. This approach provides a very
close interaction between PLC and motion programs, resulting in faster reaction time, but in
general has a more complex structure.
ƒ Split the PLC program into two different parts running in two different buffers. This
approach is most suitable when a time-critical part of the program has to operate faster than
the rest of the program. PLC programs run at either a fast or slow scanning rate, and the user
must assign a greater priority one buffer using the PRATE variable.
ƒ Implement a part of the PLC program as a set of autoroutines. This approach provides a very
fast and interrupt-like response to critical conditions, because the autoroutine condition is
checked each controller cycle.
The following is an example of a PLC program implemented in a separate buffer using
autoroutines for fast response:
1 real T1

2 int Bits

3 Start:

4 OUT0.0 = X_MST.#INPOS

5 if T1 <= TIME

6 if Bits.0 T1 = T1 + 30000 else T1 = T1 + 15*60000 end

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 In p ut s a n d O u t p ut s 9-7

7 Bits.0 = ^Bits.0

8 end

9 OUT0.4 = IN0.4 & Bits.0

10 goto Start

11

12 on IN0.15; killall; ret

Line1 Definition of local variable T1 that is used to store the next switch time. T1 may
be defined as integer, but as a real, it can provide continuous running for an
extended period without overflow. The program relies on the automatic
initialization of all local variables to zero when they are declared.
Line2 Definition of local variable Bits. In this program only one bit of Bits is used. One
temporary integer variable can be used for storing 32 temporary bits.
Line3 Start label. A typical case in PLC programming is a long program cycle that
executes to the end and returns to the beginning. In the example shown above, the
execution period is quite short even with default rate of ‘one Line per each
controller cycle’. In a long program, the execution cycle can reach hundreds of
milliseconds. This is a good reason to divide a typical PLC program into slow and
fast sections.
Line 4 OUT0.0 reflects the ‘in position’ state of the motor. If the motor is not in position,
the output is 0. If it is in position, the output is 1.
Lines OUT0.4 controls a periodic activity that must be executed each 15 minutes for a
5-9 30-second period. It is executed only if IN0.4 is active. In a typical application, the
output might be connected to lubrication pump.
Line10 The end of the main cycle.
Line12 An autoroutine that provides extra fast response to IN0.15, typically an emergency
input. The whole autoroutine is implemented in one line providing an immediate
kill of all motions within one controller cycle when input port 0 bit 15 is 1.

9.1.5. Support for HSSI Communication

High-Speed Synchronous Serial Interface (HSSI) channels available in the SPiiPlus controllers
can be used for connecting additional inputs/outputs. ACSPL+ supports access to HSSI through
the standard arrays EXTIN and EXTOUT. The size of the arrays depends on the controller
model: see the controller's Hardware Guide.
The arrays can be queried, indexed and used in expressions like other standard variables.
Example:
?B/EXTIN1 Query HSSI input word 1 in binary format

00000000,00000000,00000010,00100010 Only low 16 bits are meaningful

EXTOUT0.12 = 1 Send 1 to HSSI output word 0 bit 12

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

9-8 I np u t s a n d O ut p u t s

See also the HSSI not connected fault, page 8-32.

For detailed information about the HSSI interface, see the HSSI Hardware Guide

9.2. Analog I/O

For analog I/O hardware specifications, refer to the controller's Hardware Guide.
To retrieve the voltage ranges of the analog inputs or outputs, use the sysinfo function, page 5-55
with 4 or 5 as the index argument.
The analog I/O are represented by the standard variable AIN (see page 11-16).

9.2.1. Monitoring Signals Via Analog Outputs

Each controller analog output is represented by an element of array AOUT. For example, the
SPiiPlus PCI-4/8 has 16 analog I/O represented by 16 elements of AOUT.
The voltage range of the analog outputs and their resolution is model-dependent. For example, in
the SPiiPlus PCI-4/8 the range of the analog outputs is +/-10V with 16 bit resolution.
For analog I/O specifications, refer to the controller's Hardware Guide.
Not all outputs can be used freely. If an output is connected to a drive, it has a dedicated
destination and cannot be used.
For example, in the SPiiPlus PCI-8 each axis has two dedicated outputs:
X axis: outputs 0, 1 A-axis: outputs 2 ,3 Y-axis: outputs 4 ,5 B-axis: outputs 6 ,7
Z-axis: outputs 8, 9 C-axis: outputs 10, 11 T-axis: outputs 12, 13 D-axis: outputs 14, 15

If a software-commutated brushless motor is connected to the X-axis, both output 0 and output 1
are unavailable.
On the other hand, if a brush motor is connected to the same axis, output 1 is free.
Examples of standard variables that can be monitored at 1kHz by assigning the variable to an
entity of AOUT:
Feedback position - FPOS.
Feedback velocity – FVEL.
Feedback acceleration - FACC.
The same applies for any other ACSPL+ variable (standard or user-defined).

NOTE FVEL is calculated by digital differentiation of FPOS. FACC is

calculated by digital differentiation of the FVEL variable.
The standard variable FVFIL defines a power of the smoothing filter
used in the FVEL calculation.

Example

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 In p ut s a n d O u t p ut s 9-9

The following ACSPL+ program assigns X-axis feedback position to output # 3 and acceleration
to output #1. In the example, the user variables SF1 and SF2 are scale factors.
real SF1,SF2

SF1=0.01 ; SF2=0.001 Define scaling factors

WHILE 1; AOUT3 = FPOS0 * SF1; AOUT1 = FACC0 * SF2; END

If the acceleration signal is too noisy, FVFIL can be increased.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 Mo d e l - D e p e n de n t F e a t u re s 10-1

10. MODEL-DEPENDENT FEATURES

Features that can vary by controller model include:

• the number of axes.
• the number of inputs and outputs
• the number of Servo Processors
In addition, there are a number of features that apply only for specific controller models.

10.1. PEG Output Assignment

PEG (page 7-7), output assignment depends on the controller model. In some controller models, a
digital output must be assigned for the use of the brake signal. In these models the digital output
pins can be configured for either general use (page 9-1), PEG (page 7-7), or mechanical braking
(page 7-21). Each pin can be configured separately.
In other controller models, there are dedicated PEG outputs (one per axis). (If an application does
not require PEG, these outputs can be reassigned for general use.)

10.1.1. PEG Output Assignment for SPiiPlus PCI-4/8 and

SPiiPlus PCI-DDM4
In these models digital output pins are shared between PEG and general purpose use (TABLE 10-
8). After power-up, all the hardware outputs are assigned to OUT0 (general purpose use) and are
isolated from PEG. Therefore, command assignpeg is absolutely necessary before PEG
commands can be executed.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

10-2 M o de l - D e p e nd e n t F e a t ur e s

TABLE 10-8 Digital Output Sharing

PEG Output General Purpose

Output

X PEG State 0 OUT0.0

X PEG State 1 OUT0.1
X PEG State 2 OUT0.2
X PEG State 3 OUT0.8
X PEG Pulse OUT0.3
Y PEG State 0 OUT0.4
Y PEG State 1 OUT0.5
Y PEG State 2 OUT0.6
Y PEG State 3 OUT0.9
Y PEG Pulse OUT0.7
Z PEG Pulse 1) OUT0.10
T PEG Pulse 1) OUT0.11
1)
The output is available only in SPiiPlus PCI-8.

10.1.2. PEG Output Assignment for SPiiPlus CM Modules

SPiiPlus CM control modules have separate general purpose hardware outputs and PEG hardware
outputs. After power-up the PEG hardware outputs are assigned as predefined PEG state and
pulse outputs. Therefore, command assignpeg is not required before PEG commands can be
executed. However, it can be useful for the following:
• to set the initial state of PEG state outputs
• to reconfigure unused PEG hardware outputs for use as general-purpose outputs controlled
through the OUT array (TABLE 10-9).
For example, assignment:
OUT8.3 = 1
sets the X PEG State 3 pin high, but only if that hardware output was reconfigured to general
purpose use with an assignpeg command. If the hardware output was not reconfigured, bit
OUT8.3 is isolated from the output and the assignment has no effect on the output.

TABLE 10-9 PEG Output Reconfiguration for General Purpose Use

PEG Output General Purpose Bit in

OUT0 Array

X PEG State 0 OUT8.0

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Mo d e l - D e p e n de n t F e a t u re s 10-3

PEG Output General Purpose Bit in

OUT0 Array

X PEG State 1 OUT8.1

X PEG State 2 OUT8.2
X PEG State 3 OUT8.3
X PEG Pulse OUT8.8
Y PEG State 0 1) OUT9.0
Y PEG State 1 1) OUT9.1
Y PEG State 2 1) OUT9.2
Y PEG State 3 1) OUT9.3
Y PEG Pulse 1) OUT9.8
1)
The output is available only in SPiiPlus CM-3.

10.2. Mechanical Brake Output Assignment

Mechanical brake (page 7-21) output assignment depends on the controller model. In some
models, a digital output must be assigned for the use of the brake signal. In these models the
digital output pins can be configured for either general use (page 9-1), PEG (page 7-7), or
mechanical braking (page 7-21). Each pin can be configured separately.
In other controller models, there are dedicated, high power brake outputs (one per axis). (If
braking is not needed, these outputs can be reassigned for general use.)

10.2.1. Brake Output Assignment for SPiiPlus PCI-4/8 and

SPiiPlus PCI-DDM4
The brake outputs share the same pins (TABLE 10-10) with the general purpose outputs (page 9-
1) and PEG outputs (page 7-6).

TABLE 10-10 Assignment of Digital Outputs for Brake, PEG, or General

Physical Output When Used for When Used for When Used for
General Purpose PEG Braking
Output 0 OUT0.0 X PEG State 0 X Brake
Output 1 OUT0.1 X PEG State 1 Y Brake
Output 2 OUT0.2 X PEG State 2 Z Brake
Output 3 OUT0.3 X PEG Pulse
Output 4 OUT0.4 Y PEG State 0 T Brake
Output 5 OUT0.5 Y PEG State 1 A Brake

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

10-4 M o de l - D e p e nd e n t F e a t ur e s

Physical Output When Used for When Used for When Used for
General Purpose PEG Braking
Output 6 OUT0.6 Y PEG State 2 B Brake
Output 7 OUT0.7 Y PEG Pulse
Output 8 OUT0.8 X PEG State 3 C Brake
Output 9 OUT0.9 Y PEG State 3 D Brake
Output 10 OUT0.10 Z PEG Pulse
Output 11 OUT0.11 T PEG Pulse

If a digital output is assigned to one of these functions (for example, general purpose) it cannot be
used for the other functions (in this case, PEG or brake). For example, if output 8 is assigned to C
brake, it is isolated from the OUT0.8 bit and from the PEG function. Therefore the state of the
output will not be affected by assignment to the OUT0.8 bit or by PEG generation.
After power-up, all outputs are assigned by default to the OUT0 bits for general purpose use and
all OUT0 bits are cleared.
A digital output can be configured for one of the three uses with the setconf(29) function. The key
argument must be 29, the index argument defines the output number, and the value argument
defines the assignment (TABLE 10-11):

TABLE 10-11 Digital Output Assignment with setconf

Value Assignment

0 OUT0 bit (general use)

1 PEG pulse/state
2 Brake
For example:
setconf(29,10,1) Assign output 10 to Z PEG Pulse
setconf(29,8,2) Assign output 8 to C Brake
setconf(29,3,0) Assign output 3 to OUT0.3 bit

The corresponding getconf(29) function call returns the current assignment of the output specified
by the index argument. See also the reference information for setconf/getconf(29), page 5-62.
See brake output operation (page 7-22).

10.2.2. Brake Output Assignment for SPiiPlus CM

As distinct from other SPiiPlus controllers, CM control modules provide a dedicated high-power
digital brake output per controller axis. No special assignment is required for brake outputs.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Mo d e l - D e p e n de n t F e a t u re s 10-5

If an application does require the mechanical braking function, the SPiiPlus CM high-power
digital brake outputs can be reconfigured for general use simply by clearing bit 24 (#BRAKE) of
the corresponding MFLAGS variable. In that case, the outputs are mapped to the bits of OUT1
variable for general use (TABLE 10-12):

TABLE 10-12 Digital Output Assignment with setconf

Axis Brake HW Output Reassigned to

X OUT1.0
Y OUT1.1
A OUT1.4

For example, if bit Y_MFLAGS.#BRAKE is cleared, then the Y axis high power brake output
functions as a general purpose output, and is controlled by OUT1.1.
See brake output operation (page 7-22).

10.3. DPRAM for Fast Host Communication (PCI-Based

Controller Models)
Dual-port RAM (DPRAM) is controller-based volatile memory that can be accessed both by the
controller and by the host computer. DPRAM provides several advantages:
• Fastest way to copy standard variables from the controller to the host (copytodpr
command).
• Global user variables can be declared in the DPRAM, accessible to both the host-based
program and the ACSPL+ program (extended global variable declaration).
• Fastest way for host-based program to send commands and variables to the controller
(copyfromdpr command).
• Fastest way for host-based program to initiate PTP (copyfromdpr and track commands)
The SPiiPlus controller DPRAM has 16-bit access. The size of the DPRAM is model-dependent
and can be retrieved with the sysinfo function key 6 (see page 5-55). See also the controller
hardware guide.
The relative address range of the DPRAM starts at byte 0 to byte 0x3FF.
The first 64 16-bit words (128 bytes, relative addresses from 0 to 0x7F) are reserved for system
use. The rest of the DPRAM (from 0x80 to (size of DPRAM -1)) is available to the user.
Integer and real standard variables occupy different space in the DPRAM. An integer variable
occupies four bytes or two 16-bit words. A real variable occupies eight bytes or four 16-bit words.
In both cases the least significant bits occupy the lower address of the DPRAM.

10.3.1. copytodpr Command

The copytodpr command has the following syntax:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

10-6 M o de l - D e p e nd e n t F e a t ur e s

copytodpr dpr-address, variable-list

where dpr-address is the relative address within the DPRAM,
variable-list is a list of up to eight standard variables separated by commas.
The command instructs the controller to copy the value of each standard variable specified in the
variable list to the address in the DPRAM (dpr-address). The controller continues to copy the
values, every controller cycle, irrespective of all other controller activities. Therefore the host-
computer program can only use the DPRAM copy as a read-only variable. A host attempt to write
to the DPRAM address will have no effect, because the controller overwrites the DPRAM address
in the next cycle.
The dpr-address argument specifies the relative DPRAM address for the first variable in the list.
The second variable in the list is allocated to the higher address adjacent to the first variable and
so on.
Example:
copytodpr 0xA0, X_MST, X_FPOS, Y_MST, Y_FPOS
Variables X_MST and Y_MST are integer, variables X_FPOS and Y_FPOS are real. Therefore,
the relative DPRAM addresses for the variables will be allocated as follows:
0xA0 (160) – X_MST (4 bytes)
0xA4 (164) – X_FPOS (8 bytes)
0xAC (172) – Y_MST (4 bytes)
0xB0 (176) – Y_FPOS (8 bytes)
Any number of copytodpr commands can be executed and at any place within the ACSPL+
program. The command is typically used in the AUTOEXEC section (see page 4-37).
Execution of a copytodpr command is dependent on the state of the S_FLAGS.#COPYTO bit
(page 11-54). When the bit is set, copying is disabled. When the bit is clear, copying is enabled.

10.3.2. copyfromdpr Command

The standard way for a host-based program to initiate an action in the controller is for the
program to send a command through one of the available communication channels, the fastest
being the PCI bus. However, even execution using the PCI bus communication involves a
measurable delay (several milliseconds), because each command passes through command queue
and interpretation process.
Using DPRAM, the host-based program is able to bypass the command queue and interpretation
process. The feature provides a fast way of writing values from the host application to standard
variables.
The copydfrompr command has the following syntax:
copyfromdpr dpr-address, variable-list
where dpr-address is the relative address within the DPRAM,
variable-list is a list of standard variables separated by commas. Read-only variables cannot
be specified in the list.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Mo d e l - D e p e n de n t F e a t u re s 10-7

The command instructs the controller to copy one or more values from the DPRAM to the
standard variables specified in variable-list.
The dpr-address argument specifies the relative DPRAM address for the first variable in the list.
The second variable in the list is allocated in the upper address adjacent to the first variable and so
on. The specified address cannot be less than 128, because the first 64 words (128 bytes) are
reserved for system use.
Example:
copyfromdpr 0xA0, OUT0, X_TPOS, X_VEL, X_ACC
Variable OUT0 is integer, variables X_TPOS, X_VEL, X_ACC, are real. Therefore, the relative
DPRAM addresses for the variables will be allocated as follows:
0xA0 (160) – OUT0 (4 bytes)
0xA4 (164) – X_TPOS (8 bytes)
0xAC (172) – X_VEL (8 bytes)
0xB4 (180) – X_ACC (8 bytes)
Any number of copyfromdpr commands can be executed and at any place within the ACSPL+
program. The command is typically used in the AUTOEXEC section (see page 4-37).
Execution of a copyfromdpr command is dependent on the state of the
S_FLAGS.#COPYFROM bit (page 11-54). When the bit is set, copying is disabled. When the
bit is clear, copying is enabled.

10.3.2.1. copyfromdpr Modes

Copying from dual-port RAM to a variable is a time consuming operation. If an application
executes many copyfromdpr commands, the accumulated effect may cause high controller usage
or even a Time Overuse fault. Controller usage can be monitored with the #U command. Maximal
usage of 90% or more is dangerous and may cause jerks in motion profile.
The controller supports two modes of copyfromdpr operation: copy-each-cycle and copy-only-if-
requested. The user selects the modes with bit 6 (#COPYOIR) of the S_FLAGS variable:
• S_FLAGS.#COPYOIR=0: copy-each-cycle mode - the controller copies from DPRAM to
the variable each controller cycle.
• S_FLAGS.#COPYOIR=1: copy-only-if-requested mode - the controller copies from
DPRAM to the variable only when the host computer writes to DPRAM.
These modes are related only to copyfromdpr operation. Copying from a variable to DPRAM
(copytodpr command) is executed each controller cycle not affected by the selected mode.

10.3.2.1.1. Difference between the Modes

In copy-each-cycle mode, all copy operations are executed each controller cycle. Therefore they
provide high and uniform load for the controller. The controller usage reported by the #U
command displays high values for minimal, average and maximal usage.
In copy-only-if-requested mode, the controller executes copying only when the host computer
writes to DPRAM. Between the write operations, the copying is not executed so that the
controller usage drops to low values. However, once the host writes to DPRAM, the controller

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

10-8 M o de l - D e p e nd e n t F e a t ur e s

executes a number of copy operations. Therefore the #U command may display low average
usage but high maximal usage. The maximal number of copy operations executed in one cycle is
less than or equal to the overall number of definitions in all copyfromdpr commands. Therefore,
the maximal usage in this mode can reach the maximal usage level of copy-each-cycle mode, but
cannot exceed it.
How close the maximal usage in copy-only-if-requested mode comes to the maximal usage in
copy-each-cycle mode depends on the application. The DPRAM layout can be optimized in order
to minimize the maximal usage.

10.3.2.1.2. More details

In copy-only-if-requested mode, the user DPRAM space is divided into 8 banks:
Bank 1: addresses from 0x080 to 0x0FF
Bank 2: addresses from 0x100 to 0x17F
Bank 3: addresses from 0x180 to 0x1FF
Bank 4: addresses from 0x200 to 0x27F
Bank 5: addresses from 0x280 to 0x2FF
Bank 6: addresses from 0x300 to 0x37F
Bank 7: addresses from 0x380 to 0x3FF
Bank 0 - addresses > 1024 (not available)
When the host computer writes to a bank, the controller executes all copy operations specified for
this bank. Therefore, one write operation from the host can cause many copy operations on the
controller side.
If the host updates all the DPRAM addresses simultaneously, no optimization can be done and the
maximal usage will be the same as in copy-each-cycle mode (the average usage, however, may be
much less).
Otherwise, the following optimization can be recommended:
• Divide the variables updated by the host through DPRAM into groups, so that the variables
in one group tend to be updated simultaneously.
• Map the variables in one group to one DPRAM bank.
• Map different groups to different DPRAM banks.

10.3.3. stopcopytodpr Command

The stopcopytodpr command cancels all previously executed copytodpr and copyfromdpr
commands, stopping the copying of variables to/from the DPRAM.
The stopcopytodpr command syntax includes no arguments.

10.3.4. DPRAM Allocation in Global Variable Declaration

A global user variable declaration (see page 5-13) can include a request to allocate the variable in
the DPRAM.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Mo d e l - D e p e n de n t F e a t u re s 10-9

The following syntax is provided:

global [integer|real] dpr dpr-address, variable-list
dpr-address is the relative address within the DPRAM,
variable-list is a list of user names separated by commas.
Unlike a regular global variable, which is stored in regular RAM, the variable declared by the
extended declaration is stored in the DPRAM.
The host program can read and write a variable located in the DPRAM. Therefore user variables
located in DPRAM provide a bi-directional means of communication between the host-based
program and the controller-based ACSPL+ program.
As with a regular declaration, the extended declaration can define the variable as integer or real,
as scalar or array.
The dpr-address argument specifies the relative DPRAM address for the first variable in the list.
The second variable in the list is allocated the next (ascending) address and so on.
Example:
global int dpr 0xC0, First, Second(3), Third

The relative DPRAM addresses for the variables will be allocated as follows:
0xC0 (192) – First
0xC4 (196) – Second(0)
0xC8 (200) – Second(1)
0xCC (204) – Second(2)
0xD0 (208) – Third

10.3.5. Example: Setting Digital Outputs from the Host

Assume, an application requires that a C program running on the host computer operate the
controller digital outputs.
The following example represents a C program running on the host computer. The program
implements all necessary steps required to operate the controller digital outputs.
The delay, measured from execution of acsc_WriteDPRAMInteger(h,0xa8,…) to
physical change on the digital output, varies from 0 to 1 millisecond (the controller cycle is 1
millisecond).
The C program executes the following steps:
1. Open communication.
2. Send the command copyfromdpr 0xa8,OUT0 to the controller. The command causes
the controller every controller cycle to copy a number from DPRAM address 0xA8 to
variable OUT0.
3. Each a cycle (until a keyboard button is pressed) write to DPRAM address 0xA8 alternately
0 and –1. This will cause pulses across all the digital outputs.
4. Send to the controller the command stopcopytodpr. The command stops the copying
from DPRAM address 0xA8 to variable OUT0.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

10-10 M o de l - D e p en d e n t F e a t ur e s

5. Close communication.
#include “stdafx.h”

#include "..\acscgonext\acsc.h"

#include <conio.h>

int main(int argc, char* argv[])

HANDLE h=acsc_OpenCommPCI(-1);

char command[100],Reply[100];

int N;

acsc_WriteDPRAMInteger(h,0xa8,000);

strcpy(command,"copyfromdpr 0xa8,OUT0\r");

int res=acsc_Transaction(h,command,strlen(command),Reply,100,&N,NULL);

Sleep(100);

int i;

for(i=0;i<100000&&!kbhit();i++)

acsc_WriteDPRAMInteger(h,0xa8,-1);

Sleep(10);

acsc_WriteDPRAMInteger(h,0xa8,0);

Sleep(20);

strcpy(command,"stopcopytodpr\r");

res=acsc_Transaction(h,command,strlen(command),Reply,100,&N,NULL);

acsc_CloseComm(h);

return 0;

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Mo d e l - D e p e n de n t F e a t u re s 10-11

10.3.6. Example: Starting PTP Motion from the Host

Assume, an application requires that a C program running in the host computer start a sequence of
PTP motions .
The following example represents a C program running on the host computer. The program
implements all necessary steps required to start a sequence of PTP motions.
The delay, measured from executing command acsc_WriteDPRAMInteger(h,0xa0,…) to
motion start indicated by bit AST.#MOVE, varies from 0.65 to 1.5 millisecond (the controller
cycle is 1 millisecond).
The C program executes the following steps:
1. Open communication.
2. Send to the controller the command copyfromdpr 0xa0,OUT0. The command causes
the controller every controller cycle to copy a number from DPRAM address 0xA0 to
variable B_TPOS.
3. Enable motor B and initialize track motion.
4. Every cycle (until a keyboard button is pressed), increment DPRAM address 0xA0 by
increments of 100 counts. The value is copied to B_TPOS and activates a PTP motion.
5. Send to the controller the command stopcopytodpr. The command stops copying
DPRAM address 0xA8 to variable OUT0.
6. Disable motor B.
7. Close communication.
#include "stdafx.h"

#include "acsc.h"

#include <conio.h>

int main(int argc, char* argv[])

HANDLE h=acsc_OpenCommPCI(-1);

Char command[100],Reply[100];

int N;

acsc_Enable(h,ACSC_AXIS_B,NULL);

Sleep(500); // Wait for enable excution

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

10-12 M o de l - D e p en d e n t F e a t ur e s

acsc_SetFPosition(h,5,0,NULL);

acsc_WriteDPRAMReal(h,0xa0,000); //Initialize the DPRAM

// Set the link between DPRAM field and the standard variables

strcpy(command,"copyfromdpr 0xa0,B_TPOS\r");

res=acsc_Transaction(h,command,strlen(command),Reply,100,&N,NULL);

// Initialize track motion

strcpy(command,"track B\r");

res=acsc_Transaction(h,command,strlen(command),Reply,100,&N,NULL);

Sleep(100);

int i;

for(i=0;i<100000&&!kbhit();I++)

acsc_WriteDPRAMReal(h,0xa0,i*100);

Sleep(150); //Pause between the cycles

strcpy(command,"stopcopytodpr\r");

res=acsc_Transaction(h,command,strlen(command),Reply,100,&N,NULL);

acsc_Disable(h,ACSC_AXIS_B,NULL);

acsc_CloseComm(h);

return 0;

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Mo d e l - D e p e n de n t F e a t u re s 10-13

10.4. Dynamic Braking (for integrated models)

MODEL
DEPENDENT
Dynamic braking is supported only in integrated models.

The dynamic brake reduces the motor runoff if the motor becomes disabled during motion. In
dynamic braking the controller short-circuits the motor armature.
If dynamic braking is enabled for an axis, the controller applies the braking when the feedback
velocity falls below the value specified by the VELBRK parameter (default – 0).
The MFLAGS.#BRAKE bit enables dynamic braking (default – off).

10.5. Constant Current Mode (for integrated models)

MODEL
DEPENDENT Dynamic braking is supported only in integrated models.
The SPiiPlus PCI-DDM4A supports constant current mode for
axes Y and B.

Constant current mode provides extra safety. When the mode is activated, and the emergency stop
signal is on, the motor is kept at a standstill by the drive.
• The function, setconf (133, 1, 1) enables constant current mode for axes Y and B. The
function, setconf (133, 1, 0) disables constant current mode for axes Y and B.
• To retrieve the constant current mode status for Y and B axes, getconf (133, 1) is used. It
retrieves a non-zero value if constant current mode is on and zero if constant current mode is
off.
The drive activates constant current mode only if all of the following conditions are true:
• Emergency Stop (ES) signal is on.
• All axes are disabled.
• Dynamic brake mode is off (MFLAGS(Axis).#BRAKE = 0).
Only once these conditions are true can constant current mode be enabled by the function setconf
(133, 1, 1). If any of the conditions is changed, it will deactivate constant current mode.
To set/get the current level used for constant current mode, the following setconf/getconf
parameters are used:
• setconf (130, {1|5}, current level), where current level defines that the constant current level
as a percentage of the maximum current for the specified axis (Y or B only, represented by
the index value 1 or 5 respectively). The default maximum value that can be set is 16% for
axis Y and 30% for axis B (this value can be changed, see description of key 131 below).

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

10-14 M o de l - D e p en d e n t F e a t ur e s

• getconf (130, {1|5}) retrieves the present value of current level for the specified axis.
The default value of current level is 0, so it must be defined before constant current mode can be
used.
To set/get the maximum value that can be set with setconf (130, . . .), the following
setconf/getconf parameters are used:
• setconf (131, {1|5}, max current level), where max current level defines the maximum
allowable value of the current level as a percentage of the maximum current for the specified
axis (Y or B only, represented by the index value 1 or 5 respectively).
• getconf (131, {1|5}) retrieves the present maximum allowable current level for the specified
axis.
The following ACSPL+ program illustrates how to implement constant current mode:
! Constant current mode implementation

on S_FAULT.#ES

disableall

wait 100

MFLAGS1.#BRAKE = 0; MFLAGS5.#BRAKE = 0 ! disable Brake Mode for axes Y, B

setconf(130, 1, 10) ! set constant current level (10%) for axis Y

setconf(130, 5, 20) ! set constant current level (20%) for axis B

setconf(133, 1, 1) ! enable constant current mode

ret

on ^S_FAULT.#ES | S_FAULT.#DRIVE

setconf(133, 1, 0) ! disable constant current mode

ret

See the SPiiPlus PCI-DDM4A Four-Axis Digital Drive Module Hardware Guide for more
information.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-1

11. STANDARD VARIABLE REFERENCE

Standard variables are predefined in the controller. A standard variable can be used in any
ACSPL+ program without user declaration. Redefinition of standard variable names is prohibited
and causes program error.
All standard variables have global scope; so that all references to a global variable in any program
buffer refer to the same variable.
This reference starts with brief descriptions of the standard variables, first by group and again
listed alphabetically. This is followed by detailed descriptions of the standard variables in
alphabetical order.

11.1. Standard Variables Ordered By Group

11.1.1. State
Name Size Type Accessibility Description Page

S_ST Scalar Integer Read-only System State 11-56

TIME Scalar Real Read-only Elapsed Time 11-69
AST 8 Integer Read-only Axis State 11-17
APOS 8 Real Read-only Axis Position 11-17
MPOS 8 Real Read-only Master Position 11-48
MST 8 Integer Read-only Motor State 11-48
FPOS 8 Real Read-only Feedback Position 11-31
FVEL 8 Real Read-only Feedback Velocity 11-31

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-2 S t a nd a r d Va r i a b l e R e f e re n c e

Name Size Type Accessibility Description Page

FACC 8 Real Read-only Feedback Acceleration 11-30

F2POS 8 Real Read-only Secondary Feedback Position 11-29
PE 8 Real Read-only Position Error 11-49
RPOS 8 Real Read-only Reference Position 11-51
RVEL 8 Real Read-only Reference Velocity 11-52
RACC 8 Real Read-only Reference Acceleration 11-51
IST 8 Real Read-only Index State 11-41
IND 8 Real Read-only Index Position 11-39
E2IND 8 Real Read-only Secondary Index Position 11-27
MARK 8 Real Read-only Mark Position 11-42
M2ARK 8 Real Read-only Secondary Mark Position 11-42

11.1.2. Motion
Name Size Type Accessibility Description Page
GPATH 8 Real Read-only Group Path 11-34
GPHASE 8 Real Read-only Motion Phase 11-36
GVEC 8 Real Read-only Group Vector 11-37
GVEL 8 Real Read-only Group Velocity 11-37
GACC 8 Real Read-only Group Acceleration 11-32
GJERK 8 Real Read-only Group Jerk 11-33
GRTIME 8 Real Read-only Remaining Motion Time 11-35
GMOT 8 Integer Read-only Group Motion Number 11-33
GMQU 8 Integer Read-only Group Motion Queue 11-33
GMTYPE 8 Integer Read-only Motion Type 11-34
GSEG 8 Integer Read-only Group Segment Number 11-35
VEL 8 Real Read-Write Default velocity 11-69
ACC 8 Real Read-write Acceleration 11-14
DEC 8 Real Read-write Deceleration 11-22
JERK 8 Real Read-write Jerk 11-41
KDEC 8 Real Read-write Kill Deceleration 11-42

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-3

Name Size Type Accessibility Description Page

VELBRK 8 Real Configuration Velocity for Braking 11-70
TPOS 8 Real Read-write Target Position 11-69

11.1.3. Program Execution Control

Name Siz Type Accessibility Description Page
e
PFLAGS 10 Integer Read-write Program Flags 11-50
PST 10 Integer Read-only Program State 11-51
PLINES 10 Integer Read-only Number of Lines 11-50
PCHARS 10 Integer Read-only Number of Characters 11-49
PEXL 10 Integer Read-only Executed Line 11-50
PERR 10 Integer Read-only Program Error 11-49
PERL 10 Integer Read-only Program Error Line 11-49
PRATE 10 Integer Read-write Program Rate 11-51
ONRATE 10 Integer Read-write Autoroutine Rate 11-48

11.1.4. General Purpose

Name Size Type Accessibility Description Page
I 100 Integer Read-Write I Array 11-37
V 100 Integer Read-Write V Array 11-69

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-4 S t a nd a r d Va r i a b l e R e f e re n c e

11.1.5. Input/Output
Name Size Type Accessibility Description Page
IN 8 Integer Read-only General-Purpose Dig. Inputs 11-39
OUT 8 Integer Read-Write General-Purpose Dig. 11-49
Outputs
AIN 16 Integer Read-only Analog Inputs 11-16
AOUT 16 Integer Read-Write Analog Outputs 11-16
FK Scalar Integer Read-only Function Key 11-30
DCOM 8 Integer Read-write Drive Command 11-22
DOUT 8 Integer Read-only Drive Output 11-23
EXTIN 16 Integer Read-only Extended Inputs (HSSI) 11-29
EXTOUT 16 Integer Read-write Extended Outputs (HSSI) 11-29

11.1.6. Data Collection

Name Size Type Accessibility Description Page
S_DCN Scalar Integer Read-only System DC, Number of 11-53
Samples
S_DCP Scalar Real Read-only System DC, Period 11-53
DCN 8 Integer Read-only Axis DC, Number of 11-21
Samples
DCP 8 Real Read-only Axis DC, Period 11-22

11.1.7. Monitoring
Name Size Type Accessibility Description Page
SMNA *4 Integer Read-Write Software Monitor Address 11-66
SMNV *4 Integer Read-only Software Monitor Value 11-67
* Size is model dependent – one per SP.

11.1.8. Safety Control

Name Size Type Accessibility Description Page
FAULT 8 Integer Read-only Faults 11-30
FMASK 8 Integer Read-write Fault Mask 11-31
FDEF 8 Integer Read-write Default Response Mask 11-30

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-5

Name Size Type Accessibility Description Page

SAFIN 8 Integer Read-only (r/w Safety Inputs 11-56
for Simulator)
SAFINI 8 Integer Read-write Safety Inputs Inversion 11-57
S_FAULT Scalar Integer Read-only System Faults 11-53
S_FMASK Scalar Integer Read-write System Fault Mask 11-55
S_FDEF Scalar Integer Read-write System Default Response 11-53
Mask
S_SAFIN Scalar Integer Read-only (r/w System Safety Inputs 11-55
for Simulator)
S_SAFINI Scalar Integer Read-write System Safety Inputs 11-56
Inversion
AERR 8 Integer Read-only Axis Error 11-14
MERR 8 Integer Read-only Motor Error 11-43

11.1.9. Configuration
Name Size Type Accessibility Description Page
IENA Scalar Integer Read-write Interrupt Enable/Disable 11-38
ISENA 8 Integer Read-write Interrupt-Specific 11-40
Enable/Disable
CFG Scalar Integer Read-only Configuration Mode 11-19
CTIME Scalar Real Read-write Controller Cycle Time 11-20
S_FLAGS Scalar Integer Read-write System Flags 11-54
BAUD Scalar Integer Read-write IO Baud Rate 11-17
DISPCH Scalar Integer Read-write IO Default Channel 11-23
ECHO Scalar Integer Read-write IO Echo Channel 11-27
COMMFL Scalar Integer Read-write Communication IO Flags 11-19
IMASK 8 Integer Read-write Index Mask 11-38
AFLAGS 8 Integer Read-write Axis Flags 11-16
EFAC 8 Real Read-write Encoder Factor 11-26
E2FAC 8 Real Read-write Secondary Encoder Factor 11-26
E_FREQ 8 Integer Read-write Encoder Frequency 11-24
E_TYPE 8 Integer Read-write Encoder Type 11-25
E2_TYPE 8 Integer Read-write Secondary Encoder Type 11-26
E_SCMUL 8 Integer Read-write Encoder Sin-Cos Multiplier 11-24

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-6 S t a nd a r d Va r i a b l e R e f e re n c e

Name Size Type Accessibility Description Page

ENTIME 8 Real Read-write Enable Time 11-28
ERRI 8 Real Read-write Tolerable Error (Idle) 11-28
ERRV 8 Real Read-write Tolerable Error (Velocity) 11-28
ERRA 8 Real Read-write Tolerable Error 11-28
(Acceleration)
CERRI 8 Real Read-write Critical Error (Idle) 11-18
CERRV 8 Real Read-write Critical Error (Velocity) 11-19
CERRA 8 Real Read-write Critical Error (Acceleration) 11-18
DELI 8 Real Read-write Delay on Transition to Idle 11-23
State
DELV 8 Real Read-write Delay on Transition to 11-23
Velocity State
FVFIL 8 Real Read-write Feedback Velocity Filter 11-32
MFF 8 Real Read-write Master Feedforward 11-45
MFLAGS 8 Integer Read-write Motor Flags 11-45
RVFIL 8 Real Read-write Reference Velocity Filter 11-52
SETTLE 8 Real Read-write Settling Time 11-57
SLLIMIT 8 Real Read-write Software Left Limit 11-66
SRLIMIT 8 Real Read-write Software Right Limit 11-67
STEPW 8 Real Read-write Stepper Pulse Width 11-67
STEPF 8 Real Read-write Stepper Factor 11-67
SYNV 8 Real Read-write Synchronous Velocity 11-68
TARGRAD 8 Real Read-write Target Envelope 11-68
XVEL 8 Real Read-write Maximum Velocity 11-71
XACC 8 Real Read-write Maximum Acceleration 11-70
XCURI 8 Real Read-write Maximum Idle Motor 11-70
Current
XRMS 8 Real Read-write Maximum Allowed RMS 11-71
Current
XCURV 8 Real Read-write Maximum Moving Motor 11-71
Current
XSACC 8 Real Read-write Maximum Slave 11-71
Acceleration

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-7

11.1.10. Servo Loop

The servo-loop variables are used primarily for configuration and
adjustment. The Adjuster feature in the SPiiPlus MMI software tool
is a powerful, easy-to-use interface to the servo control loops. (The
control loops are described in detail in the SPiiPlus PCI-4/8 Hardware
ADVANCED Guide.)
The variables are fully accessible at the ACSPL+ level. While
ACSPL+ programs generally do not refer to servo-loop variables at run
time, an advanced program could change a servo-loop variable on the
fly to provide adaptive control.
The servo-loop variables, and adjustments based on them, will be
supported by all future firmware versions.

11.1.10.1. Current Loop

Name Size Type Accessibility Description Page
SLBIASA 8 Real Read only Current bias A. 11-58
(integrated models)
Read-write
(nonintegrated
models)
SLBIASB 8 Real Read only Current bias B. 11-58
(integrated models)
Read-write
(nonintegrated
models
SLIKI 8 Real Read-write Integrator coefficient in 11-61
current servo loop. (For
integrated models only).
SLIKP 8 Real Read-write Proportional coefficient in 11-61
current servo loop. (For
integrated models only).
SLIOFFS 8 Real Read-write Offset to be added to the result 11-61
of the current loop control.

11.1.10.2. Commutation
Name Size Type Accessibility Description Page
SLCNP 8 Integer Read-write Number of poles for rotary 11-60
motor, 2 for linear motor
SLCPA 8 Real Read-write Phase advance in electrical 11-60
degrees at XVEL velocity.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-8 S t a nd a r d Va r i a b l e R e f e re n c e

Name Size Type Accessibility Description Page

SLCOFFS 8 Real Read-write Commutation offset to be added 11-59
to the commutation phase.
SLCORG 8 Real Read-write Commutation phase at the point 11-59
of origin.
SLCPRD 8 Real Read-write Commutation period. 11-60

11.1.10.3. Velocity Loop

Name Size Type Accessibility Description Page
SLAFF 8 Real Read-write Acceleration feed-forward. 11-58
SLFRC 8 Real Read-write Friction 11-60
SLVKI 8 Real Read-write Integrator coefficient in velocity 11-65
servo loop.
SLVKP 8 Real Read-write Proportional coefficient in 11-65
velocity servo loop.
SLVLI 8 Real Read-write Integrator limit in velocity servo 11-65
loop.
SLVNATT 8 Real Read-write Notch filter attenuation. 11-65
SLVNFRQ 8 Real Read-write Notch filter frequency. 11-65
SLVNWID 8 Real Read-write Notch filter width. 11-66
SLVSOF 8 Real Read-write Second order filter bandwidth. 11-66

11.1.10.4. Position Loop

Name Size Type Accessibility Description Page
SLEMOS 8 Integer Read-write Sets the order of the sin-cos 11-60
filter.
SLPBITS 8 Integer Read-write Number of bits in position 11-62
feedback (used with HSSI).
SLPKI 8 Real Read-write Integrator coefficient in position 11-62
servo loop.
SLPKP 8 Real Read-write Proportional coefficient in 11-62
position servo loop.
SLPLI 8 Real Read-write Integrator limit in position servo 11-62
loop.
SLPROUT 8 Integer Read-write Position feedback routing. 11-62

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-9

11.2. Standard Variables Ordered Alphabetically

Name Size Type Accessibility Description Page
* Size is model dependent – one per SP.
ACC 8 Real Read-write Acceleration 11-14
AERR 8 Integer Read-only Axis Error 11-14
AFLAGS 8 Integer Read-write Axis Flags 11-16
AIN 16 Integer Read-only Analog Inputs 11-16
AOUT 16 Integer Read-Write Analog Outputs 11-16
APOS 8 Real Read-only Axis Position 11-17
AST 8 Integer Read-only Axis State 11-17
BAUD Scalar Integer Read-write IO Baud Rate 11-17
CERRA 8 Real Read-write Critical Error (Acceleration) 11-18
CERRI 8 Real Read-write Critical Error (Idle) 11-18
CERRV 8 Real Read-write Critical Error (Velocity) 11-19
CFG Scalar Integer Read-only Configuration Mode 11-19
COMMFL Scalar Integer Read-write Communication IO Flags 11-19
CTIME Scalar Real Read-write Control Cycle Time 11-20
DCN 8 Integer Read-only Axis DC, Number of 11-21
Samples
DCOM 8 Integer Read-write Drive Command 11-22
DCP 8 Real Read-only Axis DC, Period 11-22
DEC 8 Real Read-write Deceleration 11-22
DELI 8 Real Read-write Delay on Transition to Idle 11-23
State
DELV 8 Real Read-write Delay on Transition to 11-23
Velocity State
DISPCH Scalar Integer Read-write IO Default Channel 11-23
DOUT 8 Integer Read-only Drive Output 11-23
E_FREQ 8 Integer Read-write Encoder Frequency 11-24
E_SCMUL 8 Integer Read-write Encoder Sin-Cos Multiplier 11-24
E_TYPE 8 Integer Read-write Encoder Type 11-25
E2_TYPE 8 Integer Read-write Secondary Encoder Type 11-26
E2FAC 8 Real Read-write Secondary Encoder Factor 11-26
E2IND 8 Real Read-only Secondary Index Position 11-27

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-10 S t a nd a r d Va r i a b l e R e f e re n c e

Name Size Type Accessibility Description Page

ECHO Scalar Integer Read-write IO Echo Channel 11-27
EFAC 8 Real Read-write Encoder Factor 11-26
ENTIME 8 Real Read-write Enable Time 11-28
ERRA 8 Real Read-write Tolerable Error 11-28
(Acceleration)
ERRI 8 Real Read-write Tolerable Error (Idle) 11-28
ERRV 8 Real Read-write Tolerable Error (Velocity) 11-28
EXTIN 16 Integer Read-only Extended Inputs (HSSI) 11-29
EXTOUT 16 Integer Read-write Extended Outputs (HSSI) 11-29
F2POS 8 Real Read-only Secondary Feedback Position 11-29
FACC 8 Real Read-only Feedback Acceleration 11-30
FAULT 8 Integer Read-only Faults 11-30
FDEF 8 Integer Read-write Default Response Mask 11-30
FK Scalar Integer Read-only Function Key 11-30
FMASK 8 Integer Read-write Fault Mask 11-31
FPOS 8 Real Read-only Feedback Position 11-31
FVEL 8 Real Read-only Feedback Velocity 11-31
FVFIL 8 Real Read-write Feedback Velocity Filter 11-32
GACC 8 Real Read-only Group Acceleration 11-32
GJERK 8 Real Read-only Group Jerk 11-33
GMOT 8 Integer Read-only Group Motion Number 11-33
GMQU 8 Integer Read-only Group Motion Queue 11-33
GMTYPE 8 Integer Read-only Motion Type 11-34
GPATH 8 Real Read-only Group Path 11-34
GPHASE 8 Real Read-only Motion Phase 11-36
GRTIME 8 Real Read-only Remaining Motion Time 11-35
GSEG 8 Integer Read-only Group Segment Number 11-35
GVEC 8 Real Read-only Group Vector 11-37
GVEL 8 Real Read-only Group Velocity 11-37
I 100 Integer Read-Write I Array 11-37
IENA Scalar Integer Read-write Interrupt Enable/Disable 11-38
IMASK 8 Integer Read-write Index Mask 11-38

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-11

Name Size Type Accessibility Description Page

IN 8 Integer Read-only General-Purpose Dig. Inputs 11-39
IND 8 Real Read-only Index Position 11-39
ISENA 8 Integer Read-write Interrupt-Specific 11-40
Enable/Disable
IST 8 Real Read-only Index State 11-41
JERK 8 Real Read-write Jerk 11-41
KDEC 8 Real Read-write Kill deceleration 11-42
M2ARK 8 Real Read-only Secondary Mark Position 11-42
MARK 8 Real Read-only Mark Position 11-42
MERR 8 Integer Read-only Motor Error 11-43
MFF 8 Real Read-write Master Feedforward 11-45
MFLAGS 8 Integer Read-write Motor Flags 11-45
MPOS 8 Real Read-only Master Position 11-48
MST 8 Integer Read-only Motor State 11-48
ONRATE 10 Integer Read-write Autoroutine Rate 11-48
OUT 8 Integer Read-Write General-Purpose Dig. 11-49
Outputs
PCHARS 10 Integer Read-only Number of Characters 11-49
PE 8 Real Read-only Position Error 11-49
PERL 10 Integer Read-only Program Error Line 11-49
PERR 10 Integer Read-only Program Error 11-49
PEXL 10 Integer Read-only Executed Line 11-50
PFLAGS 10 Integer Read-write Program Flags 11-50
PLINES 10 Integer Read-only Number of Lines 11-50
PRATE 10 Integer Read-write Program Rate 11-51
PST 10 Integer Read-only Program State 11-51
RACC 8 Real Read-only Reference Acceleration 11-51
RPOS 8 Real Read-only Reference Position 11-51
RVEL 8 Real Read-only Reference Velocity 11-52
RVFIL 8 Real Read-write Reference Velocity Filter 11-52
S_DCN Scalar Integer Read-only System DC, Number of 11-53
Samples
S_DCP Scalar Real Read-only System DC, Period 11-53

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-12 S t a nd a r d Va r i a b l e R e f e re n c e

Name Size Type Accessibility Description Page

S_FAULT Scalar Integer Read-only System Faults 11-53
S_FDEF Scalar Integer Read-write System Default Response 11-53
Mask
S_FLAGS Scalar Integer Read-write System Flags 11-54
S_FMASK Scalar Integer Read-write System Fault Mask 11-55
S_SAFIN Scalar Integer Read-only (r/w System Safety Inputs 11-55
for Simulator)
S_SAFINI Scalar Integer Read-write System Safety Inputs 11-56
Inversion
S_ST Scalar Integer Read-only System State 11-56
SAFIN 8 Integer Read-only (r/w Safety Inputs 11-56
for Simulator)
SAFINI 8 Integer Read-write Safety Inputs Inversion 11-57
SETTLE 8 Real Read-write Settling Time 11-57
SLAFF 8 Real Read-write Acceleration feed-forward. 11-58
SLBIASA 8 Real Read only Current bias A. 11-58
(integrated
models)
Read-write
(nonintegrated
models)
SLBIASB 8 Real Read only Current bias B. 11-58
(integrated
models)
Read-write
(nonintegrated
models
SLCNP 8 Integer Read-write Number of poles for rotary 11-60
motor, 2 for linear motor
SLCOFFS 8 Real Read-write Commutation offset to be 11-59
added to the commutation
phase.
SLCORG 8 Real Read-write Commutation phase at the 11-59
point of origin.
SLCPA 8 Real Read-write Phase advance in electrical 11-60
degrees at XVEL velocity.
8 Real Read-write Commutation period. 11-60
SLCPRD

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-13

Name Size Type Accessibility Description Page

SLEMOS 8 Integer Read-write Sets the order of the sin-cos 11-60

filter.
8 Real Read-write Friction 11-60
SLFRC
SLIKI 8 Real Read-write Integrator coefficient in 11-61
current servo loop. (For
integrated models only).
SLIKP 8 Real Read-write Proportional coefficient in 11-61
current servo loop. (For
integrated models only).
SLIOFFS 8 Real Read-write Offset to be added to the 11-61
result of the current loop
control.
SLLIMIT 8 Real Read-write Software Left Limit 11-66
SLPBITS 8 Integer Read-write Number of bits in position 11-62
feedback (used with HSSI).
SLPKI 8 Real Read-write Integrator coefficient in 11-62
position servo loop.
SLPKP 8 Real Read-write Proportional coefficient in 11-62
position servo loop.
SLPLI 8 Real Read-write Integrator limit in position 11-62
servo loop.
SLPROUT 8 Integer Read-write Position feedback routing. 11-62
SLVKI 8 Real Read-write Integrator coefficient in 11-65
velocity servo loop.
SLVKP 8 Real Read-write Proportional coefficient in 11-65
velocity servo loop.
SLVLI 8 Real Read-write Integrator limit in velocity 11-65
servo loop.
SLVNATT 8 Real Read-write Notch filter attenuation. 11-65
SLVNFRQ 8 Real Read-write Notch filter frequency. 11-65
SLVNWID 8 Real Read-write Notch filter width. 11-66
SLVSOF 8 Real Read-write Second order filter 11-66
bandwidth.
SMNA 4 Integer Read-Write Software Monitor Address 11-66
SMNV 4 Integer Read-only Software Monitor Value 11-67
SRLIMIT 8 Real Read-write Software Right Limit 11-67
STEPF 8 Real Read-write Stepper Factor 11-67

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-14 S t a nd a r d Va r i a b l e R e f e re n c e

Name Size Type Accessibility Description Page

STEPW 8 Real Read-write Stepper Pulse Width 11-67
SYNV 8 Real Read-write Synchronous velocity 11-68
TARGRAD 8 Real Read-write Target Envelope 11-68
TIME Scalar Real Read-only Elapsed Time 11-69
TPOS 8 Real Read-write Target Position 11-69
V 100 Integer Read-Write V Array 11-69
VEL 8 Real Read-Write Default velocity 11-69
VELBRK 8 Real Read-write Velocity for Braking 11-70
XACC 8 Real Read-write Maximum Acceleration 11-70
XCURI 8 Real Read-write Maximum Idle Motor 11-70
Current
XCURV 8 Real Read-write Maximum Moving Motor 11-71
Current
XRMS 8 Real Read-write Maximum Allowed RMS 11-71
Current
XSACC 8 Real Read-write Maximum Slave Acceleration 11-71
XVEL 8 Real Read-write Maximum Velocity 11-71

11.3. Standard Variables Reference

ACC Acceleration
Size 8 (one value per axis)
Type Real
Accessibility Read-write
Comments ACC defines the acceleration of the motion profile. For one-axis motion
ACC defines axis acceleration. If the axis is a leading axis in a group, ACC
defines vector acceleration of common motion.
If the variable is assigned a new value when a motion is in progress, the
change does not affect the motions that are currently executing or were
created before the change. All motions created after the change will use the
new value.

AERR Axis Error

Size 8 (one value per axis)
Type Integer

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-15

AERR Axis Error

Accessibility Read-Only
Comments AERR stores the termination code of the last executed motion for trouble-
shooting purposes.
Single-axis motion stores its termination code in the AERR element that
corresponds to the moved axis. Multi-axis motion stores its termination code
in the AERR element that corresponds to the leading axis of the motion.
When a motion starts, the controller zeroes the elements corresponding of
AERR that correspond to the axes involved in the motion. When the motion
terminates for any reason, the controller stores the termination code in the
corresponding AERR element. Then the element remains unchanged until the
next motion starts for the corresponding axis.
The following termination codes are available:
0 The motion is in progress
5001 Motion finished successfully
5002 Motion was killed by kill command
5003 Motion was terminated by halt command
5010 Motion failed: Right Limit
5011 Motion failed: Left Limit
5012 Motion failed: Preliminary Right Limit
5013 Motion failed: Preliminary Left Limit
5014 Motion failed: Overheat
5015 Motion failed: Software Right Limit
5016 Motion failed: Software Left Limit
5017 Motion failed: Encoder Not Connected
5018 Motion failed: Encoder 2 Not Connected
5019 Motion failed: Drive Alarm
5020 Motion failed: Encoder Error
5021 Motion failed: Encoder 2 Error
5022 Motion failed: Position Error
5023 Motion failed: Critical Position Error
5024 Motion failed: Velocity Limit
5025 Motion failed: Acceleration Limit
5026 Motion failed: Overcurrent
5027 Motion failed: Servo Processor Alarm
5035 Motion failed: Program Error

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-16 S t a nd a r d Va r i a b l e R e f e re n c e

AERR Axis Error

5036 Motion failed: Memory Overuse
5037 Motion failed: Time Overuse
5038 Motion failed: Emergency Stop
5039 Motion failed: Servo Interrupt

AFLAGS Axis Flags

Size 8 (one value per axis)
Type Integer
Accessibility Read-write
Comments AFLAGS contains a set of bits that define different settings for the axis.
Currently, only the #NOGROUP bit can be set in the variable. #NOGROUP
disables including the axis in a group, so that any group or motion command
that requires including the axis in a group will fail.
Other bits are reserved for future use, and must be kept set at zero.

AIN Analog Inputs

Size 16
Type Integer
Accessibility Read-only
Comments AIN reads the current numerical value of the analog inputs.
Some aspects of AIN are model-dependent, including the quantity of inputs,
the A to D resolution, the voltage range, and whether the analog inputs are
shared-use with sin-cos encoder inputs. See the controller's Hardware Guide
for details.

AOUT Analog Outputs

Size 16
Type Integer
Accessibility Read-Write
Comments AOUT defines the current voltage of the analog outputs. Analog outputs can
also be used for signal monitoring (page 9-8).
Some aspects of AOUT are model-dependent, including the quantity of
outputs and their D to A resolution. See the controller's Hardware Guide for
details.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-17

APOS Axis Position

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments APOS provides the current reference value for the axis.
APOS updates each controller cycle if a motion that involves the axis is in
progress. Otherwise the variable retains its previous value.
If the corresponding motor has a default connection (MFLAGS has bit
#DEFCON raised), the APOS and RPOS variables are identical

AST Axis State

Size 8 (one value per axis)
Type Integer
Accessibility Read-only
Comments AST provides a set of bits that display the current state of the axis.
Bit name No. Description
#LEAD 0 The bit is set if the axis is leading in a group
#PEG 2 The bit is set when PEG is in progress
#DC 3 The bit is set while the axis data collection is in
progress
#MOVE 5 The bit is set while the axis is involved in a motion
#ACC 6 Accelerating
#BUILDUP 7 Segments build-up
#VELLOCK 8 The bit raised when the slave is synchronized to master
in velocity lock mode. While the bit is raised the slave
velocity strictly follows the master velocity.
#POSLOCK 9 The bit is raised when the slave is synchronized to
master in position lock mode. While the bit is raised
the slave position follows strictly the master position.

BAUD IO Baud Rate

Size Scalar
Type Integer
Accessibility Read-write

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-18 S t a nd a r d Va r i a b l e R e f e re n c e

BAUD IO Baud Rate

Comments BAUD defines the communication rate in bits per second for the serial
communication channel.
As a configuration variable, BAUD can be changed only in configuration
mode. The change in variable status takes effect only after controller restart.

BONTIME Brake On Time (Brake Activation Time)

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments The value specifies the brake activation time. See also disabling brake
operation, page Error! Bookmark not defined..

BOFFTIME Brake Off Time (Brake Deactivation Time)

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments The value specifies the brake deactivation time. See also enabling brake
operation, page 7-22.

CERRA Critical Error (Acceleration)

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments CERRA defines critical position error when the motor is moving with
acceleration.
Variables CERRI, CERRV, CERRA control the detection of Critical
Position Error Faults. For details see page 8-23.

CERRI Critical Error (Idle)

Size 8 (one value per motor)
Type Real
Accessibility Read-write

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-19

CERRI Critical Error (Idle)

Comments CERRI defines critical position error when the motor is idle.
Variables CERRI, CERRV, CERRA control detection of Critical Position
Error Faults. For details see page 8-23

CERRV Critical Error (Velocity)

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments CERRV defines critical position error when the motor is moving with
constant velocity.
Variables CERRI, CERRV, CERRA control detection of Critical Position
Error Faults. For details see page 8-23.

CFG Configuration Mode

Size Scalar
Type Integer
Accessibility Read-only
Comments CFG indicates the application state.
When the controller is in configuration mode, CFG is 1.
When the controller is in protected mode, CFG is 0.
An attempt to assign a new value to a protected variable when CFG is 0 will
cause an error.
See Section 5.10.

COMMFL Communication IO Flags

Size Scalar
Type Integer
Accessibility Read-write
Comments COMMFL contains a set of bits that affect controller communication.
Bit name No. Description
#VERBOSE 0 Controls the form of error messages. When the
bit is set, the controller provides an extended
message when an error occurs.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-20 S t a nd a r d Va r i a b l e R e f e re n c e

COMMFL Communication IO Flags

#SAFEMSG 4 Controller sends unsolicited messages in Safe
communication format. Normally the user does
not need to change this bit.
#CSUMMSG 6 If bit 4 is set, then this bit determines that a
checksum is included in unsolicited messages.
Normally the user does not need to change this
bit.
#NOCOMM 7 Controls the communication in protected mode.
If the bit is raised, the controller ignores any
command received via communication channels
except the queries that start from ‘?’ character.
The bit is not effective if the controller is in
configuration mode. The default of the bit is 0.
The #UNPROTECT command is received and
executed even if this bit is raised.
#NOQUERY 8 Controls the communication in protected mode.
If the bit is raised, the controller ignores any
query received via communication channels.
The bit is not effective if the controller is in
configuration mode. The default of the bit is 0.

CTIME Controller Cycle Time

Size Scalar
Type Real
Accessibility Read-write
Comments You can select from the values 0.5, 1.0 (default) and 2.0 to define the length
of the controller cycle.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-21

CTIME Controller Cycle Time

1. Changing CTIME to 0.5 may overload the
controller. After changing, monitor the
controller usage with the #U command at
WARNING different points of the application (see
Report of Real-Time Usage (#U), page 4-
21). If at any point the maximal usage
exceeds 80%, the 0.5 millisecond cycle
cannot be used.
2. With 2 millisecond cycle the controller
does not support serial communication at
115200 baud rate. The maximum baud rate
is 57600.
3. The SPiiPlus MMI currently does not
support changing CTIME using the
Configurator/Adjuster. Change CTIME
using the Communication Terminal.
4. The controller uses the CTIME value at
startup time only. Therefore, any change in
CTIME will be active after the controller
restart. After changing CTIME, execute
#SAVE and #HWRES commands (a fast
way to do this is to select the Save and
Restart commands in the Tools menu of
the SPiiPlus MMI.

Many operation in the controller are synchronized to the controller cycle. For
example, profile generation is executed each controller cycle. Therefore, if
CTIME is 0.5 the profile generation will be calculated twice each
millisecond.

DCN Axis DC, Number of Samples

Size 8 (one value per axis)
Type Integer
Accessibility Read-only
Comments DCN provides the number of stored samples in axis data collection.
If an axis data collection is in progress, the variable increments each time
when the next sample is stored. When the data collection terminates, the
variable holds the last value, until the next data collection starts for the same
axis.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-22 S t a nd a r d Va r i a b l e R e f e re n c e

DCOM Drive Command

Size 8
Type Integer
Accessibility Read-write
Comments In open-loop mode, the controller calculates the drive voltage output taking
the value of DCOM as the percentage of maximum available drive output
voltage.
For example, the SPiiPlus PCI-4/8 provides differential drive output in the
range from –10 to +10V. Therefore, assigning 100 to DCOM provides +10V
on the drive output, –100 corresponds to –10V and 0 to 0V.
The drive output voltage is model-dependent. See the controller's Hardware
Guide for details.

DCP Axis DC, Period

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments DCP provides the sampling period of axis data collection.
When an axis data collection starts, DCP is assigned a real data collection
period that may differ from the period specified in the DC command, because
the period is rounded to integer number of controller cycles.
Unless a temporal data collection is specified, the value remains unchanged
until the next data collection starts for the same axis. In case of temporal data
collection, the period may change during the data collection.

DEC Deceleration
Size 8 (one value per axis)
Type Real
Accessibility Read-write
Comments DEC defines the deceleration of the motion profile. For one-axis motion
DEC defines axis deceleration. If the axis is a leading axis in a group, DEC
defines the vector deceleration of common motion.
If DEC is changed when a motion is in progress, the change does not affect
the motions that are currently executing or were created before the change.
All motions created after the change will use the new value.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-23

DELI Delay on Transition to Idle State

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments DELI is used to detect Position Error Fault (Page 8-21) and Critical Position
Error Fault (Page 8-23).
DELI defines delay when using ERRI and CERRI according to the real
motor transition to idle state.

DELV Delay on Transition to Velocity State

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments DELV is used to detect Position Error Fault and Critical Position Error Fault.
DELV defines delay in using ERRV and CERRV after ERRA and CERRA
according to the real motor transition to constant velocity motion. For details
see page 11-18.

DISPCH IO Default Channel

Size Scalar
Type Integer
Accessibility Read-write
Comments DISPCH defines communication channel for messages that are not replies to
terminal commands (unsolicited messages). The controller generates an
unsolicited message as a result of a disp or send command in the executed
ACSPL+ program.
If DISPCH = -1, unsolicited messages are sent to the same channel where the
last command from the host was received (if no terminal command was
received yet, the unsolicited message is discarded).
If DISPCH specifies a valid communication channel, all unsolicited
messages are sent to this channel irrespective of the channel used for terminal
commands.

DOUT Drive Output

Size 8
Type Integer
Accessibility Read-only

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-24 S t a nd a r d Va r i a b l e R e f e re n c e

DOUT Drive Output

Comments Range: -32767 to 32768.
DOUT provides the current value of the control signal generated by the
controller.
The voltage that corresponds to the value of DOUT, depends on the
controller model. See the controller's Hardware Guide for details.

E_FREQ Encoder Frequency

Size 8 (one value per motor)
Type Integer
Accessibility Read-write
Comments E_FREQ defines the maximum encoder pulse frequency measured after the
internal x4 multiplication.
The only available values for E_FREQ are 20 (MHz) and 40 (MHz). At
maximum frequency 20MHz the controller provides more filtering of encoder
signal. Therefore, the user must change the value to 40 (MHz) only if the
encoder used in the application provides frequency more than 20MHz at the
maximum required velocity.

E_SCMUL Encoder Sin-Cos Multiplier

Size 8 (one value per motor)
Type Integer
Accessibility Read-write
Comments E_SCMUL specifies the sin-cos multiplication factor as a power of 2. The
maximum value of 16 corresponds to a multiplication of 65536 = 216. The
minimum value of 2 corresponds to a multiplication of 4 = 22.

EOFFS Encoder Offset

Size 8 (one value per motor)
Type Real
Accessibility Read-write

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-25

EOFFS Encoder Offset

Comments EOFFS is a read-only standard variable that provides the offset between the
raw feedback in encoder counts and the FPOS value calculated by the
controller. The value of EOFFS changes when the set command defines a new
origin for an axis.
When reading the feedback position from the SP, the controller executes
feedback transform according to the formula:
FPOS = FP*EFAC + EOFFS
where FPOS is the controller feedback position in user units, FP is an SP-
calculated feedback position in encoder counts, EFAC is a user-defined value
of the corresponding EFAC factor, and EOFFS represents an offset.

E2OFFS Secondary Encoder Offset

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments E2OFFS is a read-only standard variable that provides the offset between the
raw feedback from the secondary encoder (in encoder counts) and the F2POS
value calculated by the controller. The value of E2OFFS changes when the
set command defines a new origin for the axis's secondary feedback.
When reading the secondary feedback position from the SP, the controller
executes feedback transform according to the formula:
F2POS = FP2*E2FAC + E2OFFS
where F2POS is the secondary controller feedback position in user units, FP2
is an SP-calculated secondary feedback position in encoder counts, E2FAC is
a user-defined value of the corresponding E2FAC factor, and E2OFFS
represents an offset.

E_TYPE Encoder Type

Size 8 (one value per motor)
Type Integer
Accessibility Read-write
Comments E_TYPE defines encoder type.
The most common encoder type is quadrature, which corresponds to the
default value 3.
As a configuration variable, the variable can be changed only if the controller
is in configuration mode.
The following values are available:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-26 S t a nd a r d Va r i a b l e R e f e re n c e

E_TYPE Encoder Type

0 Up-Down Counter
1 Clock-Direction Counter
3 Quadrature encoder
4 Sin-cos encoder multiplier

E2_TYPE Secondary Encoder Type

Size 8 (one value per motor)
Type Integer
Accessibility Read-write
Comments E2_TYPE defines the secondary encoder type.
The most common encoder type is quadrature, which corresponds to the
default value 3.
The following values are available:
0 Up-Down Counter
1 Clock-Direction Counter
3 Quadrature encoder

EFAC Encoder Factor

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments EFAC defines a factor between the raw feedback in encoder counts and the
FPOS value calculated by the controller.
When reading the feedback position from the SP, the controller executes
feedback transform according to the formula:
FPOS = FP*EFAC + EOFFS
where FPOS is the controller feedback position in user units, FP is an SP-
calculated feedback position in encoder counts, EFAC is a user-defined value
of the corresponding EFAC factor, and EOFFS represents an offset.

E2FAC Secondary Encoder Factor

Size 8 (one value per motor)
Type Real
Accessibility Read-write

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-27

E2FAC Secondary Encoder Factor

Comments E2FAC defines a factor between the secondary raw feedback in encoder
counts and the F2POS value calculated by the controller.
When reading the secondary feedback position from the SP, the controller
executes feedback transform according to the formula:
F2POS = FP2*E2FAC + E2OFFS
where F2POS is the secondary controller feedback position in user units, FP2
is an SP-calculated secondary feedback position in encoder counts, E2FAC is
a user-defined value of the corresponding E2FAC factor, and E2OFFS
represents an offset.

E2IND Secondary Index Position

Size 8 (one value per motor)
Type Real
Accessibility Read-only
Comments E2IND holds the position of the last encountered secondary encoder index.
The variable operates in connection with bit #IND2 in variable IST.
After power-up bit #IND2 is reset and the value of E2IND is undefined.
When the motor encounters a secondary encoder index, the bit is raised and
the current position (value of variable F2POS) is latched into the variable
E2IND. Latching is provided with hardware support, therefore the delay is
extremely small.
If the motion continues and the motor encounters the next index, the new
index value is ignored as long as #IND2 remains raised.
The application needs to clears bit #IND2 explicitly in order to resume the
latching logic.

ECHO IO Echo Channel

Size Scalar
Type Integer
Accessibility Read-write
Comments ECHO defines an echo communication channel.
If ECHO specifies a valid communication channel, the controller sends an
echo of each command received from any communication channel to the
specified channel.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-28 S t a nd a r d Va r i a b l e R e f e re n c e

ENTIME Enable Time

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments ENTIME controls the execution of the enable command.
Exact usage of the variable depends on the flag bit MFLAGS.#ENTIME: If
the bit is zero, the ENTIME value defines the maximum allowed value of
motor enable. The enable operation actually ends as soon as the drive
switches signal SAFIN.#DRIVE to inactive state. If the signal remains active
more than ENTIME milliseconds, the enable command fails.
If the bit is raised, the value of ENTIME defines the time of the enable
operation. The enable command in the application always takes ENTIME
milliseconds. After this interval the motor is considered enabled. If, after
ENTIME milliseconds the SAFIN.#DRIVE signal is still in active state, the
controller declares a Drive Alarm fault.

ERRA Tolerable Error (Acceleration)

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments ERRA defines the maximum tolerable position error when the motor is
moving with acceleration.
Variables ERRI, ERRV, ERRA control the detection of Position Error Fault.
For details see page 11-28.

ERRI Tolerable Error (Idle)

Size 8 (one value per motor)
Type Real
Accessibility Read-write
Comments ERRI defines the maximum tolerable position error when the motor is idle.
Variables ERRI, ERRV, ERRA control detection of Position Error Fault.
For details see page 8-21.

ERRV Tolerable Error (Velocity)

Size 8 (one value per motor)
Type Real
Accessibility Read-write

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-29

ERRV Tolerable Error (Velocity)

Comments ERRV defines the maximum tolerable position error when the motor is
moving with constant velocity.
Variables ERRI, ERRV, ERRA control detection of Position Error Fault.
For details see page 8-21

EXTIN Extended Inputs (HSSI inputs)

Size 16
Type Integer
Accessibility Read-only
Comments The bits of EXTIN read the current state of the HSSI inputs. Each element of
the array reads 16 bits. Up to 256 inputs can be read (the number of inputs
depends on the HSSI module).
For details about the HSSI, see the HSSI Modules Hardware Guide.
The size of EXTIN is model-dependent. See the controller's Hardware Guide
for details.

EXTOUT Extended Outputs (HSSI outputs)

Size 16
Type Integer
Accessibility Read-Write
Comments The bits of EXTOUT read/write the state of the HSSI outputs. Each element
of the array contains 16 bits. Up to 256 outputs can be read/written (the
number of outputs depends on the HSSI module).
For more information, refer to the description of the particular HSSI module
in the HSSI Modules Hardware Guide.

F2POS Secondary Feedback Position

Size 8 (one value per motor)
Type Real
Accessibility Read-only
Comments F2POS provides the current secondary feedback value for the motor.
The user can shift the origin of secondary feedback position using the set
command.
The user can select the units of secondary feedback position by setting the
E2FAC variable.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-30 S t a nd a r d Va r i a b l e R e f e re n c e

FACC Feedback Acceleration

Size 8 (one value per motor)
Type Real
Accessibility Read-only
Comments FACC provides the feedback acceleration value for the motor.
The value is calculated by digital differentiation of the FVEL variable.

FAULT Faults
Size 8 (one value per motor)
Type Integer
Accessibility Read-only
Comments FAULT provides a set of bits that present the current state of each axis fault.
The user can set the bits in variable FMASK to define which faults must be
examined and processed for an axis.
The faults are examined each controller cycle. If the fault condition is true,
the corresponding bit is set; otherwise the bit is reset. The user can check the
fault bits in the ACSPL+ program, or can define automatic response using
autoroutines.
For a list of fault bits see section 0.

FDEF Default Response Mask

Size 8 (one value per motor)
Type Integer
Accessibility Read-write
Comments FDEF provides a set of bits for controlling fault processing; each bit controls
the default processing of one fault.
If a bit in the variable is raised, the controller executes the default response
when the corresponding fault occurs. If the bit is reset, the default response is
disabled.
Not every fault has a default response. For a fault that has no default
response, the corresponding bit of FDEF is inoperative.
For a list of fault bits see section 0.

FK Function Key
Size Scalar
Type Integer

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-31

FK Function Key
Accessibility Read-only
Comments FK is used by the controller to store functional keys in an input string
processed with the input command (see Section 0).
If the controller encounters a zero character in the input string, it stores value
of the next character in FK.
This is the usual way to receiving function key codes (F1 – F12).
An autoroutine can be used to respond to changes in FK.

FMASK Fault Mask

Size 8 (one value per motor)
Type Integer
Accessibility Read-write
Comments FMASK provides a set of bits, where each bit enables the examination and
processing of a type of fault.
If a bit in the variable is raised, the corresponding fault is examined each
controller cycle.
If a bit in the variable is reset, the corresponding fault is not examined.
Therefore, the corresponding bit in FAULT can never be set
For a list of fault bits see section 0.

FPOS Feedback Position

Size 8 (one value per motor)
Type Real
Accessibility Read-only
Comments FPOS provides the current feedback position for the motor.
The user can shift the origin of feedback position using the set command.
The user can select the units of feedback position by setting the EFAC
variable.

FVEL Feedback Velocity

Size 8 (one value per motor)
Type Real
Accessibility Read-only

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-32 S t a nd a r d Va r i a b l e R e f e re n c e

FVEL Feedback Velocity

Comments FVEL provides the feedback velocity value for the motor. The value is
calculated by digital differentiation of FPOS.
FVFIL defines a power of the smoothing filter used in the FVEL calculation.

FVFIL Feedback Velocity Filter

Size 8
Type Real
Accessibility Read-write
Comments FVFIL determines the intensity (in %) of the filter that the controller uses
when calculating the FVEL variable.
FVFIL = 0 corresponds to no filtering. In this case the controller calculates
FVEL as the derivative of the FPOS variable:
Δ = (FPOSn - FPOSn-1) * K
FVELn = Δ
where K is a scaling factor that reduces FVEL to user units per second.
As the FPOS value is supplied by a discrete physical sensor, the FVEL value
calculated without filtering contains a considerable amount of noise.
Non-zero value of FVFIL provides additional filtering in the FVEL
calculation according to the formula:
FVELn = Δ * (1 – FVFIL/100) + FVEL n-1* FVFIL/100

GACC Group Acceleration

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments GACC provides the current value of motion acceleration.
The variable updates each controller cycle if one of the following is true:
ƒ One-axis motion for the axis is in progress, or
ƒ The axis is a leading axis in a group and the motion in the group is in
progress
Otherwise the variable retains its previous value.
In the case of one-axis motion the variable provides axis acceleration. If the
axis is a leading axis, the variable provides the vector acceleration of the
group motion.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-33

GJERK Group Jerk

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments GJERK provides the current value of motion jerk.
The variable updates each controller cycle if one of the following is true:
ƒ The axis is involved in One-axis motion progress, or
ƒ the axis is a leading axis in a group and the motion in the group is in
progress
Otherwise the variable retains its previous value.
In the case of one-axis motion the variable provides the axis jerk. If the axis is
a leading axis, the variable provides the vector jerk of the common motion.

GMOT Group Motion Number

Size 8 (one value per axis)
Type Integer
Accessibility Read-only
Comments GMOT provides the ordinal number of the current motion.
The variable is valid only if one of the following is true:
ƒ One-axis motion for the axis is in progress, or
ƒ The axis is a leading axis in a group and the motion in the group is in
progress
After power-up the variable is zero. The variable increments each time when
a motion of the corresponding axis / axis group terminates.
GMOT resets to zero each time when the axis is regrouped, i.e. a group that
contains given axis is created or split-up.

GMQU Group Motion Queue

Size 8 (one value per axis)
Type Integer
Accessibility Read-only

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-34 S t a nd a r d Va r i a b l e R e f e re n c e

GMQU Group Motion Queue

Comments GMQU provides the total number of motions in the motion queue including
the currently executing motion. The maximum motion queue per axis is 5.
The variable is valid only if one of the following is true:
ƒ One-axis motion for the axis is in progress, or
ƒ The axis is a leading axis in a group and the motion in the group is in
progress
After power-up GMQU is zero and increments by one each time a motion of
the corresponding axis/axis group is issued. It decrements by one each time a
motion of the corresponding axis/axis group terminates.
GMQU resets to zero each time when the axis is regrouped, i.e. a group that
contains the axis is created or split-up.

GMTYPE Motion Type

Size 8 (one value per axis)
Type Integer
Accessibility Read-only
Comments The controller updates the variable each time that a motion involving the
corresponding axis or axis group starts or terminates .
The variable is updated according to the type of the motion:
0 – no motion
1 – ptp motion
2 – mptp motion
3 – track motion
4 – mseg motion
5 – jog motion
6 – slave motion
7 – path motion
8 – pvspline motion

GPATH Group Path

Size 8 (one value per axis)
Type Real
Accessibility Read-only

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-35

GPATH Group Path

Comments GPATH provides the current path value (the distance from the motion origin
to the current motion point).
The variable updates each controller cycle if one of the following is true:
• One-axis motion for the axis is in progress, or
• The axis is a leading axis in a group and the motion in the group is in
progress
Otherwise the GPATH holds its previous value.
In the case of one-axis motion the GPATH provides a positive distance from
the initial point of the motion. If the axis is a leading axis, the variable
provides a vector distance along the trajectory from the motion origin.

GRTIME Remaining Motion Time

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments GRTIME provides an estimated value of time remaining (in milliseconds)
until the end of the current motion.
The variable updates each controller cycle if one of the following is true:
ƒ One-axis motion for the axis is in progress, or
ƒ The axis is a leading axis in a group and a motion in the group is in
progress
GRTIME does not update if the motion is of Jog or Master-Slave type. If the
variable does not update, it retains its previous value.
The GRTIME error of calculation is never more than one controller cycle,
except during the initial motion acceleration, until the motion comes to the
required velocity or to the inflection point, if the required velocity cannot be
achieved.

GSEG Group Segment Number

Size 8 (one value per axis)
Type Integer
Accessibility Read-only

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-36 S t a nd a r d Va r i a b l e R e f e re n c e

GSEG Group Segment Number

Comments GSEG provides the ordinal number of the currently executing segment.
The variable updates only if one of the following is true:
ƒ One-axis motion for the axis is in progress, or
ƒ The axis is a leading axis in a group and the motion in the group is in
progress
Otherwise the variable retains its previous value.
The variable updates as follows:
ƒ If the current motion in the axis/axis group is not multisegment, the
GSEG value is –1.
ƒ The value resets to zero when a multisegment motion starts
ƒ The value increments each time when the motion passes from one
segment to the next.
ƒ The value decrements each time the motion passes from one segment to
the previous (possible only in master-slave motion).
ƒ Because the motion returns to the start point in cyclic motion, the
variable may appear greater than a number of segment in the motion if the
motion overruns the segment sequence in positive direction.
ƒ For master-slave cyclic motion the variable may appear negative, if the
motion overruns the segment sequence in negative direction.

GPHASE Motion Phase

Size 8
Type Real
Accessibility Read-only
Comments GPHASE provides the current phase of a motion and can have the following
values:
0 – no motion
1 – acceleration buildup
2 – constant acceleration
3 – acceleration finishing
4 – constant velocity
5 – deceleration buildup
6 – constant deceleration
7 – deceleration finishing
8 – kill deceleration
9 – asynchronous phase of master-slave motion
10 – synchronous phase of master-slave motion
11 – stalled phase of master-slave motion.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-37

GVEC Group Vector

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments GVEC provides the components of the tangent vector to the trajectory of the
currently executed motion for each involved axis.
The variable updates each controller cycle, if a motion involving the axis is in
progress. Otherwise the variable retains its previous value.
If the motion is one-axis, the variable is equal to 1 or -1 one depending on the
motion direction.
If a multi-axis motion is in progress in a group, the GVEC components
corresponding to the axes included in the group, are updated each controller
cycle. These components, taken as a whole, build up a tangent vector to the
motion trajectory.

GVEL Group Velocity

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments GVEL provides the current motion velocity value.
The variable updates each controller cycle if one of the following is true:
ƒ One-axis motion for the axis is in progress, or
ƒ The axis is a leading axis in a group and the motion in the group is in
progress
Otherwise the variable retains its previous value.
In case of one-axis motion GVEL provides the absolute instant velocity. If
the axis is a leading axis, the variable provides a vector velocity of the
common motion.

I I Array
Size 100
Type Integer
Accessibility Read-Write
Comments I defines a general-purpose array that can be used in any application program
as a predefined global variable.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-38 S t a nd a r d Va r i a b l e R e f e re n c e

IENA Interrupt Enable/Disable

Size Scalar
Type Integer
Accessibility Read-write
Comments Scalar variable that enables/disables all interrupts that belong to a specific
interrupt status bit.
The IENA variable contains the following bits:

3 Enable PEG X 14 Enable Mark 2 T interrupt

interrupt
4 Enable PEG Y 15 Enable Emergency Stop interrupt
interrupt
5 Enable PEG Z 16 Enable Physical Motion End
interrupt interrupt
6 Enable PEG T 17 Enable Logical Motion End
interrupt interrupt
7 Enable Mark 1 X 18 Enable Motion Failure (Motion
interrupt interruption due to a fault)
interrupt
8 Enable Mark 2 X 19 Enable Motor Failure (Motor
interrupt disable due to a fault) interrupt
9 Enable Mark 1 Y 20 Enable Program Termination
interrupt interrupt
10 Enable Mark 2 Y 21 Enable Dynamic Buffer interrupt
interrupt
11 Enable Mark 1 Z 22 Enable ACSPL+ interrupt (by
interrupt INTERRUPT command)
12 Enable Mark 2 Z 23 Enable Digital Input interrupt
interrupt
13 Enable Mark 1 T
interrupt

IMASK Index Mask

Size 8 (one value per motor)
Type Integer
Accessibility Read-write

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-39

IMASK Index Mask

Comments IMASK contains a set of bits that define which motor index and mark signals
are processed.
If a bit is zero, the controller neither analyzes or latches the corresponding
index/mark signal.
Every axis does not provide all index and mark signals. Secondary encoder
index is available only if a secondary encoder is available. Mark signals are
typically unavailable for axes A, B, C, D.
The following bits are used in IMASK:
Bit name No. Description
#IND 0 Primary encoder index.
#IND2 1 Secondary encoder index.
#MARK 2 Mark1
#MARK2 3 Mark2

IN General-Purpose Digital Inputs

Size 8
Type Integer
Accessibility Read-only
Comments The bits of IN read the current state of the general-purpose digital inputs. See
detailed description (page 9-3).
Some aspects of IN are model-dependent, including the quantity of digital
inputs, their resolution, and whether mark inputs can be reconfigured as
general purpose inputs. See the controller's Hardware Guide for details.

IND Index Position

Size 8 (one value per motor)
Type Real
Accessibility Read-only

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-40 S t a nd a r d Va r i a b l e R e f e re n c e

IND Index Position

Comments IND holds the position of the last encountered encoder index. The variable
operates in connection with bit #IND in variable IST.
After power-up the flag bit #IND is reset and the value of the IND, the Index
Position, is undefined, because an index capture has not yet occurred. When
the motor encounters an encoder index, the bit is raised and the current
position (value of variable FPOS) is latched into the variable IND. Latching
is provided with hardware support, therefore the delay is extremely small.
If the motion continues and the motor encounters the next index, the new
index value is ignored as long as #IND remains raised.
To resume the latching logic the #IND bit must be explicitly cleared by the
command IST.#=0.

ISENA Interrupt-Specific Enable/Disable

Size 8
Type Integer
Accessibility Read-write
Comments Array that enables/disables interrupts within a specific interrupt status bit.
Each elements corresponds to one interrupt status bit and specifies which axes
or buffers or inputs are enabled to cause interrupt.
The ISENA array contains the following elements:

0 Controls physical 4 Controls program termination

motion end interrupt. interrupt.
Bit 0 enables Bit 0 enables interrupts from
interrupts from axis X, buffer 0, bit 1 – buffer 1, and so
bit 1 – axis Y, and so on.
on.
1 Controls logical 5 Controls command execution
motion end interrupt. interrupt (dynamic buffer only).
Bit 0 enables Bit 0 enables interrupts from
interrupts from axis X, buffer 0, bit 1 – buffer 1, and so
bit 1 – axis Y, and so on.
on.
2 Controls motion 6 Controls ACSPL+ interrupt
failure interrupt. caused by interrupt command.
Bit 0 enables Bit 0 enables interrupts from
interrupts from axis X, buffer 0, bit 1 – buffer 1, and so
bit 1 – axis Y, and so on.
on.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-41

ISENA Interrupt-Specific Enable/Disable

3 Controls motor failure 7 Controls digital input interrupt.

interrupt. Bit 0 enables interrupts from input
Bit 0 enables 0, bit 1 – input 1, and so on.
interrupts from axis X,
bit 1 – axis Y, and so
on.

IST Index State

Size 8 (one value per motor)
Type Integer
Accessibility Read-Write
Comments IST contains a set of bits that indicate the state of the index and the mark
variables.
The controller processes index/mark signals as follows:
When an index/mark signal is encountered for the first time, the controller
latches FPOS or F2POS to one of the variables IND, E2IND, MARK,
M2ARK and raises the corresponding bit of IST.
As long as a bit of IST is raised, the controller does not latch another value to
the corresponding variable even if the signal occurs again.
To resume the latching logic, the application must explicitly reset the
corresponding bit of IST.
The following bits are used in IST:
Bit name No. Description
#IND Primary encoder index.
#IND2 Secondary encoder index.
#MARK Mark1
#MARK2 Mark2

JERK Jerk
Size 8 (one value per axis)
Type Real
Accessibility Configuration

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-42 S t a nd a r d Va r i a b l e R e f e re n c e

JERK Jerk
Comments JERK defines the jerk of the motion profile. For one-axis motion JERK
defines the axis jerk. If the axis is a leading axis in a group, JERK defines
vector jerk of the common motion.
If the variable is changed when a motion is in progress, the change does not
affect the motions that are executing or were created before the change. All
motions created after the change will use the new value of JERK.

KDEC Kill deceleration

Size 8 (one value per axis)
Type Real
Accessibility Configuration
Comments KDEC defines deceleration when a motion is killed by the user or failed due
to a fault. For one-axis motion the value defines axis deceleration. If the axis
is a leading axis in a group, its value defines vector deceleration when the
common motion is killed or failed.
If the variable is changed when a motion is in progress, the change does not
affect the motions that are executing or were created before the change. All
motions created after the change will use the new value.

M2ARK Secondary Mark Position

Size 8 (one value per motor)
Type Real
Accessibility Read-only
Comments M2ARK holds the position of the last encountered MARK2 signal. The
variable operates in connection with bit #MARK2 in variable IST.
After power-up bit #MARK2 is reset and the value of M2ARK is undefined.
When the motor encounters MARK2 signal, the bit is raised and the current
position (value of variable FPOS) is latched into the variable M2ARK.
Latching is provided with hardware support, therefore the delay is extremely
small.
If the motion continues and the motor encounters another MARK2 signal the
new value is ignored as long as #MARK2 remains raised.
To resume the latching logic the #MARK bit must be explicitly cleared.

MARK Mark Position

Size 8 (one value per motor)
Type Real

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-43

MARK Mark Position

Accessibility Read-only
Comments MARK holds the position of the last encountered MARK1 hardware signal.
The variable operates together with bit #MARK in variable IST.
After power-up bit #MARK is reset and the value of MARK is undefined.
When the motor encounters the MARK1 signal, the bit is raised and the
current position (the value of variable FPOS) is latched into the variable
MARK. Latching is provided with hardware support, therefore the delay is
extremely small.
If the motion continues and the motor encounters another MARK1 signal the
new value is ignored as long as #MARK remains raised.
To resume the latching logic the #MARK bit must be explicitly cleared.

MERR Motor Error

Size 8 (one value per axis)
Type Integer
Accessibility Read-Only
Comments MERR stores the reason why the motor was disabled.
When a motor is enabled, the controller zeroes the corresponding element
of MERR. When the motor is disabled for any reason, the controller stores
the error code in the corresponding MERR element. Then the element
remains unchanged until the motor is enabled again.

MERR values (see also error codes, page 12.5):

MERR values 5060 to 5078 are drive alarms
MODEL and are supported only in motion control
DEPENDENT products that include integrated drives (SPiiPlus
PCI-DDM4A and SPiiPlus CM). For more
detailed descriptions of the alarms and
troubleshooting instructions, see the motion
control product's Hardware Guide.
0 Motor enabled
5003 Motion was terminated by user
5004 The motor was disabled by disable command
5005 Motion was terminated because a motor was disabled
5006 Motion was killed
5007 Motor was disabled due to a generalized fault
5008 Motion was killed due to a generalized fault
5010 Motor failed: Right Limit

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-44 S t a nd a r d Va r i a b l e R e f e re n c e

MERR Motor Error

5011 Motor failed: Left Limit
5012 Motor failed: Preliminary Right Limit
5013 Motor failed: Preliminary Left Limit
5014 Motor failed: Overheat
5015 Motor failed: Software Right Limit
5016 Motor failed: Software Left Limit
5017 Motor failed: Encoder Not Connected
5018 Motor failed: Encoder 2 Not Connected
5019 Motor failed: Drive Alarm
5020 Motor failed: Encoder Error
5021 Motor failed: Encoder 2 Error
5022 Motor failed: Position Error
5023 Motor failed: Critical Position Error
5024 Motor failed: Velocity Limit
5025 Motor failed: Acceleration Limit
5026 Motor failed: Overcurrent
5027 Motor failed: Servo Processor Alarm
5035 Motor failed: Program Error
5036 Motor failed: Memory Overuse
5037 Motor failed: Time Overuse
5038 Motor failed: Emergency Stop
5039 Motor failed: Servo Interrupt
5060 (Integrated models only) Drive alarm: No fault
5061 (Integrated models only) Drive alarm: Short circuit.
(Integrated models only) Drive alarm: External protection
5062
activated.
5063 (Integrated models only) Drive alarm: Power supply too low.
5064 (Integrated models only) Drive alarm: Power supply too high.
5065 (Integrated models only) Drive alarm: Temperature too high
5067 5066 (Integrated models only) Drive alarm: Power supply 24VF1.
5068 5067 (Integrated models only) Drive alarm: Power supply 24VF2.
5069 5068 (Integrated models only) Drive alarm: Emergency Stop
5075 5069 (Integrated models only) Drive alarm: Power down

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-45

MERR Motor Error

5100 5075 (Integrated models only) Drive alarm: Digital drive interface
not connected.

MFF Master Feedforward

Size 8
Type Real
Accessibility Configuration
Comments MFF specifies the feedforward time for the MPOS calculation in
milliseconds.
The controller calculates the MPOS value according to a formula supplied by
the master command. Non-zero value of MFF provides additional
extrapolation of the calculated value to the predicted value at the current time
plus MFF. The purpose is to compensate delay introduced by the controller
and the external circuits.
The default value of MFF depends on the controller model so that it
compensates the delay introduced by the controller itself. Increase the MFF
value if you want to compensate additional delay introduced by sensor or
other circuits.

MFLAGS Motor Flags

Size 8 (one value per motor)
Type Integer
Accessibility Configuration
Comments The MFLAGS variable contains a set of bits that configure the motor.
MFLAGS is typically configured using the Adjuster or Configurator utilities
in the SPiiPlus MMI software tool.
Use direct bit assignment for on the fly change, for example from closed-loop
operation to the open-loop and vice versa.
The MFLAGS index number is the motor number minus one. For example,
MFLAGS2.#DEFCON actually points to motor/axis number 3, or the -Z-
axis. The axis number (ordinal numbers) start at (1) while the MFLAGs array
actually starts at (0).
Bit name No Description
.
#DUMMY 0 If the bit is one, the axis is dummy. The control
algorithm is not calculated for this axis.
#OPEN 1 If the bit is one, the controller provides open-loop
control. See Open-Loop Operation for further details.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-46 S t a nd a r d Va r i a b l e R e f e re n c e

#HOME 3 The exact definition and usage of the bit depends on a

user application.
The controller clears the bit at startup time, but then
neither changes the bit nor verifies its value.
A user application can set and reset the bit using
regular assignment command like
X_MFLAGS.#HOME = 1.
Typically, an application sets the bit to one in the end
of the homing process.
#STEPPER 4 If the bit is one, the controller provides the control
algorithm for a pulse-direction stepper motor.
#ENCLOOP 5 If the bit is one, the controller provides a stepper
feedback loop. The encoder inputs are isolated from
the encoder counter, and the counter is connected to
the pulse-direction stepper motor outputs. Therefore,
feedback position follows the stepper pulses.
The bit is effective only with bit 4.
#STEPENC 6 If the bit is one, the controller provides the control
algorithm for a pulse-direction stepper motor with
verification encoder.
The bit is effective only with bit 4.
#BRUSHL 8 If the bit is one, the controller provides commutation
for the DC brushless motor. The bit must be set only if
the controller is connected to a three-phase amplifier
with two-phase input.
The bit must be zero if the amplifier provides
commutation itself and uses one ±10V input from the
controller.
#BRUSHOK 9 After power-up the controller clears the bit. While the
bit is zero, the brushless motor control algorithm
provides an open-loop commutation, so that the
motion is not exact. This mode must be used for
homing, until the commutation offset is available.
Once the bit is assigned with one, the controller
provides a closed-loop commutation and controls the
motor precisely.
The bit is effective only with bit 8.

#DBRAKE 11 Note: Dynamic braking is supported only in integrated

models.
If the bit is set, the controller will apply dynamic
braking to stop the motor when the axis is disabled
and the feedback velocity is less than the predefined
value of VELBRK.
If the axis is disabled due to a drive alarm fault,
dynamic brake mode is not used.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-47

#INVENC 12 If the bit is one, the controller inverts the direction of

encoder counting.
#INVDOUT 13 If the bit is one, the controller inverts the drive output.
This effectively inverts the sign of the feedback.
#NOTCH 14 If the bit is one, the controller inserts additional filter
into the control algorithm. The filter can implement
the notch characteristic or variety of other
characteristics depending on the parameters.
Use the MMI Adjuster to configure the filter.
#NOFILT 15 If the bit is zero, the control algorithm includes a
second-order filter specified by bandwidth SLVSOF.
If the bit is one, the control algorithm bypasses the
second-order filter.
#DEFCON 17 If the bit is one, the controller considers the default
connection between APOS and RPOS
(RPOS=APOS). In default connection the controller
provides blocking of APOS and RPOS so that they
are always equal. While the bit is one, the controller
does not accept the connect command for the axis.
#ENMOD 19 The bit modifies execution of the enable command.
See mechanical brake operation (page 7-22).
#DUALLOOP 20 If the bit is zero, the control algorithm implements a
regular single-loop scheme obtaining the position and
velocity feedback from the same feedback sensor as
define by SLPROUT.
If the bit is one, the control algorithm implements a
dual-loop scheme. For more information on dual loop
control, see the appendix about control loops in the
SPiiPlus Setup Guide.
#LINEAR 21 If the bit is one, the motor is linear.
#BRAKE 23 If the bit is zero, the controller does not provide brake
control.
If the bit is one, the brake is deactivated when the
motor is enabled and activated when the motor is
disabled. For detailed description see enable and
disable operations below.
Model Specific - SPiiPlus PCI-4/8 and SPiiPlus
PCI-DDM4: Even if the bit is set to one, the brake
control signal affects the corresponding output only if
the digital output has been configured for braking, as
described in brake outputs, page 7-21.
#ED2 24 Remote Connection HSSI-ED2.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-48 S t a nd a r d Va r i a b l e R e f e re n c e

MPOS Master Position

Size 8 (one value per axis)
Type Real
Accessibility Read-only
Comments MPOS provides the current master value for the axis.
The value is valid only if master command for the axis has executed. The
variable updates each controller cycle according to the formula specified in
the master command.

MST Motor State

Size 8 (one value per motor)
Type Integer
Accessibility Read-only
Comments MST contains a set of bits that display the current motor state.
The following bits can be tested in the variable:
Bit name No. Description
#ENABLED 0 The bit is set when the motor is enabled.
#OPEN 1 The bit is set when the motor is operating with open
loop control.
#INPOS 4 The bit is set when the motor has reached a target
position. Setting of this bit is controlled by variables
TARGRAD and SETTLE.
#MOVE 5 The bit is set when the motor is moving.
#ACC 6 The bit is set when the motor is accelerating.

ONRATE Autoroutine Rate

Size 10 (one value per each program buffer)
Type Integer
Accessibility Configuration
Comments ONRATE controls the autoroutine execution rate.
When an autoroutine executes in the program buffer, the execution rate is
ONRATE lines per each controller cycle. The normal rate of program
execution (when no autoroutine is activated) is defined by PRATE value.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-49

OUT General-Purpose Digital Outputs

Size 8
Type Integer
Accessibility Read-Write
Comments The bits of the OUT variable define the current state of the general-purpose
outputs. See detailed description (page 9-3).
Some aspects of OUT are model-dependent, including the quantity of digital
outputs, their resolution, whether they can be reconfigured for use with PEG
or braking, and whether there are dedicated PEG and brake outputs that can
be reconfigured for general purpose. See the controller's Hardware Guide for
details.

PE Position Error
Size 8 (one value per motor)
Type Real
Accessibility Read-only
Comments PE is the difference between RPOS and FPOS ( the current position error).
The value is valid only if the motor is enabled.

PCHARS Number of Characters

Size 10 (one value per each program buffer)
Type Integer
Accessibility Read-only
Comments PCHARS provides the total number of characters stored in the buffer.

PERL Program Error Line

Size 10 (one value per each program buffer)
Type Integer
Accessibility Read-only
Comments PERL holds the number of the program line that caused the last program
error in the buffer.

PERR Program Error

Size 10 (one value per each program buffer)
Type Integer

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-50 S t a nd a r d Va r i a b l e R e f e re n c e

PERR Program Error

Accessibility Read-only
Comments PERR holds the error code of the last program error encountered in the
buffer.

PEXL Executed Line

Size 10 (one value per each program buffer)
Type Integer
Accessibility Read-only
Comments PEXL provides the number of the currently executed line in the buffer.
If the program has not executed, the variable reads zero.

PFLAGS Program Flags

Size 10 (one value per program buffer)
Type Integer
Accessibility Configuration
Comments PFLAGS contains a set of bits that defines behavior of the program buffer.
Bit name No. Description
#NOAUTO 0 If the bit is set, no autoroutine located in the buffer can
start.
#NOEDIT 1 If the bit is set, then when the controller is in protected
mode, the buffer cannot be edited.
#DYNAMIC 2 Defines if a buffer functions as a dynamic buffer
#PRIVILEGE 4 If raised, buffer is marked as privileged and,
irregardless of whether controller is in protection
mode, will execute as if controller is in configuration
mode (default is 0).
#DEBUG 5 If raised, buffer is marked as being in debug mode.

PLINES Number of Lines

Size 10 (one value per each program buffer)
Type Integer
Accessibility Read-only
Comments PLINES provides the total number of lines stored in a buffer. For a dynamic
buffer, it provides the current number of commands.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-51

PRATE Program Rate

Size 10 (one value per each program buffer)
Type Integer
Accessibility Configuration
Comments PRATE controls the program execution rate. The execution rate is PRATE
lines per each controller cycle.
PRATE is used only if no autoroutine is activated in the buffer. While an
autoroutine is executed, the ONRATE value defines execution rate.

PST Program State

Size 10 (one value per each program buffer)
Type Integer
Accessibility Read-only
Comments PST contains a set of bits that display current state of the program buffer.
The bits are as follows:
No. Name Description
0 #COMPILED Set when the program in the buffer is compiled.
1 #RUN Set while the program is running
2 #SUSPEND Set if the program is suspended after the step
execution or due to breakpoint in debug mode.
5 #DEBUG Set if the program is executed in debug mode, i.e.
breakpoints are active
7 #AUTO Set while an autoroutine is running

RACC Reference Acceleration

Type Real
Accessibility Read-only
Comments RACC provides current reference acceleration value for the motor.
The variable updates each controller cycle. The value is calculated by digital
differentiation of the RVEL variable.

RPOS Reference Position

Size 8 (one value per motor)
Type Real
Accessibility Read-only

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-52 S t a nd a r d Va r i a b l e R e f e re n c e

RPOS Reference Position

Comments RPOS provides the current motor reference value.
The variable updates each controller cycle according to the connection
specified for the motor.
If the motor has default connection (MFLAGS has bit #DEFCON set), the
variable is the same value as Axis Position APOS.
When the motor is disabled, RPOS = FPOS

RVEL Reference Velocity

Size 8 (one value per motor)
Type Real
Accessibility Read-only
Comments RVEL provides the current motor reference velocity.
The variable updates each controller cycle The value is calculated by digital
differentiation of the RPOS variable.

RVFIL Reference Velocity Filter

Size 8
Type Real
Accessibility Configuration
Comments RVFIL specifies the power of filter that the controller uses in calculating the
RVEL variable. The value is specified in percent.
Zero RVFIL corresponds to no filtering. In this case the controller calculates
RVEL as a first difference of the RPOS variable:
Δ = (RPOSn - RPOSn-1) * K
RVELn = Δ
where K is a scaling factor that reduces RVEL to position unit per second.
Non-zero value of RVFIL provides additional filtering in the RVEL
calculation according to the formula:
RVELn = Δ * (1 – RVFIL/100) + RVEL n-1* RVFIL/100
The default value of RVFIL is zero. No filtering is required as long as the axis
motion is not a master-slave motion. In this case RPOS is a calculated value
and the first difference provides a smooth approximation of velocity.
If an axis is involved in a master-slave motion, RPOS usually contains a
signal from discrete physical sensor that provides amount of noise in the first
difference. Increase the value of RVFIL if a smoother approximation is
required.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-53

S_DCN System DC, Number of Samples

Size Scalar
Type Integer
Accessibility Read-only
Comments S_DCN provides the number of stored samples in system data collection.
If a system data collection is in progress, the variable increments each time a
sample is stored. When the data collection terminates, the variable holds the
last value, until the next system data collection starts.

S_DCP System DC, Period

Size Scalar
Type Real
Accessibility Read-only
Comments S_DCP provides the sampling period for system data collection.
When a system data collection starts, the variable is assigned with a real data
collection period. The value may differ from the period specified in the DC
command, because period is rounded to integer number of controller cycles.

S_FAULT System Faults

Size Scalar
Type Integer
Accessibility Read-only
Comments S_FAULT provides a set of bits; each bit reports one system fault (i.e. a fault
that is not related to any specific axis).
The user can set the bits in variable S_FMASK in order to define which
system faults are examined and processed.
The faults are examined each controller cycle. If the fault condition is true,
the corresponding bit is set; otherwise the bit is reset. The user can check the
fault bits in the ACSPL+ program, or can define automatic response using
autoroutines.
For a list of system fault bits see page 8-17.

S_FDEF System Default Response Mask

Size Scalar
Type Integer

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-54 S t a nd a r d Va r i a b l e R e f e re n c e

S_FDEF System Default Response Mask

Accessibility Configuration
Comments S_FDEF provides a set of bits that control automatic processing of system
faults.
If a bit in the variable is raised, the controller executes the default response
when the corresponding fault occurs.
If the bit is reset, the default response is disabled.
For a list of fault bits see section 0.

S_FLAGS System Flags

Size Scalar
Type Integer
Accessibility Configuration
Comments S_FLAGS contains a set of bits that define different settings for the
controller.
Bit name No. Description
1 S_FLAGS.1 controls whether the controller allots a
controller cycle to processing non-executing lines
(comments, empty lines, labels, etc.). If the bit is 0
(default), these lines are skipped during execution.
If the bit is 1, these lines are each allotted a
controller cycle.
The S_FLAGS.1 bit affects the program
compilation. Therefore, if the bit is changed, the
results go into effect only after a program is
recompiled.
#FCLEAR 2 S_FLAGS.#FCLEAR= 0 (default) puts the
controller is in regular mode.
S_FLAGS.#FCLEAR = 1 puts the controller in
strict mode (page 8.3.7).
#TT 3 Enable translation table.
#COPYTO 4 If the bit is clear, each cycle the controller copies
standard variables to the dual-port RAM as defined
by the last copytodpr command (page 10-5).
If the bit is set, copying is disabled. However, the
parameter definitions provided by the copytodpr
command is retained and copying resumes as soon
as the bit is cleared again.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-55

#COPYFROM 5 If the bit is clear, each cycle the controller copies

from the dual-port RAM to standard variables as
defined by the last copyfromdpr command.
If the bit is set, copying is disabled. However, the
parameter definitions provided by the
copyfromdpr command is retained and copying
resumes as soon as the bit is cleared again.
#COPYOIR 6 Determines the mode of copyfromdpr operation
(page 10-7):

• 0: copy-each-cycle
• 1: copy-only-if-requested.

S_FMASK System Fault Mask

Size Scalar
Type Integer
Accessibility Configuration
Comments S_FMASK provides a set of bits, each bit enables examination and
processing of one system fault.
If a bit in the variable is raised, the corresponding fault is examined each
controller cycle.
If a bit in the variable is reset, the corresponding fault is not examined.
Therefore, the corresponding bit in S_FAULT can never be set.
See the summary of the fault bits, page 8-3.

S_SAFIN System Safety Inputs

Size Scalar
Type Integer
Accessibility Read-only (read/write when working with Simulator)
Comments S_SAFIN contains a bit that reads the current state of the system safety
inputs.
(Variable SAFIN reads axis-related safety inputs).
S_SAFIN provides the raw values of the inputs. Inversion as defined by
S_SAFINI does not affect the value of S_SAFIN.
Only the #ES bit (Emergency Stop) is meaningful in S_SAFIN.
S_SAFIN is normally read-only. However, it can be written to when working
with the Simulator, to simulate safety inputs.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-56 S t a nd a r d Va r i a b l e R e f e re n c e

S_SAFINI System Safety Inputs Inversion

Size Scalar
Type Integer
Accessibility Configuration
Comments S_SAFINI contains the bits that define inversion for system safety inputs.
Variable SAFINI defines inversion for the axis-related safety inputs.
If a bit of S_SAFINI is zero, the corresponding signal is not inverted and
therefore high voltage is considered active state. If a bit of S_SAFINI is
raised, the bit is inverted and low voltage is considered active state.
Bits of S_SAFINI do not affect the bits of because S_SAFIN provides the
raw values of the safety inputs S_SAFIN.
Only the #ES bit (Emergency Stop) is meaningful in S_SAFINI:

S_ST System State

Size Scalar
Type Integer
Accessibility Read-only
Comments S_ST provides a set of bits that display the current controller state.
The following bit may be tested in the variable:
#DC The bit is set while a system data collection is in progress

SAFIN Safety Inputs

Size 8 (one value per motor)
Type Integer
Accessibility Read-only (read/write when working with Simulator)
Comments SAFIN contains the bits that read the current state of the axis-related safety
inputs.
Variable S_SAFIN reads system safety inputs.
SAFIN provides the raw values of the inputs. Inversion defined by SAFINI
does not affect the value of SAFIN.
SAFIN is normally read-only. However, it can be written to when working
with the Simulator, to simulate safety inputs.
Bit name No. Description
#RL 0 Right Limit
#LL 1 Left Limit

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-57

SAFIN Safety Inputs

#RL2 2 Preliminary Right Limit
#LL2 3 Preliminary Left Limit
#HOT 4 Overheat
#DRIVE 9 Drive Alarm

SAFINI Safety Inputs Inversion

Size 8 (one value per motor)
Type Integer
Accessibility Configuration
Comments SAFINI contains the bits that define inversion for the corresponding axis-
related safety inputs.
Variable S_SAFINI defines inversion for the system safety inputs.
If a bit of SAFINI is zero, the corresponding signal is not inverted and
therefore high voltage is considered active state. If a bit of SAFINI is raised,
the bit is inverted and low voltage is considered active state.
Bits of SAFINI do not affect the bits of because SAFIN provides the raw
values of the safety inputs.
Bit name No. Description
#RL 0 Right Limit
#LL 1 Left Limit
#RL2 2 Preliminary Right Limit
#LL2 3 Preliminary Left Limit
#HOT 4 Overheat
#DRIVE 9 Drive Alarm

SETTLE Settling Time

Size 8 (one value per motor)
Type Real
Accessibility Configuration
Units milliseconds
Default 0

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-58 S t a nd a r d Va r i a b l e R e f e re n c e

SETTLE Settling Time

Comments SETTLE controls the setting of the MST.#INPOS bit .
When the motor is not moving, the controller compares the position error (PE
value) and the target envelope (TARGRAD value) every cycle. Bit #INPOS
is raised when PE drops to within the range (-TARGRAD, +TARGRAD)
and remains within the range for a period of time equal or greater than
SETTLE.
If the motor starts to move or PE goes out of the range, bit MST.#INPOS is
cleared.

SLAFF Servo Loop - Velocity: Acceleration feed-forward

Size 8
Type Real
Accessibility Read-write
Comments Range: 0 to 16777215 (default is 0)

SLBIASA Servo Loop - Current: Bias A

Size 8
Type Real
Accessibility Read only (integrated models)
Read-write (nonintegrated models)
Comments Units: % of max output.
Range: -10 to 10; (default = 0).
For integrated models: Value is read-only and displays the measured value of
the current input bias.
For nonintegrated models: Value is read-write and specifies the bias of the
drive output. The controller uses the value only for brushless motor
commutated by the controller.

SLBIASB Servo Loop - Current: Bias B

Size 8
Type Real
Accessibility Read only (integrated models)
Read-write (nonintegrated models)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-59

SLBIASB Servo Loop - Current: Bias B

Comments Units: % of max output.
Range: -10 to 10; (default = 0).
For integrated models: Value is read-only and displays the measured value of
the current input bias.
For nonintegrated models: Value is read-write and specifies the bias of the
drive output. The controller uses the value only for brushless motor
commutated by the controller.

SLCOFFS Servo Loop - Commutation Offset

Size 8
Type Real
Accessibility Read-write
Comments The variable contains a commutation offset in electrical degrees to be added
to the commutation phase.
The variable is valid only if a brushless motor is specified (MFLAGS.8 = 1).
Assignment to the variable immediately changes the commutation phase.
Use the value to introduce a small correction to the commutation phase.
Normally, the variable is changed in the process of adjustment (use the
Adjuster feature of the SPiiPlus MMI ).
Range -60 – +60 (degrees)

SLCORG Servo Loop, Commutation Origin

Size 8
Type Real
Accessibility Read-write
Comments The variable contains a commutation phase in electrical degrees in the point
of origin (usually, in the point of index).
The variable is valid only if a brushless motor is specified (MFLAGS.8 = 1).
Direct assignment to the variable has no immediate effect.
Normally, the variable is changed in the process of adjustment (use the
Adjuster feature of the SPiiPlus MMI ) and is used by a startup program.
Range -180 – +180 (degrees)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-60 S t a nd a r d Va r i a b l e R e f e re n c e

SLCNP Servo Loop - Commutation: Number of poles for rotary motor

Size 8
Type Real
Accessibility Read-write
Comments Range: 2 to 1000 (default is 8).
Set to 2 for linear motor.

SLCPA Servo Loop - Commutation: Phase Advance

Size 8
Type Real
Accessibility Read-write
Comments Range: from -60 to 60.
Defines phase advance in electrical degrees at XVEL (maximum allowed
velocity for the motor).
The actual phase advance is calculated as SLCPA*Vel/XVEL where Vel is
the current reference velocity.

SLCPRD Servo Loop - Commutation: Period

Size 8
Type Real
Accessibility Read-write
Comments Range: 256-16777215 (default is 8000).
Feedback counts per revolution for rotational motor, Feedback counts per two
magnetic pitches for linear motor.

SLEMOS Servo Loop - Sin-Cos Filter Order

Size 8
Type Integer
Accessibility Read-write
Comments Range: 0 – 4 (default is 4). See also Sin-Cos Filter (page 7-16).

SLFRC Servo Loop – Velocity Friction

Size 8
Type Real

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-61

SLFRC Servo Loop – Velocity Friction

Accessibility Read-write
Comments Range: 0 to 50 (default is 0). Units are % of max output.

SLIKI Servo Loop - Current: Integrator Coefficient

Size 8
Type Real
Accessibility Read-write
Comments Range: 0-65000
The value is active only in integrated models.

SLIKP Servo Loop - Current: Proportional Coefficient

Size 8
Type Real
Accessibility Read-write
Comments Range: 0-256000; (default is 1000).
The value is active only in integrated models.

SLIOFFS Servo Loop - Offset in Current Loop

Size 8
Type Real
Accessibility Read-write
Comments The variable contains an offset to be added to the result of the current loop
control.
The primary goal of the variable is to compensate for an active component of
the motor load. For example, in a vertical axis the weight of the carriage can
be compensated.
The variable is valid for DC brush and brushless motors.
The variable contains value in percents of maximal drive output.
Normally, the variable is changed in the process of adjustment (use the
Adjuster feature of the SPiiPlus MMI ).
Range -50 – +50 (percent)

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-62 S t a nd a r d Va r i a b l e R e f e re n c e

SLPBITS Servo Loop - Position: Number of bits in position feedback.

Size 8
Type Real
Accessibility Read-write
Comments Range: 2 to 16 (default is 14). Used with HSSI feedback.

SLPKI Servo Loop - Position: Integrator coefficient

Size 8
Type Real
Accessibility Read-write
Comments Range: 0 to 16777215 (default is 0)

SLPKP Servo Loop - Position: Proportional coefficient

Size 8
Type Real
Accessibility Read-write
Comments Range: 0 to 16777215 (default is 0)

SLPLI Servo Loop - Position: Integrator limit

Size 8
Type Real
Accessibility Read-write
Comments Range: 0 to 100 (default is 0)

SLPROUT Servo Loop - Position Feedback Routing

Size 8
Type Real
Accessibility Read-write
Comments
NOTE Normally SLPROUT is set automatically by
the Adjuster feature of the SPiiPlus MMI
software tool. Setting it directly is possible, but
is not recommended due to the complexity
involved.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-63

SLPROUT Servo Loop - Position Feedback Routing

Default = 0.
The controller supports a standard control loop configuration: X position
feedback is obtained from X encoder, Y – from Y encoder, and so on
A non-default value in a routing variable provides feedback from an
alternative sensor. For example, if X_SLPROUT is 10, the position
feedback is obtained from analog input 0 rather than from the encoder. In
that case, the feedback source could be a potentiometer or any other device
that produce analog voltage proportional to the motor position.
The meaning of the routing value depends on the axis (and the controller
model). For example, value 1 specified for X or A axis selects the X
encoder, the same value for Y or B axis selects the Y encoder.

Value Axis Feedback Source

1 X, A X encoder
Y, B Y encoder
Z, C Z encoder
T, D T encoder
2 X, A A encoder
Y, B B encoder
Z, C C encoder
T, D D encoder
10 X, Y, A, B Analog input 0
Z, T, C, D Analog input 0 for
integrated models,
analog input 8 for
nonintegrated models
11 X, Y, A, B Analog input 1
Z, T, C, D Analog input 1 for
integrated models,
analog input 9 for
nonintegrated models
12 X, Y, A, B Analog input 2
Z, T, C, D Analog input 2 for
integrated models,
analog input 10 for
nonintegrated models
13 X, Y, A, B Analog input 3

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-64 S t a nd a r d Va r i a b l e R e f e re n c e

SLPROUT Servo Loop - Position Feedback Routing

Z, T, C, D Analog input 3 for

integrated models,
analog input 11 for
nonintegrated models
14 X, Y, A, B Analog input 4
Z, T, C, D Analog input 4 for
integrated models,
analog input 12 for
nonintegrated models
15 X, Y, A, B Analog input 5
Z, T, C, D Analog input 5 for
integrated models,
analog input 13 for
nonintegrated models
16 X, Y, A, B Analog input 6
Z, T, C, D Analog input 6 for
integrated models,
analog input 14 for
nonintegrated models
17 X, Y, A, B Analog input 7
Z, T, C, D Analog input 7 for
integrated models,
analog input 15 for
nonintegrated models
20 X, A, HSSI input register 0
Y, B HSSI input register 4
Z, C HSSI input register 8
T, D HSSI input register 12
21 X, A, HSSI input register 1
Y, B HSSI input register 5
Z, C HSSI input register 9
T, D HSSI input register 13
22 X, A, HSSI input register 2
Y, B HSSI input register 6
Z, C HSSI input register 10
T, D HSSI input register 14

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-65

SLPROUT Servo Loop - Position Feedback Routing

23 X, A, HSSI input register 3

Y, B HSSI input register 7
Z, C HSSI input register 11
T, D HSSI input register 15

SLVKI Servo Loop - Velocity: Integrator coefficient

Size 8
Type Real
Accessibility Read-write
Comments Range: 0 to 20000 (default is 200)

SLVKP Servo Loop - Velocity: Proportional coefficient

Size 8
Type Real
Accessibility Read-write
Comments Range: 0 to 16777215 (default is 100)

SLVLI Servo Loop - Velocity: Integrator limit

Size 8
Type Real
Accessibility Read-write
Comments Range: 0 to l00 (default is 50). Units are % of max.

SLVNATT Servo Loop - Velocity: Notch filter attenuation

Size 8
Type Real
Accessibility Read-write
Comments Range0.05 to 20 (default is 50).

SLVNFRQ Servo Loop - Notch filter frequency

Size 8
Type Real

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-66 S t a nd a r d Va r i a b l e R e f e re n c e

SLVNFRQ Servo Loop - Notch filter frequency

Accessibility Read-write
Comments Range: 0.1 to 4000 (default is 300). Units are Hz.

SLVNWID Servo Loop - Velocity: Notch filter width

Size 8
Type Real
Accessibility Read-write
Comments Range: 0.1 to 4000 (default is 700). Units are Hz.

SLVSOF Servo Loop - Velocity: Second order filter bandwidth

Size 8
Type Real
Accessibility Read-write
Comments Range: 0.1 to 4000 (default is 700). Units are Hz.

SLLIMIT Software Left Limit

Size 8 (one value per motor)
Type Real
Accessibility Configuration
Comments SLLIMIT defines the minimum allowed position for the motor.
If reference position RPOS is less than this value, a Software Left Limit fault
results and bit #SLL is set in variable FAULT.

SMNA Software Monitor Address

Size Size is model dependent – one per SP.
Type Integer
Accessibility Read-Write
Comments SMNA defines the SP address of a variable to be monitored in the form of the
SMNV variable.
After SNMA variable is set, the requested SP variable is copied into the
SNMV variable each controller cycle. The SNMV variable can be used in
ACSPL+ expressions, in terminal commands, or in data collection.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-67

SMNV Software Monitor Value

Size Size is model dependent – one per SP.
Type Integer
Accessibility Read-only
Comments SMNV provides a monitored value requested by the SMNA variable.
After the SNMA variable is set, the requested SP is copied into SNMV
variable each controller cycle. The SNMV variable can be used in ACSPL+
expressions, in terminal commands or in data collection.

SRLIMIT Software Right Limit

Size 8 (one value per motor)
Type Real
Accessibility Configuration
Comments SRLIMIT defines the maximum allowed position for the motor.
If the reference position RPOS is greater than this value, Software Right
Limit fault is detected and bit #SRL is set in variable FAULT.

STEPF Stepper Factor

Size 8 (one value per motor)
Type Real
Accessibility Configuration
Comments STEPF defines the ratio between one stepper pulse and the user unit.
The value of 1 (default) means that motion programming is provided in motor
steps. For example, the command
ptp/r X,320

will move the motor by 320 steps from the current position.
If another unit is required for motion programming, the user must configure
an appropriate value for STEPF. For example, a controlled plant provides a
gear ratio of 500 motor pulses per inch. If the motion programming unit must
be provided in inches, the configured STEPF value must be 0.002.

STEPW Stepper Pulse Width

Size 8 (one value per motor)
Type Real
Accessibility Configuration

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-68 S t a nd a r d Va r i a b l e R e f e re n c e

STEPW Stepper Pulse Width

Comments STEPW defines the pulse width for the stepper motor in milliseconds.
The value defines the width of the pulses generated on the pulse output for
stepper control. The value is limited from 25e-6 (25 nanosecond) to 0.051
(51 microsecond).

SYNV Synchronous Velocity

Size 8 (one value per axis)
Type Real
Accessibility Configuration
Comments SYNV defines the tolerable difference in master and slave velocities during
which the slave can be synchronized to the master.
The value is used when the axis is specified in slave command, or the axis is
a leading axis in a group that executes slaved-segmented motion.
Master-slave motion always starts asynchronously. The controller tries to
achieve synchronism by having the slave pursue the master in order to equate
their velocities. The velocities are considered equal if the absolute difference
is not greater than SYNC. For velocity-locked motion this condition is
sufficient for establishing synchronism. For position-locked motion the
controller also tries to equate the master and slave positions.
The slave may lose synchronism if the required slave acceleration exceeds
XSACC value. In this case the controller tries to regain synchronism by
having the slave pursue the master with the maximum allowed motion
parameters. Value SYNC is used to define a moment of establishing
synchronism as described above.

TARGRAD Target Radius

Size 8 (one value per motor)
Type Real
Accessibility Configuration
Comments TARGRAD controls the setting of the #INPOS bit in the MST variable.
When the motor is not moving, the controller compares the position error
(PE value) and the target envelope (TARGRAD value) each cycle. The
#INPOS bit is raised when PE drops into the range (-TARGRAD,
+TARGRAD) and remains within the range for a period of time equal or
greater than SETTLE.
If the motor starts to move, or comes out of the range, the #INPOS bit is
cleared.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-69

TIME Elapsed Time

Size Scalar
Type Real
Accessibility Read-only
Comments TIME provides the elapsed time from the controller power-up (in
milliseconds).

TPOS Target Position

Size 8 (one value per axis)
Type Real
Accessibility Read-write
Comments The variable can be updated by the controller or by the user.
The controller updates the variable at the following times:
1. When the controller starts executing ptp motion, it stores in the
variable’s elements the target coordinates of the axes involved.
2. During mptp motion the controller updates the target coordinates each
time when it starts motion to the next point.
3. When the controller starts executing track motion, it stores in the
variable’s elements the current coordinates of the axes involved.
4. When the controller starts executing any other motion, it stores in the
variable’s elements of the involved axes a big value.
The user can assign values to the variable at any time, but the values only
affect the controller when track motion is used. For more information, see the
description of track motion, page 6-10.

V V Array
Size 100
Type Integer
Accessibility Read-Write
Comments V defines a general-purpose array that can be used in any application program
as a predefined global variable.

VEL Default Velocity

Size 8 (one value per axis)
Type Real
Accessibility Read-Write

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-70 S t a nd a r d Va r i a b l e R e f e re n c e

VEL Default Velocity

Comments VEL defines the default velocity of the motion profile. If a motion command
does not specify a specific velocity, the default value is used. For one-axis
motion the value defines axis velocity. If the axis is a leading axis in a group,
its value defines vector velocity of common motion.
If the variable is changed when a motion is in progress, the change does not
affect the motions that are executing or were created before the change. All
motions created after the change will use the new value.

VELBRK Velocity for Braking

Size 8 (one value per motor)
Type Real
Accessibility Configuration
Comments If the MFLAGS.#BRAKE bit is set, the controller will apply dynamic
braking to stop the motor when the axis is disabled and the feedback velocity
is less than the predefined value of VELBRK (default is 0).
Note: Dynamic braking is supported only in integrated models.

XACC Maximum Acceleration

Size 8 (one value per motor)
Type Real
Accessibility Configuration
Comments XACC defines the maximum allowed acceleration for the motor.
If the reference acceleration RACC exceeds this value, the Acceleration
Limit fault is activated and bit #AL is set in variable FAULT.

XCURI Maximum Idle Motor Current

Size 8 (one value per axis)
Type Real
Accessibility Configuration
Comments The variable limits the corresponding drive output when the motor is idle (not
moving). The variable is defined as a percentage of the maximum output
voltage.
For example, in SPiiPlus PCI-4/8, the maximum output voltage is ±10V.
Setting XCURI to 50 will limit the drive output to the range –5V to +5V
when the motor is idle.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 S t a n da r d V a ri a bl e R e f e r e nc e 11-71

XCURV Maximum Moving Motor Current

Size 8 (one value per axis)
Type Real
Accessibility Configuration
Comments The variable applies limit to the corresponding drive output when the motor is
moving. The variable is defined as a percentage of the maximum output
voltage.
For example, in SPiiPlus PCI-4/8, the maximum output voltage is ±10V.
Setting XCURV to 50 will limit the drive output to the range –5V to +5V
when the motor is moving.

XRMS Maximum Allowed RMS Current

Size 8 (one value per axis)
Type Real
Accessibility Configuration
Comments The SP program calculates RMS of the corresponding controller drive output.
If the calculated value exceeds the allowed value, the Overcurrent fault
occurs. The variable is defined as a percentage of the maximum output
voltage.

XSACC Maximum Slave Acceleration

Size 8 (one value per axis)
Type Real
Accessibility Configuration
Comments XSACC defines the maximum allowed slave acceleration in master-slave
motion.
The value is used when the axis is specified in the slave command, or the axis
is a leading axis in a group that executes slaved-segmented motion.
When a slave is synchronized to a master, the controller verifies the slave
acceleration against the XSACC value each controller cycle. If the slave
acceleration exceeds the XSACC value, the motion falls out of synchronism.
The controller tries to regain synchronism by having the slave pursue the
master with the maximum allowed motion parameters.
See SYNV variable for more information.

XVEL Maximum Velocity

Size 8 (one value per motor)
Type Real

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

11-72 S t a nd a r d Va r i a b l e R e f e re n c e

XVEL Maximum Velocity

Accessibility Configuration
Comments XVEL defines the maximum allowed velocity for the motor.
If the RVEL feedback velocity exceeds this value, the Velocity Limit fault is
tripped and the #VL bit is set in variable FAULT.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 E r r or /D ia g no s t ic 12-1

12. ERROR/DIAGNOSTIC

12.1. General
This chapter provides a description of how error codes are generated, and a brief description of
each error.

12.2. Error Codes

Each error in the controller has a corresponding 4-digit error code. Regardless of how an error is
detected and reported, the user can request the error description from the controller. A request for
error description consists of two question marks followed by the error code. For example, the
following communication may occur when the controller is in protected mode:
X_XVEL = 10000 Attempt of assignment to a
protected variable
?2085 The controller reports an error

??2085 Request for error description

Protection violation Error description

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

12-2 E rr o r /D ia g n o s t ic

12.2.1. Error Code Ranges

Error codes are divided into several ranges (See Error Reference, page 12-5 for a description of
specific error codes):

Range Type Description

0 – 999 Errors detected by Errors are detected by C Library without communication
SPiiPlus C Library with the controller. The controller itself never returns
error codes in this range.
A host application that calls a C Library function can
receive this code if a function call failed.
For explanation of the errors see SPiiPlus C Library
Reference Guide.
1000 – Errors in terminal Errors in terminal commands are reported immediately in
1999 commands the prompt that is displayed in response to the command.
2000 – ACSPL+ ACSPL+ compilation errors are reported either
2999 compilation errors immediately when the erroneous line is inserted, or
subsequently, when the controller attempts to compile an
ACSPL+ program. If a program in a buffer undergoes
compilation and an error is detected, the error code is
stored in the corresponding element of the PERR array
and the erroneous line number is stored in the
corresponding element of the PERL array
3000 – ACSPL+ Codes from 3000 to 3019 do not indicate an error. For
3999 termination codes example, code 3002 reports that the user has terminated
the program.
Codes from 3020 to 3999 indicate run-time errors.
If an error occurs in immediate execution of ACSPL+
command, the error is indicated immediately in the
prompt. If an error occurs when an ACSPL+ program is
executed in a buffer, no immediate indication is
provided. Instead, the error code and the line number are
stored in the corresponding elements of the PERR and
PERL arrays.

5000 – Motion termination Codes from 5000 to 5008 do not indicate an error. They
5999 codes and motor report normal motion termination.
disable codes
Codes from 5009 and higher appear when a motion is
terminated or a motor is disabled due to a fault detected
by the controller.
When a motion terminates abnormally, or a motor is
disabled , the error code is stored in the MERR variable.
> 6000 User-defined codes The user can execute commands kill, killall, disable,
disableall with an argument that specifies a user-defined
error code.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 E r r or /D ia g no s t ic 12-3

Range Type Description

The specified error code is stored in the MERR variable.

12.3. Error Detection

Error detection can occur in three circumstances:
ƒ An erroneous command is received through any communication channel
ƒ An error occurs while the controller executes an ACSPL+ program
ƒ The controller kills a motion or disables a motor because a fault was detected

12.4. Error Indication

12.4.1. Errors In Received Commands

If the controller receives a correct command, it responds with the normal prompt (colon).
If a command cannot be executed for any reason, the controller responds with the error prompt.
The error prompt contains the ? character and 4-digit error code. For example:
X_VEL = 1000

: Normal prompt – the command was successful

X_FPOS = 0

?2020 Error – attempt of assignment to a read-only variable

12.4.2. Errors In ACSPL+ Programs

If the controller executes an ACSPL+ program and an error occurs due to the program execution,
the controller does the following:
4. Aborts the erroneous program
5. Stores the error code in the corresponding element of the PERR array
6. Stores the line number that caused the error in the corresponding element of the PERL array
7. Activates the #PROG fault. The default controller response to the fault is to kill all executed
motions.
No error prompt is issued. The user must analyze the state of the buffer in order to detect program
errors. For example:
?1 Query the state of buffer 1

Buffer 1: 78 lines, run-time error 3077 in line 37

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

12-4 E rr o r /D ia g n o s t ic

?PERR(1) The state also can be monitored through variable PERR

3077 The code of the last error

12.4.3. Motion Termination Codes

A motion executed in the controller can terminate for different reasons:
ƒ The motion comes to its final point – normal termination
ƒ The user interrupts the motion with command halt or kill
ƒ The controller detects a fault that requires motion kill
In all cases the controller stores the termination reason in the corresponding element of the AERR
(Axis Error) variable. No error prompt is issued. The user must analyze the state of the axis in
order to detect motion termination. For example:
?X Query of the state of axis
X
Motor x: enabled, idle, in position
Axis X: motion was killed by user

?X_AERR The state also can be

monitored through
variable AERR
5002 The termination code –
motion was killed by
user
:

?Y Query of the state of axis

Y
Motor y: enabled, idle, in position
Axis Y: motion failed, reason 5011

?Y_AERR The state also can be

monitored through
variable AERR
5011 The termination code –
Left Limit fault
:

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 E r r or /D ia g no s t ic 12-5

12.4.4. Motion Termination and Motor Disable Codes

A motion executed in the controller can terminate for the different reasons:
ƒ The motion comes to its final point – normal termination
ƒ The user or ACSPL+ program interrupts the motion with command halt, kill, or killall
ƒ A motor involved in the motion is disabled for any reason
ƒ The controller detects a fault that requires motion kill
The controller disables a motor for the following reasons:
ƒ The user or ACSPL+ program executes command disable or disableall
ƒ The controller detects a fault that requires motor disable
If a motor is disabled or a motion is killed due to a fault, the controller stores the reason in the
corresponding element of the MERR (Motor Error) variable.
The user can also specify a termination code for commands kill, killall, disable or disableall. If
one of the commands is used with a non-zero reason argument, the specified code is stored in one
or more corresponding elements of MERR as a termination/disable code.
In a case where no error prompt is issued, the user must analyze the state of the motor in order to
detect whether the motor was disabled or a motion was killed abnormally. For example:

?Z Query of the state of

motor Z

Motor z: disabled
Disable reason: 5023 – Critical Position Error
Axis Z: motion was killed because a motor was disabled

?Z_MERR The state also can be

monitored through
variable MERR

5023 The error code – motor

was disabled because of
critical position error fault

12.5. Error Reference

Error Number Error Name Explanation
1022 Illegal command The controller received a message that is not
recognized as a legal command.
1023 Read-only variable cannot be The command specifies assignment to a read-
assigned only variable.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-6 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

1025 Time interval between two The controller has received a part of a
characters in command is more command but the next character has not
then 2 seconds arrived within 2 seconds.
The error never occurs when the user
communicates with the controller through a
communication terminal.
The error is relevant when an application
communicates with the controller using
SPiiPlus C Library, and indicates a
communication problem.
1028 Scalar variable cannot accept A scalar variable cannot be prefixed with axis
axis specification specification
1029 Extra characters after the The controller received a message that
command includes a legal command followed by one or
more characters that cannot be interpreted.
The controller does not execute the command.
1034 Illegal index value The command includes numerical index
specification, but the specified index is not a
number.
1035 Index is out of range The error is caused by one the following:
• The specified index value is more than or
equal to the number of elements in the
array
• The specified index value is negative
• The specified index values are
incompatible (first value in the range
greater than last).
1037 Illegal variable name The command requires specification of a
standard variable name, but the specified
name is not a name of a standard variable.
1038 Wrong checksum in the The command contains checksum, and the
command checksum value is wrong. The error never
occurs when the user communicates with the
controller through a communication terminal.
The error is relevant when an application
communicates with the controller using
SPiiPlus C Library, and indicates
communication problems.
1040 Unable to open file The command specifies an internal file in the
nonvolatile (flash) memory that does not
exist.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 E r r or /D ia g no s t ic 12-7

Error Number Error Name Explanation

1041 Assigned value is out of range The command attempts to assign the standard
variable with a value that is out of the range
allowed for this variable.
1043 Program cannot start because The command attempts to start an uncompiled
the buffer was not compiled ACSPL+ program. To compile a program, use
the #nC command, where n is the buffer
number.
1044 Command cannot be executed The command attempts to affect a running
while the program is running ACSPL+ program. Stop the program before
executing the command. To stop a program,
use the #nS command, where n is the buffer
number.
1045 Numerical error in standard The command includes a standard function
function that caused a numerical error. Check if the
arguments of the function fall into the allowed
range.
1046 Write file error The command has caused writing to the
nonvolatile (flash) memory that failed.
Possible reason is a flash memory overflow
because of too many stored user files.
1047 Read file error The command has caused reading from the
nonvolatile (flash) memory that failed. A
reoccurring error points to a serious problem
in the controller hardware or firmware.
1048 More axes than were defined in The point command specifies more axes than
the motion were specified in the motion that the
command refers to.
1050 Conflict with user-defined axis The command is incompatible with a user-
group defined axis group that was defined before.
The axes specified in the command must
either all belong to one user-defined axis
group, or not to intersect with any user-
defined axis group.
1051 Line number is out of range The command specifies a line number that
does not exist in the specified program buffer.
1052 Buffer number is out of range The command specifies illegal buffer number.
The controller contains the program buffers
numbered from 0 to 9.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-8 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

1053 Wrong type The command addresses a standard variable
and the type of the variable is different from
the type specified in the command.
The error never occurs when the user
communicates with the controller through a
communication terminal.
The error is relevant when an application
communicates with the controller using
SPiiPlus C Library. The error indicates
problems in communication.
1055 Command requires line number The command must contain a line number
specification specification.
1060 Illegal memory command The memory management command is
improperly formatted.
1061 ')' wasn't found The command contains a non-paired left
bracket.
1063 Variable is not defined in the The command addresses a variable that is not
buffer declared in the specified buffer, or the
specified buffer is not compiled.
1064 Undefined global variable The command addresses a global variable that
is not declared in any buffer, or the buffer that
contains the declaration is not compiled.
Variable name must be in upper case.
1065 Command cannot be executed The command is in conflict with one or more
while the current motion is in of the currently executed motions. To kill a
progress motion use the kill or killall command.
1067 GO command failed The controller has no motions waiting for the
go command.
1068 Referenced axis does not The command refers to a motion, but the
execute a motion (motion was specified axis is not involved in any motion.
terminated?)
1069 This command can be used only Commands point and mpoint are compatible
with MPTP, PATH or only with the mptp, path or pvspline motions
PVSPLINE motion
1070 Attempt to add segment after The command attempts to add a segment or a
ENDS command point to the motion that was closed before
with the ends command.
1071 File name was expected The command must specify a name of internal
file in the nonvolatile (flash) memory.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 E r r or /D ia g no s t ic 12-9

Error Number Error Name Explanation

1072 Wrong array size The command specifies an array, but the
motion that the command refers to, or other
command arguments require an array of
another size.
1073 Text for search is not specified The command must specify a text for search
operation.
1074 Only standard or SP variable is The command requires a standard or SP
allowed in the command variable name to be specified.
1076 Undefined label The command requires a label specification.
The program that contains the label specified
in the command must be compiled in a buffer.
1077 Protection violation The command attempts to assign a protected
variable when the controller is in protected
mode. The controller must be put in
configuration mode before protected variables
can be assigned.
1078 Variable can be changed only The command attempts to assign a variable
while the motor is disabled that can be changed only if the motor is
disabled.
If the variable is axis-related, disable the
corresponding motor before assigning the
variable.
If the variable is not axis-related, disable all
motors before assigning the variable.
1081 Incompatible suffixes The command includes suffixes that cannot be
used together.
1085 Extra number after the The command specifies a superfluous
command numerical argument.
1086 Variable name must be specified The command requires a variable name
specification.
1087 Command cannot be executed The command specifies one or more axes that
while the axis is moving are involved in a motion. The command can
be executed only after the motion finishes.
1088 Variable can be queried only in The command attempts to query a variable in
compiled buffer a buffer that was not compiled.
1089 Label can be referenced only in The command attempts to reference a label in
compiled buffer a buffer that was not compiled.
1090 This type of motion is not The slave or track command specifies an axis
allowed for grouped axis that was included in a user-defined group.
Only a single axis can be specified in the
slave or track command.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-10 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

1091 Less arguments than required The motion command specifies less
coordinate values that required by the axis
specification.
1092 More arguments than required The motion command specifies more
coordinate values that required by the axis
specification.
1093 Bit selector value is greater than The expression specified in the bit selector
31 or less than 0 yields a value greater than 31 or less than 0.
1096 ‘}’ was not found The command includes a non-paired left curly
bracket.
1097 Previous data collection is in The command attempts to start a data
progress collection while the previous data collection
for the same axis is still in progress.
1098 Stalled motion requires limits The motion command, which includes a suffix
specification of stalled motion, requires specification of the
motion limits.
1099 Extra numbers after the The motion command includes superfluous
command numerical arguments.
1101 The program is suspended, the The command attempts to start a program
start line number is not allowed from a specified line when the program is in
suspended state.
A program in suspended state can be only
resumed from the next line. The line
specification is not allowed.
The only way to start a suspended program
from arbitrary line is to stop the program, and
to start it again from the desired line.
1105 Format error The command is incorrectly formatted.
1106 Error in SP function The function that accesses SP memory cannot
be executed.
Check the address specified in the function
call. The address must fall into the range
0..511.
1108 Invalid real number The command includes specification of a real
number that cannot be interpreted as a valid
real.
1112 No matches were found The search command did not find any match.
1114 The program finished without The program that runs in a buffer executed the
STOP command last command and this was not a stop
command.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-11

Error Number Error Name Explanation

1115 Stack underflow (RET without The program that runs in a buffer caused stack
CALL) underflow.
This occurs if the program executes the ret
command that without the paired call
command.
1116 Stack overflow (too many The program that runs in a buffer caused stack
nested CALLs) overflow.
This occurs if the program executes too many
nested call commands. Check that the
program does not specify infinite recursion
(subroutine calls itself infinitely).
1117 Attempt to enter autoroutine The program that runs in a buffer comes to the
directly on command.
The on command must never be executed in
the normal program flow.
1118 Axis value is out of range The command specifies an axis by number or
expression, and the resulting value is not a
legal axis number.
Only a result from 0 to 7 can be interpreted as
axis number.
1120 The motion must involve the The segmented motion must always involve
first two axes from the group two axes. If a user-defined group contains
more than two axes, the segmented motion
must involve the first two axes in the group.
1121 Unknown #-constant The command specifies an unknown symbolic
constant.
1122 Bit selection is not applicable Bit selector cannot be applied to real value.
1123 Illegal bit selector Value of bit selector must fall into the range
0..32.
1124 Attempt to enable motor failed The enable command failed.
Additional information can be obtained from
the corresponding element of the MERR
variable (motor disable code).
1125 Error in SP program The command caused unsuccessful loading of
an SP program. The file with the SP program
contains an error.
1126 Illegal SP number The command specifies an illegal SP number.
Legal SP numbers are from 0 to 3.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-12 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

1127 Editing of this buffer is disabled The command attempts to open the buffer for
editing or to change the program in the buffer.
Editing of a buffer is disabled if the controller
is in protected mode and bit 1 of the
corresponding element of the PFLAGS
variable is set to 1.
1129 In binary command the name The command syntax requires a name to be
specification must end with / followed by the / (slash) character.
1139 Illegal input The controller tries to interpret the inserted
string as a response to the executed input
command, but the string does not follow the
required format.
1130 Segment sequence for the Commands mptp, mseg, path, pvspline are
previous motion were not followed by a sequence of points or segments.
terminated with ends command. The sequence must terminate with an ends
command.
1144 Simulator does not support this The command cannot be executed by
command Simulator.
1148 Too many sin-cos multipliers The user tried to select more multipliers than
selected. allowed
1151 This is a DEMO version of The demo version of the Simulator has a
Simulator. 5 minutes of work limited session length. The Simulator is going
remains. to stop after 5 minutes.
1152 The DEMO version of The demo version of the Simulator has a
Simulator has terminated limited session length. The session time has
elapsed.
1153 Illegal query command The controller cannot recognize the query
command.
1253 Unable to work with Dummy The command cannot be executed for a
motor dummy motor.
Check flag MFLAGS.#DUMMY.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-13

Error Number Error Name Explanation

2002 Unrecognized command The program line contains a sequence that is
not recognized as a legal command.
If the line starts from a standard variable
name, check the following:
• all letters are uppercase
• spelling is correct
If the line starts from a user variable name,
check the following:
• the variable is defined before use
• the letter case matches the definition
• spelling is correct
2003 Unexpected delimiter, A command contained in the line is
incomplete command incomplete.
2006 Unexpected END The end command is specified without a
paired if, loop or while command.
2007 Two adjacent operators Two binary operator are specified in the
expression without an operand between.
2008 Left bracket was expected Left bracket was not found in a position
where it is expected.
Possible reasons for this error are array name
without index or function call without
arguments.
2009 Right bracket was expected The expression or sub-expression has an
unpaired left bracket.
2010 Comma was expected Comma character was not found in a position
where it is expected.
Possible reasons for this error are:
• Missing comma between the arguments of
the command or function
• The command or function call has less
arguments than required.
2011 Equals sign was expected Equal sign in assignment is missing.
2015 Only positive constant is The declaration of array contains a size
allowed as array dimension definition other than positive integer constant.
2016 Only label or line number is The start command can contain the start line
allowed as start point definition. The start line definition can appear
only as a label or a positive line number.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-14 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

2018 Scalar variable cannot be The command contains a scalar variable
indexed or used with axis followed by index specification or prefixed by
specification axis specification.
2020 Read-only variable cannot be The command attempts to assign a read-only
assigned variable.
2021 Label was expected The goto or call command must specify a
label name.
2022 Array name was expected The command or function requires an array
name as one of its arguments. The array name
must not be indexed.
2023 Variable name was expected The declaration specifies an illegal variable
name.
A variable name must begin with a letter or
underscore and can include letters, digits and
underscores.
A variable name must not include any of the
following:
• Keywords (if, wait, sin, etc.)
names of the standard variable (FPOS,
MST, etc.)
• Standard label (AUTOEXEC).
• Axis designation (X, Y, Z, T, A, B, C and
D) prefix- or postfix- indexed form of a
standard variable.
2024 Undefined label The goto or call command specify a label
name that was not defined in the program.
2025 Duplicated label The program contains two identical labels.
2026 Undefined variable name The command contains a variable name that
was not declared in the program.
2027 Duplicated variable name The program declares two variables with
identical names.
2030 User array is limited to 10000 The program declares an array that contains
elements more than 10000 elements.
The limitation applies also to two-dimensional
arrays. The total number of elements in a two-
dimensional array is equal to the product of its
sizes by each dimension. The total number of
elements must not exceed 10000.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-15

Error Number Error Name Explanation

2031 Global of different The program declares a global variable with
type/dimension was defined in the name that was already declared in other
other buffer buffer with different type or dimension.
2033 Mandatory argument is omitted The command or function call contains fewer
arguments than required.
2034 More arguments than required The command or function call contains more
arguments than required.
2035 Wrong argument type The command or function call contains an
argument of incorrect type.
2036 Function that not returns value The expression cannot include a function that
cannot be used in expression has no return value.
2037 Axis specification was expected The command must specify an axis.
Axis specification can appear: as a letter
designation, like X, Y, A, or as an expression
that evaluates to a value in the range 0..7.
2044 Index is out of range The constant index value is greater than the
array size minus one, or is negative.
2045 Illegal axis value The axis value specified by a numerical
constant is greater than the number of axes
minus one, or is negative.
2048 Argument must be specified as The command requires a direction
+ or - sign specification that must be presented by
character + or -.
2049 Illegal suffix for this command The command specifies a suffix, which is
illegal for this command.
2050 Name of standard variable was The command requires an argument that
expected specifies one of the standard variables.
2051 Only APOS, RPOS, FPOS and The set command must specify assignment to
F2POS are allowed in SET one element of one of the following variables:
command APOS, RPOS, FPOS, F2POS.
The variables must be in upper case.
2052 Variable name was expected The command requires an argument that
specifies a scalar variable or an element of
array.
General expression or constant is not allowed
for this argument.
2053 Constant argument was The command requires an argument that
expected specifies a numerical constant.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-16 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

2054 Illegal buffer number The command must specify a constant buffer
number. The constant must fall into the range
from 0 to 9.
2055 Assigned value is out of range The command attempts to assign a variable
with a value that falls out of the range allowed
for the variable.
2056 Zero divide The command attempts to divide by zero.
2057 Only The imm command must specify assignment
VEL,ACC,DEC,JERK,KDEC to one element of one of the following
are allowed in IMM command variables: VEL, ACC, DEC, JERK, KDEC.
2058 Bit selection cannot be applied The bit selector is specified for a real variable.
to real variable
2059 ELSE without IF The else command is specified without
corresponding if.
2060 ELSEIF without IF The elseif command is specified without
corresponding if.
2061 LOOP without END The loop command has no corresponding
end.
2062 DO without END The do command has no corresponding end.
2063 IF without END The if command has no corresponding end.
2064 Memory overflow The application requires too much memory.
Reduce the number and size of the local and
global variables used in the application, or use
a more powerful model of the controller.
2065 Axis constant or axis expression The command must include an axis
in brackets expected specification.
Axis specification can appear as a sequence of
axis designations, like X, XYZ, ZAD, or as a
list of expressions enclosed in parentheses: for
example: 0, 2, 4 is equivalent to XZA.
The axis designations must be in upper case.
2066 Too many axis specifiers The axis specification includes too many axis
specifiers.
2067 An axis is specified more than The axis specification includes two identical
once axis specifiers.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-17

Error Number Error Name Explanation

2068 Sign constant or sign expression The command must include a sign
in brackets expected specification. Each sign in the specification
defines a direction of one involved axis.
Sign specification can appear:
• As a sequence of sign characters, like +,
+–+, –+–+
• As a list of expressions enclosed in
brackets: (0, 1, 0) is equivalent to +–+.
2066 Too many sign specifiers The sign specification includes too many sign
specifiers.
2070 Unknown #-constant The command includes an unknown symbolic
constant.
2071 Local variable is not allowed in The command does not allow the use of local
this command variables. Only standard and user global
variables can be used.
2072 WHILE without END The while command has no corresponding
end.
2073 WAIT,TILL,GOTO,CALL,RET The command is not valid for immediate
,LOOP,WHILE,ON,INPUT are execution. The command only can be used in
not allowed in terminal a program.
command
2074 Only RPOS variable is allowed The connect command must specify
after CONNECT assignment to one element of one of the
RPOS variable.
2075 Only MPOS variable is allowed The master command must specify
after MASTER assignment to one element of one of the
MPOS variable.
2076 Constant bit selector is greater The command includes a constant bit selector.
than 31 or less than 0 The value of bit selector must fall into the
range from 0 to 31.
2077 Array name requires indexing The array name must be followed by an index
specification.
For a two-dimensional array, two index
specifiers are required.
2078 Current empty space in the The dynamic buffer contains too many
dynamic buffer is not enough commands queued for execution.
for the command
The application must wait for the controller to
execute and remove one or more commands
from the buffer.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-18 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

2079 GOTO,CALL,RET,LOOP, Commands GOTO, CALL, RET, LOOP,
WHILE,IF,ON are not allowed WHILE, IF, ON cannot be used in dynamic
in dynamic buffer buffer.
2080 Local variable declaration is not Only global variables can be defined in a
allowed in a terminal command. terminal command.
2081 Variable declaration is not Variable declaration cannot be executed in
allowed in dynamic buffer dynamic buffer.
2082 Illegal file name The command requires file name
specification.
2083 Integer overflow The result of constant integer expression is
more than 2147483647 or less than
-2147483648.
Consider using real constants instead of
integer. To change constant type to real, add
decimal point to the end of the constant.
2084 Integer constants are allowed in Consider using real constants instead of
the range from -2147483648 to integer. To change constant type to real, add
+2147483647 decimal point to the end of the constant.
2085 Protection violation The controller is in protected mode and the
command violates one of the protection rules.
Refer to the description of protection
requirements, page 5-121.
2086 Protection attribute cannot be Command setprotection cannot be executed
changed for this parameter for this standard variable.
2087 Only constant 0 or 1 is allowed The command allows only 0 or 1 at the right
at the right side of the equals sign.
2088 No dual-port RAM in this The controller contains no dual-port RAM,
controller therefore the DPRAM-managing command
cannot be executed in this controller model.
2089 Bit selection is not available for The controller does not support operations
DPR variable with bits for a variable located in dual-port
RAM.
2090 Only global variables can be Local variable cannot be declared in dual-port
defined in DPR RAM.
2091 DPR address must be specified The DPRAM-managing command must
contain specification of dual-port RAM
address.
2092 Only even numbers from 128 to The specified dual-port RAM address must be
504 are allowed as DPR address an even numbers in the range from 128 to
504.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-19

Error Number Error Name Explanation

2093 Collision with other variable in The command tries to redefine address
DPR already specified in another dual-port RAM -
managing command.
2094 DPR variable is not allowed in A dual-port RAM variable name cannot be
this command used with commands connect, master,
copytodpr, copyfromdpr, dc.
2095 Illegal line number The specified line number must be a positive
non-zero integer.
2096 Only even numbers from 128 to The specified dual-port RAM address must be
1016 are allowed as DPR an even number in the range 128 to 504.
address
3023 Read-only variable cannot be The command specifies assignment to a read-
assigned only variable.
3028 Scalar variable cannot accept A scalar variable cannot be prefixed with axis
axis specification specification.
3034 Illegal index value The command specifies assignment to a read-
only variable.
3035 Index is out of range The reason of the error is one the following:
• The specified index value is more or
equal to the number of elements in the
array
• The specified index value is negative
• The specified index values are
incompatible (first value in the range
greater than last).
3037 Illegal variable name The command requires specification of a
standard variable name, but the specified
name is not a name of a standard variable.
3040 Unable to open file The command specifies a file in the
nonvolatile (flash) memory that does not
exist.
3041 Assigned value is out of range The command attempts to assign the standard
variable with a value that is out of the range
allowed for this variable.
3043 Program cannot start because The command attempts to start an ACSPL+
the buffer was not compiled program that has not been compiled. To
compile a program, use #nC command, where
n is the buffer number.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-20 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

3044 Command cannot be executed The command attempts to affect a running
while the program is running ACSPL+ program. Stop the program before
executing the command. To stop a program,
use #nS command, where n is the buffer
number.
3045 Numerical error in standard The command includes a standard function
function that caused numerical error. Check if the
arguments of the function fall into the allowed
range.
3046 Write file error The command has caused writing to the
nonvolatile (flash) memory that failed. A re-
occurring error of this type indicates a serious
problem in the controller hardware or
firmware.
3047 Read file error The command has caused reading from the
nonvolatile (flash) memory that failed. A re-
occurring error of this type points to a serious
problem in the controller hardware or
firmware.
3048 More axes than were defined in The point command specifies more axes than
the motion were specified in the motion that the
command refers to.
3050 Conflict with user-defined axis The command is incompatible with a user-
group defined axis group that was defined before.
The axes specified in the command must
either all belong to one user-defined axis
group, or not to intersect with any user-
defined axis group.
3051 Line number is out of range The command specifies a line number that
does not exist in the specified program buffer.
3052 Buffer number is out of range The command specifies illegal buffer number.
The controller contains the program buffers
numbered from 0 to 9.
3053 Wrong type The command addresses a standard variable
whose type is different from the variable
specified in the command.
The error never occurs when the user
communicates with the controller through a
communication terminal.
The error only when an application
communicates with the controller using the
SPiiPlus C Library. The error indicates
problems in communication.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-21

Error Number Error Name Explanation

3055 Command requires line number The command must contain a line number
specification specification.
3060 Illegal memory command The memory management command is
improperly formatted.
3061 ')' wasn't found The command contains a non-paired left
bracket.
3063 Variable is not defined in the The command addresses a variable that is not
buffer declared in the specified buffer, or the
specified buffer is not compiled.
3064 Undefined global variable The command addresses a global variable that
is not declared in any buffer, or the buffer that
contains the declaration is not compiled.
3065 Command cannot be executed The command is in conflict with one or more
while the current motion is in of the currently executed motions. To kill a
progress motion use the kill or killall command.
3067 GO command failed The controller has no motions waiting for the
go command.
3068 No motion to which this The command specifies an axis, but no motion
command can refer was specified for this axis.
3069 Command is incompatible with The command specifies an axis, but the
the motion specified for this motion specified for the axis is incompatible
axis with the command.
3070 Attempt to add segment after The command attempts to add a segment or a
ENDS command point to the motion that has already been
closed with the ends command.
3071 File name was expected The command must specify the name of an
internal file in the nonvolatile (flash) memory.
3072 Wrong array size The command specifies an array, but the
motion that the command refers to, or other
command arguments require an array of
another size.
3073 Text for search is not specified The command must specify a text for search
operation.
3074 Only standard or SP variable is The command requires a standard or SP
allowed in the command variable name to be specified.
3076 Undefined label The command requires a label specification.
The program that contains the label specified
in the command must be compiled in a buffer.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-22 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

3077 Variable is protected The command attempts to assign a protected
variable when the controller is in protected
mode. The controller must be put in
configuration mode before protected variables
can be assigned.
3078 Variable can be changed only The command attempts to assign a variable
while the motor is disabled that can be changed only if the motor is
disabled.
If the variable is axis-related, disable the
corresponding motor before assigning the
variable.
If the variable is not axis-related, disable all
motors before assigning the variable.
3079 Motion cannot start because one The motion command involves one or more
or more motors are disabled motors that are disabled.
3080 Default Connection flag is set The command cannot be executed because the
for the motor default connection flag is set for the motor.
The default connection flag is bit 17
(symbolic constant #DEFCON) of the
MFLAGS variable.
3081 Incompatible suffixes The command includes suffixes that cannot be
used together.
3085 Extra number after the The command specifies a superfluous
command numerical argument.
3086 Variable name must be specified The command requires a variable name
specification.
3087 Command cannot be executed The command specifies one or more axes that
while the axis is moving are involved in a motion. The command can
be executed only after the motion finishes.
3088 Variable can be queried only in The command attempts to query a variable in
compiled buffer a buffer that was not compiled.
3089 Label can be referenced only in The command attempts to reference a label in
compiled buffer a buffer that was not compiled.
3090 This type of motion is not The slave or track command specifies axis
allowed for grouped axis that was included in a user-defined group.
Only a single axis can be specified in the
slave or track command.
3091 Less arguments than required The motion command specifies less
coordinate values than required by the axis
specification.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-23

Error Number Error Name Explanation

3092 More arguments than required The motion command specifies more
coordinate values than required by the axis
specification.
3093 Bit selector value is greater than The expression specified in the bit selector
31 or less than 0 yields a value greater than 31 or less than 0.
3096 ‘}’ was not found The command includes a non-paired left curly
bracket.
3097 Previous data collection is in The command attempts to start a data
progress collection while the previous data collection
for the same axis is still in progress.
3098 Stalled motion requires limits The motion command, which includes a suffix
specification of stalled motion, requires specification of the
motion limits.
3099 Extra numbers after the The motion command includes superfluous
command numerical arguments.
3101 The program is suspended, the The command attempts to start a program
start line number is not allowed from a specified line when the program is in
suspended state.
A program in suspended state can be only
resumed from the next line. The line
specification is not allowed.
The only way to start a suspended program
from a specific line is to stop the program,
and to start it again from the desired line.
3105 Format error The command is incorrectly formatted.
3106 Error in SP function The function that accesses SP memory cannot
be executed.
Check the address specified in the function
call. The address must fall into the range
0..511.
3108 Invalid real number The command includes specification of a real
number that cannot be interpreted as a valid
real number.
3112 No matches were found The search command did not find any
matches.
3114 The program finished without a The program that is running in a buffer
STOP command executed the last command, and it was not a
stop command.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-24 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

3115 Stack underflow (RET without The program that runs in a buffer caused stack
CALL) underflow.
This occurs if the program executes the ret
command without a paired call command.
3116 Stack overflow (too many The program that is running in a buffer caused
nested CALLs) stack overflow.
This occurs if the program executes two many
nested call commands. Check that the
program does not specify infinite recursion
(subroutine calls itself infinitely).
3117 Attempt to directly enter The program that is running in a buffer comes
autoroutine to the on command.
The on command must never be executed in
the normal program flow.
3118 Axis value is out of range The command specifies an axis by number or
expression, and the resulting value is not a
legal axis number.
Only a result from 0 to 7 can be interpreted as
an axis number.
3120 The motion must involve the The segmented motion must always involve
first two axes from the group two axes. If a user-defined group contains
more than two axes, the segmented motion
must involve the first two axes in the group.
3121 Unknown #-constant The command specifies an unknown symbolic
constant.
3122 Bit selection is not applicable Bit selector cannot be applied to a real value.
3123 Illegal bit selector Value of bit selector must fall into the range
0..32.
3124 Attempt to enable motor failed The enable command failed.
Additional information can be obtained from
the corresponding element of the MERR
variable (motor disable code).
3125 Error in SP program The command caused unsuccessful loading of
an SP program. The file with the SP program
contains an error.
3126 Illegal SP number The command specifies an illegal SP number.
Legal SP numbers are from 0 to 3.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-25

Error Number Error Name Explanation

3127 Editing of this buffer is disabled The command attempts to open the buffer for
editing or to change the program in the buffer.
Editing of a buffer is disabled if bit 1 of the
corresponding element of the PFLAGS
variable is set to 1.
3129 In binary command the name The command syntax requires a name to be
specification must end with / followed by the / (slash) character.
3130 Segment sequence for the Commands mptp, mseg, path, are followed
previous motion was not by a number of the point or segment
terminated with ENDS commands – segment definition sequence.
The segment definition sequence must be
closed with the ends command.
3132 The file is not a legal user data The read command specifies a file in the
file nonvolatile (flash) memory that is not a legal
user data file.
Only the files created with the write
command are legal user data files.
3133 Discrepancy in types of the The array and the user data file specified in
saved and restored arrays the read command contain data of different
types.
The read command must specify an array of
the same type and dimension as the array that
was specified in the write command that
created the file.
For example, the error occurs if a real array
was saved in the file by the write command,
but the read command tries to load the file
into an integer array.
3134 Discrepancy in sizes of the The array and the user data file specified in
saved and restored arrays the read command are of different sizes.
The read command must specify array of the
same type and dimension as the array that was
specified in the write command that created
the file.
3136 Wrong relation between first The interval value specified in the PEG
point, last point and interval command does not correspond to the start and
final points.
For example, the error occurs if the final point
is less than the start point, but the step is
positive.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-26 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

3137 Illegal analog output number The command specifies a number of analog
output which is not available in the controller.
3138 Incompatible SP and analog The command specifies an analog output
output number that cannot be accessed in the
specified SP.
3139 Illegal input The controller tries to interpret the string as a
response to the executed input command but
the string does not follow the required format.
3142 Arguments are inconsistent The command specifies inconsistent
arguments.
Check the following conditions:
• The number of time pulses specified in
the PEG command is positive
• If the number of time pulses is specified
in the PEG command, the time pulse
period also must be specified as a
positive number
3144 Simulator does not support this The command cannot be executed by the
command Simulator.
3145 The specified DPR address is The command specifies a DPRAM address
less than 128 or exceeds the that is out of the available range.
DPR size
3146 Collision with other variable in The command specifies the DPRAM address
DPR that overlaps with other addresses specified in
the previous copyfromdpr or copytodpr
commands.
3149 Illegal SP address The SP address must fall into the range from 0
to 512.
3150 Only even numbers are allowed The command specifies an odd number as a
as DPR address DPRAM address.
3151 This is a DEMO version of The demo version of the Simulator has a
Simulator. 5 minutes of work limited session time. The Simulator is going
remains. to stop after 5 minutes.
3152 The DEMO version of The demo version of the Simulator has a
Simulator has terminated limited session time. The session time has
elapsed.
3154 This command can be used only Commands projection, line, arc1, arc2, and
with MSEG motion stopper apply to mseg motion only.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-27

Error Number Error Name Explanation

3155 Motion cannot start because the In strict mode (S_FLAGS.#FCLEAR = 1)
previous motion failed. Use the motion cannot start after a fault has
FCLEAR command. occurred.
Use the fclear command to clear the result of
the fault.
3201 End-of-Sequence is illegal for The ends command cannot be specified for
this motion this type of motion.
3212 ARC arguments are inconsistent The arc1 or arc2 command specifies
inconsistent arguments. The desired arc
cannot be calculated.
3213 Stopper is prohibited for master- The stopper command cannot be used with
slave motion segmented master-slave motion.
3214 Adjacent stoppers are prohibited Two adjacent stopper commands are not
allowed.
3215 In cyclic path the first and the In a cyclic segmented motion the first point of
last points must coincide the first segment must coincide with the last
point of the last segment.
3216 Velocity is specified, but the Velocity argument can be specified in the
motion command had no V point, line, arc1, arc2 commands only if the
suffix corresponding motion command has specified
suffix v.
3217 Segment of zero length Segments of zero length are not allowed.
3231 Illegal key in The key argument specifies a value that is not
GETCONF/SETCONF supported in this controller.
3232 Illegal index in The index argument specifies a value that is
GETCONF/SETCONF not supported for the specified key.
3233 Illegal value in SETCONF The specified value argument is illegal for the
specified key.
3234 Value in SETCONF must be 0 For the specified key only 0 or 1 are legal in
or 1 the value argument.
3235 SETCONF function is disabled The specified setconf function is disabled in
the current controller mode.
3236 SETCONF cannot be executed The specified setconf function cannot be
while the motor is enabled executed while the motor is enabled.
3253 Unable to work with Dummy The command cannot be executed for a
motor dummy motor.
The addressed motor is configurated as
dummy, see flag MFLAGS.#DUMMY.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-28 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

3254 The operation requires the The command can be executed only while the
motor to be enabled motor is enabled.
3255 The operation requires the The command can be executed only while the
motor to be disabled motor is disabled.
3256 The operation is valid only for The command cannot be executed for any
brushless motor motor type other than brushless.
3257 The operation failed because the The command cannot be executed because the
brushless motor is not involved brushless motor is not commutated.
commutated
Flag MFLAGS.#BRUSHOK reflects the
state of the brushless commutation.
To bring the motor to commutated state the
user needs to execute commut command or a
specific initialization program.
3258 The operation failed because the The command cannot be executed because the
motor is in open-loop mode motor is in open-loop state.
The open-loop state is reported by bit
MST.#OPEN.
The open-loop mode may be caused by setting
flag MFLAGS.#OPEN.
3259 Motion cannot start because the The motion command cannot be executed
motor is defined as dummy because one or more of the involved motors
are dummy.
A motor is configurated as dummy by flag
MFLAGS.#DUMMY.
3260 Motion cannot start because the The motion command cannot be executed
motor is disabled because one or more of the involved motors
are disabled.
3261 Motion cannot start because the The motion command cannot be executed
brushless motor is not because one or more of the involved motors
commutated are not commutated.
Flag MFLAGS.#BRUSHOK displays the
state of the brushless commutation.
To bring the motor to commutated state the
user need to execute commut command or a
specific initialization program.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-29

Error Number Error Name Explanation

3262 Motion cannot start because the The motion command cannot be executed
motor is in open-loop mode because one or more of the involved motors
are in open-loop state.
The open-loop state is shown by bit
MST.#OPEN.
The open-loop mode may be caused by setting
flag MFLAGS.#OPEN.
3263 Motion cannot start because the The motion command cannot be executed
previous motion failed. Use because the previous motion for one or more
FCLEAR command. of the involved motors failed and the strict
mode is set in the controller.
The strict mode is defined by bit
S_FLAGS.#FCLEAR.
Use the fclear command to clear the result of
the fault.
3263 SP program does not support The command is not supported in the current
this operation version of the controller.
Specifically the SP program does not support
the operation. Check if the SP program has
been changed.
5001 Motion generation finished The motion came to the final point and was
successfully completed.
5003 Motion was terminated by user The motion was terminated by the halt
command before the final point was reached
5004 Motor was disabled by user The motor was disabled by disable command The motor was d
5005 Motion was terminated because The motor was disabled by the disable
a motor was disabled command.
5006 Motion was killed The motion was terminated by the kill
command before the final point was reached
5007 Motor was disabled due to a If a generalized fault occurs in an axis, code
generalized fault 5007 is stored in the MERR variable for all
affected axes.
5008 Motion was killed due to a If a generalized fault occurs in an axis, code
generalized fault 5008 is stored in the MERR variable for all
affected axes.
5010 Right Limit The motor was disabled or the motion failed
because of a right limit fault.
5011 Left Limit The motor was disabled or the motion failed
because of a left limit fault.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-30 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

5012 Preliminary Right Limit The motor was disabled or the motion failed
because of a preliminary right limit fault.
5013 Preliminary Left Limit The motor was disabled or the motion failed
because of a preliminary left limit fault.
5014 Overheat The motor was disabled or the motion failed
because of an overheat fault.
5015 Software Right Limit The motor was disabled or the motion failed
because of a software right limit fault.
5016 Software Left Limit The motor was disabled or the motion failed
because of a software left limit fault.
5017 Encoder Not Connected The motor was disabled or the motion failed
because of an encoder not connected fault.
5018 Encoder 2 Not Connected The motor was disabled or the motion failed
because of an encoder 2 not connected fault.
5019 Drive Alarm The motor was disabled or the motion failed
because of a drive alarm fault.
5020 Encoder Error The motor was disabled or the motion failed
because of an encoder error fault.
5021 Encoder 2 Error The motor was disabled or the motion failed
because of an encoder 2 error fault.
5022 Position Error The motor was disabled or the motion failed
because of a position error fault.
5023 Critical Position Error The motor was disabled or the motion failed
because of a critical position error fault.
5024 Velocity Limit The motor was disabled or the motion failed
because of a velocity limit fault.
5025 Acceleration Limit The motor was disabled or the motion failed
because of an acceleration limit fault.
5026 Overcurrent The motor was disabled or the motion failed
because of an overcurrent fault.
5027 Servo Processor Alarm The motor was disabled or the motion failed
because of a servo processor alarm fault.
5035 Program Error The motor was disabled or the motion failed
because of a program error fault.
5036 Memory Overuse The motor was disabled or the motion failed
because of a memory overuse fault.
5037 Time Overuse The motor was disabled or the motion failed
because of a time overuse fault.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 Er r or / D ia g no s t i c 12-31

Error Number Error Name Explanation

5038 Emergency Stop The motor was disabled or the motion failed
because of a emergency stop fault.
5039 Servo Interrupt The motor was disabled or the motion failed
because of a servo interrupt fault.
5060 Driver Alarm: No fault Applies to integrated models only: Drive
alarm: No fault
5061 Drive Alarm: Short Circuit Applies to integrated models only: The motor
was disabled or the motion failed because of
A short circuit condition in the drive. i
5062 Drive Alarm: External Applies to integrated models only: The motor
Protection Activated was disabled or the motion failed because of
an external protection condition in the drive.1
5063 Drive Alarm: Power Supply Too Applies to integrated models only: The motor
Low was disabled or the motion failed because of a
power supply too low condition in the drive.1
5064 Drive Alarm: Power Supply Too Applies to integrated models only: The motor
High was disabled or the motion failed because of a
power supply too high condition in the drive.1
5065 Drive Alarm: Temperature Too Applies to integrated models only: The motor
High was disabled or the motion failed because of a
power supply too high condition in the drive.1
5066 Drive Alarm: Power Supply Applies to integrated models only: The motor
24VF1 was disabled or the motion failed because of a
power supply 24VF1 condition in the drive.1
5067 Drive Alarm: Power Supply Applies to integrated models only: The motor
24VF2 was disabled or the motion failed because of a
power supply 24VF2 condition in the drive.1
5068 Drive Alarm: Emergency Stop Applies to integrated models only: The motor
was disabled or the motion failed because of
an emergency stop condition in the drive.1
5069 Drive alarm: Power-down Applies to integrated models only: The motor
was disabled or the motion failed because of a
power-down condition in the drive.1
5075 Drive Alarm: Digital Drive Applies to integrated models only: The motor
Interface not Connected was disabled or the motion failed because of
an digital drive interface not connected
condition in the drive.1

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 12-32 E rr o r /D ia g n o s t ic

Error Number Error Name Explanation

5100 Current bias measured is out of Applies to integrated models only: At the
range beginning of the enable process the controller
measures the current and calculates an
average bias (offset). If the result is greater
then the predefined maximum value (2% of
maximum output), the controller generates the
error and axis remains disabled.

i
For explanation of the drive-specific errors see the Hardware Guide of the specific controller.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A P PE N D I X A – H o s t C o mm un i c a t i on P r ot o c o l A-33

APPENDIX A – HOST COMMUNICATION

PROTOCOL

The SPiiPlus host communication protocol is designed to provide efficient and reliable command
exchange between a host computer and the SPiiPlus series controllers. The protocol provides two
communication formats: safe and regular.
Safe format is based on block-by-block transfer of data with delivery confirmation. Any binary
information can be transferred in safe format.
The command in regular format is a sequence of ASCII characters with a ‘\r’ (0xD) character at
the end of command.
The SPiiPlus package includes the SPiiPlus C Library, which implements the host communication
protocol and provides a host-based Windows application with a set of high-level functions to
communicate with the SPiiPlus controller via serial link (RS-232), via Ethernet network, and via
PCI bus (and with the SPiiPlus Simulator).
The SPiiPlus C Library relieves the user in most cases of the need to implement the host
communication protocol. The most common case where a programmer might be required to have
knowledge of the host protocol is where the host application will run on a non-Windows
operating system, such as Unix or Linux. In that case, the host application is unable to
communicate via the Windows-based C Library and will have to follow the host communication
protocol described here.

Safe Format
Safe format is not a separate controller mode. Any command can be transmitted to the controller
in safe format. The controller replies to the safe-formatted command also in safe format. The safe-
formatted commands can be mixed with regular formatted commands.
Safe format appears in two variants: with or without checksum. The controller reply follows the
host:

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-34 A PP EN D I X A – H o s t C om mu n i c a t i o n Pr o t o c ol

• If the issued command includes a checksum, the controller will reply with a checksum.
• If the issued command does not include a checksum, the controller will reply without a
checksum.
A command in safe format consists of 4-byte prefix, the command body, and 1- or 5-byte suffix.
Command body is exactly the regular ACSPL+ command with ‘\r’ appended (0xD).
The prefix has the following structure:
Byte 0: Starting frame character
Byte 1: Command ID - any value from 0 to 255.
Bytes 2,3: Command length in bytes (least significant byte appears first). The command
length is the number of bytes in the command body not including the prefix and
suffix.
The suffix has the following structure:
Byte 0: Ending frame character
Bytes 1-4: Appear only in safe with checksum format and contain checksum (least
significant byte appears first).

The checksum is calculated as follows:

• The checksum is calculated for the message body not including prefix and suffix.
• The message body is treated as an array of integer (4-byte) numbers.
• If the length of the message body is not divisible by 4, the last number is supplemented by 1,
2 or 3 zero upper bytes.
• The checksum is a sum of all these integers.
Limitations:
• Length of the body must not exceed 2032 bytes.
• Commands #n (open buffer), #nI (insert), # (close buffer) are not allowed in safe format.
• Commands in safe format that refer to a buffer must specify the buffer number explicitly.
The buffer cannot be open in safe format. Even if a regular command opens a buffer, at the
same time a safe-formatted command sees the buffer as closed.

Safe Format Block

There are several types of safe format blocks:

• Command (any command that is sent to the controller)
• Command with checksum (any command that is sent to the controller)
• Reply (from the controller)
• Reply with checksum (from the controller)

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A P PE N D I X A – H o s t C o mm un i c a t i on P r ot o c o l A-35

• Prompt command (to the controller)

• Prompt reply (from the controller)
• Unsolicited message (from the controller)
• Unsolicited message with checksum (from the controller)

Structure of Safe Format Block

The format of different types blocks is presented in the following table:

Type Prefix Body Suffix Sender

Command <D3><ID><16 bit length> Yes <D6> Host

Command with <DC><ID><16 bit length> Yes <D6><32 bit checksum> “
checksum
Reply <E3><ID><16 bit length> Yes <E6> Control-
ler
Reply with <EC><ID><16 bit length> Yes <E6><32 bit checksum> “
checksum
Prompt command <D9><ID> None None “
Prompt reply <E9><ID> None None “
Unsolicited <E5><ID><16 bit length> Yes <E6> “
message
Unsolicited <EE><ID><16 bit length> Yes <E6><32 bit checksum> “
message with
checksum

Error reply
To determine whether the controller reply contains an error code, the following condition must be
met.
• First character of the reply body is a question mark ‘?’
• Length of the reply body equals six bytes
The error code consists of four ASCII digit characters (0..9) starting with the second character of
the reply body.
Example: Error reply in safe format with error code 3079:

Type Prefix Body Suffix

Error reply <E3><ID>6 ?3079<0D <E6>

>
Error reply with <EC><ID>6 ?3079<0D <E6><32 bit of checksum>
checksum >

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-36 A PP EN D I X A – H o s t C om mu n i c a t i o n Pr o t o c ol

Chains
To send a command exceeding 2032 bytes in safe format, the command must be sent as a chain of
blocks. The maximum number of data characters in each block of chain must be 2032 bytes or
less. The format of each block is the usual safe format, except the following:
each block, except the last, contains 1 in the most significant bit of the third byte of the prefix.
The ID for all blocks in a chain must be the same. Therefore, the prefix of each block, except the
last, has the following structure:
Byte 0: Starting frame character
Byte 1: Command ID for this block - a value from 0 to 255.
Byte 2: Least significant byte of the command length.
Byte 3, bits 0-6: Most significant byte of the command length.
Byte 3, bit 7: Always one (chain flag) except for the last block in the chain where this
bit is zero.
To each block that contains a chain flag the receiver replies with a safe format prompt reply
(<D9><ID> if the receiver is the host or <E9><ID> if the receiver is the controller) confirming
that the block has been received and requesting the next block in the chain. The sender sends the
next block only after receiving the prompt.
The last block in the chain has the same ID as all the other blocks in the chain but no chain flag.
The receiver accumulates all chained blocks.
When a host sends a chain to the controller, after receiving the last block, the controller executes
the command as an entire unit. Then the controller sends a reply to the host, comprising either the
standard prompt in the case of successful completion or an error message in the case of an error.

Unsolicited Message

When a disp or send command executes in the controller’s program buffer, the controller sends
the output as an unsolicited message. (The unsolicited message is not a reply to a terminal
command.)
If bit 4 of the controller variable COMMFL is set, the controller sends unsolicited messages in
safe format. If bit 6 is also set, the unsolicited messages are sent with a checksum.
In safe format the controller adds a prefix and a suffix to each unsolicited message.
Message ID is incremented by the controller so that consecutive messages have consecutive IDs.
The length of an unsolicited message is always equal to or less than 2032.

Binary Commands
Binary commands must not end with the ‘\r’ (0xD) character. The host must send binary
commands in safe format.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A P PE N D I X A – H o s t C o mm un i c a t i on P r ot o c o l A-37

NOTE
Single quotation marks (') are used in the command syntax as notation
delimiters and are not part of the command.

Finding a String
The command searches for a specified string in a controller’s program buffer. The command
returns the line numbers that contain the requested string.

%F'buffer''line''text'
%FI'buffer''line''text'
where

F - specifes case-sensitive search and FI specifies case-insensitive search.

'buffer' - buffer number, one-byte binary.

'line' – number of start line for search, two-byte integer.

'text' - search text, any sequence of bytes.

The controller’s reply to the command consists of sequential short integer values. Each value has
2 bytes; the least significant byte appears first. Each value represents the sequential number of
line that contains matching sequence. The values appear in ascending order.

Finding a Breakpoint
The command provides information about breakpoints in a buffer. The command is a binary
command and has the following structure:
%B'buffer'
‘buffer’ – single byte, contains number of the buffer as binary, not ASCII.
As a binary command, the command must not end with ‘\r’ (0xD) character. The host has to send
binary commands using the safe format.
The controller’s reply to the command consists of sequential short integer values. Each value has
2 bytes, the least significant byte appears first. Each value represents the sequential number of
line that contains a breakpoint. The values appear in ascending order.

Reading/Writing Variables
The command provides read/write to any standard, global or local variable in binary format. The
command is a binary command.
The read command has the following structure:

%?'type''variable_specification'/

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-38 A PP EN D I X A – H o s t C om mu n i c a t i o n Pr o t o c ol

The write command has the following structure:

%>'type''variable_specification'/'value'...
‘type’ – single byte, contains the length, in bytes, of one element of the variable. It must be 4
for an integer variable and 8 for a real variable as binary, not ASCII.

‘variable_specification’ - must be followed by a slash (/) character and has the following
syntax:

['buffer_specifier']'variable_name'['index'['index']]
‘buffer_specifier’ contains the buffer number as an ASCII number followed by a
semicolon (:). The ‘buffer_specifier’ is used only for local variables. Standard and
global variables must be specified without a ‘buffer_specifier’.
The ‘index’ argument is used only with array variables (scalar variables must be specified without
an ‘index’). If an array variable is specified without indexes, all elements of the array are
addressed by the command. The read command (%?) without an index returns the values of all
the elements in the array. The write command (%>) without indexes sets all the elements in the
array and must contain the same number of ‘values’ as there are array elements.)
If only one ‘index’ is given for a two-dimensional array, the ‘index’ addresses a full row of the
array.
The ‘index’ specification has the following syntax:

'index_value'[,'index_value’]
If one instance of 'index_value' is specified, it specifies a single index. If two instances of
'index_value' are specified (separated by a comma), then they specify an index range from the
first to the second value inclusive.
Each index value is a raw binary representation of a short integer (2 bytes). The least
significant byte appears first.
The write command (%>) sets all specified elements and must contain as many values as required
by the ‘index’ specification for the variable argument.
Each value is a raw binary presentation of integer (4 bytes) or real (8 bytes) number, according to
the variable type. The least significant byte appears first. The binary commands must not be
followed by a ‘\r’ character. The host has to send binary commands using the safe format as
specified above.
The controller’s reply to a read command (>%) consists of as many values as required by ‘index’
specifications. Each value is a raw binary presentation of integer (4 bytes) or real (8 bytes)
number, according to the variable type. The least significant byte appears first.

Writing to a Program Buffer

The command stores the text (ACSPL+ program) in the specified controller program buffer. The
command has the following structure:

#nE’text’
n - number of the controller’s program buffer (as an ASCII character),

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A P PE N D I X A – H o s t C o mm un i c a t i on P r ot o c o l A-39

‘text’ - any sequence of characters.

If the buffer already contains a program, the text is appended to the end of the existing program.
The command provides no compilation or syntax check. Normally, the command #nE is followed
by #nC command that performs compilation. To be properly interpreted as a correct ACSPL+
program, the ‘text’ in the command must comply with the following rules:
• The ‘text’ must end with a '\r' (0xD) character. There can be no other instances of this
character in the text.
• Lines in the ‘text’ must be separated by '\n' (0xA) character.
• The last line of the text must also be terminated with '\n' character.

Reading from a Program Buffer

The command reads the text (ACSPL+ program) from the specified controller program
buffer. The command has the following structure:

#nLRn1,n2
n - number of the controller’s program buffer (ASCII characters),

n1 - offset in the buffer (ASCII characters),

n2 - number of characters requested from the buffer (ASCII characters).

The controller response includes the requested number of characters followed by the usual
prompt. The first sent character is a character located in position n1 of the buffer. The number of
the sent characters can be less than n2, if the end of the buffer was achieved before n2 characters
were retrieved.

Managing Files
SPiiPlus controllers have flash (nonvolatile) memory, which retains data when the power is off.
This memory has a file system organization and keeps the firmware files, files of user application
and etc.
The following commands manage the files in the controller’s flash memory:

#TR/'path'/ Read file

#TW/'path'/'data' Write file

#TC/'path'/ Clear file

For details about the flash memory file structure, please contact ACS Motion Control support
(support@acs Motion Control.com).
The #TR command causes the controller to send the contents of the specified file from the flash to
the host.
For example, the command
#TR/C:\SB4\STARTUP\PAR.$$$/
transfers the system parameters from the controller’s flash memory to the host.

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-40 A PP EN D I X A – H o s t C om mu n i c a t i o n Pr o t o c ol

The #TW command causes the controller to create the specified file in the flash and to write the
attached data to the file. If the file already exists in the flash, the data is appended to the end of the
existing file.
The data written to the file is attached to the command. If the command is transmitted in safe
mode, the data can be a binary data. As with many of the other controller commands, the
command must end with a ‘\r’ (0xD) character. This ‘\r’ character is not considered a part of the
data and is not written to the file.
The #TC command causes the controller to delete the file in the flash.

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 A pp e n d i x b - P r e vi o us R e l e a s e N o t e s A-41

APPENDIX B - PREVIOUS RELEASE NOTES

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

 I nd e x A-12-1

INDEX

#RESET, 4-42
—#—
#RL, 8-18
#AL, 8-30
#SAVE, 4-38
#CL, 8-31
#SAVEPAR, 4-39
#CLEAR, 4-42
#SAVEPROG, 4-39
#CPE, 8-24
#SAVESP, 4-39
#DRIVE, 8-28
#SLL, 8-20
#ENC, 8-26
#SP, 8-32
#ENC2, 8-26
#SRL, 8-20
#ENC2NC, 8-27
#TIME, 8-36
#ENCNC, 8-27
#U, 4-21
#ES, 8-33
#VL, 8-29
#HSSINC, 8-33
#HWRES, 4-42 —&—
#INT, 8-37 &, 5-72, 9-4
#LL, 8-18
—(—
#LOAD, 4-40
(peg_i command, 7-9
#LOADPAR, 4-41
—^—
#LOADPROG, 4-40
^, 5-72
#MEM, 8-35
#PE, 8-22 —|—
#PROG, 8-34 |, 5-72, 9-4

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-12-2 I nd e x

—A— avg, 5-38

abs, 5-28 axis
acceleration, 3-28 leading, 3-17
acos, 5-29 Axis designation, 5-10
ACSPL+ axis group, 3-17, 3-18
commands, 3-8 axis management commands, 5-103
ACSPL+ application axis number, 4-39, 4-41
protection, 4-21 axis position
all, 5-10 transforming, 3-23
analog I/O, 9-8 axis status
and, 5-72, 9-4 query, 4-25
APOS, 3-17, 3-23
—B—
set, 5-110
background tasks, 3-3
application
backlash, 5-114
loading, 4-40
backlash compensation, 5-51
protection, 4-21
bit assignment, 5-80
saving, 4-38
bit selection operator, 5-73
arbitrary path motion, 6-20
bitwise operators, 5-72
arc1 command, 6-34
break, 3-27
arc2 command, 6-34
break command, 5-117
arguments, 5-24
buffer, 4-6, 5-6
arithmetical
closing, 4-7
functions, 5-28
dynamic, 5-6
arithmetical operators, 5-71
editing, 4-7
array, 5-16, 5-17, 5-18, 5-19, 5-20, 5-21, 5-22, 5-
listing, 4-6
24, 5-25
opening, 4-7
indexing, 5-20
priveleged, 5-127
arrays, 5-20
state, 4-14
query, 4-27
buffers, 3-8, 4-3
asin, 5-29
dynamic, 3-9
assignment, 5-11, 5-15, 5-16, 5-25, 5-78
atan, 5-30 —C—
atan2, 5-30 call command, 5-86
AUTOEXEC, 5-10 ceil, 5-31
autoroutines, 5-4, 5-92, 9-5 CFG, 5-126

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 I nd e x A-12-3

changes configuration variables, 4-36, 4-37, 4-38, 4-39,

4-40, 4-41, 4-42, 5-15, 7-20
acceleration, 3-28
connect command, 5-112
jerk, 3-28
connections
on the fly, 3-27
plant, 3-10
velocity, 3-28
controller cycle, 3-3
changes on the fly, 3-27
controller resources, 3-7
class, 5-13
controller version
Class, 5-12
query, 4-24
closing
conventions, 1-4, 5-9, 5-12
buffer, 4-7
conversion, 5-16
codes
type, 5-80
error, 12-1
copyfromdpr, 5-103, 10-6
command
copytodpr, 10-6
terminal, 3-8
copytodpr command, 5-103
command code, 4-3
cos, 5-31
commands, 3-7, 5-74
current loop
ACSPL+, 3-8
variables, 11-7
axis management, 5-103
cyclic motion, 6-18, 6-40
interaction, 5-99
miscellaneous, 5-121 —D—
motor management, 5-103 data collection, 7-1
nonvolatile memory, 5-122 variables, 11-4
program flow, 5-81 dc, 5-121
program management, 5-96 deadzone, 5-38
structure, 4-2 debugging, 4-18
synchronization, 5-90 declaration
commutation variables, 5-17
variables, 11-7 depends command, 5-112, 5-113
compare operators, 5-72 digital I/O, 9-1
compensation, 5-114 digital inputs/outputs, 3-15
compile error, 5-18 digital outputs
compiling, 4-15 host controlled, 10-9
concurrency, 3-25 dimension, 5-20
configuration direct transform, 3-13
variables, 11-5 disable command, 5-104

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-12-4 I nd e x

disableon command, 5-98 execution, 5-6

disp command, 5-99 immediate, 5-1
DPRAM rate, 5-6
allocation for global user variable, 10-9 exp, 5-32
example, 10-9, 10-11 explicit declaration, 5-13, 5-14, 5-17, 5-18
dsign, 5-40 expression, 5-21, 5-22, 5-23, 5-24, 5-25
dynamic expressions, 5-68
buffer, 5-6
—F—
dynamic buffer, 3-9
factory default, 4-36, 4-37, 4-38, 4-41, 4-42
—E— fault, 8-17
edge, 5-41 integrity, 4-20
editing, 4-7 faults, 8-2, 8-3, 8-9, 8-18
enable command, 5-104 fclear command, 5-108
enableon command, 5-98 feedback position, 5-20, 5-22, 5-25
encoder feedback transform, 3-13
error compensation with constant step, 5-50 filter
sin-cos, 7-15 sin-cos encoder, 7-16
sin-cos multiplier, 7-15 firmware, 3-2, 3-4, 5-14
encoder error, 5-114 firmware tasks, 3-2
ends command, 6-13 flash memory, 3-10
ends command, 6-34 floor, 5-32
error formatting
codes, 12-1 queries, 4-34
detection, 12-3 function
indication, 12-3 signal-processing, 5-50
reference, 12-5 functions, 5-26
ERROR, 12-1 arithmetical, 5-28
examples miscellaneous, 5-56
arbitrary path motion, 6-22 Servo Processor (SP), 5-53
autoroutines, 5-94 signal processing, 5-38
signal-processing function, 5-50 statistical, 5-37
exclamation mark, 5-12
—G—
exclusion, 5-4
gantry, 5-113, 5-114
executing, 4-16
gear ratio, 5-114
programs, 5-1

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 I nd e x A-12-5

general purpose index, 3-14, 5-24

variables, 11-3 index specification, 5-20
getconf, 5-58 indexing, 5-20
getsp, 5-53 arrays, 5-20
global initialization, 4-36, 4-37, 4-38, 4-39, 4-40, 4-41,
4-42
variables, 5-17
input, 5-57
global scope, 5-13
input/output
global user variables
variables, 11-4
DPRAM allocation for, 10-9
inputs, 9-1
global variables, 5-26
digital, 3-15
global-scope variable, 5-13
safety, 3-14
glossary, 2-1
integer
go command, 5-116
variables, 5-16
goto command, 5-88
integrity control, 4-20
group
interaction commands, 5-99
axis, 3-17
interrupt, 5-103
group command, 5-111
interrupts, 7-17
—H—
intgr, 5-42
halt command, 5-117
inverse kinematics, 5-114
hardware interrupts, 7-17
ISENA variables, 7-21
hardware structure, 3-1
—J—
high speed serial interface, 3-16, 9-7
jerk, 3-28
HSSI, 3-16, 9-7
jog command, 6-9
hypot, 5-32
jogging, 6-9
—I—
multi-axis, 6-10
I/O
joystick, 5-52
analog, 9-8
—K—
digital, 9-1
key words, 5-9
IENA variable, 7-20
Keywords, 5-9, 5-10
if-else control structure, 5-81
kill command, 5-106
imm command, 5-118, 5-119
killall command, 5-106
immediate execution, 5-1
kinematics, 5-114
IN, 9-3
incremental PEG, 7-9

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-12-6 I nd e x

—L— mark, 3-14

label, 5-10 master, 6-31
lag, 5-43 formula, 3-17
ldexp, 5-33 master command, 3-17
leading axis, 3-18 master-slave, 6-30
leading axis, 3-17 master-slave motion, 3-17, 3-22
lifetime, 5-14 matrices, 5-20
Lifetime, 5-13 matrix, 5-16
line command, 6-34 max, 5-37
line qualifier, 4-4 memory
listing nonvolatile, 4-36, 5-20
buffer, 4-6 nonvolatile (flash), 3-10
program, 4-5 memory initialization, 4-36, 4-37, 4-39, 4-40, 4-
41
loading
min, 5-37
application variables and SP data, 4-40
miscellaneous
local, 5-12, 5-13, 5-14, 5-17, 5-18, 5-19, 5-20, 5-
21, 5-23 functions, 5-56
variables, 5-17 miscellaneous commands, 5-121
local scope, 5-14 monitoring
Local variables, 5-26 variables, 11-4
local-scope variable, 5-14 monsp, 5-54
log, 5-33 motion, 3-16, 3-25, 6-1
log10, 5-34 generation, 3-17
logical motion, 5-114 master-slave, 3-17
logical operators, 5-72 overview, 3-17
loop control structure, 5-84 physical aspects, 3-22
loop structure, 5-11 queues, 3-26
variables, 11-2
—M—
motion command, 3-27
machine coordinates, 5-114
motion profile, 3-19
machine slides, 5-114
motion sequencing, 3-25
map, 5-45
motion state, 3-24
map2, 5-47
motor management commands, 5-103
map2free, 5-48
motor states, 3-23
mapby1, 5-45
motor status
mapby2, 5-46

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 I nd e x A-12-7

query, 4-25 incremental, 7-9

mpoint, 6-18, 6-21 random, 7-10
mpoint command, 6-13 synchronous and asynchronous, 7-8
MPOS, 3-17 termination, 7-12
mptp, point, mpoint, and ends command, 6-13 peg_r command, 7-10
mseg command, 6-34 persistent variables, 5-15, 5-19
multipoint motion, 6-13 physical motion, 5-114
plant
—N—
connection, 3-10
nonvolatile memory, 3-10, 4-36, 4-37, 4-38, 4-
39, 4-40, 4-41, 4-42, 5-20 PLC, 9-6
nonvolatile memory commands, 5-122 point, 6-18, 6-21
point command, 6-13
—O—
point to point, 6-1
on command, 5-92
multi-axis, 6-3
opening
polar kinematics, 5-114
buffer, 4-7
Position Event Generation, 5-121, 7-7
open-loop operation, 6-42
position lock, 6-33, 6-41
operands, 5-71
position loop
operators
variables, 11-8
arithmetical, 5-71
pow, 5-34
bit selection, 5-73
power up, 3-10
bitwise, 5-72
power-up, 4-36, 4-37, 4-40, 4-42
compare, 5-72
prefix, 5-21
logical, 5-72
privileged
unary, 5-73
buffer, 5-127
or, 5-72, 9-4
program, 3-25, 4-1, 4-5, 4-14
orthogonality, 5-114
buffer, 4-14
OUT, 9-3
compile, 4-15
outputs, 9-1
debugging, 4-18
digital, 3-15
editing, 4-7
—P—
executing, 4-16, 5-1
path, 6-20
execution, 4-14
pause command, 5-98
execution control variables, 11-3
pausing, 4-17
flow commands, 5-81
PEG, 5-121, 7-7
listing, 4-5

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-12-8 I nd e x

pausing, 4-17 read command, 5-122

protection, 5-127 read-only, 5-13, 5-15, 5-20, 5-25
stopping, 4-16 read-write, 5-13, 5-15
stored, 5-1 real
program buffers, 3-8 variables, 5-16
program management commands, 5-96 real-time tasks, 3-3
program rate, 5-21 REFERENCE
program status query, 4-25 errors, 12-5
projection command, 6-34 STANDARD VARIABLES, 11-1, 11-14
protected, 5-13, 5-15, 5-25 report
protection, 4-21, 5-124 integrity, 4-20
PTP real-time usage, 4-21
host initiated, 10-11 safety configuration, 4-22
ptp command, 6-1 Reset, 5-14
pvspline, 6-24 resources
controller resources, 3-7
—Q—
resume command, 5-98
queries, 5-14
ret command, 5-86
query, 4-23
roll, 5-49
arrays, 4-27
RPOS, 3-23
axis status, 4-25
controller version, 4-24 —S—
formatting, 4-34 safety
motor status, 4-25 configuration, 4-22
program status, 4-25 safety control
serial number, 4-24 variables, 11-4
SP variables, 4-33 Safety ControL, 8-1
standard variables, 4-27 safety inputs, 3-14
user arrays, 4-30 sat, 5-49
user variables, 4-30 saving
vs. disp and send, 5-102 application variables and SP data, 4-38
queues scalar, 5-16, 5-17, 5-18, 5-20, 5-21
motion, 3-26 scope, 5-13
Scope, 5-12
—R—
searching, 4-10
random PEG, 7-10
segmented motion, 6-34

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 I nd e x A-12-9

send command, 5-102 split command, 5-111

serial number splitall command, 5-111
query, 4-24 sqrt, 5-35
servo loop stalled motion, 6-33
variables, 11-7 standard
Servo Processor variables, 4-12
functions, 5-53 standard variables
servo tick, 3-3 alphabetical list, 11-9
set command, 5-109 reference, 11-14
setconf, 5-58 standard variables, 3-9, 5-10, 5-13
setprotection command, 5-124 assignment, 5-79
setsp, 5-55 loading, 4-40
sign, 5-36 query, 4-27
signal processing REFERENCE, 11-1
functions, 5-38 saving, 4-38
signal-processing function examples, 5-50 Standard variables, 5-13, 5-17
sin, 5-35 start command, 5-96
sin-cos encoder, 7-15 state
filter, 7-16 variables, 11-1
sin-cos encoder multiplier, 7-15 statistical
slave, 6-32 functions, 5-37
slaved motion, 6-30 Stop, 5-14
slaved segmented motion, 6-40 stop command, 5-97
smoothness, 6-39 stopall command, 5-97
software interrupt tags, 7-19 stopcopytodpr, 10-8
software interrupts, 7-18 stopcopytodpr command, 5-103
software overview, 3-1 stopdc, 5-121, 7-6
SP stoppeg command, 7-12
functions, 5-53 stopper command, 6-34
variables, 4-13 stoppers, 6-39
SP data, 4-36, 4-37, 4-39, 4-40, 4-41, 4-42 stopping, 4-16
SP variables stored program, 5-1
loading, 4-40 strict, 8-17
query, 4-33 synchronization, 5-4, 6-32
saving, 4-38 synchronization commands, 5-90

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2

A-12-10 I nd e x

syntax, 5-9, 5-12 query, 4-30

sysinfo, 5-56 saving, 4-38
user-defined units, 3-12
—T—
tan, 5-36 —V—
tasks variable
real-time and background, 3-3 global-scope, 5-13
Terminal, 5-15, 5-19 local-scope, 5-14
terminal command, 3-8, 5-13, 5-14, 5-15, 5-19 variables, 4-12, 5-12, 5-23, 7-20
the scope-specification, 5-17 commutation, 11-7
tick configuration, 11-5
servo, 3-3 current loop, 11-7
till command, 5-91 data collection, 11-4
time-based motion, 3-19 declaration, 5-17
tools, 3-4 general purpose, 11-3
torque control, 6-42 global, 5-17
Track, 6-10 input/output, 11-4
transform integer, 5-16
direct and feedback, 3-13 local, 5-17
transforming axis position, 3-23 monitoring, 11-4
type conversion, 5-80 motion state, 3-24
type-specification, 5-17 position loop, 11-8
program execution control, 11-3
—U—
protection, 5-126
unary operators, 5-73
real, 5-16
update, 5-17
safety control, 11-4
user
servo loop, 11-7
variables, 4-13
SP, 4-12
user application, 3-4
standard, 4-12, 11-1
user arrays
state, 11-1
query, 4-30
user, 4-12
user units, 3-24
velocity loop, 11-8
user variables, 3-10, 5-12, 5-13, 5-14, 5-16, 5-
17, 5-23, 5-25 velocity, 3-28
assignment, 5-79 velocity lock, 6-33, 6-41
extended syntax for DPRAM, 10-9 velocity loop
loading, 4-40 variables, 11-8

SP i i P l u s A C S PL + P ro g ra m me r ' s G ui de - D o c u me n t r e v i s i o n n o . 4 . 2 2
 I nd e x A-12-11

—W— write command, 5-122

wait command, 5-90
—X—
while control structure, 5-83
xor, 5-72

SPi iPl us A C SPL + Pr o gr a mmer 's Gu id e - D o c um e n t r e vi s i o n no . 4 . 2 2